On 29/11/2019 18.57, Chris Murphy wrote:
On Thu, Nov 28, 2019 at 2:57 PM Goffredo Baroncelli <kreijack@xxxxxxxxx> wrote:
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).
OK I did debug=all on the grub command line instead of in the
grub.cfg, and it's much more manageable.
https://photos.app.goo.gl/75Lbobg39R4D9QUk6
It's a very strange coincidence that these errors only began soon
after the Btrfs volume becomes a two device fs. I forgot to mention
that while grub.cfg is on hfsplus, Fedora GRUB now uses blscfg.mod by
default which goes looking for BLS snippets, which happen to be on
/boot/loader/entries, which is on Btrfs. So even drawing the GRUB menu
does in fact need to read from the 2 device Btrfs.
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...
Looks to me that hd0, hd1, hd2, hd3, hd4 are all phantom devices. hd5
is the SSD, /dev/sda. cd0 is the empty dvd-rom drive.
On the basis of these info, it seems that when "ls" is run the errors come from the fact that:
- hd0..hd3 return errors when read (even before the end of device)
- hd4 returns error, because its size is 0 (as reported by grub)
However for these error btrfs seems not to be related.
Regarding the error at boot time; my hypothesis is that during the loading of the kernel, grub tries (but I don't know why) to read from hd0..hd4 returning an error. Unfortunately the videos is not available anymore.
Could you be so kindly to share the picture of the loading of the kernel/initramdisk ? Something like:
grub> set debug=all
grub> initrd /boot/initrd....
I hope that the errors come quickly. I don't think that we need the pictuers of all the download. It would be sufficient the pictures until the first (or better second) error....
BR
G.Baroncelli
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.
These errors may be misleading because the Fedora grubx64.efi doesn't
contain them, and I've only copied a few GRUB modules from
/usr/lib/grub/x86_64-efi to /boot/efi/EFI/fedora/x86_64-efi
The default installation on Fedora doesn't copy external modules to
the ESP at all, so only the ones already in the grubx64.efi are
available.
--
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
