danboid / alez

Arch Linux Easy ZFS installer

Arch Linux Easy ZFS (ALEZ) installer

by Dan MacDonald and John Ramsden

WHAT IS ALEZ?

ALEZ (pronounced 'ales', as in beer) is a shell script to simplify the process of installing Arch Linux using the ZFS file system.

ALEZ automates the processes of partitioning disks, creating and configuring a ZFS pool and some basic datasets, installing a base Arch Linux system and configuring and installing the GRUB or systemd bootloader so that they all play nicely with ZFS.

The default datasets are configured ready to be managed with the (zedenv) boot environment manager.

LIMITATIONS

ALEZ has a few limitations you need to be aware of:

• x86-64/amd64 is the only platform supported by the Arch ZFS repo and hence this script.

• ALEZ only supports partitioning or installing to drives using GPT. ALEZ does not support creating MBR partitions but both BIOS and UEFI machines are supported.

• It only supports creating single or double disk (mirrored) pools - there is no RAIDZ support.

HOW DO I USE IT?

The easiest way to use ALEZ is to download archlinux-alez., which is a version of Arch Linux remastered to include ZFS support and the Arch Linux Easy ZFS (ALEZ) installer. Transfer the iso onto a USB drive (or burn it to a disc) just as you would for the regular Arch iso, boot it and then type 'alez' at the prompt to start the installer.

Stable vs LTS kernel

The stable kernel is the default Linux kernel installed as part of a regular base Arch install. The stable kernel is normally more current than the LTS kernel so it may offer more hardware support and/or features. It gets updated more often than the LTS kernel.

TROUBLESHOOTING

Faulty ISO?

Travis CI auto-generates new ISOs for almost every commit made to the ALEZ repo. These auto-generated ISOs don't always fully work so before opening a issue please try installing with an older ALEZ ISO first. We will try remove ISOs known not to work.

archzfs key import fails

If ALEZ abruptly 'completes' near the start of the install, it could be that it failed to import the key for the archzfs repo because the archlinux-keyring PGP signatures package included on the iso is outdated. Rather than waiting for a new ISO to be uploaded you can follow the instructions in create-alez-iso.txt to create an updated ISO.

Running ALEZ within virtual machines

GRUB fails to install under VMs created using the virt-manager and virtualbox defaults because they both default to using an IDE disk bus. Change your VM disk bus or storage controller type to SATA or VirtIO before running ALEZ.

You may also want to check out my other ZFS-related repos, Creating ZFS disks under Linux and ZFS aliases - my most used ZFS commands as aliases.

alez's Issues

Invalid archive created for downgrade kernel

The linux archive downloaded with curl for downgrade is an 'invalid archive'.

ALEZ/alez.sh

Lines 177 to 178 in 5820e2f

	curl --progress-bar --output "${pkgdir}/${pkg}" "${url}" && \
	chrun "pacman -U --noconfirm /${pkg}" && rm "${pkgdir}/${pkg}"

Fix incoming using wget.

Virtio disks fail due to quoting

Virtio disks fail again stating

cannot use '/dev/mapper': must be a block device or regular file

This can be tracked down the quoting in the update_parts function.

ALEZ/alez.sh

Line 354 in 4c74a4d

