Add support for Arch/Artix Linux

[ghost]

Articles are directly viewable at here.

Revised layout is the following:

bpool/BOOT/default        on        /boot
bpool/BOOT/bootenv        on        /boot        # alternative boot environment
rpool/ROOT/default        on        /
rpool/ROOT/bootenv        on        /            # alternative boot environment
rpool/DATA/default/{home,var/log,...}            # persistent data

This layout enables the destruction of the initial boot environment default. With the previous layout, where persistent data is nested under rpool/ROOT/default, this is not possible.

Another addition is appending pool names with a random UUID. This will prevent naming conflict when importing pools on another root on ZFS system.

Boot environment management is performed with this AUR package. It will also add relevent GRUB menu entries for easy recovery.

A pacman hook for creating boot environments upon each pacman transaction is also available.

@rlaager @gmelikov

Signed-off-by: Maurice Zhou ja@apvc.uk

[rlaager]

Please remove the "@rlaager" bits, including in the issue URL. If you're intending on maintaining this, you probably want to replace that with your username.

The formatting is messed up on "Prepare the Live Environment" step 4 (and then the second step 4, which would be step 8). But that might just be the GitHub viewer? I haven't tested building this normally.

nit: poolUUID doesn't seem to fit the variable naming convention of the other variables.

In Create Datasets, step 4, you're going to have newlines in the for loop, you don't need semi-colons at the ends of lines.

It's been my practice to wrap long command lines. Granted, that's a matter of taste, but I like to avoid needing scrollbars to see the full command if the browser window is narrower (e.g. half of a 1080p screen vertically is common for me).

Again, a matter of taste, but I've intentionally avoided heredocs (e.g. tee ... << EOF). Using a real text editor makes it easier for people to edit things if they make a typo.

I'm not sure why you're setting $INST_ROOT for the root password and then having to echo it to chpasswd, rather than just having the user run passwd at that point.

Setting ZPOOL_VDEV_NAME_PATH=1 in everyone's environment is really heavy-handed. Is there a better way to solve that that just applies to GRUB? Also, hasn't GRUB been setting that for a while? I suspect you're confused about something here. 1 is not a useful value. It needs to be either YES or ON to take effect anyway (which again, GRUB should be setting); see lib/libzfs/libzfs_pool.c in the ZFS tree.

Is the EFI mirroring setup that you're doing the normal way that Arch Linux handles this?

In terms of the big picture, why create yet another boot environment script rather than use zsys?

[ghost]

Please remove the "@rlaager" bits, including in the issue URL.

Replaced with my user name.

The formatting is messed up

Fixed.

nit: poolUUID doesn't seem to fit

Replaced with INST_UUID.

don't need semi-colons

Removed.

It's been my practice to wrap long command lines.

I understand your point. But how to wrap lines like this one?

echo crypt-swap ${DISK}-part4 /dev/urandom swap,cipher=aes-cbc-essiv:sha256,size=256 >> $INST_MNT/etc/crypttab

How about this:

echo crypt-swap ${DISK}-part4 \
  /dev/urandom \
  swap,cipher=aes-cbc-essiv:sha256,size=256 \
  >> $INST_MNT/etc/crypttab

Using a real text editor

My intention is to automate things a little.

With heredocs, if the value of the variables are correct, there's no possibility of typo when pasting the commands to a terminal.

In contrast, the text editor approach, which is employed by the Debian and Ubuntu guides, the user needs to manually replace the variable, inside the editor, each time after pasting something. I think this is more error-prone.

For example, in Debian guide:

apt install --yes openssh-server

vi /etc/ssh/sshd_config
# Set: PermitRootLogin yes

Here I would prefer just one line of echo PermitRootLogin yes >> /etc/ssh/sshd_config, as the default value is commented out in the config file.

I'm not sure why you're setting $INST_ROOT for the root password and then having to echo it to chpasswd, rather than just having the user run passwd at that point.

Replaced with passwd. Same for setting root pool password.

Setting ZPOOL_VDEV_NAME_PATH=1 in everyone's environment is really heavy-handed. Is there a better way to solve that that just applies to GRUB?

But if the user forgot to set this, grub-mkconfig will fail each time when executed.

I agree this approach is heavy-handed, but I can't think of a better workaround.

Also, hasn't GRUB been setting that for a while?

No, with vanilla GRUB this is not fixed.

It needs to be either YES or ON to take effect anyway.

My mistake. Changed to YES.

Is the EFI mirroring setup that you're doing the normal way that Arch Linux handles this?

No, I invented that myself.

Previously I was mirroring EFI with dd, as described in the Debian/Ubuntu guide.

But it turns out that my server can't boot from a dded partition. Only manually mount the partition and copy EFI folder worked for me.

In terms of the big picture, why create yet another boot environment script rather than use zsys?

bieaz is a simple script ported from FreeBSD beadm, it only does one job, managing boot environments on one system.

Contrast zsys, which aims to manage ZFS on multiple systems in a data center setting. I think this is unnecessary and a over kill.

bieaz works on vanilla GRUB. I digged in the Ubuntu GRUB source a little, and it turns out that they applied lots of Ubuntu-specific patches on GRUB just to make it work with zsys.

I don't think Arch Linux, which strives to provide vanilla packages, will accept this kind of patch.

Moreover, it seems to me that nobody is working on porting zsys to another distribution yet.

So my questions are:

• why use the bloated zsys, when a simple script would suffice?
• are the zsys-specific GRUB patches portable to other distributions?
• will other distributions accept such patches to GRUB, just to make zsys work?

[ghost]

Ubuntu GRUB source:

# We have a more specialized ZFS handler, with multiple system in 10_linux_zfs.
...

And their 10_linux_zfs does not exist in vanilla GRUB.

