On 28/11/2019 01.42, Chris Murphy wrote:
On Tue, Nov 26, 2019 at 11:07 PM Goffredo Baroncelli <kreijack@xxxxxxxxx> wrote:
[...]
Could you enable the debug, doing set pager=1 set debug=allI 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)"
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) 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.
-- gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