mapfile -t partids < <(ls /dev/disk/by-id/* "$(${show_path} && ls /dev/disk/by-path/* || : ;)")

Currently, because it is quoted, the ls output is treated as a single string of multiple disks, resulting in the following:

ls /dev/disk/by-id/ata-QEMU_DVD-ROM_QM00001 '/dev/disk/by-path/pci-0000:00:1f.2-ata-1
/dev/disk/by-path/pci-0000:04:00.0
/dev/disk/by-path/pci-0000:04:00.0-part1
/dev/disk/by-path/pci-0000:04:00.0-part2
/dev/disk/by-path/virtio-pci-0000:04:00.0
/dev/disk/by-path/virtio-pci-0000:04:00.0-part1
/dev/disk/by-path/virtio-pci-0000:04:00.0-part2'
ls: cannot access '/dev/disk/by-path/pci-0000:00:1f.2-ata-1'$'\n''/dev/disk/by-path/pci-0000:04:00.0'$'\n''/dev/disk/by-path/pci-0000:04:00.0-part1'$'\n''/dev/disk/by-path/pci-0000:04:00.0-part2'$'\n''/dev/disk/by-path/virtio-pci-0000:04:00.0'$'\n''/dev/disk/by-path/virtio-pci-0000:04:00.0-part1'$'\n''/dev/disk/by-path/virtio-pci-0000:04:00.0-part2': No such file or directory

Update w/ newer kernel and newer ZFS? :)

Very soon after 0.8.0 came 0.8.1. And they're up to 5.1.15 now. Any chance of a new .iso w/ newer versions? :)

zfs mirrored install failure on NVMe and UEFI

I have tried multiple paths to install a mirrored ALEZ install on two NVMe drives using UEFI, and failed. I have installed ALEZ in the past, but not this configuration.

I followed the process below

1. Grabbed the latest alez installer (note: even though I grabbed the latest, ALEZ starts saying that a newer version exists, and then identifies the newer version as the same one I pulled).
2. Installed on a USB stick and booted the target off of the USB in UEFI mode.
3. Selected either systemd-boot or GRUB. Errors from each listed below
4. Partitioned the two NVMe drives
5. Create a mirrored ZFS pool, and assigned part-2 on each drive
6. In the case of systemd-boot, install efi on one of the NVMe's part-1
7. Run the install
8. Reboot - and fail

GRUB boot

Please insert a valid boot drive....

systemd-boot

Starting version 247.3.1-arch
:: running hook [udev]
:: triggering uevents...
:: mounting '' on real root
mount: /new_root: no filesystem type specified
You are now being dropped into an emergency shell

What am I missing?

grub-mkconfig question

Sorry to bother you with this, but my google foo is failing me.

I just installed amd-ucode and wanted to update my grub.cfg and ran grub-mkconfig -o /boot/grub/grub.cfg and I get the following error.

/usr/bin/grub-probe: error: failed to get canonical path of `/dev/ata-KINGSTON_SA400S37480G_50026B7782EE112D-part2'.

What am I doing wrong? Thanks.

File "alez-downloader.sh" referenced in ISO self-creation instructions txt no longer exists in repo

ALEZ/create-alez-iso.txt

Line 48 in cbda8a4

# cp alez-downloader.sh ~/aleziso/airootfs/usr/local/bin/alez

Basically, I want to play with a build of this. ;)

How do I manage the ROOT dataset?

I had setup ALEZ about 2 years ago and it has been going well, but I'm not sure I understand how to maintain the zroot/ROOT dataset. It looks like many snapshots have been created. How are the snapshots supposed to be pruned? I fear my drive will eventually be used up.

david@bar:~$ zfs list -o space -r zroot/ROOT | wc
   4662   32634  731934
david@bar:~$ zfs list -o space -r zroot/ROOT | head
NAME                                                                                                AVAIL   USED  USEDSNAP  USEDDS  USEDREFRESERV  USEDCHILD
zroot/ROOT                                                                                           194G   215G        0B    176K             0B       215G
zroot/ROOT/default                                                                                   194G   215G        0B    135G             0B      80.6G
zroot/ROOT/default/0004106facc034e1d2d75d4372f4b7f28e1aba770e715b48d0ed1dd9221f70c9                  194G   212K        8K    204K             0B         0B
zroot/ROOT/default/0004106facc034e1d2d75d4372f4b7f28e1aba770e715b48d0ed1dd9221f70c9@620970535           -     8K         -       -              -          -
zroot/ROOT/default/00114407428dc8fc68806430cc3ee24790273c29f21feed222b40676d52af064                  194G   196K        8K    188K             0B         0B
zroot/ROOT/default/00114407428dc8fc68806430cc3ee24790273c29f21feed222b40676d52af064@11882290            -     8K         -       -              -          -
zroot/ROOT/default/005ebedcb2476c7be47742af3d206ab55c1edbfa74adf318f7d62f0b35ad2580                  194G   964K        0B    964K             0B         0B
zroot/ROOT/default/006379fc82a9ae75e326004502859c5e3ebd0ce884841fe8ceae01b1daf26e66                  194G   208M        8K    208M             0B         0B
zroot/ROOT/default/006379fc82a9ae75e326004502859c5e3ebd0ce884841fe8ceae01b1daf26e66@693157732           -     8K         -       -              -          -

Network is unreachable after installation

Hello,

First of all, a big thanks to everyone involved in this project. This will make my life so much easier.

I am having an issue.

I booted up the iso. Needed internet to install so I hooked up my Android and enabled tethering. I ran a ping and it “just worked”. So I ran 'alez' and followed the prompts until I got:
Installation complete. You may now reboot into your new install.
Before rebooting I mounted the datasets and partitions, entered chroot, ran passwd, set hosts file, set hostname, set time zone, enabled UTF-8, ran locale-gen, exited chroot unmounted and exported. After rebooting I connected my Android, enabled tethering, ran ping and got:
ping: connect: Network is unreachable

Did I miss something? Any help would be greatly appreciated.

Features are all disabled using systemd-boot

While the script doesn't specify feature flags when using systemd-boot, and therefore all the default features should be enabled, when I checked on the live system it appeared that ALL features were disabled and I had to zpool upgrade.

I miss your updates... where'd you go?

Hey @danboid, where'd you go? I loved your ALEZ images for Arch installs w/ ZFS. I miss the updates! :)

can't mod probe zfs on 2020 release

Just fetched archlinux-alez-2020.02.29.03.21.57 release to try in a vm and was unable to modprobe zfs

dialog prompt is unclear regarding "-part"

I tried first in ansi-term and then xterm, ssh'd into a virtualbox guest.

The dialog screens were not clear at one point, see screenshot attached.

Basically, it told me to choose partitions with -part, but the dialog
cut-off made it impossible for me to tell which entry I should choose,
because while I was cycling through the list, they all had cutoff the
string before the *-part section.

At this point I C-c and ls -al /dev/disk/by-id and saw there were two
partitions with -part, which then makes question which one I was
supposed to pick anyways?

Thank you

edit: So you can see in this screenshot, the disk string in the dialog is cutoff, not being wide enough. I cannot see to the right the remaining *-part. Clearly then I break with C-c and took a look at the disks with ls -al /dev/disk... (That's why you only see the top-half fragment of the dialog.)

ISO install error

Seems like the arch-keyring is to far out of date in the ISO so it refuses to install some packages which lead to the install script to fail.

Any chance for an updated ISO?

Thanks in advance.

unexpected behavior from useradd while chrooted

I tried adding my user account while chrooted with "useradd -m -g users -G wheel -s /bin/bash lenny" as I have dome for some time. I could see my home directory at /home/lenny and the permissions looked good. However when I rebooted and tried to log in I got an error stating that I had no home directory. When I looked /home/lenny was no longer visible. I tried adding my user account by running "useradd -d /home/lenny -g users -G wheel -s /bin/bash lenny" instead but that did not work either. I was able to confirm this by doing a couple of passes on my test system. For what its worth I launched ALEZ with "alez 2> ~/error.log" to see if it would capture anything. What I got was:

error: '/linux-5.7.12.arch1-1-x86_64.pkg.tar.xz': could not find or read package
Created symlink /etc/systemd/system/multi-user.target.wants/zfs.target -> /usr/lib/systemd/system/zfs.target.

systemd-boot-system-token.service failing

systemd-boot-system-token.service is failing with the message Failed to open random seed file for writing: Operation not permitted

On IRC, the #archlinux channel was kind enough to help me.

That's bootctl trying to write the random seed. (A new feature in systemd 243.) Is /boot mounted read-only for some reason?

I was not sure if /boot is mounted as read-only but I thought it probably was.

Could you help me to get bootctl to write the random seed with the ALEZ setup?

Hang on boot with the May release

Greetings,

I am having a problem where most times (say 4 out of 5) booting from the USB where I copied the iso, I get through the entire Arch boot process, but in stead of getting a prompt, I'm sitting at a blank screen. There is a cursor, but no keyboard input, no prompt, etc. The only thing I can do is hard reset the machine and try again.

I have reverted to the April release, and the problem does not occur.

Christopher

ISO creation questions

Hi there,

I am trying to build the custom ISO from my local source code.
I noticed there is a Dockerfile. On the other hand, there is Boot into an up-to-date install of Arch (but not under LXD/LXC as the build script doesn't work in a container) in create-alez-iso.txt. So can we build the ISO in a container or not?

Another important point is that the Dockerfile builds the ISO by getting the source code from Github whereas it should really use local source code as one would git clone the whole repository anyway. Similarly, auto-updating ALEZ with the downloader is I think a bad idea and that is why you have releases (plus you already have them set up). What do you think? I can change all that in a first PR if you want, I'm quite familiar with Docker.

silent failure on blocked hkp server

I've had ALEZ silently fail by not installing any zfs packages because the hkp keyserver was not reachable. ALEZ completes seemingly successfully but the kernel can't mount the root partition on the next boot.
Changing --keyserver hkp://pool.sks-keyservers.net to --keyserver hkp://pool.sks-keyservers.net:80 fixed it because some corporate firewall blocks the default keyserver port.

Maybe ALEZ should at least fail outright if keyservers can't be reached

zol, systemd, and /var/log/journald still an issue?

Hey Dan

I note quite a bit of zol edit activity on archwiki. Page's "Talk" seems to be locked though so am opening 'issue' here.

I don't use zol on arch anymore but am curious if this issue is still extant openzfs/zfs#3768 Further elaborated upon here http://www.teamcool.net/posts/zol-systemd-pain-points.html

I invested a fair bit trying to get this sorted but my efforts were met with hostility at the time so I gave up and moved on. If this has been resolved by more recent systemd I'd like to let ryao know.

Peace

EFI partition isn't mirrored

Hi there,

First of all, thanks for the nice program, it takes out a lot of headaches 👍
I can see my root is mirrored on two of my drives with ZFS, but what about /mnt/efi? It does not seem to be mirrorred. So this would mean that removing one of the two drives could make (50% chance) the system unbootable. Is there a way to mirror (or other) the boot partition as well?

Thanks!

Swap dataset by default?

Would making a dataset for swap and allowing the user to define the size be a good plan or do you figure that's a user responsibility?

I've pretty much gone off the ubuntu plan and used:

# zfs create -V 8G -b $(getconf PAGESIZE) -o compression=zle \ -o logbias=throughput -o sync=always \ -o primarycache=metadata -o secondarycache=none \ -o com.sun:auto-snapshot=false zroot/swap

# echo /dev/zvol/zroot/swap none swap defaults 0 0 >> /etc/fstab

# swapon -av

support for encryption?

Hi,

does ALEZ support encryption?
If so, how do I enable it?

I'm considering renistalling arch and would like to use ZFS but need disk encryption to protect sensitive data in case I loose my notebook.

Thanks for the great script!

Drops to emerghency shell if zfs-linux is not in sync with new kernel

Linux 5.7.7 is out but zfs-linux is still at 5.7.6.
The install ran but zfs-linux was not installed.

When rebooting the console shows:

:: running early hook [udev]
Starting version 245.6-8-arch
:: running hook [udev]
:: Triggering events
:: mounting ' ' on real root
mount: /new_root: no filesystem type specified.
You are now being dropped into an emergency shell.
sh: can't access tty; job control turned off
[rootfs ]# _

cannot boot from activated BE (zedenv, EFI+systemd-boot)

Even if I make new BE and activate it using zedenv,

zedenv create newbe
zedenv activate newbe
reboot

still default will be used to boot, although I expected that newbe would be used.
The reason is that options zfs=${zroot}/ROOT/default is specified in efi/loader/entries/zedenv-default.conf (created by ALEZ).
But this should be zfs=bootfs to work BE-activation correctly.
I think this occurs with GRUB, too, but I've not tested.

--- alez.sh,orig	2018-10-29 12:38:18.000000000 +0100
+++ alez.sh	2018-10-28 22:38:06.000000000 +0100
@@ -200,7 +200,7 @@
         title           [default] (Arch Linux)
         linux           /env/zedenv-default/vmlinuz-${2}
         initrd          /env/zedenv-default/initramfs-${2}.img
-        options         zfs=${zroot}/ROOT/default rw
+        options         zfs=bootfs rw
 EOF
 }

ArchZFS repo broken

ALEZ is currently unable to access the archzfs repository.

A workaround is to use the archiso-zfs package at https://github.com/eoli3n/archiso-zfs

Instead of 'pacman -Syy" to refresh repos run 'curl -s https://eoli3n.github.io/archzfs/init | bash'

From there you can run alez as usual.

Should we consider adding this command to the alez script when building an ALEZ image?

zedenv for Boot Environments in ALEZ (and how to do networking)

Hi, Dan, Your ALEZ is excellent!
Fresh install today with newest version of iso.
Want to install and configure zedenv or beadm.
pacman -Syu results in this error.
Protocol "rsync" not supported or disabled in libcurl
How to fix that? Please do fix this. Thanks.

Support for Asus Zenith II Extreme

Motherboard: Asus Zenith II Extreme Alpha
Processor: 3970x
Wireless Network Chip: Intel AX200

I have tried booting 2020.05.06.02.02.39 and `2020.04.03.03.34.36' and I have not been able to complete the process on either installer.

2020.05.06.02.02.39 This installer boots and systemd starts. After a few seconds it starts preforming dhcp and then the screen blanks and i get a white blinking cursor. The system will accept input from the keyboard but nothing will be display and no commands will be executed. I am unable to change ttys or get logs from this system because it will not accept input.

2020.04.03.03.34.36 This installer will complete the booting process and drop to a root shell but any attempt to connect to wifi will result in a failure notice from wifi-menu. I can get logs if required from this installer.

The system boots and connects to wifi with the standard 2020.05.01 Arch Linux installer.

ALEZ build issue

I am inclined to ask if there are plans to update ALEZ now that OpenZFS 2 has been released.

Until then I am trying to build an ALEZ ISO with ZFS 2. The ISO I made boots ok and a 'modprobe zfs' returns no error. However there is a permissions issue with the custom script files that I placed in /usr/local/bin of the ISO. If I create a /temp directory and copy the files over I can set the execution bit with chmod +x but the scripts will not execute. Even as root I get a permission denied.

Use https for zfs pacman repo address

I noticed that the modification to pacman.conf uses http rather than https. The archzfs wiki suggests using https (https://github.com/archzfs/archzfs/wiki#using-the-archzfs-repository).

Is there any particular reason why http is used in ALEZ?

Should boot to console instead of UEFI shell

This is minor but it threw me the first time around because I was not watching when it happened. I booted my test system and I got a UEFI shell instead of the console. I thought that I had set up my system wrong. Previous versions of ALEZ booted to the console by default.

"Downloading kernel from archive" message prints wrong variable

When the kernel is out of sync with the upstream Arch kernel, ALEZ really helpfully works out the older kernel versions, downloads and installs them. Awesome.

However, the print statement explaining this uses the wrong variable - it prints the current Arch version, not the zfs-linux version.

ALEZ works great

@danboid @johnramsden thank you for this project. I recently returned to Arch Linux for daily development of RabbitMQ and ALEZ made installation on ZFS just as easy as my FreeBSD machine.

🥳

I hope you don't mind the superfluous GitHub issue.

Error in UEFI install

Trying to install on a UEFI only system (2011 Macbook Pro). I get the zpool created fine, but when it goes into the section to create the ESP, it fails immediately after "View partition layout before creating esp?" whether you say yes or no. It throws:

ls: cannot access '': no such file or directory

Error: Expected 2 arguments, found only 1.
Use --help to list options

Then goes on to unmount datasets, etc.

Following through the script, it looks like it's failing on get_parts or update_parts, around about line 552.

build.sh support removed

Legacy build.sh script is removed from archiso package. This breaks the ALEZ script. Should be update to mkarchiso
https://gitlab.archlinux.org/archlinux/archiso/-/commit/1bd944ee7cc287359d9b7e504b5f02d324f5a2ea

grub route works - systemd-boot doesn't

I've been playing around with this and when I choose the systemd-boot path thru the installer, i end up with a non-bootable system. I've got 2 small sata ssds for mirrored root, and 5 nvmes for data. The boot drives are /dev/sda and /dev/sdb:

When i reboot with the USB key and manually mount /dev/sda1 to see what happened, all i see is a folder hierarchy "env/zedenv-default" with no files in it. I tried running "bootctl --path=/mnt install", which did copy over the efi stub files and create a UEFI boot entry that shows up, but it still won't boot.

When i try the grub path - all other things being equal - it works fine. I would prefer the systemd-boot path, so any ideas why it isn't working? The machine is configured in UEFI mode (as opposed to dual mode) and "efivars --list" works as expected.

Also, after successfully booting via the grub method - i manually created my data pool which worked fine, but notice that it wouldn't automount between reboots (i.e. i'd have to do a "zpool import dpool" after each reboot. I was wondering if fixing this was as simple as maybe just manually rebuilding the initramfs image or something but didn't try it.

ZFS hook is not being added to the mkinitcpio

ZFS hook is not being added to the mkinitcpio, this happened under BIOS with 1 disk.

I end up with the following output.

Update initial ramdisk (initrd) with ZFS support...                │  
             │ ==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'd │  
             │   -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initr │  
             │ ==> Starting build: 4.19.2-arch1-1-ARCH                            │  
             │   -> Running build hook: [base]                                    │  
             │   -> Running build hook: [udev]                                    │  
             │   -> Running build hook: [autodetect]                              │  
             │   -> Running build hook: [modconf]                                 │  
             │   -> Running build hook: [block]                                   │  
             │   -> Running build hook: [keyboard]==> ERROR: Hook 'zfs' cannot be found
             │   -> Running build hook: [filesystems]                             │  
             │ ==> Generating module dependencies                                 │  
             │ ==> Creating gzip-compressed initcpio image: /boot/initramfs-linux==> WARNING: errors were encounte==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'f │  
             │   -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initr │  
             │ ==> Starting build: 4.19.2-arch1-1-ARCH                            │  
             │   -> Running build hook: [base]                                    │  
             │   -> Running build hook: [udev]                                    │  
             │   -> Running build hook: [modconf]                                 │  
             │   -> Running build hook: [block]==> WARNING: Possibly missing firmware for module: wd719x        │   -> Running build hook: [keyboard]==> ERROR: Hook 'zfs' cannot be found
     ==> WARNING:-> Running build hook: [filesystems]                             │  
             │ ==> Generating module dependencies                                 │  
             │ ==> Creating gzip-compressed initcpio image: /boot/initramfs-linux==> WARNING: errors were encountered

I haven't had time to investigate where this problem is coming from but it seems like the hook just isn't being added to the config, even though it should be

ALEZ/alez.sh

Line 144 in c09208e

sed -i 's/HOOKS=.*/HOOKS="base udev autodetect modconf block keyboard zfs filesystems"/g' "${installdir}/etc/mkinitcpio.conf"

ALEZ fails after pacstrap

So, after a failed attempt to install Arch with ZFS, and then a sucessful attempt with BTRFS, I decided to give this a shot.

I'm using an MSI Gaming 5 Z97 motherboard, with the target drive being a Samsung 850 EVO (which is currently listed as /dev/sde because I have 4 other HGST drives in my system and I can't be bothered to rearrange the SATA cables). I've burned the ISO (the one I downloaded from the releases page) to a nice verbatim CD-R (because I've never been able to successfully install any operating system from USB on this machine for some unfathomable reason), and I'm booting via BIOS (because I've also never been able to get UEFI to boot anything).

