From: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH installer] install: install correct grub metapackage for the current boot-mode
Date: Mon, 23 Oct 2023 11:47:20 +0200 [thread overview]
Message-ID: <1698054138.34j3wefqts.astroid@yuna.none> (raw)
In-Reply-To: <20230928140533.653796-1-s.ivanov@proxmox.com>
On September 28, 2023 4:05 pm, Stoiko Ivanov wrote:
> grub packages in debian split between:
> * meta-packages, which handles (among other things) the reinstalling
> grub to the actual device/ESP in case of a version upgrade (grub-pc,
> grub-efi-amd64)
> * bin-packages, which contain the actual boot-loaders
> The bin-packages can coexist on a system, but the meta-package
> conflict with each other (didn't check why, but I don't see a hard
> conflict on a quick glance)
>
> Currently our ISO installs grub-pc unconditionally (and both bin
> packages, since we install the legacy bootloader also on uefi-booted
> systems). This results in uefi-systems not getting a new grub
> installed automatically upon upgrade.
>
> Reported in our community-forum from users who upgraded to PVE 8.0,
> and still run into an issue fixed in grub for bookworm:
> https://forum.proxmox.com/threads/.123512/
>
> Reproduced and analyzed by Friedrich.
>
> This patch changes the installer, to install the meta-package fitting
> for the boot-mode.
>
> We do not set the debconf variable install_devices, because in my
> tests a plain debian installed in uefi mode has this set, and a
> `grep -ri install_devices /var/lib/dpkg/info` yields only results with
> grub-pc.
this paragraph confused me phrasing-wise (what it means is that the
'install_devices' variable is only defined for 'grub-pc', and thus
(still) only set for that package/namespace)
> Reported-by: Friedrich Weber <f.weber@proxmox.com>
> Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Reviewed-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
> ---
> quickly tested by building an ISO (with the necessary modifications to
> ship both packages as .deb) and installing in legacy mode and uefi mode
> once.
did a similar test with comparing /boot before/after installing the
latest grub security update, which showed that the expected variant gets
updated (legacy if system was originally installed legacy, efi if it was
efi, both of course with no manual switch of boot mode or meta packages
in between).
as discussed off list, we might still want to improve the handling of
the "other" variant somehow, at least by detecting out-of-dateness
and/or missing meta packages somewhere after a switch over.
> Proxmox/Install.pm | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Proxmox/Install.pm b/Proxmox/Install.pm
> index 1117fc4..d775ac0 100644
> --- a/Proxmox/Install.pm
> +++ b/Proxmox/Install.pm
> @@ -1057,6 +1057,12 @@ _EOD
> chomp;
> my $path = $_;
> my ($deb) = $path =~ m/${proxmox_pkgdir}\/(.*\.deb)/;
> +
> + # the grub-pc/grub-efi-amd64 packages (w/o -bin) are the ones actually updating grub
> + # upon upgrade - and conflict with each other - install the fitting one only
> + next if ($deb =~ /grub-pc_/ && $run_env->{boot_type} ne 'bios');
> + next if ($deb =~ /grub-efi-amd64_/ && $run_env->{boot_type} ne 'efi');
> +
> update_progress($count/$pkg_count, 0.5, 0.75, "extracting $deb");
> print STDERR "extracting: $deb\n";
> syscmd("chroot $targetdir dpkg $dpkg_opts --force-depends --no-triggers --unpack /tmp/pkg/$deb") == 0
> --
> 2.39.2
>
>
>
> _______________________________________________
> pve-devel mailing list
> pve-devel@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>
>
>
next prev parent reply other threads:[~2023-10-23 9:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-28 14:05 Stoiko Ivanov
2023-09-28 14:29 ` Stoiko Ivanov
2023-09-28 14:32 ` Thomas Lamprecht
2023-10-02 15:15 ` Friedrich Weber
2023-10-23 9:47 ` Fabian Grünbichler [this message]
2023-11-06 17:32 ` [pve-devel] applied: " Thomas Lamprecht
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1698054138.34j3wefqts.astroid@yuna.none \
--to=f.gruenbichler@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.