Re: GRUB bug with Btrfs multiple devices

[Chris Murphy <lists@colorremedies.com>]

On Tue, Nov 26, 2019 at 11:07 PM Goffredo Baroncelli <kreijack@inwind.it> wrote:
>
> On 27/11/2019 02.35, Chris Murphy wrote:
> > On Tue, Nov 26, 2019 at 4:53 PM Chris Murphy <lists@colorremedies.com> wrote:
> >>
> >> On Tue, Nov 26, 2019 at 2:11 PM Goffredo Baroncelli <kreijack@libero.it> wrote:
> >>>
> >>> I think that the errors is due to the "rescan" logic (see grub commit [1]). Could you try a more recent grub (2.04 instead of 2.02) ?
> >>
> >> Yes Fedora Rawhide has 2.04 in it, so I'll give that a shot next time
> >> I rebuild this particular laptop, which should be relatively soon; or
> >> even maybe I can reproduce this problem in a VM with two virtio
> >> devices.
> >
> > I was able to just update to the Fedora 2.04-4.fc32 packages. It's not
> > upstream's but it's a quick and dirty way to give it a shot. Turns
> > out, the same errors happen, although the line number for efidisk.c
> > has changed:
> > https://photos.app.goo.gl/aKWRYhJkkJRDtC1W7
> >
> > For grins, I dropped to a grub prompt, and issued ls and get a different result:
> > https://photos.app.goo.gl/MvL9QZa6zGsiktAf9
>
> Looking at the second picture, it seems that grub had problem to access the disk 0..3 not only when is doing a btrfs activity.
> No problem accessing hd4 and hd5*
>
> Could you enable the debug, doing
>
>         set pager=1
>         set debug=all

I need to narrow the scope. Adding 'set debug=all', there's just way
too much to video, minutes of pages just holding down space bar full
time which is even too fast to video. There must be over 1000 pages, a
tiny minority contain efidisk.c references, the vast majority are
btrfs.c references. As many pages as there are, I was never able to
stop right on a boundary between efidisk.c and btrfs.c. So I gave up
on that approach.

Since the errors happen with efidisk.c I've enabled 'set
debug=efidisk' and captured 74 photos, available at the link below
(they are in pager order)

https://photos.app.goo.gl/nuDH5hFMRxUVKXpX6

It does seem that the errors only happen in efidisk.c and only when
trying to read from what might be phantom devices; I do not know how a
second device in a Btrfs volume triggers this though. There must be
some interaction between efidisk.c and btrfs.c? The grubx64.efi,
grubenv, grub.cfg, and grub modules are all on an HFS+ (no journal)
file system acting as the EFI System partition (as is the default
behavior in Fedora on Macs for many years now). Only vmlinuz and
initramfs are on Btrfs. So I'm not really even sure why btrfs.c gets
called before the GRUB menu is displayed.

I'll see about reproducing this with a VM using edk2 UEFI and two
virtio devices, at least get to a cleaner environment so we're not
confusing multiple system specific weird things. And I can also leave
this particular Mac laptop as it is for further study.


-- 
Chris Murphy