Anyway, when I start the ALEZ installation, everything seems to go fine. I select the drive, set it to be partitioned, and then it appears to be doing the pacstrap. However, it seems to fail at some point between then and the GRUB configuration.

The first time it failed, it looked like this:
https://cdn.discordapp.com/attachments/389121244919889935/562640429091389471/20190401_171202.jpg

After doing df -h, I noticed that my cowspace or whatever you want to call it was completely full. Figuring that this was the issue, I changed the Arch boot behavior to now have 4 gigabytes of cowspace. This proved to be overkill in terms of this issue, but I found a second issue:

https://cdn.discordapp.com/attachments/389121244919889935/562640429091389470/20190401_193050.jpg

I'm not sure what to do now. This happens regardless of which kernel I choose, and it happens every single time I tried it with more cowspace.

I'm willing to cooperate in any way to get this issue fixed. Please let me know if you need more info.

ALEZ fails all install-variants on HP EliteBook 2730p | 2740p | 2760p

I have tested ALEZ in the following configurations

1. out of Antergos Live (18.11|18.12)
2. out of ALEZ-arch[…].iso, as given in README

… on the following systems (all completely cleaned including zap of GPT and MBR and additionally overwriting first and last regions (as either setup by the installer or custom configured in forefront) with 0s after any failed attempt - deemed necessary, because ALEZ vomited and freezed on each take without):

