On 16/04/2025 at 15:51, Martin-Éric Racine wrote:
ke 16.4.2025 klo 15.41 Pascal Hambourg (pas...@plouf.fr.eu.org) kirjoitti:
On 16/04/2025 at 13:38, Martin-Éric Racine wrote:
As the attached screenshot shows, 'fuseblk' seemingly doesn't know
anything about the 'subvol' option for btrfs, which is what causes the
failure to mount root. As to whether this implies a GRUB or Linux
module, I wouldn't know.
The failure has nothing to do with fuse.
I guess the kernel tries to mount the root filesystem with fuseblk as a
last resort *after* the initramfs unpacking failure because it is the
only built-in driver, all other block device/filesystem drivers being
modules in the initramfs.
Shouldn't a built-in autofs handle that part?
I am not sure what you mean by "autofs". AFAIK autofs is an on-demand
mount feature, so irrelevant for the root filesystem. The kernel image
(vmlinuz) does not have built-in block/filesystem drivers and needs to
load the related modules from the initramfs in order to be able to mount
the root filesystem.
Anyhow, that line about 'subvol' being an unrecognized option for
fuseblk is significant.
I don't think so. fuseblk is the wrong filesystem type and the "subvol"
option is intended for btrfs so it is not surprising that it is not
recognized.
If you start grub shell and load the kernel and initramfs by hand, does
it show an error when loading the initramfs ?
No error.
There may be some silent data corruption when grub reads the initramfs.
Can you test with the initramfs on another filesystem type (fat, ext4) ?
Can you test with grub for BIOS/legacy boot ?
