View previous topic :: View next topic |
Author |
Message |
KShots Guru
Joined: 09 Oct 2003 Posts: 591 Location: Florida
|
Posted: Mon Dec 19, 2016 10:52 pm Post subject: ZFS+LUKS+systemd+dracut==headache |
|
|
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:
dracut.conf Code: | add_dracutmodules+="crypt plymouth systemd zfs"
hostonly="yes"
add_fstab+="/root/initrd-fstab" | 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: Code: | NAME PROPERTY VALUE SOURCE
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:
/root/initrd-fstab Code: | UUID="EC07-7720" /file vfat noatime 1 2 | My /etc/crypttab looks like this: Code: | 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: Code: | 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 zfs.target. 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: Code: | 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 |
|
|
Roman_Gruber Advocate
Joined: 03 Oct 2006 Posts: 3846 Location: Austro Bavaria
|
Posted: Wed Dec 21, 2016 9:44 pm Post subject: |
|
|
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 |
|
|
|
|
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
|
|