if a fallback bootloader is installed, but the Grub packages are not set
up to manage it, inform the user about it. this setup is problematic if
the fallback bootloader is used as boot option (now or in the future),
so it's best to fix it up before a problem occurs.
for proxmox-boot-tool managed ESPs, we always install both when
(re)initing the ESPs, this only affects setup with a regular,
always-mounted, single ESP, such as ext4 on top of LVM.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
This reverts commit 9c41f94826 as it
seems there are quite a few systems where only the simplefb is
available, so even though this sometimes causes issues it seems less
problematic if present than not.
And the issues are mostly restricted to passthrough and the host
grabbing the GPU through that module, with workarounds possible.
Update the filename while at it.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
noticed while installing with secure-boot enabled on ZFS RAID1:
The system has no entry to boot from in the efi-vars and
the entry for the first disk simply does not boot (I assume OVMF tries
the default bootx64.efi.
Since `proxmox-boot-tool init` should only be done for ESPs, which are
dedicated to proxmox products I don't think that this will cause many
regressions
For comparison - our installer has done the manual equivalent of the
--removable option for installs on ext4 for quite a while.
minimally tested on a VM during install.
Reported-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
these can happen for example if the system
- is set up to boot using systemd-boot
- but grub updates trigger a call to "grub-install"
- and systemd-boot is not installed
in this case, "proxmox-boot-tool reinit" will fail because of the lack of
"systemd-boot", and the upgrade triggering the grub-install call would error
out.
all the error messages/warnings are still printed and hopefully noticed.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
only the package name is different, the file paths are identical and they are
not co-installable.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Reviewed-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Tested-by: Stoiko Ivanov <s.ivanov@proxmox.com>
and add shim- to the list of packages that are allowed to trigger.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Reviewed-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Tested-by: Stoiko Ivanov <s.ivanov@proxmox.com>
init has to be explicit, re-init is auto-detected based on presense of
'proxmox' Grub EFI binary on ESP.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Reviewed-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Tested-by: Stoiko Ivanov <s.ivanov@proxmox.com>
this part of the hook applies only to systems not using pbt for
bootmangement.
Currently our ISO installs grub-pc unconditionally - and never the
conflicting grub-efi-amd64. Both packages are responsible for
running grub-install (for the appropriate disks) upon an upgrade of
grub.
This results in grub currently not getting updated on uefi-booted
systems (which do not use proxmox-boot-tool).
The patch causes a warning to be printed to notify the user.
Also considered putting the check+warning in d/postinst - but this way
it will get triggered more often (upon every
kernel-upgrade/update-initramfs, instead of only on
proxmox-kernel-helper updates, which are less often), increasing the
chances of being noticed.
checking for the changelog-presence was chosen, over `dpkg-query` for
the status, for consistency with the similar patch for pve7to8 (and
potentially a small speed-gain).
Suggested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Reviewed-by: Friedrich Weber <f.weber@proxmox.com>
Tested-by: Friedrich Weber <f.weber@proxmox.com>
update_esps is called first in the actual execution below - exiting
early does not work for systems that don't use proxmox-boot-tool if a
check added later needs to work there too.
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Reviewed-by: Friedrich Weber <f.weber@proxmox.com>
Tested-by: Friedrich Weber <f.weber@proxmox.com>
following the rename in our kernel packaging, otherwise the scripts here
wouldn't pick up the new kernels (except if currently booted).
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
`proxmox-boot-tool kernel remove --help`, or any version agrument
that started with a '-', lead to the grep usage message being written
into /etc/kernel/proxmox-boot-manual-kernels. The problem was `grep`
interpreted the kernel version agrument as an option since it starts
with '-'.
most shells interpret the ! contained in "double quotes" as event and
try to resolve that, luckily dash doesn't do that but still simply
dangerous to do such stuff..
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
by default recommends get pulled in on upgrades, at least if the user
did not disable this or used the respective CLI switch, so go for a
suggests instead:
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
systemd-boot is a separate binary package, and proxmox-boot-tool needs
it in the uefi-case as boot-loader for the ESPs
Not adding as Depends, because it is not strictly necessary for
proxmox-boot-tool (pinning is independent as is its use on legacy-boot
systems)
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
With the shipping of systemd-boot as separate package, we cannot rely
on `bootctl` being present in all systems (e.g. currently all systems
upgraded from PVE 7 will not automatically pull systemd-boot in.
This patch adds a check for existence + warning with an explanation to
the only invocation of bootctl in the boot-tool codebase
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
With Debian Bookworm systemd-boot is a separate binary-package,
instead of part of the main systemd package.
Since it's not installed by default, Debian-upstream has added
hook-scripts to the package, which manage kernel copying to the esp
(kernel-install).
The hookscripts print a warning if the ESP is not mounted at
$SYSTEMD_ESP_PATH or /boot/efi, /efi or /boot - through `bootctl
is-installed --quiet` [0,1].
This patch adds a function, which disables the hookscripts from
upstream if /etc/kernel/proxmox-boot-uuids is present.
It adds an explanation as marker and 'exit 0' on top of the script, so
that users know why the scripts were touched (e.g. when a new
systemd-boot hookscript version from upstream asks what to do with the
local modifications)
While editing shell-script hooks from other packages is quite brittle
it still seems like the best option, to support most use-cases
(including users, who don't use proxmox-boot-tool, but want to
manually install systemd-boot).
Alternatives considered:
* dpkg-divert for all hookscripts - sadly the Debian policy manual
warns against this
* adding Replaces: systemd-boot to d/control - afaict this would need
systemd-boot to also declare this for proxmox-kernel-helper [3]
Tested on 2 VMs installed with the 8.0 ISO (once with legacy once with
uefi boot)
[0]
8a38b62f37/src/shared/find-esp.c (L503)
[1]
8a38b62f37/src/boot/bootctl.c (L90)
[2] https://www.debian.org/doc/debian-policy/ap-pkg-diversions.html
[3] https://www.debian.org/doc/debian-policy/ch-relationships.html
Reported-by: Aaron Lauterer <a.lauterer@proxmox.com>
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
[T: avoid potential false exit code, use if ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
and ensure upgrades that also involve a kernel install/uninstall/upgrade still
work by symlinking the old path to the new one.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