a) HP EliteBook 2730p
a1 – CPU Intel® Core 2 Duo CPU L9400 – RAM 4GiB (2*2) DDR-II – iGPU Intel 4500 MHD

b) HP EliteBook 2740p

b1 – CPU "Arrandale" Intel Core i5 520M vPro – RAM 4GiB (22) DDR-III – iGPU "Ironlake"
b2 – CPU "Arrandale" Intel Core i5 540M vPro – RAM 8GB (24) DDR-III – iGPU "Ironlake"

c) HP EliteBook 2760p
c1 – CPU "SandyBridge" Intel Core i7 2620M vPro – RAM 16 GiB (2*8) DDR-III – iGPU "HD 3000"

– AMT (disabled)
– BIOS | UEFI
– HDD – a1|b1|b2 – INT µSATA GB 80 Intel SSD 320 1.8" | 160 GB Toshiba 1.8"
– HDD INT SATA
– HDD EXT USB 2 IDE 2.5" + 3,5" GB : 40|80|120
– HDD EXT USB 3 with the following drives
– EXT SATA (300|600) 2.5" + 3.5" GB : 40|80|160|320|1.5TB|2TB|3TB
– EXT eSATA (via 2740p Docking Station + via PC-Card) same drives as listed before in EXT SATA
– EXT FireWire 400 to SATA with the drives listed on EXT SATA
– WLAN Intel a|b|g|n
– WWAN a1 [Qualcomm Gobi 1000] – b1|b2 [Qualcomm Gobi 2000] | c1 [Erricson 5521 HSPA+]
– BT BroadCom
– LAN GigaBit Intel
– SmartCard
– PC-Card 54
– SDHC

