** Description changed:
[Impact]
- * An explanation of the effects of the bug on users and
+ * 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.
- * justification for backporting the fix to the stable release.
+ * If a user had existing pools, they are exported too.
- * In addition, it is helpful, but not required, to include an
- explanation of how the upload fixes this bug.
+ * This fix only unmount pool that are used as a target for the
+ installation, leaving alone any other pool.
[Test Case]
- * detailed instructions how to reproduce the bug
+ 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
- * these should allow someone who is not familiar with the affected
- package to reproduce the bug and verify that the updated package fixes
- the problem.
+ => Verify that the pool is still there with zpool list. Without the fix,
+ tpool is exported.
[Regression Potential]
- * discussion of how regressions are most likely to manifest as a result
- of this change.
-
- * It is assumed that any SRU candidate patch is well-tested before
- upload and has a low overall risk of regression, but it's important
- to make the effort to think about what ''could'' happen in the
- event of a regression.
-
- * This both shows the SRU team that the risks have been considered,
- and provides guidance to testers in regression-testing the SRU.
-
- [Other Info]
-
- * Anything else you think is useful to include
- * Anticipate questions from users, SRU, +1 maintenance, security teams and
the Technical Board
- * and address these questions in advance
+ * Low risk of regression. Worst case, the bug is not fixed and pools
+ are still unmounted.
===
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)
** Also affects: ubiquity (Ubuntu Focal)
Importance: Undecided
Status: New
** Description changed:
[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:
+ 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
+ 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.
+
+ [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)
** Description changed:
[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.
+ 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.
+
+ * 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)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1875045
Title:
Ubiquity 20.04 exports existing ZFS pools
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1875045/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
