Re: GRUB bug with Btrfs multiple devices

[Goffredo Baroncelli <kreijack@inwind.it>]

On 28/11/2019 21.05, Chris Murphy wrote:
> On Thu, Nov 28, 2019 at 10:58 AM Goffredo Baroncelli <kreijack@inwind.it> wrote:
>>
>> On 28/11/2019 01.42, Chris Murphy wrote:
>>> On Tue, Nov 26, 2019 at 11:07 PM Goffredo Baroncelli <kreijack@inwind.it> wrote:
>>>>
>> [...]
>>>> 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.
>>
>> If I remember correctly, in the previous email you reports that even a simple "ls" at the grub prompt raises an error.
>> So you could watch what happens when doing something simpler like "ls" or "ls (hd0)"
> 
> Errors with only ls.
> https://photos.app.goo.gl/BJpsLvwpL6yf19uj6

It seems that my supposition is true: the problem exists independently of btrfs.
It would be useful to see the debug (set debug=all + set pager=1) when doing "ls". It is a not so huge set of information (however it is composed by few pages).

> 
> Errors with ls per device
> https://photos.app.goo.gl/pgxQDdj1JDjq86mZ9

Grub sees hd0..hd3 as disks of ~120GB; to be exactly, the size is 125753602048 bytes. The error is reported as unable to access sector 0xea3bfc8, which is locate at 0xea3bf00*512=125753491456 byte, which is less than the previous value...

It seems that  GRUB is correct in complaining. It is trying to access a valid disk location which return an error.
Why grub is trying to access this location ? My supposition is that grub is trying to probe a filesystem (or a partition type...)

The problem seems to be related to the first 4 disks, which have all the same size and are "phantom" disks...
May be that the problem is that GRUB incorrectly detects disks ?
> 
> But without rebooting, just repeating the ls for the same devices, I
> don't get the error for hd4 again.
> https://photos.app.goo.gl/M6yraHfgfAsMigaP8

My understanding is that GRUB tried to load some external modules (zfs, ufs2, ...) without success. However this tentative was attempted only the first time. This could explain the fact that the error appeared only one time.
> 
>>From the first ls, it shows GPT on hd5, shouldn't 'ls (hd5)' report
> GPT rather than no file system? gdisk finds no problem with the GPT on
> /dev/sda which is hd5.

It seems no
-----------------------------------------------------------------------
                             GNU GRUB  version 2.03

    Minimal BASH-like line editing is supported. For the first word, TAB
    lists possible command completions. Anywhere else TAB lists possible
    device or file completions.


grub> ls
(proc) (hd11) (hd13) (hd14) (hd15) (hd19) (hd20) (hd31) (hd31,msdos1) (hd32) (h
d32,msdos2) (hd32,msdos1) (hd51) (hd52) (hd53) (hd61) (hd62) (hd63) (hd64) (hd7
1) (hd72) (hd73) (hd74) (hd99) (hd99,gpt2) (hd99,gpt1) (host) (md/0)
grub> ls (hd99)
Device hd99: No known filesystem detected - Sector size 512B - Total size
10485760KiB
grub>
-----------------------------------------------------------------------

> 
> 


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5