If the system seems to be using proxmox-boot, simply run it, in
addition to warning the user about the situation.
Since the warning is only printed when update-grub is not called
by dpkg or proxmoxmox-boot-tool, this should be safe, and potentially
help keeping systems bootable.
Suggested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
if a (legacy) system is booted with proxmox-boot-tool, running
`grub-install` without being aware of the fact can render the system
unbootable (e.g. when letting the early stage point to an incompatible
zpool instead of the ESP).
To prevent this we add a dpkg-diversion [0], which simply checks if
`proxmox-boot-tool status` indicates that proxmox-boot is used and
errors out in that case, and runs the actual grub-install else.
Co-authored-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
If the system seems to be booted using proxmox-boot, write a header at
the beginning of the grub.cfg generated when running `update-grub`
Additionally print a warning in case the script is run interactively.
This is determined by checking for DPKG_VERSION, which is set when
running as post-inst task (after a kernel install/removal)
and for PVE_EFIBOOT_UNSHARED, which is set by proxmox-boot-tool when
running `proxmox-boot-tool refresh.`
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
This patch adds support for booting non-uefi/legacy/bios-boot ZFS
installs, by using proxmox-boot-tool to copy the kernels to the ESP
and then generate a fitting grub config for booting from the vfat ESP:
* grub is installed onto the ESP and the MBR points to the ESP
* after copying/deleting the kernels proxmox-boot-tool bindmounts the
ESP on /boot (inside the new mount namespace)
* grub-update then manages to generate a fitting config.
Some paths/sanity-checks needed adaptation (to differentiate between
EFI boot and not (based on the existence of /sys/firmware/efi)
The arguments for grub-install are taken from the pve-installer.
The approach is inspired by @avw in our community-forum [0].
[0] https://forum.proxmox.com/threads/zfs-error-no-such-device-error-unknown-filesystem-entering-rescue-mode.75122/post-374799
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
in order to be consistent with the renaming of pve-efiboot-tool to
proxmox-boot-tool.
Sending as separate patch, since it changes and removes a file in
'/etc', which could be considered part of the external 'api' of
proxmox-boot-tool
Co-authored-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
This is mostly in preparation for renaming pve-efiboot-uuids into
proxmox-boot-uuids, but can help in general (since each duplicate uuid
causes excessive disk i/o upon kernel upgrades).
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
currently simply checking if $ESP_LIST exists, and indicating via
the exit status if proxmox-boot-tool is used for booting the system.
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
We will be using the mechanics also for ZFS systems booting with BIOS
legacy boot, and the tool is used also in PMG and PBS.
A symlink is kept in place for compatibility reasons
The hook scripts are marked as conffiles (as all files in /etc) and
are handled by dpkg-maintscript-helper(1) via dh_installdeb(1)
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Show the real path of the partition in case when the basename couldn't
be determined and the partition given is a symlinked one like
/dev/disk/by-id/<part>/
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
The format command will fail when using other paths like
/dev/disk/by-id/<part> instead of /dev/sdXY directly. It cannot find
the path /sys/block/<disk>/<part>/partition path.
The part name in /dev/disk/by-id is a symlink to /dev/sdXY. At that
point we already have the symlink resolved to the real path. It is
stored in `bdev`.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
This fixes selecting kernels for manual inclusion in the ESP which do
not come with a "-pve" in name.
It fixes listing, by just printing out the whole list as is. refresh
complains already if there's a kernel selected but no respective
vmlinuz got found. Additionally, we already plainly add the "manual
kernel list" in kernel_keep_versions, but filter then out any kernel
not containing a "-pve" in boot_kernel_list.
But boot_kernel_list should actually only filter out the kernel meta
packages.
So, use a inverse match and check for a /\d+\.\d+/ pattern, this
seems to work well enough.
Note that kernel_keep_versions doesn't picks up non-pve kernels
anyway, so this only really alters manual selection.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
this awk line only works with gawk because of implementation differences
between awk alternatives.
debian has mawk installed by default, and mawk does not implement word
boundary regex. to avoid having to depend on gawk, we can just use perl
instead.
Signed-off-by: Oguz Bektas <o.bektas@proxmox.com>
In the case were someone removes the current kernel we do not can
"keep" it anymore. While this was obviously no issue for the
autoremoval logic, it is an issue for the pve-efiboot-tool refresh
command, which reuses this helper to see which kernels it needs to
keep on the ESP.
Without this a running kernel was never removed from the EFI System
Partitions if de-installed from a host, so if it sorted as newest one
it was then booted again, which naturally confuses users (it was just
removed!!). So to ensure that we cannot get such zombie kernels
ensure that only installed kernels are included in the list.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
* add some spaces for separation, increasing readability
* do not use the non-existent variable x as replacement, but an actual
empty string ""
* don't use the "truth-y action" at end to make awk print the line ($0)
but explicitly print $0 after the gsub, makes it easier to get for
people with not much awk background
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
if we fallback to /proc/cmdline, it can include the booted initrd.
to avoid loader entries with initrd 'options' lines, we have to parse
them out.
Signed-off-by: Oguz Bektas <o.bektas@proxmox.com>
Previously, mentioning "virtual package" in the package long
description was enough to supress the "empty-binary-package" linitian
tag[0]. That changed, so let's use "metapackage", which is suggested
as one of the replacement options.
[0]: https://lintian.debian.org/tags/empty-binary-package.html
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
