Home | News | Download | Packages | Forum | Wiki | Github

I cannot build zfs in chroot?


#1

In short: I want to boot Void off of a zfs dataset (using legacy mounts, but that’s irrelevant here), and i can, without problems, build zfs and dependencies on the host/installation system, but it fails in the chroot to the new system. (I can boot the kernel from GRUB, but it doesn’t get past the kernel messages because it has no root)

I have, by now, only one zfs dataset for Void (mostly because this is just a test run, the actual install will have multiple datasets), which is data/void.
On the install system (which has zfs built successfully), i mount that dataset using mount -t zfs data/void /mnt, which works just fine.
I then run for dir in dev proc run sys; do mount --rbind /$dir /mnt/$dir; done to mount the needed directories, followed by a chroot /mnt /bin/bash.
Inside the chroot, i installed zfs using xbps-install -S zfs. I didn’t notice it failed for some time, because it literally says “FAILED” and nothing else. That’s why i know the kernel boots properly - i have tried to boot it multiple times and it worked, except for the missing zfs support of course.
No matter what i try (mostly editing dracut config files), i can’t get it to build inside the chroot. I have tried multiple kernel versions as well.
What could be the issue? How can i see why exactly it fails, and not just FAILED?
Thanks in advance


#2

ZFS is not part of the mainline kernel so you may compile it by yourself with ZFF support… Just a guess…


#3

Okay, i guess i need to clarify - i want to use the the zfs module that is to be built with dkms and provided by the zfs package i the Void repos. The dkms hook on the kernel for zfs fails.


#4

Ahh okay.

I am not sure but I think to build a dkms module you have to running kernel you are building for… Further you need to have the kernel headers installled… On arch linux I wasn’t able to build dkms modules inside chroot neither…


#5

More background info: I’m using this and this as my main references, and i can successfully build the “spl” dkms inside the chroot, zfs is the only module that fails.
My current dracut config looks like this:

hostonly="yes"
nofsck="yes"
add_dracutmodules+=" zfs "
omit_dracutmodules+=" btrfs resume "

I have also tried mounting the file systems with mount -t procfs proc /mnt/proc etc., which didn’t really change anything.


#6

I wonder if this is useful here?


#7

@emacsomancer i don’t think so, at least right now (as i think i would have to understand how that is built).

I have now turned off the quiet flag for the dkms calls (in /etc/kernel.d/post-install/10-dkms), so i can actually see the error messages - they look like this:
Screenshot_20180409_072807

Screenshot_20180409_072905
(config.log doesn’t really say anything, it looks more like, well, a config file, but i could upload it as well if someone thinks it would be of help)
I will now try reinstalling the zfs package and see if that helps.

EDIT: Looks like it might be this: https://github.com/zfsonlinux/zfs/issues/7358


#8

The thing is, this has to work in order to have the root on zfs - there is no other way to accomplish this, at least not one that I can think of.
I think I’m gonna try destroying that dataset and reinstalling Void on it once again - maybe some packages were broken at the time of bootstrap and they are fixed now, or something went wrong with my connection back then.

UPDATE: So my third bootstrap attempt didn’t reveal much more than the first two; this time, i tried installing the grub package as well (even tho i don’t need it), and i also added zfs to the initial bootstrap command. Nothing changed, really; the only thing i noticed was that when installing zfs from outside of the chroot, both dkms modules (spl and zfs) fail to build, whereas inside of the chroot, only zfs fails, while spl works fine. I really wonder what i’m missing here.


#9

I have tried a lot more stuff and still had no sign of success.
I now have also built zfs on the main system multiple times, so i’m pretty sure it works reliably as long as i’m outside the chroot.
Because it works there, i’m currently trying to compare the build environments.
I have noted the kernel source directories (and other details) from both the host/main system’s and the chroot’s dkms output:

Host:
checking for target asm dir... asm-x86_64
checking kernel source directory... /lib/modules/4.15.15_1/build
checking kernel build directory... /lib/modules/4.15.15_1/build
checking kernel source version... 4.15.15_1
checking kernel file name for module symbols... Module.symvers
checking spl source directory... /usr/src/spl-0.7.7
checking spl build directory... /var/lib/dkms/spl/0.7.7/4.15.15_1/x86_64
checking spl source version... 0.7.7-1

chroot:
checking for target asm dir... asm-x86_64
checking kernel source directory... /lib/modules/4.15.15_1/build
checking kernel build directory... /lib/modules/4.15.15_1/build
checking kernel source version... 4.15.15_1
checking kernel file name for module symbols... Module.symvers
checking spl source directory... /usr/src/spl-0.7.7
checking spl build directory... /var/lib/dkms/spl/0.7.7/4.15.15_1/x86_64
checking spl source version... 0.7.7-1

So everything’s identical there.
After that, i tried to compare the content of the different build directories, but to no extent - they are identical, except for the fact that the host already has the zfs modules, of course.
I have also diffed the /usr/include dir of both the host and the new system, and i have installed some packages that i thought might be needed for zfs, including libmount-devel and libblkid-devel, but it didn’t change anything.
I cannot efficiently compare the installed packages of both systems, because the (older) host system has over 1000 more packages installed and i wouldn’t know how to tell which one could have do to with zfs.
I will continue my (re)search.

If anyone who’s better at parsing such things would like to help me, here’s the list of packages the host has, which the new chrooted system doesn’t have (1053): https://hastebin.com/owujarobed.css


#10

Install perl in your chroot and the DKMS build hook for ZFS will finish correctly.

export ZPOOL_VDEV_NAME_PATH=1
xbps-install perl
xbps-reconfigure -f linux4.15

Edit: zfs-0.7.8_2 has this fix rolled in.


(Edmond Dantes ) #11

if you’re insterested in building and maintaining a Linux kernel with built-in OpenZFS/SPL support, using zfsonlinux without relying on dkms, check out the ZFS root (builtin) page from Slackwiki: it’s the only acceptable guide I’ve ever found on the topic. Remainder: the key configure params for the zfsonlinux port are:

--enable-linux-builtin Configure for builtin in-tree kernel modules
--with-linux=PATH Path to kernel source
--with-linux-obj=PATH Path to kernel build objects
--with-spl=PATH         Path to spl source
--with-spl-obj=PATH     Path to spl build objects

And then enable Solaris Porting Layer and ZFS file system support in your kernel config. Once I tested this with make menuconfig and it successfully detected zfs on the source_dir.