ZFS install/boot fails; no such pool and/or Could not find the root block device

[rspartz]

Hello!  I have tried many times to get this to work based on the fine ZFS_Install_Guide but I consistently fail at this point (see screenshot).

Both the kernel and initramfs are completely rebuilt using genkernel, but it can never find 'rpool' as the root device.

Any guidance is appreciated!

[temptorsent]

Hello,

To help figure out what's going on, a little more information is needed.

• Can you confirm that your pool is called 'rpool' and you exported it when you finished the creation steps?
• Did you set the bootfs attribute on the pool correctly?
• Did you make sure you copied the cache file?
• Does the grub.cfg have anything odd that might be forcing a wrong uuid and otherwise look correct?
• Did the zfs and spl modules load and are they the right version?

To be safe as far as the initramfs goes, you should emerge your kernel sources, use genkernel to build just the kernel, then emerge zfs, spl, & zfs-kmod, then use genkernel to build the whole initramfs using the flags for at least zfs and uuid support, then continue on with grub and verify the cfg refers to the correct initramfs filneame!

Take care,

   ~~~Chris~~~

 

P.S. #funtoo on freenode.net is a great place to get live help and discussion.

[rspartz]

Hello, Chris -

To answer about the 'pool' and the 'bootfs' info:

sysresccd ~ # zpool list
NAME    SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
rpool   191G  12.8G   178G         -     3%     6%  1.00x  ONLINE  /mnt/funtoo
sysresccd ~ # zpool get bootfs rpool
NAME   PROPERTY  VALUE              SOURCE
rpool  bootfs    rpool/ROOT/funtoo  local
sysresccd ~ #

Here's the zpool.cache info, both from /tmp and inside the chroot:

sysresccd ~ # ls -lsda /tmp/zpool.cache
4 -rw-r--r-- 1 root root 1416 Feb  8 08:30 /tmp/zpool.cache
sysresccd ~ # ls -lsda /mnt/funtoo/etc/zfs/zpool.cache
5 -rw-r--r-- 1 root root 1416 Feb  7 17:22 /mnt/funtoo/etc/zfs/zpool.cache
sysresccd ~ #

I've attached my grub.cfg for review:

As far as the zfs , spl and zfs-kmod loading, I don't know how to check that right at the moment of booting where it fails. I have gone to 'shell' and did lsmod , and it does show zfs but I can't confirm the other two.

 

I did read your advice at the bottom and I went through your steps, very carefully, and still no luck on the boot. I've even taken the initramfs that genkernel creates, extracted files from it and verified that the zpool.cache that is in the initramfs *matches* the one in /etc/zfs <shrug>

Also for point of reference, the version fo ZOL is

sysresccd /mnt/funtoo/boot/grub # dmesg | grep ZFS
[   27.796730] ZFS: Loaded module v0.7.5-r0-gentoo, ZFS pool version 5000, ZFS filesystem version 5
sysresccd /mnt/funtoo/boot/grub #

Is that version too new?

Also, for reference, this is the 3rd stage that I am using to build this vm:

http://ftp.osuosl.org/pub/funtoo/funtoo-current/x86-64bit/intel64-haswell/2018-02-04/stage3-intel64-haswell-funtoo-current-2018-02-04.tar.xz

My question to you is, have you been able to successfully boot after following the Guide? Or, as you read it, is there something that might be assumed that may  be worth mentioning? I say that because I tried the Guide awhile ago and I could never get the zpool to 'export' at the end. Well the piece that I was missing was 'freeing up swap' so the pool could be exported. That was not mentioned at that time, but I see now it's been added to the guide.

I really appreciate the response!

-=Ray

 

 

 

 

 

 

 

 

 

 

 

 

 

grub.cfg

[Tassie_Tux]

Hi folks. I have spent most of last week working through https://www.funtoo.org/ZFS_Install_Guide again, with a view to update/fix the guide where needed.

I too am facing the exact same issue. With over 8 retry-from-scratch attempts so far, the initramfs cannot import the pool.

I am using a QEMU/KVM virtual machine as the install environment and I have tried using Ubuntu 16.04 and 17.10. All unsuccessful. The build is funtoo-current x86-64bit intel64-sandybridge.

