[Bug 221075] regression: 11.1 is unable to mount ZFS / on boot

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Mon Oct 23 07:50:06 UTC 2017


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221075

Markus Wild <freebsd-bugs at virtualtec.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |freebsd-bugs at virtualtec.ch

--- Comment #15 from Markus Wild <freebsd-bugs at virtualtec.ch> ---
Just wanted to add a "me too" mention for this bug.

Short summary:
- Supermicro X10DRI-T motherboard, using UEFI boot, 128G RAM, 2 CPUs
- 2 Intel DC P3700 NVME cards, to be used as mirrored zfs root and mirrored log
devices for a data pool
- FreeBSD-11.1 release installs fine off memstick, and the built system boots
correctly, but this system uses the entire
  disks (so I need to shrink the system to make room for log partitions)
- so I then rebooted into usb live system, and did a gpart backup of the nvme
drives (see later). zfs snapshot -r, zfs
  send -R > backup, gpart delete last index and recreate with shorter size on
both drives, recreate zroot pool with
  correct ashift, restore with zfs receive from backup, set bootfs, reboot
- the rebooting system bootloader finds the zroot pool correctly, and proceeds
to load the kernel. However, when it's
  supposed to mount the root filesystem, I get:
    Trying to mount root from zfs:zroot/ROOT/default []...
    Mounting from zfs:zroot/ROOT/default failed with error 6.
- when I list the available boot devices, all partitions of the nvme disks are
listed
- I can import this pool without any issues with the usb live system, there are
no errors on import.
- I then redid the whole exercise, but restored the previously backed up
partition tables (full size zfs
  partition), did exactly the same steps as described above to restore the
previous zfs filesystem, rebooted, and the
  system started up normally.

I then tried to recreate the pool using nvd0p3/nvd1p3 instead of gpt-labels,
but this didn't help. But, when I built a custom
kernel as suggested here:

include GENERIC
ident CUSTOM
nodevice mmc
nodevice mmcsd
nodevice sdhci

this kernel booted fine! So, whatever went into the system for MMC support is
messing with correct mounting of zfs root pools...

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-fs mailing list