Ubiquity 20.04 exports existing ZFS pools

[Saverio Miroddi]

[Impact]

 * Ubiquity unmounts everything that could be mounted on the target file system when it starts and on tear down. For ZFS it exports all the pools.

 * If a user had existing pools, they are exported too.

 * This fix only unmount pool that are used as a target for the installation, leaving alone any other pool.

[Test Case]

 1. Boot a live session
 2. Create a new pool with:
$ zpool create -R /mnt tpool /dev/vda
 3. Verify that the pool is created with zpool list
 4. Start ubiquity
 5. Quit ubiquity

=> Verify that the pool is still there with zpool list. Without the fix, tpool is exported.

[Regression Potential]

 * Low risk of regression. Worst case, the bug is not fixed and pools are still unmounted or none of the pools are exported. This case would prevent to do 2 installations in a row from the same live session.

[Other info]

 * Already shipped in Groovy.

===

For unclear reasons (18.04 didn't have this issue), Ubiquity on 20.04 exports existing ZFS pools, (very) shortly after execution.

To repeat (assumes a `/dev/sda` disk):

- start a 20.04 Ubuntu Desktop live media
- open a terminal
- create a zfs pool: `zpool create test /dev/sda`
- verify that it's been created: `zpool list`
- launch ubiquity: `ubiquity`
- open a separate terminal
- list the ZFS pools: `zpool list`

no pools are now listed.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: ubiquity 20.04.15
ProcVersionSignature: Ubuntu 5.4.0-26.30-generic 5.4.30
Uname: Linux 5.4.0-26-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu27
Architecture: amd64
CasperMD5CheckMismatches: ./casper/vmlinuz
CasperMD5CheckResult: skip
CasperVersion: 1.445
CurrentDesktop: MATE
Date: Sat Apr 25 15:21:25 2020
InstallCmdLine: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/ubuntu-mate.seed quiet splash ---
LiveMediaBuild: Ubuntu-MATE 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=C.UTF-8
 SHELL=/bin/bash
SourcePackage: ubiquity
UpgradeStatus: No upgrade log present (probably fresh install)

[Saverio Miroddi (64kramsystem)]

Something odd is going on, which I don't know if it's expected or not, as Ubiquity may be intentionally messing with udev.

Specifically, if I have zvols, and run Ubiquity (which exports them), once I reimport the pool, the zvols have the block devices swapped. I can reproduce this all the time, and it doesn't happen when I export/import without Ubiquity involved.

[Jean-Baptiste Lallement (jibel)]

I'm working on a patch to only unmount pools that we've mounted as part of the installation to prevent unmounting pools that don't belong to us.

Regarding your other issue, it is possible that using /dev/sdX for vdev causes it. Depending on the type of block device these names are not stable and may change on boot or when udev runs. It's more reliable to use /dev/disk/by-uuid or /dev/disk/by-partuuid which are persistent.

[Saverio Miroddi (64kramsystem)]

> Regarding your other issue, it is possible that using /dev/sdX for vdev
> causes it. Depending on the type of block device these names are not
> stable and may change on boot or when udev runs. It's more reliable to
> use /dev/disk/by-uuid or /dev/disk/by-partuuid which are persistent.

I think this is valid for pools (which in fact, I configure with this strategly, specifically by using `/dev/by-id` entries), but not for zvols (which is where I experienced the problem).

Zvols use `/dev/zd*` symlink destinations, and those were the entries that I found swapped.

I don't think there is a any relation between `/dev/disk/by-(id|uuid)` and zvols, since zvols live inside pools.

[Launchpad Janitor (janitor)]

This bug was fixed in the package ubiquity - 20.10.2

---------------
ubiquity (20.10.2) groovy; urgency=medium

  [ Jean-Baptiste Lallement ]
  * zsys-setup: Use persistent device name for vdevs (LP: #1880869)
  * Only export pools created during installation and containing dataset
    mounted under /target (LP: #1875045)

  [ Dimitri John Ledkov ]
  * Automatic update of included source packages: partman-partitioning
    120ubuntu3. LP: #1796260

 -- Dimitri John Ledkov <email address hidden> Thu, 28 May 2020 22:41:16 +0100

[Brian Murray (brian-murray)]

Hello Saverio, or anyone else affected,

Accepted ubiquity into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/ubiquity/20.04.15.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Jean-Baptiste Lallement (jibel)]

SRU verification for Focal:
I have reproduced the problem with ubiquity 20.04.15 in focal and have verified that the version of ubiquity 20.04.15.1 in -proposed fixes the issue.

Marking as verification-done

[Launchpad Janitor (janitor)]

This bug was fixed in the package ubiquity - 20.04.15.1

---------------
ubiquity (20.04.15.1) focal; urgency=medium

  [ Sebastien Bacher ]
  * debian/real-po: updated translations from launchpad, including strings
    from the new subpage for RST (LP: #1874103)

  [ Michael Hudson-Doyle ]
  * make grub_default consider the boot argument in the non-removable case
    (LP: #1847898)

  [ Jean-Baptiste Lallement ]
  * Enable ZFS autotrim (LP: #1883686)
  * Use persistent path for pool's vdevs (LP: #1880869)
  * Do not export all pools (LP: #1875045)

  [ Dimitri John Ledkov ]
  * ubiquity-dm: start gsd-keyboard for keyboard indicator (LP: #1847307)

 -- Dimitri John Ledkov <email address hidden> Tue, 16 Jun 2020 11:17:42 +0100

[Łukasz Zemczak (sil2100)]

The verification of the Stable Release Update for ubiquity has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Brendan_P (brendan-p)]

Hello Folks,

I think I experienced this bug upgrading Ubuntu from 18.04 > 20.04 last night. If not, apologies.

I have the OS running on USB drive, normal install with all my data in a ZFS pool. After roboot/upgrade completed my ZFS pool is no longer listed.

Not a ZFS guru so nervous of next steps to resolve the issue. Any suggestions/help truly appreciated.