Don't know where to mount a zfs home dataset in /etc/fstab to

[shadowrylander]

Hello! Me again! 😹

I was just wondering where I should mount my zfs home partition on endeavour os / arch after installing bedrock; the setup was working fine before installing it, and now I can't get back into my account. This is what was in my fstab:

[pool]/home    /home    zfs    defaults,nofail,x-systemd.requires=zfs-mount.service    0 0

And this doesn't work either:

[pool]/home    /bedrock/strata/endeavouros/home    zfs    defaults,nofail,x-systemd.requires=zfs-mount.service    0 0

Any help would be greatly appreciated!

[paradigm]

Some background: The Linux kernel's primary tool to manipulate the virtual filesystem layer is mount points, and so they're one of the more notable tools Bedrock uses to control processes see what files where. Bedrock sets up a number of mount points before handing control off to the selected init system, including one on /home. Some software which mount /etc/fstab on startup will skip mounting on locations that are already mount points. Presumably, upon seeing a preexisting mount point, they assume the item has already been mounted, and consequently skip them. To work around this, Bedrock will mount /etc/fstab itself before handing control off to the selected init. This works adequately for most use cases. However, Bedrock proper doesn't know how to mount zfs entries. This is why you're running into this. In the long term I'd like to fix this by using the selected init's tools to mount /etc/fstab, although it's something of a catch-22 problem that may require some finesse. This is something I very much want to do, but I can make no promises about when I get around to it.

I don't know zfs, but for other filesystems one could in theory work around this by just running the mount command directly. For example,

mount /dev/sdb1 /home

This would mount over the Bedrock created mount point, which is exactly what we want. This could be automated by placing the command in /etc/rc.local (and possibly enabling rc.local support in your preferred init if it does not support it out-of-the-box). I do not know the zfs equivalent command here; perhaps you do.

The other obvious work-around is to not use a zfs mount for any Bedrock global location, although I certainly understand why that's not ideal.

[shadowrylander]

So close! I was hoping to see where bedrock would mount /home in a system without the zfs mount and use that in the fstab, but apparently that wouldn't work. Would it be possible to use a systemd unit file to mount /home instead of using rc.local?

[paradigm]

So close! I was hoping to see where bedrock would mount /home in a system without the zfs mount and use that in the fstab, but apparently that wouldn't work.

I applaud the reasoning there; it totally makes sense absent some of Bedrock's unique quirks.

Would it be possible to use a systemd unit file to mount /home instead of using rc.local?

Only reason I default to recommending rc.local is it's a touch more portable; if you ever want to reboot into OpenRC or runit or SysV, that'll also be available.

Provided you don't foresee that, or intend to cross that bridge when you come to it, I don't see any reason against using a systemd unit file here.

[shadowrylander]

Applaud the reasoning [...]

Why thank you! 😸

Switch to another init manager

I'm actually using a combination of systemd and runit-systemd; runit seems to be better for continuous processes, while systemd for one-time processes, such as reboots, etc. So it's the best of both worlds! As long as I don't switch to Void, and that's unlikely to happen on a Surface Book 2 due to the lack of HiDPI support in the installer, and poor eyesight on my part.

I think that solves my problem for now, then! I'll go ahead and mark this as closed! Thank you kindly for the help! 😸

[paradigm]

Happy to help! Sorry you ran into this in the first place. Hopefully I'll figure out that catch-22 of using the init stratum's mount infrastructure to mount /etc/fstab before doing Bedrock setup before launching the init so the work around we settled on isn't required for others in the future.

[shadowrylander]

That would be useful! 😹 Thanks again!