All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robbie Harwood <rharwood@redhat.com>
To: "Philip Müller" <philm@manjaro.org>,
	"Daniel Kiper" <daniel.kiper@oracle.com>,
	"Javier Martinez Canillas" <javierm@redhat.com>
Cc: Bernhard Landauer <bernhard@manjaro.org>,
	Mark Wagie <mark@manjaro.org>,
	grub-devel@gnu.org
Subject: Re: [Regression] efi: Don't display a uefi-firmware entry if it's not supported
Date: Tue, 30 Aug 2022 16:16:57 -0400	[thread overview]
Message-ID: <jlgtu5tbi6e.fsf@redhat.com> (raw)
In-Reply-To: <897c60aa-a254-09e3-9efa-a221cd58d2a9@manjaro.org>

[-- Attachment #1: Type: text/plain, Size: 2325 bytes --]

Philip Müller <philm@manjaro.org> writes:

>> Hello Robbie, hello Daniel,
>>
>> with the commit 26031d3b101648352e4e427f04bf69d320088e77
>> 30_uefi-firmware will always call `fwsetup --is-supported' to check
>> if the system supports EFI or not. However most installed grub
>> versions on MBR don't support the '--is-supported' flag and crash the
>> menu creation routine.
>>
>> Arch Linux is tracking the issue here: https://bugs.archlinux.org/task/75701
>>
>> What would be the best approach with older installations of grub via
>> grub-install not having to reinstall grub to MBR as some users don't
>> even know on how to install grub properly as that job a graphical
>> installer does.
>
> Hi all,

Adding grub-devel to CC.

> I looked into the '30_uefi-firmware' changes a little more and also 
> commented my findings at the Arch-Bugtracker: 
> https://bugs.archlinux.org/task/75701#comment210684
>
> Before Menu changes we simply had this:
>
> ### BEGIN /etc/grub.d/30_uefi-firmware ###
> menuentry 'UEFI Firmware Settings' $menuentry_id_option 'uefi-firmware' {
>    fwsetup
> }
> ### END /etc/grub.d/30_uefi-firmware ###
>
> After Menu changes we went to that:
>
> ### BEGIN /etc/grub.d/30_uefi-firmware ###
> fwsetup --is-supported
> if [ "$grub_platform" = "efi" -a "$?" = 0 ]; then
>    menuentry 'UEFI Firmware Settings' $menuentry_id_option 'uefi-firmware' {
>      fwsetup
>    }
> fi
> ### END /etc/grub.d/30_uefi-firmware ###
>
> So 0eb684e8bfb0a9d2d42017a354740be25947babe I get and 
> 26031d3b101648352e4e427f04bf69d320088e77 tries to improve things, 
> however doesn't count in what will happen if 'fwsetup' is not supporting 
> the flag. It may either crash due to 
> 1e79bbfbda24a08cb856ff30f8b1bec460779b91 or start UEFI firmware instead.

Why doesn't grub on the MBR get updated when you install a new grub
package?  That seems like the real issue here - what am I missing?

Regardless, if we can't count on fwsetup being updated, then I think we
need to go back to the original version of my patch which doesn't have
--is-supported.

> Simply don't break user-space when older grub got installed to MBR. 
> Somehow this idea needs some more thinking and a solution for that
> case too.

Sure, what do you suggest?

Be well,
--Robbie

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

       reply	other threads:[~2022-08-30 20:17 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <9274cc62-1922-76c8-925b-b172389b6c3d@manjaro.org>
     [not found] ` <897c60aa-a254-09e3-9efa-a221cd58d2a9@manjaro.org>
2022-08-30 20:16   ` Robbie Harwood [this message]
2022-08-30 21:14     ` [Regression] efi: Don't display a uefi-firmware entry if it's not supported Mike Gilbert
2022-08-30 21:34       ` Javier Martinez Canillas
2022-08-30 22:07         ` Philip Müller
2022-08-30 22:43           ` Javier Martinez Canillas
2022-08-30 23:15             ` Philip Müller
2022-08-31  4:46               ` Luna Jernberg
2022-08-31 18:44             ` Robbie Harwood
2022-09-01 17:11               ` Philip Müller
2022-08-31 11:16           ` Morten Linderud
2022-08-31 11:47     ` Mihai Moldovan
2022-08-31 15:14     ` Dimitri John Ledkov
2022-09-05 22:49       ` Glenn Washburn
2022-10-28 12:55         ` Daniel Kiper

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=jlgtu5tbi6e.fsf@redhat.com \
    --to=rharwood@redhat.com \
    --cc=bernhard@manjaro.org \
    --cc=daniel.kiper@oracle.com \
    --cc=grub-devel@gnu.org \
    --cc=javierm@redhat.com \
    --cc=mark@manjaro.org \
    --cc=philm@manjaro.org \
    /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.