My current thinking is that the problem lies with the initramfs created by sys-kernel/genkernel. On pool import failure I go into the initramfs shell and see that there are no /dev/disk/by-id/ symlinks. Given that these links were used at pool creation and are referenced by zpool.cache, their absence in the initramfs is perhaps the cause of this import failure. (I cannot remember now whether or not I tried 'zpool import -d /dev rpool' from the initramfs shell. Too many attempts to keep track of!)

Anyhow... that is my theory. On a Windows PC I have Funtoo on ZFS root in VirtualBox. That instance of Funtoo is what I used as the basis of updating https://www.funtoo.org/ZFS_Install_Guide back in late 2016. My goal this weekend is to look at that initramfs to confirm or exclude my theory that the issue is initramfs lacking /dev/disk/by-id/ symlinks.

I will let you know what I find out.

 

PS: 'swapoff /dev/zvol/rpool/swap' is indeed required to export rpool prior to first boot.

 

[nand.1]

I ran into this problem when upgrading ZFS from 0.6.5 to 0.7.5.

I resolved it with brute force.

When you run genkernel initramfs, it generates this warning:

* WARNING... WARNING... WARNING...
* Additional kernel cmdline arguments that *may* be required to boot properly...
* add "dozfs" for ZFS volume management support
* add either "real_root=ZFS" (bootfs autodetection) or "real_root=ZFS=<dataset>" to boot from a ZFS dataset

I heeded this warning and in /etc/default/grub I changed it from:

GRUB_CMDLINE_LINUX="dozfs real_root=ZFS=rpool/ROOT/funtoo"

to:

GRUB_CMDLINE_LINUX="dozfs real_root=ZFS"

Also worth noting is that I only ran into this problem on my server, which runs ZFS with mirrored VDEVs.

I had initially created the server pool with the following command:

root@ubuntu:~# zpool create -f -o ashift=12 -o cachefile=/tmp/zpool.cache -O normalization=formD -O atime=off -m none -R /mnt/funtoo rpool mirror /dev/disk/by-id/foo /dev/disk/by-id/foo mirror /dev/disk/by-id/foo /dev/disk/by-id/foo

My desktop computer, which runs a single disk pool as described in the ZFS install guide, was able to update ZFS successfully, without having to change it to bootfs autodetection.

I am not sure if this is a regression with GRUB or ZFS, but these were my observations. Try it out and see if it resolves the problem for you.

[Tassie_Tux]

(Disregard my earlier theory. The absence of /dev/disk/by-id/ symlinks is not the issue as my old/working Funtoo on ZFS root install does not have these in the initramfs yet boot successfully.)

 

At the GRUB command line, editing the parameters to boot with 'real_root=ZFS' is indeed successful, although there are several seconds delay.

 

In the initramfs shell I am able to successfully import the pool manually with 'zpool import -N -d /dev rpool'. The command 'zpool import -N -c /etc/zfs/zpool.cache rpool' however fails with the same message reported by rspartz.

[Oleg Vinichenko]

this is indication of initramfs being the main target in tracking the problem. this is must be reported on bugs.funtoo.org. The install guide and update for ZFS should work. Detailed report with what problems are.

[temptorsent]

Ray,

I was successful in building and booting my ZFS based system mostly following the guide, however I deviated in several important ways, including building a mirrored vdev and installing grub to both bootsectors to allow boot if one has failed, updating the kernel sources before building spl and the zfs userspace & modules, and most importantly, modified the grub configuration to autodetect and look for the right filename for my kernel; also, I don't have swap on the pool.

I am going to do a reinstall on my machine this weekend, not including recreating the datasets, and I will further evaluate the guide,  the zfs packaging, and genkernel itself for issues which may need to be fixed or clarified.

Take care,

   ~~~Chris~~~

[rspartz]

To all who've contributed to this thread;  so far no luck with any options suggested. I think I am in agreement with Oleg that initramfs must be the 'closest' to the root cause, or possibly something to do with GRUB since it consistently fails to find the 'root device'.

I will submit a bug report on this right away.

If anyone has more to add, after their own testing, please comment here and I will add to the bug report. -thank you.