was forgotten during the general renaming of pve-efiboot ->
proxmox-boot.
follows commit 8c0a22adfe
Signed-off-by: Stoiko Ivanov <s.ivanov@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>
following the commit of removing the wrong indentation of the linux
and initrd lines - this commit strips empty lines (and leading
trailing whitespace) in /etc/kernel/cmdline.
I managed to reproduce the issue reported in the forum [0] by adding
empty lines to /etc/kernel/cmdline) - without this - systemd-boot
booted quite happily even with the indentation.
considered using perl -pe with multiline matching but thanks to
Thomas' suggestion went with the shell-builtin read.
the check for existance of 'root=' in the resulting CMDLINE was added,
since my test-system had an empty line in the beginning, which again
rendered it unbootable.
quickly tested on a VM.
[0]: https://forum.proxmox.com/threads/problem-with-proxmox-boot-tool.99043/
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Not an actual issue, the systemd parser just skips those
whitespaces[0], but it may confuse people and lead to false-positive
conclusions about a culprit for loader issues, so fix that up.
[0]: https://github.com/systemd/systemd/blob/main/src/boot/efi/boot.c#L1064
diff before -> after:
version 5.11.22-7-pve
options root=ZFS=rpool/ROOT/pve-1 boot=zfs iommu=pt
- linux /EFI/proxmox/5.11.22-7-pve/vmlinuz-5.11.22-7-pve
- initrd /EFI/proxmox/5.11.22-7-pve/initrd.img-5.11.22-7-pve
+linux /EFI/proxmox/5.11.22-7-pve/vmlinuz-5.11.22-7-pve
+initrd /EFI/proxmox/5.11.22-7-pve/initrd.img-5.11.22-7-pve
Fixes: 2a8a4b5 ("proxmox-boot: fix#3632 copy kernel+initrd unconditionally")
Signed-off-by: Oguz Bektas <o.bektas@proxmox.com>
[ Thomas: Clarify that the commit does not fix anything but is still
good to have ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
do not use the -u (update) flag when copying kernel images and inird
from /boot to the ESPs:
* the ESPs are formatted with vfat, which has a 2 second precision for
mtime (`linux/fs/fat/misc.c` - `fat_truncate_time`)
* cp -u compares the mtimes of source (kernel image in /boot not on
vfat) and destination - leading to the copy always being carried
out, if the source files remain the same (and do not happen to have
a mtime exactly happening on a even second)
as laid out in the bug-report - the case where this leads to an
unbootable system is when a kernel-version is shipped twice (built
with different tool-chains) - e.g. currently the 5.11 kernels in PVE 6
and PVE 7.
tested the behavior of `cp -u` by running opensnopp-bpfcc and copying
a file twice onto ext4 (opened only once) and on vfat (opened twice).
additionally reproduced the issue (by dist-upgrading a PVE 6 VM to 7
with the pve-no-subscription repo) and verified this patch fixes it.
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
like for Grub where this is handled via snippets with PVE > PMG > PBS.
Reported-by: Oguz Bektas <o.bektas@proxmox.com>
Signed-off-by: Fabian Grünbichler <f.gruenbichler@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 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>
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>
