Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
View unanswered posts
View posts from last 24 hours

Reply to topic    Gentoo Forums Forum Index Unsupported Software
View previous topic :: View next topic  
Author Message

Joined: 09 Oct 2003
Posts: 505
Location: Florida

PostPosted: Mon Dec 19, 2016 10:52 pm    Post subject: ZFS+LUKS+systemd+dracut==headache Reply with quote

Yeah, it's a headache... but it's apparently workable. ZFS on top of LUKS took an entire weekend to figure out, and in the end I can rather solidly point the finger at the ZFS scripts for dracut (I'll describe that below). At any rate...

Eventually, I managed to get a somewhat working solution as described below:

add_dracutmodules+="crypt plymouth systemd zfs"
Kernel command line should include root=zfs:AUTO according to the documentation... I haven't seen any evidence this actually tells dracut where the root device is. In addition, you should define a bootfs entry for your zpool:
rpool  bootfs    rpool/ROOT/rootfs  local

In my setup, I have my decryption key stored on a USB thumb drive, which is removed when the system boots (hence the inclusion of the fstab in dracut.conf). It simply looks like this:
UUID="EC07-7720" /file vfat noatime 1 2
My /etc/crypttab looks like this:
rpool-crypt     UUID=1747abc4-9804-4888-8cce-e2f510dc926f       /file/key           luks
swap                                            /dev/disk/by-id/scsi-2001b4d231010d801-part1 /dev/urandom            swap,cipher=aes-xts-plain64:sha256,size=256
This uses the key from the thumbdrive to unlock rpool-crypt, and initializes some randomly encrypted swap on boot. All this works great... however dracut generates an initrd that looks for a root of /dev/block/ and waits indefinately (forever). Poking at the initrd, I found that /etc/cmdline.d/95root-dev.conf has the following:
 root=/dev/block/ rootfstype=zfs rootflags=rw,relatime,xattr,noacl
I couldn't say why it has /dev/block/ defined as the root parameter, but removing the 'root=' argument entirely causes the system to boot and initialize successfully. I've enabled all the zfs-*.service units (except zfs-import-scan.service, as I'm using the ZFS cache instead, and the zfs-zed.service). I also enabled the On the entirely possible chance I've mis-configured something, is there a better way of doing this? Or is this a bug in the ZFS scripts for dracut? It's a bit inconvenient to have to re-open every initrd I ever generate to remove the root=/dev/block/ entry.

Further info:

ZFS version 0.7.0-rc2_86_g1528bfd
dracut version 044-r1
systemd version 226-r2
cryptsetup version 1.7.2

For those simply needing a working system, the script snippet below is what I use to automate the "band-aid" fix:
echo -e "Modifying the initrd to boot ZFS properly..."
rm -rf /tmp/initrd
mkdir -p /tmp/initrd || exit 1
pushd /tmp/initrd 2>&1 >/dev/null || exit 1
cat "${FILE}" | cpio -i || exit 1
sed -i 's|root=/dev/block/ ||' etc/cmdline.d/95root-dev.conf || exit 1
find . | cpio --create --format='newc' > "${FILE}" || exit 1
popd > /dev/null
... where FILE is the full path to the initrd image (this assumes your initrd is uncompressed - adjust as suitable if it is compressed)
Life without passion is death in disguise
Back to top
View user's profile Send private message

Joined: 03 Oct 2006
Posts: 3806
Location: Austro Bavaria

PostPosted: Wed Dec 21, 2016 9:44 pm    Post subject: Reply with quote

Nothing unusual.

I also had to adapt my "genkernel" initramfs because it is / was broken / maybe still is broken.

I would not name it a headache. I would name it a custom solution and a learning curve. Nothing premade. I just assembled a few pieces and when you have basic knowledge how a box boots, it can be achieved.

I use busybox with lvm2, luks, ext4 and grub2 prerelease.

I am not fond of exotic software !

I would not expect any initramfs / init script to work for every use-case possible. I would not expect that any piece of initialization will work with every available piece of software which comes next!

The busybox part was easier to adapt as the other available solution a year ago for myself. I assume it is / was a coding error of the guy who wrote the gentoo genkernel script in my case!
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Unsupported Software All times are GMT
Page 1 of 1

Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum