I will read it a few times more, because it is complex. In the past I booted from ext4 and I had stored all my ~15 Virtual Machines in vms/vms (and on the desktop I have vms/kvm too). I was pleased with the instantaneous response times in the VMs, because the Linux VMs did almost completely run from L1ARC. So when I decided to boot from ZFS, I decided to use the VMS datapool to avoid repartitioning the disk. That vms datapool was already at the begin of the 1TB SSHD. That worked fine, also when moving the disks from Phenom to Ryzen and during the upgrade from 18.04 to 19.04 to 19.10. The first problem has been the update of ZFS itself, which I start to understand now.
By the way today I did run into the same problems again. I did run a VM on my desktop with Ubuntu 19.10 using ext4. After the release of the new installer, I installed Ubuntu on ZFS on a seconds disk sdb. Despite a minor problem it worked fine. I had a nice dual boot. Again till today on my sda-ext4 installation, when zfsutils-linux was updated, the update failed again in the that mount. It seems bpool or rpool also cause problems in such a dual boot with ext4. The bypass is simple this time, I remove sdb during the update process However I think, it is strange to use something like "zfs mount -a" in the update process itself, the system to be updated is already mounted. Besides it makes the update process vulnerable. Thank you for the explanation, that I will read again. On 9/10/19 7:21 p. m., Richard Laager wrote: > You had a setup with multiple root filesystems which each had > canmount=on and mountpoint=/. So they both tried to automatically mount > at /. (When booting in the root-on-ZFS config, one was already mounted > as your root filesystem.) ZFS, unlike other Linux filesystems, refuses > to mount over non-empty directories. Thus, mounting over / fails. Thus > `zfs mount -a` would fail, which was the underlying command for zfs- > mount.service. As a result of the mount failing, you got into a state > where some datasets mounted, but not all of them. As a result of this, > you had empty directories for some mountpoints in the wrong filesystems. > As a result, those empty directories continued to break `zfs mount -a`. > > In your case, it's likely that the relevant directory was /vms/vms. This > was preventing you from mounting the vms dataset at /vms. To be > absolutely clear, this was because /vms was non-empty, because it > contained /vms/vms. > > You first fixed the underlying issue with the root filesystems by > setting canmount=noauto on both of them. That still left the second > problem. Once you `rmdir`ed the directory(ies) that were in the way, > mounting works correctly. > > Separately from the issues above, it's best practice to NOT store anything in > the root dataset on a pool (the dataset with the same name as the pool, in > this case "vms"), because that dataset can never be renamed. If you're not > actually using the "vms" dataset itself, I suggest the following: > zfs unmount vms/vms > rmdir /vms/vms # this rmdir not required, but I like to cleanup completely > zfs unmount vms > zfs set canmount=off vms > zfs mount vms/vms > -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to zfs-linux in Ubuntu. https://bugs.launchpad.net/bugs/1846424 Title: 19.10 ZFS Update failed on 2019-10-02 Status in zfs-linux package in Ubuntu: Invalid Bug description: On all my systems the update from zfs-initrams_0.8.1-1ubuntu12_amd64.deb failed the same is true for zfs-zed and zfsutils-linux. The system still runs on 0.8.1-1ubuntu11_amd64. The first error message was about a failing mount and at the end it announced that all 3 modules were not updated. I have the error on Xubuntu 19.10, Ubuntu Mate 19.10 on my laptop i5-2520M and in a VBox VM on a Ryzen 3 2200G with Ubuntu 19.10. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1846424/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
