将pebuilder变成dibuilder.sh,将di tools集入boot层(4):打包pve debs，利用pve代替pd打造你的bearmetal多os系统并集入boot

本文关键字：sed 部分替换,debootstrap多源处理，merge multiple deb source into 1

在《将pebuilder变成dibuilder.sh,将di tools集入boot层(2):发明minstack live os》中，我们讲到了针对单个deb repo路径进行debootstrap打包差异化部分，产生宏deb的的操作，在那文中，其本质是“利用dpkg -e加后配置脚本代替apt，使apt动态配置包变成静态包+后配置脚本”，为了这种极致化目的，我们甚至用ar代替dpkg -e，甚至都不用到dpkg -i，这一切都是为了让deb包的处理变得足够portable：

这里有二个处理，1，借助工具，从网上的debian源出发，在本地建立一个部分源，2，借助dibuilder.sh，将这些源重新remastering形成新发行版。
这些处理最终遗留了二个大问题，1，我们的操作是针对单个deb repo进行的，而现实(apt)的情况是，一个系统往往是针对多个仓库（/etc/apt/sources.list/sources.d）条目进行的update/install，debootstrape只允许你指定一个，2，我们没有解决依赖问题。（3，也许还要算上3，我们的后配置脚本是排除了control/preinstall脚本的，这个应该无法避免，除非我们保留源差异化deb包，而且这种包并不能dpkg -i安装，因为它不能像升级包一样去掩盖（类似mount -o）同位置下的文件，会提示之前的包已经将文件放到那个位置了。）4,上文中，我们采用netiso作为基包测试debootstrap，但实际上我们应该用tdl-initramfs作为基包。而不是一个iso。不过，使用iso的结果也是正确的。但我们是以tdl-initramfs作为基础remastering发行的，所以最好用后者。

废话不多说。下面讲述整理一个pve-initramfs所需的debs，得到其基础包的过程(至于后配置和解决依赖的部分，以后有机会再强化吧)，开始！

1，得到pve debs

上文求得xorg基础包用的是debootstrape，debootstrap要求一个单一的mirror url，而我们现在面临多源多库的情形：

我们把single suite/codename/release->compent->arch的路径叫做一个源，这就是debootstrape最后那个参数指定的mirror url,形如：

Suite: oldoldstable
Version: 8.11
Codename: jessie    我们把它称为源
Date: Sat, 06 Jul 2019 09:36:16 UTC
Architectures: amd64 armel armhf i386
Components: main contrib non-free    我们把它称为库

一般，一个debian镜像点会维护三个连续的版本，一个是oldoldstable，一个是oldstable，一个是stable，由于debian进化到了10，那个oldoldstable就是jessie8，jessie只是oldoldstable的链接。
而一个正常的debian版，不光是http://mirrors.xxx.com/debian/ jessie main这里的内容，还有http://mirrors.xxx.com/debian-security/ jessie/updates main这里的内容，比如，按aliyun它的镜像添加教程，应该是这二条：

deb http://mirrors.aliyun.com/debian/ jessie main
deb http://mirrors.aliyun.com/debian-security/ jessie/updates main

