6:12 p.m.
I've got a Fedora 29 Silverblue installation in a VM. First boot I see
the GRUB menu, and after that it's hidden. And I can't figure out how
to unhide it. Boot is failing before I get multiuser login or ssh, so
extracting information to troubleshoot/bug report isn't possible.
Repeatedly pressing or holding Esc doesn't work.
Spacebar doesn't work.
F8 doesn't work.
So now I'm stuck. Yeah, I can reinstall, and before rebooting make
sure whatever is hiding the GRUB menu is disabled, every time I do
installations. But the very reason why people were so vocal about this
feature not happening is exactly this use case.
This is a Fedora 29 host. Fedora 29 (silverblue, maybe it happens with
Workstation as well) as guest. Virt-manager is what I'm using for
interacting with the VM.
--
Chris Murphy
12:57 a.m.
F8 and Esc should work. The change page [1] mentions also holding shift.
It also mentions "sudo grub2-editenv - unset menu_auto_hide".
But it is interesting that:
1. it does not work
2. it does not unhide itself after failed boot.
Both sounds as a bugs to me.
V.
[1] https://fedoraproject.org/wiki/Changes/HiddenGrubMenu
Dne 18.9.2018 v 01:12 Chris Murphy napsal(a):
I've got a Fedora 29 Silverblue installation in a VM. First boot
I see
the GRUB menu, and after that it's hidden. And I can't figure out how
to unhide it. Boot is failing before I get multiuser login or ssh, so
extracting information to troubleshoot/bug report isn't possible.
Repeatedly pressing or holding Esc doesn't work.
Spacebar doesn't work.
F8 doesn't work.
So now I'm stuck. Yeah, I can reinstall, and before rebooting make
sure whatever is hiding the GRUB menu is disabled, every time I do
installations. But the very reason why people were so vocal about this
feature not happening is exactly this use case.
This is a Fedora 29 host. Fedora 29 (silverblue, maybe it happens with
Workstation as well) as guest. Virt-manager is what I'm using for
interacting with the VM.
5:56 a.m.
Hi,
On 18-09-18 01:12, Chris Murphy wrote:
I've got a Fedora 29 Silverblue installation in a VM. First boot
I see
the GRUB menu, and after that it's hidden. And I can't figure out how
to unhide it. Boot is failing before I get multiuser login or ssh, so
extracting information to troubleshoot/bug report isn't possible.
Repeatedly pressing or holding Esc doesn't work.
Spacebar doesn't work.
F8 doesn't work.
So now I'm stuck. Yeah, I can reinstall, and before rebooting make
sure whatever is hiding the GRUB menu is disabled, every time I do
installations. But the very reason why people were so vocal about this
feature not happening is exactly this use case.
This is a Fedora 29 host. Fedora 29 (silverblue, maybe it happens with
Workstation as well) as guest. Virt-manager is what I'm using for
interacting with the VM.
Can you please retry with a regular F29 workstation install?
I've the feeling that this bug is specific to Silverblue.
Regards,
Hans
9:36 a.m.
On Tue, Sep 18, 2018 at 4:56 AM, Hans de Goede <hdegoede(a)redhat.com> wrote:
Hi,
On 18-09-18 01:12, Chris Murphy wrote:
>
> I've got a Fedora 29 Silverblue installation in a VM. First boot I see
> the GRUB menu, and after that it's hidden. And I can't figure out how
> to unhide it. Boot is failing before I get multiuser login or ssh, so
> extracting information to troubleshoot/bug report isn't possible.
>
> Repeatedly pressing or holding Esc doesn't work.
> Spacebar doesn't work.
> F8 doesn't work.
>
> So now I'm stuck. Yeah, I can reinstall, and before rebooting make
> sure whatever is hiding the GRUB menu is disabled, every time I do
> installations. But the very reason why people were so vocal about this
> feature not happening is exactly this use case.
>
> This is a Fedora 29 host. Fedora 29 (silverblue, maybe it happens with
> Workstation as well) as guest. Virt-manager is what I'm using for
> interacting with the VM.
Can you please retry with a regular F29 workstation install?
I've the feeling that this bug is specific to Silverblue.
Same thing. Whether BIOS or UEFI. Esc, F8, SHIFT do not reveal the
hidden grub menu - whether banging on them or holding them at VM start
time.
--
Chris Murphy
9:57 a.m.
On Tue, Sep 18, 2018 at 08:36:32AM -0600, Chris Murphy wrote:
On Tue, Sep 18, 2018 at 4:56 AM, Hans de Goede
<hdegoede(a)redhat.com> wrote:
> Hi,
>
> On 18-09-18 01:12, Chris Murphy wrote:
>>
>> I've got a Fedora 29 Silverblue installation in a VM.
What kind of VM
is it?
Zbyszek
10:28 a.m.
On Tue, Sep 18, 2018 at 8:57 AM, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
On Tue, Sep 18, 2018 at 08:36:32AM -0600, Chris Murphy wrote:
> On Tue, Sep 18, 2018 at 4:56 AM, Hans de Goede <hdegoede(a)redhat.com> wrote:
> > Hi,
> >
> > On 18-09-18 01:12, Chris Murphy wrote:
> >>
> >> I've got a Fedora 29 Silverblue installation in a VM.
What kind of VM is it?
qemu/kvm using virt-manager
I am not using direct kernel boot. The grub command line, which is the
only thing that has that command line, is passed onto the kernel and I
can see that in dmesg - which would not be the case with direct kernel
boot, if grub were being skipped.
--
Chris Murphy
1:05 p.m.
Den tis 18 sep. 2018 kl 17:29 skrev Chris Murphy <lists(a)colorremedies.com>:
On Tue, Sep 18, 2018 at 8:57 AM, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
> On Tue, Sep 18, 2018 at 08:36:32AM -0600, Chris Murphy wrote:
>> On Tue, Sep 18, 2018 at 4:56 AM, Hans de Goede <hdegoede(a)redhat.com>
wrote:
>> > Hi,
>> >
>> > On 18-09-18 01:12, Chris Murphy wrote:
>> >>
>> >> I've got a Fedora 29 Silverblue installation in a VM.
> What kind of VM is it?
qemu/kvm using virt-manager
I am not using direct kernel boot. The grub command line, which is the
only thing that has that command line, is passed onto the kernel and I
can see that in dmesg - which would not be the case with direct kernel
boot, if grub were being skipped.
--
I could only get the GRUB menu by using F8, not by Esc.
/Andreas Tunek
> Chris Murphy
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
1:09 p.m.
Hi,
On 18-09-18 17:28, Chris Murphy wrote:
On Tue, Sep 18, 2018 at 8:57 AM, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
> On Tue, Sep 18, 2018 at 08:36:32AM -0600, Chris Murphy wrote:
>> On Tue, Sep 18, 2018 at 4:56 AM, Hans de Goede <hdegoede(a)redhat.com>
wrote:
>>> Hi,
>>>
>>> On 18-09-18 01:12, Chris Murphy wrote:
>>>>
>>>> I've got a Fedora 29 Silverblue installation in a VM.
> What kind of VM is it?
qemu/kvm using virt-manager
I am not using direct kernel boot. The grub command line, which is the
only thing that has that command line, is passed onto the kernel and I
can see that in dmesg - which would not be the case with direct kernel
boot, if grub were being skipped.
Ok, I've managed to reproduce this in a classic BIOS boot using VM and
then after updating grub2 to 2.02-58 and running grub2-mkinstall the
problem went away. It looks like this somehow for broken in one specific
grub2 build and then fixed again with anyone from the rhboot group
realizing it was broken in the interim.
Please try upgrading to grub2-2.02-58 from updates-testing and if
you are using classic BIOS boot also run grub2-mkinstall after this.
Regards,
Hans
2:23 p.m.
On Tue, Sep 18, 2018 at 12:09 PM, Hans de Goede <hdegoede(a)redhat.com> wrote:
Ok, I've managed to reproduce this in a classic BIOS boot using
VM and
then after updating grub2 to 2.02-58 and running grub2-mkinstall the
problem went away. It looks like this somehow for broken in one specific
grub2 build and then fixed again with anyone from the rhboot group
realizing it was broken in the interim.
Please try upgrading to grub2-2.02-58 from updates-testing and if
you are using classic BIOS boot also run grub2-mkinstall after this.
I installed Fedora-Workstation-Live-x86_64-29_Beta-1.3.iso which has
-57 so that explains it.
But is this bugginess worth a FE to try and get -58 onto the Beta?
Lots of users will install the Beta and will not want to reinstall.
Seems like suboptimal behavior.
--
Chris Murphy
5:57 p.m.
On 9/18/18 3:23 PM, Chris Murphy wrote:
But is this bugginess worth a FE to try and get -58 onto the Beta?
Lots of users will install the Beta and will not want to reinstall.
Seems like suboptimal behavior.
I think it's worth a FE since this was one of the Fedora 29 changes. I
think it'd be ideal to be able to test all 29 changes in the beta.
7:06 p.m.
On Tue, 2018-09-18 at 18:57 -0400, Randy Barlow wrote:
On 9/18/18 3:23 PM, Chris Murphy wrote:
> But is this bugginess worth a FE to try and get -58 onto the Beta?
> Lots of users will install the Beta and will not want to reinstall.
> Seems like suboptimal behavior.
I think it's worth a FE since this was one of the Fedora 29 changes. I
think it'd be ideal to be able to test all 29 changes in the beta.
Then can someone propose it, like, now? Cos I'm working on the Beta RC4
request right now...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
7:09 p.m.
New subject: F29 hidden GRUB, problem testing and how to unhide
On Tue, 2018-09-18 at 17:06 -0700, Adam Williamson wrote:
On Tue, 2018-09-18 at 18:57 -0400, Randy Barlow wrote:
> On 9/18/18 3:23 PM, Chris Murphy wrote:
> > But is this bugginess worth a FE to try and get -58 onto the Beta?
> > Lots of users will install the Beta and will not want to reinstall.
> > Seems like suboptimal behavior.
>
> I think it's worth a FE since this was one of the Fedora 29 changes. I
> think it'd be ideal to be able to test all 29 changes in the beta.
Then can someone propose it, like, now? Cos I'm working on the Beta RC4
request right now...
Note, -58 includes a somewhat-significant patch which was not mentioned
in the package changelog:
https://src.fedoraproject.org/rpms/grub2/blob/master/f/0240-Attempt-to-fi...
on the one hand, I suppose that could plausibly be what fixes this; on
the other hand, it is Change, and I don't like change on blocker week
Tuesdays...
Hans, did you test whether just running the grub2-mkinstall *without*
updating grub2 at all 'fixed' the bug? Cos now I'm suspicious about
exactly how this -58 magically fixed this.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
7:37 p.m.
On Tue, 2018-09-18 at 20:09 +0200, Hans de Goede wrote:
Hi,
On 18-09-18 17:28, Chris Murphy wrote:
> On Tue, Sep 18, 2018 at 8:57 AM, Zbigniew Jędrzejewski-Szmek
> <zbyszek(a)in.waw.pl> wrote:
> > On Tue, Sep 18, 2018 at 08:36:32AM -0600, Chris Murphy wrote:
> > > On Tue, Sep 18, 2018 at 4:56 AM, Hans de Goede <hdegoede(a)redhat.com>
wrote:
> > > > Hi,
> > > >
> > > > On 18-09-18 01:12, Chris Murphy wrote:
> > > > > I've got a Fedora 29 Silverblue installation in a VM.
> > What kind of VM is it?
>
> qemu/kvm using virt-manager
>
> I am not using direct kernel boot. The grub command line, which is the
> only thing that has that command line, is passed onto the kernel and I
> can see that in dmesg - which would not be the case with direct kernel
> boot, if grub were being skipped.
Ok, I've managed to reproduce this in a classic BIOS boot using VM and
then after updating grub2 to 2.02-58 and running grub2-mkinstall the
problem went away. It looks like this somehow for broken in one specific
grub2 build and then fixed again with anyone from the rhboot group
realizing it was broken in the interim.
Please try upgrading to grub2-2.02-58 from updates-testing and if
you are using classic BIOS boot also run grub2-mkinstall after this.
Note, I can't reproduce this with an install of Beta RC3 Workstation
live to a BIOS vm in virt-manager. F8 works every time to bring up the
boot menu (yes, I checked that if I *don't* press F8, the boot menu
*doesn't* show up, too).
Perhaps this is Silverblue-specific somehow?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
7:45 p.m.
On Tue, Sep 18, 2018 at 6:37 PM, Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
On Tue, 2018-09-18 at 20:09 +0200, Hans de Goede wrote:
> Hi,
>
> On 18-09-18 17:28, Chris Murphy wrote:
> > On Tue, Sep 18, 2018 at 8:57 AM, Zbigniew Jędrzejewski-Szmek
> > <zbyszek(a)in.waw.pl> wrote:
> > > On Tue, Sep 18, 2018 at 08:36:32AM -0600, Chris Murphy wrote:
> > > > On Tue, Sep 18, 2018 at 4:56 AM, Hans de Goede
<hdegoede(a)redhat.com> wrote:
> > > > > Hi,
> > > > >
> > > > > On 18-09-18 01:12, Chris Murphy wrote:
> > > > > > I've got a Fedora 29 Silverblue installation in a VM.
> > > What kind of VM is it?
> >
> > qemu/kvm using virt-manager
> >
> > I am not using direct kernel boot. The grub command line, which is the
> > only thing that has that command line, is passed onto the kernel and I
> > can see that in dmesg - which would not be the case with direct kernel
> > boot, if grub were being skipped.
>
> Ok, I've managed to reproduce this in a classic BIOS boot using VM and
> then after updating grub2 to 2.02-58 and running grub2-mkinstall the
> problem went away. It looks like this somehow for broken in one specific
> grub2 build and then fixed again with anyone from the rhboot group
> realizing it was broken in the interim.
>
> Please try upgrading to grub2-2.02-58 from updates-testing and if
> you are using classic BIOS boot also run grub2-mkinstall after this.
Note, I can't reproduce this with an install of Beta RC3 Workstation
live to a BIOS vm in virt-manager. F8 works every time to bring up the
boot menu (yes, I checked that if I *don't* press F8, the boot menu
*doesn't* show up, too).
Perhaps this is Silverblue-specific somehow?
No I reproduced the problem with beta 1.3 in both BIOS and UEFI VMs
using virt-manager. I tried ESC, Shift, F8, space - both holding, and
rapid pressing. *shrug*
--
Chris Murphy
7:48 p.m.
On Tue, 2018-09-18 at 18:45 -0600, Chris Murphy wrote:
On Tue, Sep 18, 2018 at 6:37 PM, Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
> On Tue, 2018-09-18 at 20:09 +0200, Hans de Goede wrote:
> > Hi,
> >
> > On 18-09-18 17:28, Chris Murphy wrote:
> > > On Tue, Sep 18, 2018 at 8:57 AM, Zbigniew Jędrzejewski-Szmek
> > > <zbyszek(a)in.waw.pl> wrote:
> > > > On Tue, Sep 18, 2018 at 08:36:32AM -0600, Chris Murphy wrote:
> > > > > On Tue, Sep 18, 2018 at 4:56 AM, Hans de Goede
<hdegoede(a)redhat.com> wrote:
> > > > > > Hi,
> > > > > >
> > > > > > On 18-09-18 01:12, Chris Murphy wrote:
> > > > > > > I've got a Fedora 29 Silverblue installation in a
VM.
> > > > What kind of VM is it?
> > >
> > > qemu/kvm using virt-manager
> > >
> > > I am not using direct kernel boot. The grub command line, which is the
> > > only thing that has that command line, is passed onto the kernel and I
> > > can see that in dmesg - which would not be the case with direct kernel
> > > boot, if grub were being skipped.
> >
> > Ok, I've managed to reproduce this in a classic BIOS boot using VM and
> > then after updating grub2 to 2.02-58 and running grub2-mkinstall the
> > problem went away. It looks like this somehow for broken in one specific
> > grub2 build and then fixed again with anyone from the rhboot group
> > realizing it was broken in the interim.
> >
> > Please try upgrading to grub2-2.02-58 from updates-testing and if
> > you are using classic BIOS boot also run grub2-mkinstall after this.
>
> Note, I can't reproduce this with an install of Beta RC3 Workstation
> live to a BIOS vm in virt-manager. F8 works every time to bring up the
> boot menu (yes, I checked that if I *don't* press F8, the boot menu
> *doesn't* show up, too).
>
> Perhaps this is Silverblue-specific somehow?
No I reproduced the problem with beta 1.3 in both BIOS and UEFI VMs
using virt-manager. I tried ESC, Shift, F8, space - both holding, and
rapid pressing. *shrug*
That's odd, it definitely works for me...
given the confusion here, I'm sending the RC4 request without grub2
-58. If we wind up finding more blockers, maybe it can go into RC5...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
7:55 p.m.
On Tue, Sep 18, 2018 at 6:48 PM, Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
On Tue, 2018-09-18 at 18:45 -0600, Chris Murphy wrote:
> On Tue, Sep 18, 2018 at 6:37 PM, Adam Williamson
> <adamwill(a)fedoraproject.org> wrote:
> > On Tue, 2018-09-18 at 20:09 +0200, Hans de Goede wrote:
> > > Hi,
> > >
> > > On 18-09-18 17:28, Chris Murphy wrote:
> > > > On Tue, Sep 18, 2018 at 8:57 AM, Zbigniew Jędrzejewski-Szmek
> > > > <zbyszek(a)in.waw.pl> wrote:
> > > > > On Tue, Sep 18, 2018 at 08:36:32AM -0600, Chris Murphy wrote:
> > > > > > On Tue, Sep 18, 2018 at 4:56 AM, Hans de Goede
<hdegoede(a)redhat.com> wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > On 18-09-18 01:12, Chris Murphy wrote:
> > > > > > > > I've got a Fedora 29 Silverblue installation
in a VM.
> > > > > What kind of VM is it?
> > > >
> > > > qemu/kvm using virt-manager
> > > >
> > > > I am not using direct kernel boot. The grub command line, which is
the
> > > > only thing that has that command line, is passed onto the kernel and
I
> > > > can see that in dmesg - which would not be the case with direct
kernel
> > > > boot, if grub were being skipped.
> > >
> > > Ok, I've managed to reproduce this in a classic BIOS boot using VM and
> > > then after updating grub2 to 2.02-58 and running grub2-mkinstall the
> > > problem went away. It looks like this somehow for broken in one specific
> > > grub2 build and then fixed again with anyone from the rhboot group
> > > realizing it was broken in the interim.
> > >
> > > Please try upgrading to grub2-2.02-58 from updates-testing and if
> > > you are using classic BIOS boot also run grub2-mkinstall after this.
> >
> > Note, I can't reproduce this with an install of Beta RC3 Workstation
> > live to a BIOS vm in virt-manager. F8 works every time to bring up the
> > boot menu (yes, I checked that if I *don't* press F8, the boot menu
> > *doesn't* show up, too).
> >
> > Perhaps this is Silverblue-specific somehow?
>
> No I reproduced the problem with beta 1.3 in both BIOS and UEFI VMs
> using virt-manager. I tried ESC, Shift, F8, space - both holding, and
> rapid pressing. *shrug*
That's odd, it definitely works for me...
given the confusion here, I'm sending the RC4 request without grub2
-58. If we wind up finding more blockers, maybe it can go into RC5...
I'm not finding a criterion requiring either the key reveal feature to
work; or for the failed boot detection to work. Seems like that might
need a tweak. Sure, anything that breaks boot and ability to login is
itself a blocker anyway.
--
Chris Murphy
7:57 p.m.
On Tue, 2018-09-18 at 18:55 -0600, Chris Murphy wrote:
I'm not finding a criterion requiring either the key reveal feature to
work; or for the failed boot detection to work. Seems like that might
need a tweak.
Yeah, possibly. Not surprising there's no criterion *yet*, as it's a
new feature, but we might want to consider adding one indeed.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
7:58 p.m.
On Tue, Sep 18, 2018 at 6:55 PM, Chris Murphy <lists(a)colorremedies.com> wrote:
On Tue, Sep 18, 2018 at 6:48 PM, Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
> On Tue, 2018-09-18 at 18:45 -0600, Chris Murphy wrote:
>> On Tue, Sep 18, 2018 at 6:37 PM, Adam Williamson
>> <adamwill(a)fedoraproject.org> wrote:
>> > On Tue, 2018-09-18 at 20:09 +0200, Hans de Goede wrote:
>> > > Hi,
>> > >
>> > > On 18-09-18 17:28, Chris Murphy wrote:
>> > > > On Tue, Sep 18, 2018 at 8:57 AM, Zbigniew Jędrzejewski-Szmek
>> > > > <zbyszek(a)in.waw.pl> wrote:
>> > > > > On Tue, Sep 18, 2018 at 08:36:32AM -0600, Chris Murphy
wrote:
>> > > > > > On Tue, Sep 18, 2018 at 4:56 AM, Hans de Goede
<hdegoede(a)redhat.com> wrote:
>> > > > > > > Hi,
>> > > > > > >
>> > > > > > > On 18-09-18 01:12, Chris Murphy wrote:
>> > > > > > > > I've got a Fedora 29 Silverblue
installation in a VM.
>> > > > > What kind of VM is it?
>> > > >
>> > > > qemu/kvm using virt-manager
>> > > >
>> > > > I am not using direct kernel boot. The grub command line, which is
the
>> > > > only thing that has that command line, is passed onto the kernel
and I
>> > > > can see that in dmesg - which would not be the case with direct
kernel
>> > > > boot, if grub were being skipped.
>> > >
>> > > Ok, I've managed to reproduce this in a classic BIOS boot using VM
and
>> > > then after updating grub2 to 2.02-58 and running grub2-mkinstall the
>> > > problem went away. It looks like this somehow for broken in one
specific
>> > > grub2 build and then fixed again with anyone from the rhboot group
>> > > realizing it was broken in the interim.
>> > >
>> > > Please try upgrading to grub2-2.02-58 from updates-testing and if
>> > > you are using classic BIOS boot also run grub2-mkinstall after this.
>> >
>> > Note, I can't reproduce this with an install of Beta RC3 Workstation
>> > live to a BIOS vm in virt-manager. F8 works every time to bring up the
>> > boot menu (yes, I checked that if I *don't* press F8, the boot menu
>> > *doesn't* show up, too).
>> >
>> > Perhaps this is Silverblue-specific somehow?
>>
>> No I reproduced the problem with beta 1.3 in both BIOS and UEFI VMs
>> using virt-manager. I tried ESC, Shift, F8, space - both holding, and
>> rapid pressing. *shrug*
>
> That's odd, it definitely works for me...
>
> given the confusion here, I'm sending the RC4 request without grub2
> -58. If we wind up finding more blockers, maybe it can go into RC5...
I'm not finding a criterion requiring either the key reveal feature to
work; or for the failed boot detection to work. Seems like that might
need a tweak. Sure, anything that breaks boot and ability to login is
itself a blocker anyway.
By the way, can we get some clarification as to the scope of the
hidden grub menu change? I think it should be restricted to
Workstation only. And not extend to anything else, including even
Silverblue (yes it's a workstation variant but there are way too many
major differences between silverblue startup and assembly behavior
that totally obviates hiding the grub menu being a good idea). I'm
pretty sure Server and Cloud people were not in favor of hiding the
grub menu.
--
Chris Murphy
8:15 p.m.
On Tue, 2018-09-18 at 18:58 -0600, Chris Murphy wrote:
By the way, can we get some clarification as to the scope of the
hidden grub menu change? I think it should be restricted to
Workstation only. And not extend to anything else, including even
Silverblue (yes it's a workstation variant but there are way too many
major differences between silverblue startup and assembly behavior
that totally obviates hiding the grub menu being a good idea). I'm
pretty sure Server and Cloud people were not in favor of hiding the
grub menu.
It is specific to Workstation. The Change page says "This new auto-hide
functionality will be automatically enabled on new Fedora Workstation
installs". The bit of anaconda that actually turns on the feature at
install time is conditionalized such that install classes can turn it
on or off. The default install class turns it off. The Workstation
class turns it on.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
1:40 a.m.
Hi,
On 19-09-18 02:09, Adam Williamson wrote:
On Tue, 2018-09-18 at 17:06 -0700, Adam Williamson wrote:
> On Tue, 2018-09-18 at 18:57 -0400, Randy Barlow wrote:
>> On 9/18/18 3:23 PM, Chris Murphy wrote:
>>> But is this bugginess worth a FE to try and get -58 onto the Beta?
>>> Lots of users will install the Beta and will not want to reinstall.
>>> Seems like suboptimal behavior.
>>
>> I think it's worth a FE since this was one of the Fedora 29 changes. I
>> think it'd be ideal to be able to test all 29 changes in the beta.
>
> Then can someone propose it, like, now? Cos I'm working on the Beta RC4
> request right now...
Note, -58 includes a somewhat-significant patch which was not mentioned
in the package changelog:
https://src.fedoraproject.org/rpms/grub2/blob/master/f/0240-Attempt-to-fi...
on the one hand, I suppose that could plausibly be what fixes this; on
the other hand, it is Change, and I don't like change on blocker week
Tuesdays...
Hans, did you test whether just running the grub2-mkinstall *without*
updating grub2 at all 'fixed' the bug?
No I did not test that. I was surprised that the bug existed at all.
Note my vm was based on a significantly older compose, so it had
grub2-2.02-51, so the dnf update + grub2-mkinstall took it all the
way from -51 to -58.
Cos now I'm suspicious about
exactly how this -58 magically fixed this.
I'm afraid I've no clue how -58 fixes this, I was surprised that I
could reproduce the bug in the first place.
Regards,
Hans
2050
days inactive
2052
days old
19 comments
7 participants
participants (7)
-
Adam Williamson -
Andreas Tunek -
Chris Murphy -
Hans de Goede -
Randy Barlow -
Vít Ondruch -
Zbigniew Jędrzejewski-Szmek