On Tue, Apr 9, 2019 at 1:37 AM Berend De Schouwer
<berend.de.schouwer@xxxxxxxxx> wrote:
>
> On Mon, 2019-04-08 at 23:26 -0700, ToddAndMargo wrote:
> > Well, this time it did the updates after rebooting, buttttttttttt
> > then I got:
> >
> > Minimal BASH-link line editing is supported. For the
> > first word, TAB lists possible command completions.
> > Anywhere else TAB lists possible device or file
> > completions
> >
> > grub>
> >
> > Uhhhhh. Guys!
>
> For me -- on a laptop -- F29 -> F30 left me with no entries in
> grub.cfg. It seems to be a BLS problem.
No entries in grub.cfg is normal on x86 and x86_64. They each get
extracted into their own snippet files in /boot/loader/entries/
> grub.cfg did contain:
>
> insmod blscfg
> blscfg
>
> /boot/loader/entries has 5 .conf files and a rescue.conf
>
> grub gave no menus.
That means GRUB can't find or read the .conf files in
/boot/loader/entries so it's going to take some effort to figure out
where the problem is.
Is there anything unique about the storage stack? Is this BIOS or
UEFI? Is /boot its own volume or is it a directory on / ? And what's
the file system?
If you want to dive into this even more in the meantime, at the grub prompt:
set debug=all
blscfg
Now you'll get a page of very verbose debug info as that command
executes. Press space and you'll get a new page. Depending on where
the problem is, it might be a few pages of debug info or it might be
50. And if you can't find some hint scrolling through all that, you'll
need to take a cell phone photo or video if it's not a VM, of
everything after blscfg :-D and maybe I'll have a moment to look at
it, or maybe Javier can look (he's on the bls project).
> Oddly enough installing xen package resulted in xen appearing in
> grub.cfg, but no non-xen kernels:
>
> insmod blscfg
> blscfg
> if [ -s $prefix/grubenv ]; then
> load_env
> fi
> ### END /etc/grub.d/10_linux ###
> ### BEGIN /etc/grub.d/20_linux_xen ###
> menuentry 'Fedora, with Xen hypervisor' --class fedora --class gnu-
> linux --class gnu --class os --class xen $menuentry_id_option 'xen
> gnulinux-simple-e4ae4541-8eca-4483-91cc-af6b83a9fdc5' {
> insmod part_msdos
> insmod ext2
> set root='hd0,msdos3'
> ...
>
> (sidenote: non-linux non-windows entries disappeared completely, under
> all conditions.)
All normal.
>
> This is using a BIOS, not EFI. (EFI on this laptop is kaput.)
Ok well if this is some legacy BIOS setting, EFI is definitely working
and then running a CSM to present a faux-BIOS to GRUB and the kernel.
Maybe that EFI implementation has bugs and there are no firmware
updates from the manufacturer and the work around is to use the CSM?
Anyway, chances are that's not the problem here.
>
>
> > So far, this has not worked to recover:
> >
> > Legacy/Standard BIOS:
> >
> > --> boot off a Xfce Live USB
> > --> fire up mount gparted to find the drive's "/" partition
> > In the following, this is "presumed" to be /dev/sda3
> >
> > $ su
> > # mkdir /mnt/root
> > # mount /dev/sda3 /mnt/root (or whatever "/" is mounted)
> >
> > # /mnt/root/usr/sbin/grub2-install --boot-directory
> > /mnt/root/boot
> > /dev/sda
>
> Try disable BLS in /etc/default/grub and re-running grub-mkconfig
Please don't. That just erases all the evidence of the problem. I
realize testing can be tedious, but that's the point right now. We
need to understand any failure at this point. BLS is a new feature in
Fedora 30, if there some major problem we need to discover it no
matter what. It either needs to get fixed, or if that isn't possible
we're looking at the contingency being deployed. So.... yeah we need
to gather evidence, not scrub it away.
--
Chris Murphy
_______________________________________________
test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/test@xxxxxxxxxxxxxxxxxxxxxxx