(代表一个源库的就是源release中指定的各个库的packages/packages.gz/packages.bz2文件，你/etc/apt/sources.list写好源库配置，sudo apt-get update后，packages中的软件条目会写入/var/lib/apt/lists，下面实践一下，
首先将上面二条源库配置写入。然后：
sudo rm -rf /var/lib/apt/lists/*
sudo rm -rf /var/lib/apt/lists/partial/*
上面命令为了解决可能出现的waitting headers，也是为了清空上次的安装信息源库数据库。
再sudo apt-get update;sudo apt list | wc -l，在一个纯粹的debian netinstall iso安装出的系统中，会得出42000多条软件包记录，包括系统已安装，待安装等,即使/var/lib/apt/lists没任何内容，sudo apt list也是能显示已安装的包的[installed,local]）

而我们要的效果是，在这个netinstall iso中安装出的本地虚拟机系统中，我们需要维护一个由mirrors.aliyun.com产生的本地子源，以使得我们能利用/etc/apt/sources.list中单条deb http://10.211.55.2:8000/downloads/mirrors/debian jessie main main-security-updates pve-no-subscription，就足以能支持安装完sudo apt install --no-install-recommends proxmox-ve（main-security-updates实际上就是release文件中把debian-security/ jessie/updates main作为debian的子库整合进来之后的效果，而proxmox-ve，是http://download.proxmox.com/debian/pve/dists/jessie/整合进来的子库效果）。

这个操作的背后逻辑是：http://10.211.55.2:8000/downloads/mirrors/debian jessie main main-security-updates pve-no-subscription，这三个源main main-security-updates pve-no-subscription整合进来之后，对应的packages是要保证其正确性的，否则apt-update之后，它不会提示你安装，而仅会提示你说“deps unmet，依赖未达到”，意思就是说你提供的源是不健全的是坏的，而在配合以前的dibuilder.sh脚本中，为了能使文件名中包含+,~的deb包名能做在onedrive中被hosting，我们修改和定制了release文件和packages/paackages.gz文件，由于这些文件的修改当初仅预设作为配合dibuilder.sh中简单的remastering，所以并没有太多考虑（比如它所在的源其实不支持apt-get，也不好用于debootstrape），里面经过修过的文件当然不能放在/etc/apt/sources.list中用(自然会导致deps unmet),而我们现在想使之正确用于debootstrape和apt-get，放在sources.list中使用（支持sudo apt install --no-install-recommends proxmox-ve）。

所以我们要重新提供正确的packages版本，直接从http://mirrors.aliyun.com/debian/dists/jessie/main/binary-amd64/Packages.gz https://mirrors.aliyun.com/debian-security/dists/jessie/updates/main/binary-amd64/Packages.gz http://download.proxmox.com/debian/pve/dists/jessie/pve-no-subscription/binary-amd64/Packages.gz下载截止目前最新的pakcages再经过如下处理即可（暂时不需要一开始就涉及到下载debs）：

我们一步一步来：

(我们之前在dibuilder.sh是严格按官方路径存放debs的，现在我们统一将debs放到dists下下级的目录中：这样更合理，因为我们是求得一个定制源的子库------ 基于此，我们来修改获得packages)

cat Packages | sed -e 's/Filename: .*//Filename: /g' > NewPackages （首先把路径去掉）

然后把三个packages中的路径都修改为各自的dists/jessie/main/binary-amd64/deb/下，dists/jessie/main-security-updates/binary-amd64/deb/下，和dists/jessie/pve-no-subscription/binary-amd64/deb/下，这个/deb/的上级也可以放各自dists的vmlinuz,cdl-initramfs,tdi-initramfs，grub files等等，------ 将索引逻辑仅保留在packages中单独编辑，deb文件全部无层次，这样维护方便。由于我们的发行版是部分拉取总库形成的，这样文件夹中不会有大量文件其实也合理。dibuilder.sh对应下载数组/下载/解压逻辑处要改一下

然后，cat Packages | sed 's/(Filename: .)+(..deb)/\1-\2/' | sed 's/(Filename: .)+(..deb)/\1-\2/' | sed 's/(Filename: .)~(..deb)/\1-\2/' > NewPackages (第一次替换+号后，还有少许+号残留，最后一次替换~，你其实可以在上面输出为NewPackages前 | grep "Filename: " 查看验证结果)

然后在本地wc -c Packages,md5sum,sha1sum,sha256sum Packages，用得出的结果修改Releases

这样packages就修改完成了，用deb http://10.211.55.2:8000/downloads/mirrors/debian jessie main main-security-updates pve-no-subscription写的sources.list在sudo apt install --no-install-recommends proxmox-ve时能出现正确的提示而不是deps unmet了。

然后是得到main-security-updates与pve-no-subscription的debs，main的我们在前面已经通过debootstrape得到过了。把源库配置恢复为aliyun.com的二条，pve的用deb http://download.proxmox.com/debian/pve jessie pve-no-subscription

sudo rm -rf /var/cache/apt/archives/*
sudo apt install -y --download-only --force-yes --no-install-recommends proxmox-ve > 2.txt (由于这是多源结构不可能用debootstrap之类的工具，这条拿掉2.txt，会提示2个升级，161个新装，共163个包要下载到/var/cache/apt/archives中去)

提取debs:

(main的新加部分90个)mkdir main-deb;cat 2.txt |  grep http://10.211.55.2:8000 | awk '{print $4,$6,$5}'| sed -e 's/ /_/g' | sed -e 's/:/%3a/g' |while read line; do sudo cp -f /var/cache/apt/archives/$line.deb main-deb; done
（security的部分35个）mkdir sec-deb;cat 2.txt |  grep http://mirrors.aliyun.com/debian-security ....
（pve的部分38个）mkdir pve-deb;cat 2.txt |  grep http://download.proxmox.com/debian ....

实际测试用deb http://10.211.55.2:8000/downloads/mirrors/debian jessie main main-security-updates pve-no-subscription安装sudo apt install --no-install-recommends proxmox-ve。

首先是修改/etc/hosts，只需要修改或加入一条，本地公网IP 对应主机名，之后hostname --ip-adress能得到那个公网IP就行了，这步是必要的，否则会在安装配置处出错。提示E: Sub-process /usr/bin/dpkg returned an error code (1)，网上安装pve的教程的其它部分可以忽略。

重新启动，pve 在 grub advanced 4.4.134-1，也是默认的第一条，但是点开用advance原来的3.0.16也可以，所以我们完全可以从90m的pve-deb结果中排除二个大deb，得到约20m的pve结果。

2，得到pve的意义：代替虚拟boot作暂代方案。用pve/lxc代替openfaas/container

第一部分实际上就是利用pve实质上就是一些debian包的本质来完成的：

Proxmox VE ships as a set of Debian packages, so you can install it on top of a standard Debian installation. After configuring the repositories Section 3.1, you need to run: apt-get update apt-get install proxmox-ve，及https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_Stretch这样的教程。

这个好处较exsi这种从内核开始封闭生产的系统大了去了：它可以用于作为我的暂代方案。

其实这个想法很久了，最初是为了实现parallels boot+oslevelvm app level vm in 1+guestos=all in the boot，后来它发展我的整个方案:一个企图将统一语言统一平台统一开发组成的最小开发栈实现做入boot的方案，这种子系统，虚拟机，app容器合一的架构特性保证了虚拟到各os的app共享同样级别的virutal appliance基础(甚至硬件统一)
在实践中，想用virtual boot firmware+libos做，发现难度较高，业界对此方案的支持处在早期，故现在转为基于linux普通方式做。在《一个统一的parallel bootloader efi设想:免PE，同时引导多个系统》和《一种虚拟boot作通用bootloader及一种通用qemu os的设想》开始一直是这种思路的尝试。在群晖等bearmetal上折腾过，甚至想买个裸金属云服务器折腾。
故目前的实现仅是采用某些方案的一个暂代，仅介绍在云主机上安装pve和各种常见和专用qemu的unix系云OS

更多考虑：

pve更像是一个debian dists。而不是一个deb bundle。当然它也可以做成xorg的宏deb包。不过这不是我的方向，make tdl-initrd-pve才是。所以只要在仓库中维护可remastering to dists的包就好了，不要宏包化加静态加后配置（这个仅适合cdi集成，其实这个是为了cdi考虑的，并不一开始考虑用在xorg包宏化上面），
为什么不使用Qubes os。。因为它是基于xen过时的。而pve同时有OS级虚拟（kvm）和OS内APP虚拟(lxc)
而且lxc container template完全可以用packer或debootstrap生成。免去用docker-cli这样的东西生成。甚至可以将minstackos装在云端，生成sket脚手架镜像用。
为什么选择4而不是更高版？
虽然Support for Proxmox VE 4.4 ends on June 30, 2018，但我们为了与以前兼容还是用jessie pve
另，pve 4的刚好没有lvm。thin lvm有个好听的名字叫精简置备,比qcow2这种更有优势，但local storage更适合调试和初级使用。

无论如何，我们安装了pve，就实现了用云主机支持快照的方式使用本地osle，在不支持再虚拟化的云主机上,lxc式的容器更容易instant commit，甚至未来我们将其单盘化装在mbp的分区中，裸金属方向使用mbp搭建pve云（附带解决mbp下无线网卡不可用，开机亮度过高这些debian在mbp上的安装使用问题）。

标签：jessie,boot,apt,pve,集入,deb,main,debian
来源： https://www.cnblogs.com/minlearn/p/14394880.html