Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debian documentation clarification: systemd vs initramfs mount #8200

Closed
pabloyoyoista opened this issue Dec 10, 2018 · 1 comment
Closed
Assignees
Labels
Type: Documentation Indicates a requested change to the documentation

Comments

@pabloyoyoista
Copy link
Contributor

I have been working for some time making ZFS work as root on several
Debian virtual machines and I have encountered some problems related to
datasets organization and mounting that have not been clearly addressed
in the documentation.

I have been following the Debian Stretch Root on ZFS[1] with the only
difference that I have placed root-descendant datasets under
"rpool/ROOT/root" instead of directly under "rpool". The reason for
that modification is that under "Debian GNU Linux initrd
documentation"[2] section "Equal level filesystems", it explains that
placing datasets directly under "rpool/ROOT" (or "rpool", it should not
make a difference) does not allow for automatic snapshot cloning and
mounting, making it impossible to automatically boot a whole system
from a snapshot.

However, this little change (placing datasets under
"rpool/ROOT/root") does not only allow for automatic snapshot cloning
and mounting, but it also modifies the behavior of regular datasets
during boot. Datasets placed under "rpool/ROOT/root" are mounted by
initramfs instead of by systemd, so things like "Debian Stretch Root on
ZFS" section "4.8 Fix filesystem mount ordering" do not apply.

It took me quite some time to understand why my system was behaving
this way, as the initrd documentation page does not clearly explain the
differences between the two architectures. It would have probably been
easier if it had been documented. In addition, the fact that systemd mount
generator[3] is integrated but still not included in any release
probably makes things even more messy.

Having said so, I wonder if there is a preferred way to contribute to the github documentation, as it is not possible to send pull requests.

[1] https://github.com/zfsonlinux/zfs/wiki/Debian-Stretch-Root-on-ZFS
[2] https://github.com/zfsonlinux/zfs/wiki/Debian-GNU-Linux-initrd-documentation
[3] #7329

@bunder2015 bunder2015 added the Type: Documentation Indicates a requested change to the documentation label Dec 10, 2018
@rlaager
Copy link
Member

rlaager commented Dec 10, 2018

This is really up to @gmelikov, but since it's a wiki and changes are easy to revert, I went ahead and boldly edited this. I see no point to the equal level filesystems approach. Either the filesystems should be at the top-level (as per the HOWTO) because they should not be rolled back with the root filesystem, or they should be a child of the root filesystem (as per the earlier example in the initrd documentation) because you do want them rolled back with the root filesystem but also want them as a separate dataset for some reason. The middle ground of having them under rpool/ROOT seems pointless (and could also confuse a beadm tool).

I also removed the examples of /boot and /var as things to separate under the root dataset: /var because it conflicts with the root-on-ZFS HOWTO, and /boot because that's where GRUB lives and GRUB is earlier in the process here. If someone knows what they are doing, they can modify things, but we shouldn't have attractive nuisances like that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Documentation Indicates a requested change to the documentation
Projects
None yet
Development

No branches or pull requests

4 participants