bugGNU GRUB - Bugs: bug #58555, grub-probe not identifying ZFS...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #58555: grub-probe not identifying ZFS root filesystem due to unsupported features

Submitter:  i336_ <i336_>
Submitted:  Sat 13 Jun 2020 08:33:14 AM UTC
   
 
Category:  Filesystem Severity:  Major
Priority:  5 - Normal Item Group:  None
Status:  None Privacy:  Public
Assigned to:  None Originator Name: 
Open/Closed:  Open Release:  Git master
Release:  Reproducibility:  Every Time
Planned Release:  None

Sat 13 Jun 2020 08:33:14 AM UTC, original submission:  

Hi all,

I've just set up a simple mirrored ZFS-on-root Debian configuration with /boot on a FAT32 partition. I'm temporarily using BIOS booting with grub-pc and a 1MB grub_boot partition, and plan to move the pool/disks to an EFI system later.

Attempting to configure GRUB for this scenario produced a /boot/grub/grub.cfg with entries like

  linux /vmlinuz-5.5.0-0.bpo.2-amd64 root=ZFS=/debian ro

which completely failed to boot due to the missing pool name.

Investigation revealed this was because grub-probe, called in /etc/grub.d/10_linux to identify the ZFS root pool name (http://git.savannah.gnu.org/cgit/grub.git/tree/util/grub.d/10_linux.in?id=6a34fdb76a07305b95e31659bc27b1d190101cbf#n76), bailed out with "grub-probe: error: unknown filesystem".

I incidentally configured multiple zpools in this setup, and idle curiosity revealed that grub-probe was able to detect one of the auxiliary pools:

  # grub-probe -t fs_label -d /dev/sda3
  grub-probe: error: unknown filesystem.
  # grub-probe -t fs_label -d /dev/sda4
  pool-1

Enabling verbose output revealed that zfs.c was bailing due to unsupported pool features:

  grub-core/fs/zfs/zfs.c:2115: zap: name = org.illumos:lz4_compress, value = 1, cd = 0
  grub-core/fs/zfs/zfs.c:2115: zap: name = com.joyent:multi_vdev_crash_dump, value = 0, cd = 0
  grub-core/fs/zfs/zfs.c:2115: zap: name = com.delphix:hole_birth, value = 1, cd = 0
  grub-core/fs/zfs/zfs.c:2115: zap: name = com.delphix:extensible_dataset, value = 1, cd = 0
  grub-core/fs/zfs/zfs.c:2115: zap: name = com.delphix:embedded_data, value = 1, cd = 0
  grub-core/fs/zfs/zfs.c:2115: zap: name = org.open-zfs:large_blocks, value = 0, cd = 0
  grub-core/fs/zfs/zfs.c:2115: zap: name = org.zfsonlinux:large_dnode, value = 1, cd = 0
  grub-core/kern/fs.c:78: zfs detection failed.

versus:

  grub-core/fs/zfs/zfs.c:2115: zap: name = org.illumos:lz4_compress, value = 1, cd = 0
  grub-core/fs/zfs/zfs.c:2115: zap: name = com.joyent:multi_vdev_crash_dump, value = 0, cd = 0
  grub-core/fs/zfs/zfs.c:2115: zap: name = com.delphix:hole_birth, value = 1, cd = 0
  grub-core/fs/zfs/zfs.c:2115: zap: name = com.delphix:extensible_dataset, value = 0, cd = 0
  grub-core/fs/zfs/zfs.c:2115: zap: name = com.delphix:embedded_data, value = 1, cd = 0
  grub-core/fs/zfs/zfs.c:2115: zap: name = org.open-zfs:large_blocks, value = 0, cd = 0
  grub-core/fs/zfs/zfs.c:2115: zap: name = org.zfsonlinux:large_dnode, value = 0, cd = 0
  grub-core/fs/zfs/zfs.c:2115: zap: name = org.illumos:sha512, value = 0, cd = 0
  grub-core/fs/zfs/zfs.c:2115: zap: name = org.illumos:skein, value = 0, cd = 0
  grub-core/fs/zfs/zfs.c:2115: zap: name = org.illumos:edonr, value = 0, cd = 0
  grub-core/fs/zfs/zfs.c:2115: zap: name = com.datto:bookmark_v2, value = 0, cd = 0
  grub-core/fs/zfs/zfs.c:2115: zap: name = com.datto:encryption, value = 0, cd = 0
  grub-core/fs/zfs/zfs.c:2115: zap: name = com.delphix:device_removal, value = 0, cd = 0
  grub-core/fs/zfs/zfs.c:2115: zap: name = , value = 0, cd = 0
  grub-core/fs/zfs/zfs.c:2115: zap: name = , value = 0, cd = 0
  pool-1
  grub-core/kern/disk.c:295: Closing `hostdisk//dev/vda'.

I did a bit of investigation, and traced that check_mos_features() calls mzap_iterate() with the check_feature() callback, which grub_strcmp()s each feature against a whitelist of known names (http://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/fs/zfs/zfs.c?id=6a34fdb76a07305b95e31659bc27b1d190101cbf#n285), and (back in mzap_iterate()) bails if any detected feature that is not known has a value of 1. Hence my conclusion above.

Incidentally, the pools were created with identical parameters:

  zpool create -o ashift=12 -O acltype=posixacl -O canmount=off -O compression=lz4 -O xattr=sa -O relatime=on -O dnodesize=auto -o cachefile=none tank mirror /dev/disk/by-partlabel/... /dev/disk/by-partlabel/... 

  zpool create -o ashift=12 -O acltype=posixacl -O canmount=off -O compression=lz4 -O xattr=sa -O relatime=on -O dnodesize=auto -o cachefile=none pool-1 /dev/disk/by-partlabel/...

  zpool create -o ashift=12 -O acltype=posixacl -O canmount=off -O compression=lz4 -O xattr=sa -O relatime=on -O dnodesize=auto -o cachefile=none pool-2 /dev/disk/by-partlabel/...

(The first is a mirror across two disks, while the other two are non-redundant, discrete pools on each disk that will provide sha256 checksumming.)

As a newcomer to ZFS, it appears to me that the root pool automatically enabled (?) the large_dnode attribute during installation because I have dnodesize=auto. I may be incorrect. (pool-1 has not been mounted or touched yet; I'm still setting everything up, etc.)
 
There are a couple conclusions I draw.

As a comparative niggle, grub-probe's exit status of 1 is not caught in 10_linux.

I outline my understanding of the bigger problem thusly:

- GRUB's ZFS implementation cannot handle all ZFS features, which is why there is a root-pool / boot-pool split.
- GRUB is calling grub-probe to supply Linux's root=ZFS=... parameter.
- grub-probe is using GRUB's zfs.c known-limited implementation to examine the root pool, which is likely to have features unsupported by GRUB enabled.

Perhaps I'm missing something here. I hope so...

Me: looks at every working GRUB 2 ZFS-on-root setup everywhere
Me: looks at the above, which says that everything should be catastrophically broken
Me: explodes

Let me know what additional information I can provide. This is an effectively blank system, so you can reply with SSH pubkeys if that would be helpful (the only caveat being 250ms RTT to .com.au).

Thanks in advance,

David Lindsay

NB. The non-head refs in the links point to the current Git master, for posterity.



i336_ <i336_>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by edechamps
  • -email is unavailable- added by i336_ (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-05-29 edechamps Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code