From Fabians feedback:
> this could have another guard for whether the system is even booted
> with grub as if the system was booted using EFI, re-initing all
> ESPs is just busy-work
So skip if proxmox-boot-tool and booted with EFI, as then GRUB is out
of the picture anyway.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
gives a better overview in case the system was switched at one time
from uefi to legacy (or the other way around).
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
most support questions w.r.t. proxmox-boot-tool do have us
asking for `stat /sys/firmware/efi` output anyways
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Deciding whether or not to add the diversion based on the version
alone fails quite hard in case pve-kernel-helper is in dpkg-state 'rc'
(removed not purged) as reported in our community forum[0]:
* removing pve-kernel-helper removes the diversion of grub-install
* if config-files are still present the preinst script gets called
with the version of the config-files (the version that got removed)
* if the version was newer than 6.4-1~ then no diversion is added
* unpacking fails, because grub-install would be overwritten leaving
pve-kernel-helper in state 'ic'
Explicitly checking whether the diversion is in place sounds like a
robust approach here.
downside: documentation on dpkg-divert in maintainer scripts [1] uses
the version approach.
[0] https://forum.proxmox.com/threads/pve-kernel-helper-wont-install.90029/
[1] https://www.debian.org/doc/debian-policy/ap-pkg-diversions.html
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
This way all ESPs (in case of a legacy booted system) get an
updated grub installation.
running only once between reboots (the markerfile is in /tmp) should
be enough. Sadly the environment does not provide a hint which version
grub is installed to.
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
in certain cases the postinst script of grub-pc runs grub-install on
the disks it gets from debconf. Simply warn and exit with 0 if
grub-install is called by dpkg and from a grub related package
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
update-grub (via grub-mkconfig) generates the grub configuration by
concatenating the output of each snippet (from /etc/grub.d).
We need to redirect the output of `proxmox-boot-tool refresh`
to not end up with a syntactically wrong config in /boot/grub/grub.cfg
(which is not used in any case)
quickly tested with a test-installation of mine
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
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>
