ZFS root on Manjaro

I thought I would provide an update for the people interested in this.

I created the merge request for the minor changes referenced above.

I also started looking at what would really be required for zfs support in m-a.

I created a local zfs branch of m-a that added support for zfs root to the mkinitcpio hooks and bootloader support for grub-uefi, grub-mrb and systemd-boot. I will push that branch tomorrow so anyone who is interested can take a look.

In theory, I should be able to knock out fstab generation, service enablement and cache creation pretty easily.

4 Likes

These all went as expected and are available in the zfs branch in gitlab.

I guess next I need to work on zpool/dataset creation. This will require new strings that need translation.

How should I handle that @Chrysostomus? Put them all in as english and wait for someone else to translate them? Use google translate for initial translations?

1 Like

This is what I do. Remember the #translate me! tags

1 Like

If we get zfs support working, I’ll add zfs and spl modules to the dependencies so that they get pulled into the the new isos automatically.

2 Likes

I mergedthe findmnt improvements. I also found the reason why grub installations were not properly detected and fixed it. The next update seems to be coming along nicely.

All that is left is:

  • microcode support for refind
  • zfs support
3 Likes

Nice! I had been noticing that grub uefi installations weren’t being detected on my grub installs and was hoping it wasn’t something I did. :smile:

With the exception of refind support, I should have it done by the end of the weekend at the latest. It is coming along fairly well and testing the partitioning and filesystem stuff is much less time consuming than testing the bootloader stuff.

What about amd microcode support for all bootloaders?

If I can finish off the zfs stuff the other thing I would like to do is have the systemd-boot stuff create hooks so that it gets updated when systemd updates or new kernels are installed.

Should get done at the same time.

This should be packaged as pacman package that just gets installed by manjaro-architect

1 Like

OK, here is the status for today.

At this point, in the zfs branch it is possible to do an end-to-end install in m-a using zfs as long as you use automatic zfs provisioning(and are using an ISO with the kernel modules for zfs).

Here is what I think remains for an initial implementation:

  • All the manual zfs provisioning
    • Importing existing zfs pools
    • Manual creation of mounted and legacy zfs FS datasets
    • Creation of zvols
    • Destruction of zfs datasets
  • Additional modifications to the mounting menu list to include zvols and legacy mounted zfs FS
  • Add the zfs and spl kernel modules to the package list automatically if you have a zfs root
  • refind support
  • Review error handling
  • Updating all the translation files
  • More testing

With the exception of the refind support(and testing), all of the above should be pretty basic. I think most of the heavy lifting is already complete. refind probably isn’t hard, I just don’t know anything about it so I will have to muddle through it.

I can do that part if you provide the variables needed for the kernel parameters.

We should maybe add more automation to that dialog anyway. Detect virtualbox and wifi drivers automatically too.

We can probably do a release already before this. That way we can get earlier testers for the new features.

1 Like

Excellent! For systemd-boot it was as simple as replacing root=device to zfs=rootdataset. So it is just zfs=$(findmnt -ln -o SOURCE ${MOUNTPOINT}) rw

For grub it was more of a pain because of grub-mkconfig being picky. I am pretty unhappy with that solution but I couldn’t find a better way to get an environment variable to manjaro-chroot I tried using sh -c but the quotes always got stripped. It works, but it isn’t pretty.

We should be pretty close then.

These are done and pushed. I also did a lot of testing.

I realized I need to add options to all the dataset creation menus to the list. That seems like tomorrows task.

3 Likes

I finished all the changes except for the support for refind. Everything has been pushed but I am still testing.

Pretty much everything has passed my testing so far except for two issues.

The first is that the initrd fails to load the root filesystem on certain hardware. I am not certain yet what they cause of that is yet but I can reproduce it so I will research that tomorrow.

The second is that since the last stable update 3 days ago the grub install on uefi systems takes 5+ minutes regardless of hardware platform. The same issue seems to be present in the current version of m-a so it doesn’t seem to have been introduced with my changes. Has anyone else reported that issue yet @Chrysostomus?

Also, my testing has been limited to testing zfs(zvols, zfs mounted filesystems and legacy mounted filesystems), btrfs and ext4 installs with the new code.

I haven’t tried anything exotic. I suppose since zfs can create block devices you could theoretically do something like xfs on lvm on luks on an encrypted zvol in a zpool on lvm on luks. That seems well beyond the realm of rational though.

3 Likes

I’m actually trying something very similar at the moment (basically my first steps with ZFS), but not on root. All in VBox because I lack the hardware.

My goal is to create a zvol block device, create a LUKS on top of that, and format the opened LUKS with ext4 or xfs. Then adapt crypttab and fstab.
I’ve not been very successful though, as the system is trying to unlock the LUKS before the zpool has been set up. Still investigating.

Also thumbs up for your work regarding ZFS on root, looking forward to it!

Not to me, no. Could be a issue with the Grub package. Is it grub-install or grub-mkconfig issue?

Fixed the above issue by editing some systemd units.
One has to remove cryptsetup.target from the After line in zfs-import-cache.service, and create a drop-in unit for systemd-cryptsetup@name.service with After=zfs-mount.service zfs-import-cache.service.

Maybe that will help you for the more complex ZFS tasks.

EDIT: no :frowning: still doesn’t work due to systemd dependency hell, needs more investigation.

I haven’t investigated it extensively. I am still waking up, but if I am remembering correctly I think it happens in the basestrap of grub-theme-manjaro. So I would speculate it is getting hung up in grub-mkconfig. I can watch it more closely when I am testing this evening.

I am not that familiar with luks but it would probably be easier on a zfs root because the zpool gets loaded earlier.

Have you looked at the encryption options that zfs provides?

Only the git version has encryption enabled.

What I was trying to do is LUKS on ZFS - what does work though is ZFS on LUKS. The problem with that is that with multiple disks, you would have to enter the LUKS password for each of them which would be quite annoying.
A workaround would be to use a USB dongle which contains keys.

@anon23612428: in Ubuntu (I know…) I decrypt the first disk with a password and all the others with a key generated out of the first disk. That works quite well. So disk 2,3,4,… have two decryption methods. One: password, 2: key generated from the first disk. If I remember correctly, a luks device can have 4 different “keys”.

That was my idea too, and I’m sure it also works on Manjaro.
But where do you put the key on the unpartioned first disk?

Forum kindly sponsored by