I use Ubuntu Mate, so this is it’s URL: http://cdimage.ubuntu.com/ubuntu-mate/daily-live/current/ .
1 Like
Makes sense. I forgot to check the other “flavors”. As tempting as it is, I will wait. I’m not a big fan of Mate 
Official announcement probably next week (didn’t have the time to write the blog post). Spoiler alert: you get more features if you install zsys after the first boot
Keep in mind that this is experimental and should rather be played on non production systems (or backup your data and be ready to reinstall if things go widly). 
2 Likes
I installed Ubuntu Mate 19.10 on ZFS in Virtualbox on sdb, while sda has Ubuntu 19.10 on ext4 with both zfsutils-linux and zfs-initramfs installed. The installer refused to install a boot loader on both sda and sdb, but after booting from ext4 and:
- updating /etc/default/grub
- update-grub and grub-install /dev/sda
I have a nice dual boot system in Virtualbox And now forwards up to the next experiments.
Done the same with Ubuntu 19.10, but only one of the zfs disks can be used at the same time due to the same datapool names.
Ubuntu 19.10 on ZFS uses almost twice the memory of the ext4 version, probably because of L1ARC
I have installed zsys, curious what that will bring.
1 Like
Thanks, I saw that. Unfortunately I’ve run into issues installing. My bug is fixed and if I understand correctly ubiquity 19.10.16 will fix it. They really do work quick fixing the bugs. I’m impressed.
Unfortunately there is another bug plaguing this ISO which has nothing to do with the changes for ZFS.
We’ll rebuild an image as soon as the fix is published and hopefully next image will be good.
Thankfully you and the other professionals will fix it. We just test and report any bugs. I don’t think anyone here is upset about finding bugs. We all know it’s part of testing.
1 Like
I don’t know if this is related to the bug mentioned above but grub can’t seem to find some files (kernel and inirtd related) on the boot pool. Which pretty much aligns with the bug mentioned above.
Should I post this somewhere else?
I used the daily from 10/09. Booted to a computer using EFI. Used the graphical install, selected the ZFS fs option. Loaded the shim for EFI into the BIOS. Then grub only boots into the BIOS firmware, as that’s the only menu entry.
I imported the pools (rpool and bpool), used chroot, ran update-grub, and still no dice. I can give output if anyone would like to see some.
PS: I tried to do a debootstrap install about a week before I tried the graphical install option, it ended up with the same error. So I figured I would post about it now since I’m having the same issues with debootstrap.
What you describe is probably the bug we mentioned (no kernel installed on the target). The casper revert has just been published and an image will soon build.
If you can reproduce it with debootstrap, please report a different bug (and ensure you have a kernel+initramfs in /boot)
Where can I find some info about zsys, that is longer then 1 paragraph.
I’ll write about it in the coming weeks, once we released (can’t do bug fixing, enhancements and writing at the same time ;))
OK bug fixing is more important, but is there no specification or design documentation?
And here you go http://cdimage.ubuntu.com/daily-live/pending/
I did a quick smoke test of the image in a VM and installation was successful (I could reboot and login, with zfs on root)
1 Like
I tried the new 20191009.2/eoan-desktop-amd64.iso and I’m still having the same issue when I use the graphical installer. I installed with the graphical installer, selected ZFS, reboot, I still have only one menu entry for grub, which is the System Firmware menu entry.
From there I boot back into the live cd (USB, really), import the pools, bind things like /dev, chroot to rpool, update-grub, and it still has kernel initrd issues. And yes, they do exist in /mnt/boot (since I’m in chroot).
Here is the output from terminal, this is after I installed eoan and rebooted back to the USB installer.
Also, when you receive the warning message that your drive is about to be wiped, it shows that it will use Ext4, not ZFS. I attached three pictures of this, one before the warning without any typos, one is the actual warning with the typo, and another instance where the installer claims it’s using Ext4 instead of ZFS.
I had to make another pastebin for the pictures, since I can only post two links in a single post as I am a new user.
I have not yet tested this with a Virtual Machine yet. Maybe that gives different results? Or maybe I am missing something…
Thanks. This works great so far. Just quickly added a pool, only 2 drives since it’s a laptop. I’ll work more on it later.
I’m also having issues with 20191009.2/eoan-desktop-amd64.iso.
It seems like sometimes, during the first boot, it doesn’t import bpool. Since bpool isn’t mounted, the kernels aren’t there: And since it does mount /boot/grub, you CAN still update grub. Grub doesn’t like it when that happens because it has no kernels.
Oddly, the third time doing an install it worked fine. No idea why.
So, it seems your issue is different from the one we described before (or the one @xalucardx is still getting): grub menu was fine, but you couldn’t boot on your system because it doesn’t impor bpool in the initramfs.
I’m wondering if you click on the last ubiquity step “installation done” or “ready to reboot” when doing the install? If ubiquity didn’t stop properly, the pools aren’t exported. Then, zpool refuse to import the new pools because for zfs, it’s still potentially imported on another system (the live one) which is something new in 0.8.
Do you think that may be the case and can explain the difference between the 3 installations? (you rebooted your machine without closing ubiquity?)
If you can reproduce it, can you try adding zfs.force=1 to the kernel line parameter when booting in grub?
Indeed, this one is known and will be in the release note. It’s difficult to fix for 19.10 (as we actually create multiple partitions and a main ext4 partition to let partman handling the ESP, and then, overwrite the ext4 partition with ZFS), so it’s technically not lying It’s something we will fix before getting out of the “experimental” phase.
@xalucardx Thanks for the details, it’s very useful. From the pastebin everything seems in order and it’s really strange that grub doesn’t find a kernel which is obviously there. Could you report a bug against ubiquity in Launchpad and attach the log of installation located in /var/log/installer in the installed system. Thanks.
To add to what @jibel told, please report on the bug as well if your machine is using secure boot (then, it could be an ubiquity regression which doesn’t install signed kernel when it should, if this is the case, would worth testing on a traditional pure ext4 install).
An additional note: thanks for the excellent pastebin That makes us win a lot of roundtrip and is exactly the level of curated details command line and output that is awesome for remote debugging!