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>
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>
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>