From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oTShZ-0006tz-5P for mharc-grub-devel@gnu.org; Wed, 31 Aug 2022 14:44:37 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43838) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oTShX-0006tb-J3 for grub-devel@gnu.org; Wed, 31 Aug 2022 14:44:35 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]:35872) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oTShT-0006pN-QG for grub-devel@gnu.org; Wed, 31 Aug 2022 14:44:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1661971469; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=EC6iutwVEMUFbpr7ucw0GFEqBGwvKoHjXbwKnjvSSRg=; b=TrihJa8CjIr1V777UjQdecS4z7k1Kp1r3p/3P6krICv9gVsb3P4G5qSsw9drOTWdjtB7YW rjjzZYeRHBPhohPJtwA94naqBFU5G1zWOv1aWlPyoblaFNil5+mgBqN0/FxVtT8NgjW4J8 jMDmGxn0mw8ZI08292l3w/RzGEoi4E0= Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-637-RPK0u0AaMNukikq8EvpTqg-1; Wed, 31 Aug 2022 14:44:28 -0400 X-MC-Unique: RPK0u0AaMNukikq8EvpTqg-1 Received: by mail-qt1-f198.google.com with SMTP id v13-20020a05622a188d00b00343794bd1daso12006828qtc.23 for ; Wed, 31 Aug 2022 11:44:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc; bh=EC6iutwVEMUFbpr7ucw0GFEqBGwvKoHjXbwKnjvSSRg=; b=oObfCMZoG63PsHsDciAGHufvxNqRl+/Y5rIB+fs98pkNHAYNoU408iXdh+dXoM7fWI kaiWgwdRmjTZ+RHRfOCTEF7TLfc0m2W9Ij24XhubzkXWeejJBAnNol7qPTRF6DoKZMp1 S6jCo4D4uEhyMOM7RduwRf9bHxay8sDrPZ1pR3Vr9uGL5eyXDFHJsWVPiyTkqh0ClkYb RcdyEIOoe7QCfU5HQQEY3Q+tCowOOU2L265Ro2BhO5+VpvqPZwdiAt2dVXDlf9AobgFz kIN825Rm67I9sQ/rsUVGMpt1DpQ1mSUBF7MgQDvsm84TUbfkDLwEmWmxSy6RJMP3k/S1 GqRA== X-Gm-Message-State: ACgBeo0nGEb1GEpt9v/9exfWJVCIfm0ncycozKv9fZuJ6mdGPT87Hj3S WkCr1cQEg8JRc4QRndI7TgdFbF2MZFSVUYXmzIy8E8omg/qai+RbxxvNxK6locK74hX950xTDiy yj0Zt9WAIKzY= X-Received: by 2002:a0c:90f1:0:b0:47b:46b7:2eaf with SMTP id p104-20020a0c90f1000000b0047b46b72eafmr20567854qvp.97.1661971467081; Wed, 31 Aug 2022 11:44:27 -0700 (PDT) X-Google-Smtp-Source: AA6agR721hqT4A+RmxvaO4Ch0w5J6Ag0kxR815dS1kqgGIuA+MZE8uMzcbHd4Xv9nX4sHdGL4OeGmA== X-Received: by 2002:a0c:90f1:0:b0:47b:46b7:2eaf with SMTP id p104-20020a0c90f1000000b0047b46b72eafmr20567836qvp.97.1661971466734; Wed, 31 Aug 2022 11:44:26 -0700 (PDT) Received: from localhost (pool-96-252-89-222.bstnma.fios.verizon.net. [96.252.89.222]) by smtp.gmail.com with ESMTPSA id hf11-20020a05622a608b00b00344b807bb95sm8775201qtb.74.2022.08.31.11.44.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 31 Aug 2022 11:44:26 -0700 (PDT) From: Robbie Harwood To: Javier Martinez Canillas , Philip =?utf-8?Q?M?= =?utf-8?Q?=C3=BCller?= , The development of GNU GRUB , Mike Gilbert Cc: Daniel Kiper , Bernhard Landauer , Mark Wagie Subject: Re: [Regression] efi: Don't display a uefi-firmware entry if it's not supported In-Reply-To: <1894ac74-5868-f54f-8013-79aaca385f9f@redhat.com> References: <9274cc62-1922-76c8-925b-b172389b6c3d@manjaro.org> <897c60aa-a254-09e3-9efa-a221cd58d2a9@manjaro.org> <7207213e-e5ee-d44e-150e-c70bde9a4fd2@redhat.com> <617d8190-0999-9b5f-f809-c4fccf7572cc@manjaro.org> <1894ac74-5868-f54f-8013-79aaca385f9f@redhat.com> Date: Wed, 31 Aug 2022 14:44:23 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=170.10.129.124; envelope-from=rharwood@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2022 18:44:35 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Javier Martinez Canillas writes: > On 8/31/22 00:07, Philip M=C3=BCller wrote: >> On 30.08.22 23:34, Javier Martinez Canillas wrote: >>>> You could add a feature flag, which causes grub-core to set an >>>> environment variable when a new feature is supported. See the features >>>> array in grub-core/normal/main.c. >>>> >>>> You would then check for this feature flag in the grub.d snippet >>>> before calling fwsetup --is-supported. >>>> >>> Please don't. As mentioned, I think we should aim to simplify the grub.= cfg >>> instead of making it more complicated. >>=20 >> Well I think it would be the best approach to add backward compatibility= =20 >> as most users don't even know on how to install grub via grub-install. >> That is done via the graphical installer Calamares on most Arch-based=20 >> Distributions. Updating the grub menu is common if you install multiple= =20 >> kernels or use snapshots via BTRFS. >>=20 >> Simply calling 'fwsetup' is a big NO-NO to me and others. The old=20 >> version runs into the EFI firware or simply turn off the PC during boot,= =20 >> which creates boot loops for some or unbootable systems. > > I'm OK to not call fwsetup at all, that's what we originally had in the > series posted by Robbie, for example in v2: > > https://lists.gnu.org/archive/html/grub-devel/2022-08/msg00169.html > > Then they added the fwsetup --is-supported option as mentioned because > other developer asked for that. That patch was included in v3 onward: > > https://lists.gnu.org/archive/html/grub-devel/2022-08/msg00196.html >=20=20 >> I checked on my end with an older grub in /boot and the updated menu.cfg= =20 >> script. Only when removing the snippet of 30_uefi-firmware the system is= =20 >> bootable again. >> > > That's fair. Then probably what we should do is to partially revert > commit 26031d3b1016 ("efi: Don't display a uefi-firmware entry if > it's not supported"). Something like the following patch perhaps ? > > From c3edc64687686d9a5a54f769ec03101b2c4cdef1 Mon Sep 17 00:00:00 2001 > From: Javier Martinez Canillas > Date: Wed, 31 Aug 2022 00:30:31 +0200 > Subject: [PATCH] templates: Don't execute fwsetup unconditionally > MIME-Version: 1.0 > Content-Type: text/plain; charset=3DUTF-8 > Content-Transfer-Encoding: 8bit > > Commit 26031d3b1016 ("efi: Don't display a uefi-firmware entry if it's not > supported") added a new `fwsetup --is-supported` option that could be used > to check if the firmware allows to enter into a firmware user interface. > > That option was then used by /etc/grub.d/30_uefi-firmware script to figure > out whether a `fwsetup` entry should be included or not in the boot menu. > > But unfortunately, old GRUB images will fail to boot if are booted with an > updated GRUB config file. Since the `fwsetup --is-supported` call would be > taken as a plan `fwsetup` with no options. > > This could either lead to a crash (i.e: on legacy BIOS systems where that > is not supported) or to the machine entering into the firmware settings. > > To prevent that, let's partially revert the mentioned commit and keep the > old logic that didn't execute the `fwsetup` command and just included an > entry for it if GRUB is executed in an EFI platform. > > Fixes: 26031d3b1016 ("efi: Don't display a uefi-firmware entry if it's no= t supported") > Reported-by: Philip M=C3=BCller > Signed-off-by: Javier Martinez Canillas > --- > util/grub.d/30_uefi-firmware.in | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/util/grub.d/30_uefi-firmware.in b/util/grub.d/30_uefi-firmwa= re.in > index c1731e5bbbb3..b6041b55e2a0 100644 > --- a/util/grub.d/30_uefi-firmware.in > +++ b/util/grub.d/30_uefi-firmware.in > @@ -31,8 +31,7 @@ LABEL=3D"UEFI Firmware Settings" > gettext_printf "Adding boot menu entry for UEFI Firmware Settings ...\n"= >&2 >=20=20 > cat << EOF > -fwsetup --is-supported > -if [ "\$grub_platform" =3D "efi" -a "\$?" =3D 0 ]; then > +if [ "\$grub_platform" =3D "efi" ]; then > menuentry '$LABEL' \$menuentry_id_option 'uefi-firmware' { > fwsetup > } > --=20 > 2.37.1 While we could revert the entire --is-supported logic as well, since this is upstream pre-release code, it's probably easier for the downstreams that pulled this change if we don't, so: Reviewed-by: Robbie Harwood . Be well, =2D-Robbie --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJIBAEBCgAyFiEEA5qc6hnelQjDaHWqJTL5F2qVpEIFAmMPrAcUHHJoYXJ3b29k QHJlZGhhdC5jb20ACgkQJTL5F2qVpELjGBAAkTjX2IT68AZqACi8l+SZ8xyV+G8n 8JrVq95VYmYmEGgwyXu18/e4/czDE2rW2maAjoTeVXorLSVKS0lyC+pYoZ+vHNlu lxBxrYd3QOA74VoD7amCExMKiSkHK/mjFwbtpLlnXn5vC9jjGSnhy/Jj40WILxCy 27QCB/mNWyTaqJ6uIZLu5s2YOMBnVI0yuojpxWxRcLinOK9Oud2YYo8fLxcRrMYr KP+SldXNSpdNOwaLWrD1N1BdyXGfBJK2LuqlXdqQZOh3XpVOPtV5r9C7lShPOjTY nS4IV4ZNBOdtHBsZDd2kuAH0sawZ/Zd2a7Y9wPFRcDntBB80s8ckzy7ON3KcEotm fjxPuuscwxiFSmdAmKWWiyqNY0RHKJ4HA5ZbKIOFyK23SO+HHjo4Hei3AINFVJLo Kzh4ZuV6OGHKHr2s/sm/6aj3JsUrRLsakCLda0tJ0uJ/alOgVZJjhydez44hIdOr FlpYaqEF4/bNahHSCHUcoVGJyBCRZUmWLIcTJzLCYlLNXmC14E0Q+n6np6DLBbb0 ImIFQPIpwrzMV2YtZJWL7lZNOoGrr8PSKodujhuxXoo1vq9n3S42Xtuyj1pxYihj pgLt19Lv7ZBnZVpE2mTVINq2RfQJdRnvWhXv6JMAlRBLBdI51K+dx86kLXkGw7+A con+7RQfThpO2ms= =82Hv -----END PGP SIGNATURE----- --=-=-=--