From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id BD7EE9C0B0 for ; Mon, 23 Oct 2023 11:47:59 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 84CFA11BBF for ; Mon, 23 Oct 2023 11:47:29 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Mon, 23 Oct 2023 11:47:28 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 45872444D0 for ; Mon, 23 Oct 2023 11:47:28 +0200 (CEST) Date: Mon, 23 Oct 2023 11:47:20 +0200 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= To: Proxmox VE development discussion References: <20230928140533.653796-1-s.ivanov@proxmox.com> In-Reply-To: <20230928140533.653796-1-s.ivanov@proxmox.com> MIME-Version: 1.0 User-Agent: astroid/0.16.0 (https://github.com/astroidmail/astroid) Message-Id: <1698054138.34j3wefqts.astroid@yuna.none> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL 0.062 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [install.pm, proxmox.com] Subject: Re: [pve-devel] [PATCH installer] install: install correct grub metapackage for the current boot-mode X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2023 09:47:59 -0000 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) >=20 > 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. >=20 > 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/ >=20 > Reproduced and analyzed by Friedrich. >=20 > This patch changes the installer, to install the meta-package fitting > for the boot-mode. >=20 > 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 > Signed-off-by: Stoiko Ivanov Reviewed-by: Fabian Gr=C3=BCnbichler > --- > 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(+) >=20 > 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 =3D $_; > my ($deb) =3D $path =3D~ m/${proxmox_pkgdir}\/(.*\.deb)/; > + > + # the grub-pc/grub-efi-amd64 packages (w/o -bin) are the ones actua= lly updating grub > + # upon upgrade - and conflict with each other - install the fitting= one only > + next if ($deb =3D~ /grub-pc_/ && $run_env->{boot_type} ne 'bios'); > + next if ($deb =3D~ /grub-efi-amd64_/ && $run_env->{boot_type} ne 'e= fi'); > + > 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-trig= gers --unpack /tmp/pkg/$deb") =3D=3D 0 > --=20 > 2.39.2 >=20 >=20 >=20 > _______________________________________________ > pve-devel mailing list > pve-devel@lists.proxmox.com > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel >=20 >=20 >=20