Thomas Lamprecht [Tue, 28 Nov 2023 07:59:47 +0000 (08:59 +0100)]
Revert "drop auto-adding the simplefb module to initramfs"
This reverts commit 9c41f9482666a392b80a3c4da3e695c4649d8ee1 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>
Stoiko Ivanov [Tue, 21 Nov 2023 20:19:02 +0000 (21:19 +0100)]
add dedicated removable installation
seems adding `--removable` makes grub install ignore most other
information - e.g. the bootloader-id (guessed based on [0]).
add dedicated call with out `--removable` in addition
Seems that's the reason why our installer also 'rolls its own
removable' [1]
minimally tested with an ISO with this installed and an install with
ZFS on / (RAID1).
Stoiko Ivanov [Tue, 21 Nov 2023 16:56:58 +0000 (17:56 +0100)]
grub-install: provide --removable to grub-install
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.
Stoiko Ivanov [Wed, 11 Oct 2023 13:23:41 +0000 (15:23 +0200)]
proxmox-boot-tool: check if correct grub metapackage is installed
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>
Stoiko Ivanov [Wed, 11 Oct 2023 13:23:40 +0000 (15:23 +0200)]
proxmox-boot-tool: do not exit early in kernel-hook
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>
Hannes Laimer [Fri, 23 Jun 2023 06:13:52 +0000 (08:13 +0200)]
boot tool: fix grep misinterpretation of arguments starting with a hyphen
`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 '-'.
Thomas Lamprecht [Thu, 22 Jun 2023 06:48:39 +0000 (08:48 +0200)]
proxmox boot: avoid double quotes for printf format text
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>
Thomas Lamprecht [Wed, 21 Jun 2023 15:26:05 +0000 (17:26 +0200)]
d/control: downgrade systemd-boot dependency to suggests
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>
Stoiko Ivanov [Wed, 21 Jun 2023 14:32:26 +0000 (16:32 +0200)]
proxmox-boot: warn on missing systemd-boot package
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)
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 /.
proxmox-boot: fix #3729 add --graceful to bootctl invocation
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
Stoiko Ivanov [Fri, 11 Feb 2022 15:15:44 +0000 (16:15 +0100)]
proxmox-boot: add pin/unpin functionality for non-p-b-t systems
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>
Stoiko Ivanov [Fri, 11 Feb 2022 15:15:42 +0000 (16:15 +0100)]
fix #3761: proxmox-boot: add pin/unpin for kernel-version
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
Stoiko Ivanov [Mon, 13 Dec 2021 14:52:15 +0000 (15:52 +0100)]
fix #3781: add Provides: wireguard-modules to control.in
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.
Stoiko Ivanov [Mon, 13 Dec 2021 14:52:14 +0000 (15:52 +0100)]
d/control.in: Provide linux-image/linux-headers
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.
Stoiko Ivanov [Wed, 10 Nov 2021 15:25:10 +0000 (16:25 +0100)]
proxmox-boot: read only first line of /etc/kernel/cmdline
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.
projects / proxmox-kernel-helper.git / log