Naming the pool may prevent EFI from detecting GRUB – might want to disable the option to name the pool for now
mmmm… that’s odd. I’ll check this one. If I must I’ll disable the option.
Yes, I was pretty shocked. This was installing on a QEMU SATA emulated drive, so the device name was /dev/sda - so nothinig odd there.
I don’t think it’s really that big of a deal to be able to name the pool as long as it works, so just disabling the option for now until you find out what’s wrong shouldn’t upset anybody.
I did not try and update the bootloader on this installation, but I imagine the fix could be as easy as
# update-grub, or at most another
# mkinitcpio -p before
# grub-install etc. However many users may not know about these, or even how to navigate to the EFI partition using the EFI shell.
Exporting the pool manually before restarting the installer ISO allows the system to boot on the first try without having to type # zpool import -f poolname
That was included in the latest Cnchi 0.14.410 … it didn’t work?
Nope, the export worked when I did it manually, but it was not automated by Cnchi – when I rebooted after installation, if I didn’t manually export the pool, the volume would not boot I got the screen that recommended that I invoke
# zpool import -f poolname – the same behavior as before.
(…) these use the dev name /dev/vda rather than /dev/sda like “normal” drives
Yep, that could be it. I’ll check the code asap. Thanks.
Thank you! VirtIO drives are considerably faster than QEMU emulated drives - they’re nearly bare-metal speed.
However for testing, the emulated drive works fine, so this might not be a big deal considering there is probably not a large user base of people trying to emulate Antergos w/ ZFS on KVM. I wouldn’t spend too much time on it if it’s difficult for you.
One last thing I’d like to mention is that GRUB2 is the only bootloader option at the moment. Do you know how hard it would be to implement systemd boot for ZFS? It would open up a whole new range of possibilities, but I think it might be a little complicated.
There’s this project I’d like to call your attention to: https://github.com/dasJ/sd-zfs
It allows choosing a ZFS dataset to boot from using systemd initrd. It also allows booting from snapshots. It could be really helpful for people who have configuration issues, which, let’s be honest, are not that uncommon with Arch repositories.
That, in combination with properly configured znapzend could make a virtually unbreakable system:
I’ll be working behind the scenes to try and get this implemented on my own, and then I’d love to share my work with you and see if we can make these part of the Antergos repo. I really think it could be a show-stopper.
I’m starting by making a PKGBUILD for the AUR of znapzend.
I’ve got a manual install working, but there are a few issues in Arch/Antergos with the service when trying to install directly from the git clone.
Edit: nevermind, it’s already in the AUR. I thought I checked but I must’ve been wrong… https://aur.archlinux.org/packages/znapzend/
What would it take for me to be a package maintainer if Antergos would consider putting znapzend in their repo?
Thanks for all your wonderful work, I really appreciate it! Very excited…
Antergos x86_64 ZFS root w/Cinnamon est Nov 25, 2017 – because after a long week of struggling, I got tired of trying to put Arch on ZFS root…
"Linux … is more a phenomenon than an OS" - Joekamprad