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

Zfs problem


(xforce) #1

When I try to boot I’m getting this error
ERROR: Root device mounted succesfully, but /usr/bin/runit-init does not exist.

When I’m checking new_root, I see most of the zfs filesystem is mounted, but the usr folder is empty,

When I boot from live cd and mount the zfs volume, the usr folder has the correct files though,

no Idea why its not working

I set the correct bootfs

edit
I now changed zfs=boofts to my rootdataset directly, and on the startup it first says it can’t import the pool, and then it cant find the dataset

when i enter zfs in busypool, it shows all sets correctly and the pool loaded


#2

Are you using GRUB?

What does your GRUB_CMDLINE_LINUX_DEFAULT line read? (I have “loglevel=4 elevator=noop noresume …” then some laptop specific stuff.)

If you look in your /boot/grub/grub.cfg, what does your "linux " line say?

I have: linux /vmlinuz-4.11.8_1 root=ZFS=tank/ROOT/void (tank/ROOT/void being the zfs path to my rootfs.

You might also try adding zfs_force=1 to your kernel boot parameters.

But if you set the bootfs property for your rootfs dataset and set the cache file, you shouldn’ t need to do that.

I found this to be a decent guide to running zfs on void.

EDIT: Looking at your error message, I would hazard a guess that you didn’t get Void properly installed on the ZFS dataset(s). That you can see the files if you mount the filesystem from a livecd seems to tell against this though. How are your zfs filesystems set up?


(xforce) #3

hi. thanks for your help.
i’m using efibootmgr
my command line looks like this

efibootmgr -d /dev/sdd -p 1 -c -L "Linux" -l /EFI/vmlinuz-4.11.7_1 -u "cryptdevice=/dev/disk/by-uuid/926c97fd-c0f6-4baa-b40d-6eff65a00546:zfs zfs_force=1 zfs=zroot/ROOT/default rw initrd=/EFI/initramfs-4.11.7_1.img init=/sbin/runit-init"

tried it before without the init part, didn’t work as well

zfs is setup like this
zroot/ROOT/default = /
and datasets for /usr /var and most other folders
zroot/usr


#4

You’re using LUKS encryption? I wasn’t able to get an encrypted ZFS root to work on Void. See here: Setting up GRUB boot for LUKS encrypted ZFS root? especially Setting up GRUB boot for LUKS encrypted ZFS root? .

So it may just not work. At least not with patching cryptsetup or the like. The only other thing you might try is changing zfs=zroot/ROOT/default to root=ZFS=zroot/ROOT/default, but I doubt it will make a difference.

My compromise solution was to create two separate ZFS partitions, one non-encrypted for / and one encrypted for /home .


(xforce) #5

yes I’m using luks, I think it should be able to work, I’ve read lots of forum posts, from people using luks and zfs, but with other distros

also the decryption works., and its importing the zfs, somehow it doesnt correctly mount or boot them

thanks for the links, going to try this


#6

I burned lots of hours and wasn’t able to get it working in Void w/ GRUB (I did have it working with Ubuntu). Do you let me know if you find something that works - I’d be very interested.


(xforce) #7

okay will do,
interesting that its working in Ubuntu but not in void? why could that be
I’m using mkinitcpio for the initramfs

did you have the same error message as me?
did your system manage to decrypt and import the zfs pool?


#8

The Ubuntu setup I got to work used a hacked zfs-initramfs to get round the cryptsetup problems with zfs. I’m pretty sure that’s the difference. The other path might be to try to patch cryptsetup to work properly with zfs, see https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1612906 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820888

Indeed, I did not have an error message like “ERROR: Root device mounted succesfully, but /usr/bin/runit-init does not exist”, but rather couldn’t get the luks encrypted zfs filesystem to be mounted properly at boot. It would hang after accepting a password for decryption.

I was using dracut and GRUB rather than mkinitcpio and efibootmgr, so it’s possible some of the behaviour will differ. (Though, sadly, it doesn’t sound like mkinitcpio and efibootmgr are faring better so far in terms of actually working properly.)


(xforce) #9

before mkinitcpio I tried dracut,
the command line options for dracut are different , but it managed to decrypt the luks drive,
but if I remember correctly, I had the system crashing too, before changing the config

anyway I am going to try, and if I get it to work post it here


#10

Hi,

after some testing I figured that the needed “kernel-parameters” do not apply to the kernel, but to the initrd-image. So the needed parameters to boot from an encrypted device differ if you are using dracut or mkinitcpio.

On my laptop I used the following entrys in my /boot/grub/grub.cfg to boot both systems from the same pool:

menuentry 'Encrypted Void Linux' --class void --class gnu-linux --class gnu --class os {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod cryptodisk
	insmod luks
	insmod gcry_rijndael
	insmod gcry_sha512
	insmod zfs
	cryptomount -u 099cc8cb4add4cb28d9f0469b3e18c28
	set root='cryptouuid/099cc8cb4add4cb28d9f0469b3e18c28'
	echo    'Loading Encrypted Void Linux ...'
	linux   /ROOT/void/boot@/vmlinuz-4.11.10_1 root=ZFS=rpool/ROOT/void ro zfs=rpool/ROOT/void rd.fstab=1 rd.luks=1 rd.luks.uuid=edd39c49-370e-44f7-a184-3b928a10296e rd.luks.crypttab=0
	echo    'Loading initial ramdisk ...'
	initrd  /ROOT/void/boot@/initramfs-4.11.10_1.img
}

menuentry 'Encrypted Arch Linux' --class arch --class gnu-linux --class gnu --class os {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod cryptodisk
	insmod luks
	insmod gcry_rijndael
	insmod gcry_sha512
	insmod zfs
	cryptomount -u 099cc8cb4add4cb28d9f0469b3e18c28
	set root='cryptouuid/099cc8cb4add4cb28d9f0469b3e18c28'
	echo    'Loading Encrypted Arch Linux ...'
	linux   /ROOT/arch/boot@/vmlinuz-linux root=ZFS=rpool/ROOT/arch rw zfs=rpool/ROOT/arch zfs_force=1 cryptdevice=/dev/sda1:root_crypt cryptkey=rootfs:/etc/luks/root_crypt-luks.key
	echo    'Loading initial ramdisk ...'
	initrd  /ROOT/arch/boot@/intel-ucode.img /ROOT/arch/boot@/initramfs-linux.img
}

On void dracut needs only this /etc/dracut.conf.d/10-crypt.conf:

install_items+=" /etc/fstab"

This is all that remained after I did some testing, so the filename is still missleading. I got rid of all the zfs, crypt and other stuff I read of. Some of it, like hostonly=yes, prevented dracut -vf or xbps-reconfigure -f linux4.11 from creating a new initrd-image. I dont know why. The fstab-entry remains because I boot both systems from the same pool, so i set mountpoint=legacy for both root datasets and used the fstab, for example:

# System
rpool/ROOT/void           /         zfs       rw,relatime,xattr,noacl  0 0
rpool/ROOT/void/var       /var      zfs       rw,relatime,xattr,noacl  0 0
rpool/ROOT/void/boot      /boot     zfs       rw,relatime,xattr,noacl  0 0

# system-wide grub.cfg
rpool/ROOT/grub         /boot/grub  zfs       rw,relatime,xattr,noacl  0 0

# Swap
/dev/mapper/swap_crypt  swap      swap      defaults                 0 0

# tmpfs
tmpfs                   /tmp      tmpfs     defaults,nosuid,nodev    0 0

On the arch system the /etc/mkinitcpio.conf looks like this:

MODULES="zfs lz4 lz4_compress"
BINARIES=""
FILES="/etc/fstab /etc/luks/root_crypt-luks.key"
HOOKS="base udev autodetect modconf block keyboard encrypt zfs"
COMPRESSION="lz4"

Using mkinitcpio and arch linux the initrd opened the root-fs for itself. I never got voids dracut-image to do this, so i had to input the password a second time after grub on every boot wich was quite anoying.

But in the mean time i switched back to using an unencrypted separate boot-zpool to get rid of grub opening the luks-device using the cpu’s real-mode. These are 40 seconds of my lifetime wasted again and again.

Hope this helps.

EDIT:

Just to avoid deadly errors: If you put your initrd on an unencrypted filesystem too, use lsinitrd /boot/initramfs-4.11.10_1.img | grep etc to make sure that there is no luks-key stored within the image.