Stoiko Ivanov [Thu, 27 Jun 2019 18:27:57 +0000 (20:27 +0200)]
add efiboot and autoremoval kernel postinst hooks
In order to add support for booting with ZFS on Root on EFI systems this
patch uses systemd-boot as boot loader.
The rationale for not using grub is that there have been quite a few problems
observed with grub and ZFS, e.g. certain RAID-controllers only having a 32bit
implementation in grub, but ZFS writing the kernelimage or initrd after 2TB
rendering a system unbootable.
Additionally grub only supports a certain subset of zpool features, which
either forces users to not use newer features, or to create an additional small
boot-pool, with the reduced feature set (which seems currently the suggestion
from ZFS-upstream [0,1]).
the kernel-hook scripts are adapted from debian's versions for:
* marking kernels as NeverAutoRemove (/etc/kernel/postinst.d/apt-auto-removal)
* calling update-grub (/etc/kernel/postinst.d/zz-update-grub)
* generating systemd-boot loader entries
(/usr/lib/kernel/install.d/90-loaderentry.install)
the list of kernels kept installed and configured for booting with systemd-boot
contains:
* the currently running kernel
* the kernel being installed
* the 2 newest kernels (determined by package-name, i.e. ABI-version)
* the latest kernel from each series (e.g. 4.13, 4.15, 5.0) by keeping the
respective meta-packages installed
the implementation diverges from systemd's boot loader specification [0] in the
following places:
* adding support for multiple ESPs - all bootable disks of a RAID get configured
with an 512M ESP - the hookscript installs the kernels to all of them
* the ESP(s) are not kept mounted, rather they get mounted and umounted by
the script:
* Should the system crash, this should make sure that the ESPs fs does not get
corrupted
* Keeping it mounted results in a boot-error, if the ESP, which is usually
mounted is not available (because the disk died)
* kernels and initrds get installed into 'EFI/proxmox/$kver' instead
of '$machineid/$kver'
Since copying the necessary kernels needs a logic for cleaning up space in
the ESP, this presents an opportunity to also be more selective about which
kernels are marked as NeverAutoRemove, instead of keeping all versions installed
which results in full disks for our users occasionally.
since this happens quite regularly when users accidentally install
conflicting packages.
sample output:
$ apt remove pve-qemu-kvm
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
libxml-libxml-perl proxmox-widget-toolkit pve-edk2-firmware pve-i18n pve-xtermjs
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
proxmox-ve pve-container pve-ha-manager pve-ha-manager-dbgsym pve-manager pve-qemu-kvm qemu-server spiceterm
0 upgraded, 0 newly installed, 8 to remove and 0 not upgraded.
After this operation, 37.6 MB disk space will be freed.
Do you want to continue? [Y/n] y
W: (pve-apt-hook) !! WARNING !!
W: (pve-apt-hook) You are attempting to remove the meta-package 'proxmox-ve'!
W: (pve-apt-hook)
W: (pve-apt-hook) If you really you want to permanently remove 'proxmox-ve' from your system, run the following command
W: (pve-apt-hook) touch '/please-remove-proxmox-ve'
W: (pve-apt-hook) and repeat your apt-get/apt invocation.
W: (pve-apt-hook)
W: (pve-apt-hook) If you are unsure why 'proxmox-ve' would be removed, please verify
W: (pve-apt-hook) - your APT repository settings
W: (pve-apt-hook) - that you are using 'apt-get dist-upgrade' or 'apt full-upgrade' to upgrade your system
E: Sub-process /usr/share/proxmox-ve/pve-apt-hook returned an error code (1)
E: Failure running script /usr/share/proxmox-ve/pve-apt-hook
projects / proxmox-ve.git / log