So it's my opinion that a functional BE manager should work with upstream.

It's not enough to just patch the boot loader downstream and be done with it.

[ghost]

Another point is, bieaz supports arbitrary pool names (rpool_UUID) and dataset paths, such as

rpool_foo/b/a/r/default

This is also supported for boot pool.

The only requirements for bieaz to work are:

1. Root file system dataset nested at least one dataset.
2. Root and boot file system dataset must have the same name.

In contrast, Ubuntu Root on ZFS requires the boot pool to be named bpool, quote Ubuntu 20.04 guide:

The boot pool name is no longer arbitrary. It must be bpool. If you really want to rename it, edit /etc/grub.d/10_linux_zfs later, after GRUB is installed (and run update-grub).

As I've said in the above comment, /etc/grub.d/10_linux_zfs is an Ubuntu-specific GRUB patch.

[rlaager]

Contrast zsys, which aims to manage ZFS on multiple systems in a data center setting.

zsys was written by the desktop team, designed for Ubuntu desktop. It's not a server / data center thing, nor for multiple systems. I'm not sure where you got that impression.

Your concern about vanilla GRUB is understandable.

[ghost]

zsys was written by the desktop team, designed for Ubuntu desktop. It's not a server / data center thing, nor for multiple systems. I'm not sure where you got that impression.

I admit I haven't really used it, as I don't use Ubuntu, but the following gives me the impression.

From its readme:

zsysctl machine

Machine management
Synopsis

Machine management

zsysctl machine COMMAND [flags]

Options

  -h, --help   help for machine

Options inherited from parent commands

  -v, --verbose count   issue INFO (-v) and DEBUG (-vv) output

zsysctl machine list

List all the machines and basic information.
Synopsis

List all the machines and basic information.

      --full   Give more detail informations on each machine.

Maybe machine here is referring to something else than a standalone computer?

[rlaager]

I admit I haven't really used it, as I don't use Ubuntu, but the following gives me the impression.

...
Yeah, I'm not sure why they use the word "machine" all over the place. I can see how that was confusing.

[ghost]

@rlaager: Any update on this? I've addressed most issues in the above post.

[rlaager]

I'm going to change my review from "Request changes" to "Approve", to stop it being in the "Request changes" state. This is more of a "not Reject" or "soft Approve".

I pulled this locally and rendered it through the usual process. Most, if not all, of the remaining formatting concerns I had are fine locally. So it was just GitHub's .rst rendering being different.

On the one hand, I don't see any huge issues here. On the other hand, I'm not in a great position to personally determine the quality of this from an Arch Linux perspective.

You also submitted a HOWTO for Void Linux (a distro I'd literally never heard of before). Someone (and I don't know their relationship to the distro nor their experience) immediately said was not representative of a good Void Linux install. This gives me some pause.

I'm not sure whether I should be the one to approve this or not. But for whoever needs to make that decision, here are some questions that might be important:

Do you use one of these (Arch/Artix) distros regularly (either as your "daily driver" workstation or in a server environment), and if so, are you using Root-on-ZFS? How long have you been using Arch/Artix? How long have you been using ZFS? Are you planning on maintaining this HOWTO over the long-term? Do you have any relevant experience (maintaining documentation and/or software) you'd like to mention?

You said you based this on the Debian HOWTO, but you've clearly removed a lot of content. For example, you've lost large bits of explanatory text (e.g. in the encryption section, pool features and options, etc.). Can you comment on that decision? I wrote a lot of those bits, so obviously I think they're a good idea. It's fine if you disagree. I'd just like to understand your thought process a bit more.

A couple of nits:

• "Create root pool partition" should have a trailing colon
• I also maintain a couple of very similar HOWTOs (in my case Debian and Ubuntu). I find it useful to compare the diffs to make sure they are as close to in sync as possible. You might want to use diff -u "Arch Linux Root on ZFS.rst" "Artix Linux Root on ZFS.rst" and cleanup some of the spurious e.g. whitespace differences.

[ghost]

@rlaager

I'm using Arch Linux on my laptop and Artix on a Dell R720xd server, both Root-on-ZFS, since early 2020. Previously, I used Root-on-ZFS with Debian, Ubuntu, Proxmox and XigmaNAS since 2016. I have also requested a review by an admin from ArchWiki.

I'm planning to maintain this HOWTO over the long-term. As I'm settled on Arch/Artix, I will certainly perform Root-on-ZFS installation, according to this guide, on other computers as well. This guide will be continuously updated from bug reports and my own experience with such installations.

I'm mostly a user and sysadmin. Some relevant experience might be: boot environment script, its pacman hook and a pipeline building Arch Live image with ZFS.

I certainly appreciate the explanatory text in Debian/Ubuntu guide, will add them back later. I omitted them at first, mostly because they occupies huge page space and are not so relevant for users who just want follow the best practices and paste commands. The nits you mentioned will be addressed as well.

About the Void Linux HOWTO: the two developers commented on the guide are the main developers behind ZFSBootMenu, in their opinion, anything using GRUB instead of ZBM is flawed and inconvenient. Currently, ZBM is only available in Void repo, hence "was not representative of a good Void Linux install". They can not say the same thing for other distros.

[rlaager]

This seems fine to me to merge, but ideally I'd like a second opinion. @gmelikov @behlendorf ?

[gmelikov]

LGTM for me as a first version of doc, but I didn't check distro-specific commands unfortunately (I don't use Arch).

@ne9z looks like we can use one page for both arch and artix instructions with different info in needed sections, but whatever you like as the maintainer of these pages.

[ghost]

@gmelikov I'd keep them separated. The divergence might expand in the future, making a single doc unfeasible.

You can just spin up a VM and test them out, if you have time, that is ;-).