WAN runs at ~ 3 MiB/s

… after some diddly daddly unstructured probing via Antergos Live [18.11 | 18.12]:
I did 3 general configurations of the above abilities:
– A – just what is needed ( means WWAN | WLAN | FireWire | PC-Card | eSATA | etc … disabled)
– B – everything (, asides AMT and TXT) enabled
– C – just what is needed but – C1 eSATA via Dock | C2 eSATA via PC-Card

Any given combination of ALEZ options tested:

What (reproducibly) happened was:

I – ALEZ crashed totally (including Freeze of the TTY) when booted via UEFI and selecting UEFI setup with GRUB on internal SATA HDD|SSD right at the moment it checks the existing partitioning, if it was not completely cleaned in forefront (as described above by total zap GPT+MBR and nullify ins and outs – a.k.a.: Yeah to kill ZFS created by ZoL only works that way; even when sweeping by overwriting with a FreeBSD or OpenIndiana complete-disk setup the via ZFSonLinux created pools are somehow surviving as phantoms - absolutely no idea why and where they (exactly) hide (because that differs - could be specific to the EliteBooks, as they even with AMT | DriveLock | Intel Anti Theft | TXT | SecureBoot, etc. disabled sometimes, magically make a jump back in time as if none of the actions have been taken.

II – ALEZ only starts downloading, in terms of actually preparing the install of the final system, if booted via BIOS, selecting either UEFI+GRUB with a maximum of 8063MiB for ESP|EF00 at sector 2048 or BIOS+GRUB (automatically 1 MiB at Sector 2048 to 4095 for EF02 bios_grub partition followed by max rest of HDD as hardcoded in ALEZ); Downloading at around 3MiB/s and installing the system takes between 30 to 45 minutes (which is a heck if i may say so); installation is always unbootable due to the fact that grub isn't effectively written, nothing there after reboot, as if grub was installed to an overlay of the real ESP|BIOS_GRUB).

All other variants (systemd instead of grub, either booted UEFI or BIOS, etc. makes no difference) fail, somewhere in between selecting auto-partition target| selecting prepared partition up to starting the download of the final system (breaks right at the beginning).

What all variants have had in common that though EXT-USB drives are shown and can be selected for auto-partitioning run up to the the point where in UEFI-setup choosing the partition (part2) for the system would have been or actually is asked (depending on the type of setup – auto-partition vs. custom prepared.

ALEZ breaks immediately if there is any media containing a zpool present.

Where ALEZ actually runs the whole install, the moment mkcpio (i hope i remember this right) processes whatever it does, ALEZ either breaks or if passing that point, mumbles about can not this can not that blabliblu … yep.

At some point (while trying to follow the output) i recognized that ALEZ attempted to check for a fsck.zfs and wonders wtf is going on; whereas i wonder, does such a tool exist?

ALEZ hicks up on downloading the system if used with a 5 GHz Ch. 36 WLAN 802.11n WPA2-PSK; also if used with a or b or through a second router on LAN, which seems related as in these cases the rate isn't handled at the rates that are possible (11|22|100 mbit), but that is most likely due to default settings of the network management.

–

If you got to this point, you might wonder why the f i am blubbering all that out?

Answer is: I did these tests over about 10 days, asides my work, so to say as an alternative to completely shutdown my brain whenever my focus got lost. Please keep that in mind.

I named the things that i noted while in that pause-state-off-of-the-real-work and bundled it to the conclusions that jumped into my dried-out eyeballs, so stark it might give you an idea of where to enable some try-and-catch-style-figurines in your concept.

If you like to inspect further, i am willed to test specific constellations, with feedback, log files whatever you need. Just create complete case-description, deliver the patched versions with clear instructions or even totally automated. For that i can for about two to three weeks one of the 2740p and the 2760p set on layback for experiments, but in a reduced setup without flipping all possible switches (which i did only because the disks i used have been marked for deletion, so any real-data overwrite was welcome). I am fine with internal HDD|SSD SATA 80|160|320 or EXTUSB SATA 40|80; which should be enough to run some specific variations, right?

By the way, all those systems work perfectly fine, with Antergos ZFS install, customized after installation for use with zedenv and/or beadm; also with Debian Jessie|Stretch || Ubuntu Xenial|Bionic|Cosmic || Manjaro || CentOS || Fedora; Older versions need some to a lot of tweaking (Python, pyenv, specific apt, etc.) but all worked in the end, with BIOS GPT and UEFI GPT as also both together as wholedisk-installs or on custom partitions, also those prepared with OpenIndiana and FreeBSD 11.1 and 11.2; What came to mind is that since ZoL included userobj_accounting feature-flag it has to be explicitly disabled on creation in e.g.: ubuntu cosmic and accompanied by posix-acl, else none of the systems worked with neither zedenv nor beadm; Maybe that's a point to consider?

And yes, you might have come to the conclusion that i am fine with all-things-debian, but clearly arch is to me like a shudder, somehow, don't even know why.

However, hope it helps transcending your minds so you feel the need to nail yourself on crossed woodstabs and smile eloquently or let your body drift through waves of snow finding yourself on a cuddly piece of flat earth in the northern hemisphere.

Hope it helps, somehow!

ZFS hook failed to be added for LTS and feedback

I'm trying out ALEZ on a new laptop. I have yet to successfully install Arch with ZFS root using ALEZ. I just tried systemd-boot and LTS but when rebooting the file system failed to mount. I thought I saw some error messages about zfs hook when the installer was running but it went by very fast. Is there a log?

I am trying again with the Stable option and grub2 but it taking a long time to install. I feel like maybe my mirror is not optimized for me. Should I prepare the mirrorlist before running alez.

This will be amazing if the installer works because I was getting overwhelmed trying to manually install root ZFS. I was able to get through the Ubuntu root ZFS install using a very specific guide online.

My second install just finished and I did notice that the zfs hook failed to install. Should I try to manually install it before rebooting? What do you recommend?

UEFI systemd-boot install fails after selecting ESP partition

ISO used: archlinux-alez-2019.05.26.16.11.18-x86_64.iso booted in UEFI mode.

Just tried to install a zfs mirror install on two brand new 1 tb SSDs. Both drives were partitioned using the auto partitioning in the script. It successfully created the zfs mirror, then asks me to choose the partition to install the ESP to. As soon as I select /dev/sda1 the installer fails with this error.

Am I doing something wrong here?
I chose the systemd-boot option for the boot loader.
For the zfs mirror I chose /dev/sda2 and /dev/sdb2.
There are no other drives connected to the system except the usb flash drive.

systemd-boot not installing correctly

I have tried installing systemd-boot on a msata drive in a UEFI setup, and using both the April and May released, I get an immediate failure "can't find new_root" I have mounted the install using the usb drive, done the chroot to /mnt, and run bootcli. The following is the result:

systemd-boot not installed in ESP.
No default/fallback boot loader installed in ESP.
System:
     Firmware: UEFI 2.31 (American Megatrends 4.653)
  Secure Boot: disabled
   Setup Mode: setup

Current Boot Loader:
      Product: systemd-boot 245.4-1-arch
     Features: ✓ Boot counting
               ✓ Menu timeout control
               ✓ One-shot menu timeout control
               ✓ Default entry control
               ✓ One-shot entry control
               ✓ Support for XBOOTLDR partition
               ✓ Support for passing random seed to OS
               ✗ Boot loader sets ESP partition information
          ESP: n/a
         File: └─/EFI/BOOT/loader.efi

Random Seed:
 Passed to OS: no
 System Token: set
       Exists: no

Available Boot Loaders on ESP:
          ESP: /boot (/dev/disk/by-partuuid/3c1824db-12d3-4300-8af3-df261986ff49)

Boot Loaders Listed in EFI Variables:
        Title: Linux Boot Manager
           ID: 0x0003
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/3c1824db-12d3-4300-8af3-df261986ff49
         File: └─/EFI/systemd/systemd-bootx64.efi

Boot Loader Entries:
        $BOOT: /boot (/dev/disk/by-partuuid/3c1824db-12d3-4300-8af3-df261986ff49)

0 entries, no entry could be determined as default.

Switch to semantic versioning?

Right now the versioning scheme being used means every update has another major version. The recommended standard versioning scheme is semantic versioning using MAJOR.MINOR.PATCH. This would allow a minor version to exist and if bugs are noticed, a patch version could come out. Would you consider using semantic versioning?

archzfs.com certificate not valid yet

It may be that archzfs.com has a bad SSL installation somehow.

The result is that zfs-utils and zfs-modules are not getting installed automatically, and I can't install them manually until I change the server to use http instead of https, in /etc/pacman.conf.

The error was something like "certificate not valid yet".

INFORMAL - For the authors and potential testers; A reasoning why my initial 'bug report' is 'unorthodox' ...

Please let me add a virtual interview here for reasoning and just let it stay here, as it might help @danboid and @johnramsden and not so profound but eagerly interested people to understand, why my 'bug 'report' is the way it is and why this is an experience that can be of help.

–––

Just to add some explanation of the why and how i did it like this (as i'm asked often):
The main reason was, as i stated initially in the 'bug report', to do some necessary overwriting of the there listed drives, so i can do something necessary, that is easy to accomplish, without focusing much.

Why else?
Because asides the coding | structuring | illustrating i have (actually in part: had) to do ( that's what i meant by saying 'real work' ) i needed to do something at least similar ( meaning stay on in the digital way of being creative ), to not disrupt my workflow, when i needed to have a break from the 'real work'.

Okay, but how does that make sense any way?
In my free time [for quite some time now] i am fiddling with all existing ways to learn how to effectively make use of ZFS and BTRFS better and more detailed, so i can conclude what i learned and transform these conclusions into practical and where possible pragmatic variants of usage that effectively lead to fully purposed driving these filesystems cross-platform on (mainly):

– [ OpenIndiana | OmniOS CE | SmartOS | Tribblix || FreeBSD | GhostBSD | TrueOS | NetBSD || Debian | Ubuntu | MX | Ovirt | XenServer | CentOS | Scientific | Fedora | Sugar | Void | Gobo | Bedrock | Manjaro | Antergos | Arch || Android | Replicant | Lineage || Windows NT 5+ | 6+ | Mobile | Phone ].

Isn't it stupid to just test by using, instead of looking at the involved code?
As i stated, mainly for the purpose of 'refreshing' myself while diving deep into the zone of digital creative work; Mind and body do need some breaks inbetween. But also, because when you use alpha | beta stage software there mostly isn't much testing (in terms of many different users and usecases) done, yet.

Okay fine, but why not after testing just present the result from the perspective of the coder | system engineer | etc.?
Because projects like these, where i think they can be of general use even for advanced users, do need some varied testing without going into the internals, independent of how complex or simple they are. Not only hackers do want to use such a software. Where Hackers means as in the classical sense of the word; i am born 77, so a kid of the 80s and the Commodore 64 was the platform where i began, so hacking , meaning punching hundreds to thousands of lines over days before even thinking about saving the work, was needed; but that way is not exactly 'modern' nowadays.

Aha, yeah, whatever … Uh, what was your point?
To offer help in a way that is diverse from the usual perspectives. Although it often hurts people, being confronted with a different perspective can and in most cases is helpful.

–––

Just to make this clear i am not interested to turn anyones work into a philosophical discourse, there are other places to do so, but the potential users that do not know about these places, may stumble over these lines, so as long as there isn't a full README which helps leading users, based on their 'profile', onto the best fitting landing sites, this 'issue' may be of use, to make those understand that are not used to participate in any way.

To get 'correct' reports filed, there has to be a definition of what is 'correct', aight?

Just take this as a thought and encouragement to widen the insight given on the repositorys landing-page.

Grub-probe - Failed to get canonical path of 'zroot/ROOT/default'

I've tried the latest ISO as well as the first ISO from 03-18 and both throw this error. I did see you had an export that supposedly fixes this, but I can't see why that would help, I'm not really sure what the root cause is.

I'm guessing this:

https://askubuntu.com/questions/827126/zfs-grub-probe-error-failed-to-get-canonical-path-of-dev-disk-name/943425

is the rational for that export in the script? If so, I can't say I particularly understand how to fix this manually if that export isn't working.

systemd-boot installs to /mnt/efi instead of /efi

Probably should use the standard configuration that systemd-boot is looking for as according to systemd/systemd#3757

PROPOSAL - Offering a LTS-Kernel-only installation

After restudying my initial experiences with ALEZ and reading issue #16 – ZFS hook failed to be added for LTS and feedback and then the accompanying notes in the Arch-Wiki about the Kernel …

There are various alternative Linux kernels available for Arch Linux in addition to the stable Linux kernel.

… I realised that many of the issues i have had, may have roots in the by-design constantly-breaking on-a-daily-basis arch-repository (comparable to using Debian Unstable for example).

I propose therefore to have the option to do an LTS-Only-Installation of Arch-Linux via ALEZ.

Please let me know if this is possible and if so what would be an effective way to do so, e.g.:

• What tasks are involved to have an Arch-Install LTS-only?
• Would it be viable or does it break Arch-Linux on next update-cycle?
• What do you, the authors, as regular Arch-users think about it?