this fixes ccfbe44f75
in the patch I accidentally removed the include of the helper
functions - the code uses `warn` from there
reported in our enterprise support portal and in our community-forum:
https://forum.proxmox.com/threads/.114998
reproduced with a VM:
* legacy bios
* installed PVE 6.3 (so that p-b-t was not used for legacy systems)
* then upgraded to a bullseye snapshot of 01.09.2022
* then upgraded to the last bullseye point-release
- this patch fixes the issue there.
The issue should not occur on systems using p-b-t or not using zfs
for /.
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
to iterate over all configured ESPs and refresh the boot-loader
installations.
the init function was changed to not run refresh directly - to prevent
refresh from running once for each ESP
currently reinit does not imply refresh
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
was forgotten during the general renaming of pve-efiboot ->
proxmox-boot.
follows commit 8c0a22adfe
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
The version of systemd boot in bullseye, tries writing an efivar which
is not writeable on certain (broken) UEFIs (HP thin clients).
The issue was not present in the version in buster (the variable
simply did not get written) and can be worked around by adding
--graceful to the `bootctl install` command.
see also:
https://github.com/systemd/systemd/issues/13603
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
While running `update-grub` directly in this case is a divergence from
the semantics of the command when p-b-t handles booting it makes the
cleanup in the `next-boot` case a bit tidier.
fetching the next-boot version explicitly again before setting the
provided version is to cover the sequence:
p-b-t kernel pin <ver1> --next-boot ; p-b-t kernel pin <ver2>
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Reviewed-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Tested-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
by setting the desired version in a dedicated file, which is used
by the systemd service as condition for removing it and refreshing
upon reboot.
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Reviewed-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Tested-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The 2 commands follow the mechanics of p-b-t kernel add/remove in
writing the desired abi-version to a config-file in /etc/kernel and
actually modifying the boot-loader configuration upon p-b-t refresh.
A dedicated new file is used instead of writing the version (with some
kind of annotation) to the manual kernel list to keep parsing the file
simple (and hopefully also cause fewer problems with manually edited
files)
For systemd-boot we write the entry into the loader.conf on the ESP(s)
instead of relying on the `bootctl set-default` mechanics (bootctl(1))
which write the entry in an EFI-var. This was preferred, because of a
few reports of unwriteable EFI-vars on some systems (e.g. DELL servers
have a setting preventing writing EFI-vars from the OS). The rationale
in `Why not simply rely on the EFI boot menu logic?` from [0] also
makes a few points in that direction.
For grub the following choices were made:
* write the pinned version (or actually the menu-path leading to it)
to a snippet in /etc/default/grub.d instead of editing the grub.cfg
files on the partition. Mostly to divert as little as possible from
the grub-workflow I assume people are used to.
* the 'root-device-id' part of the menu-entries is parsed from
/boot/grub/grug.cfg since it was stable (the same on all ESPs and in
/boot/grub), saves us from copying the part of "find device behind
/, mangle it if zfs/btrfs, call grub_probe a few times" part of
grub-mkconfig - and seems a bit more robust
Tested with a BIOS and an UEFI VM with / on ZFS.
[0] https://systemd.io/BOOT_LOADER_SPECIFICATION/
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Reviewed-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Tested-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
makes using this helper shorter in most cases
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Reviewed-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Tested-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
while it's the legacy variant it actually works over simpledrm with
amdgpu (glitches) and nvidia (complete breakage)
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
to ensure the newly switched on SYS_FB kconfig doesn't breaks the
using the fb for the kernel, e.g., via fbcon
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
without this line `apt install wireguard` pulls in Debian's kernel +
firmware which confilcts with pve-firmware - forcing users to install
via `apt install --no-install-recommends wireguard-tools` in order to
get the userspace utils.
Plain debian has the 'Provides' in the meta-package[0]
(linux-image-amd64), so following this add it to pve-kernel-$MAJ.$MIN
versioned dependency added since wireguard has a versioned dependency
on wireguard-modules.
[0] https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/templates/control.image.meta.in
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
pve-kernel-$MAJ.$MIN (e.g. pve-kernel-5.15) is the equivalent
to linux-image-amd64 for plain debian systems (similarly
pve-headers-$MAJ.$MIN).
Providing the plain debian meta-packages should improve the user
experience, for example when users install DKMS packages, which have a
dependency on linux-headers-amd64.
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
