[Bug 1867007] Re: zfs-initramfs fails with multiple rpool on separate disks

[Didier Roche]

Hey Balint. I just added the task post ZFS upload (the upload was
yesterday and I added the task this morning) so indeed, there is some
work needed, part of it being in systemd.

Basically, systemd isn’t capable of mounting datasets when pool names are duplicated on a machine
zfs-mount-generator generates .mount units with the pool name. systemd needs to either, for all poo«ls mactching the desired name
- prefers pool id matching zpool.cache
- check every pools for their dataset and import the first matching one (same dataset path)
- or the .mount unit should be able to import by ID and zfs-mount-generator upstream should generate a pool id somewhere in the unit file.

** Changed in: systemd (Ubuntu)
       Status: Incomplete => Confirmed

** Changed in: systemd (Ubuntu)
       Status: Confirmed => Triaged

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to grub2 in Ubuntu.
https://bugs.launchpad.net/bugs/1867007

Title:
  zfs-initramfs fails with multiple rpool on separate disks

Status in grub2 package in Ubuntu:
  Triaged
Status in systemd package in Ubuntu:
  Triaged
Status in zfs-linux package in Ubuntu:
  Fix Released

Bug description:
  == Test Case ==
  1. On a multi disks setup, install Ubuntu with ZFS on disk 1
  2. Reboot and make sure everything works as expected
  3. Do a second installation and install Ubuntu with ZFS on disk 2
  4. Reboot

  * Expected Result *
  GRUB should display all the machines available and let the user select which installation to boot

  * Actual result *
  - Only one machine is listed
  - initramfs crashes because there are several pool with the same name but different IDs and import the pools by name
  - Same problem in the systemd generator which will try to import all the rpools.

  == Original Description ==

  I had an Ubuntu old installation that used a ZFS root, using the
  layout described in the ZFS on Linux docs. Consequently, the pool name
  for my Ubuntu installation was "rpool". I'm currently encountering an
  issue with that pool that only allows me to mount it read-only. So,
  I'd like to replicate the datasets from there to a new device.

  On the new device, I've set up a ZFS system using the Ubuntu 20.04
  daily installer (March 9, 2020). This setup creates a new pool named
  "rpool". So, with both devices inserted, I have two distinct pools
  each named "rpool", one of which will kernel panic if I try to mount
  it read-write.

  ZFS is fine with having multiple pools with the same name. In these
  cases, you use `zfs import` with the pool's GUID and give it a
  distinct pool name on import. However, the grub config for booting
  from ZFS doesn't appear to handle multiple pools with the same rpool
  name very well. Rather than using the pool's GUID, it uses the name,
  and as such, it's unable to boot properly when another pool with the
  name "rpool" is attached to the system.

  I think it'd be better if the config were written in such a way that
  `update-grub` generated boot config bound to whatever pool it found at
  the time of its invocation, and not start searching through all pools
  dynamically upon boot. Just to be clear, I have an Ubuntu 20.04 system
  with a ZFS root that boots just fine. But, the moment I attach the old
  pool, also named "rpool", I'm no longer able to boot up my system even
  though I haven't removed the good pool and I haven't re-run `update-
  grub`. Instead of booting, I'm thrown into the grub command line.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1867007/+subscriptions