[Bug 1861941] Re: bcache by-uuid links disappear after mounting bcache0
Rafael David Tinoco
1861941 at bugs.launchpad.net
Wed Aug 5 21:47:33 UTC 2020
CURRENT STATUS:
SUMMARY:
BUG: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1861941
TESTCASE: https://paste.ubuntu.com/p/37KGy2Smnp/
PPA: https://launchpad.net/~rafaeldtinoco/+archive/ubuntu/lp1861941
BCACHE-TOOLS:
GROOVY: https://tinyurl.com/yxonp5hz (merged)
FOCAL: https://tinyurl.com/y3tbd3un (committed + verified)
BIONIC: https://tinyurl.com/y58fm4l5 (being reviewed)
SYSTEMD-UDEV:
GROOVY: https://tinyurl.com/y4w22s57 (merged patch rewording, will wait next upload)
FOCAL: https://tinyurl.com/y2uqbyll (merged patch, will ask for an upload - SRU)
BIONIC: BEING WORKED
KERNEL:
Decided that won't be changed as the udev bcache changes won't cause any
harm. Will ask for the patch to be dropped from groovy's kernel since
there isn't any need to keep it.
** Description changed:
+ [Impact]
+
+ * bcache-tools udev created symlinks might disappear when other udev
+ events are processed for the same devices.
+
+ * after mkfs.XXX in /dev/bcacheY you might face a condition where
+ /dev/bcache/by-{uuid,label}/zzz symlinks are gone.
+
+ * /dev/bcache/by-{uuid,label}/ symlinks are important so bcache devices
+ can be addressed by their UUIDs and not the ordering they were assembled
+ (MAAS depends on this feature, for example).
+
+ * it was also discussed in this bug that systemd-udev should *not*
+ populate /dev/disk/by-uuid/ with symlinks of disks that were bcache
+ backing devices. this was turned into a discussion whether blkid should
+ report those or not, and this discussion "died" after sometime.
+
+ [Test Case]
+
+ * The reproducer script is here:
+
+ https://paste.ubuntu.com/p/37KGy2Smnp/
+
+ [Regression Potential]
+
+ * We are not depending on bcache device udev events any more when
+ creating the /dev/bcache/by-{uuid,label}/ symlinks. Instead, we are
+ depending on a wrapper script that heads bcache device superblock. If
+ there is a bug in this wrapper the symlinks wouldn't work.
+
+ * Previously we were thinking in asking the kernel team to remove the
+ bcache udev event delta script they've done for previous case (LP:
+ #1729145). It creates the udev events that were being read and filling
+ the symlinks. We decided not to remove those (just from Groovy and on)
+ so we don't need to worry on Breaks/Conflicts in between the kernel
+ package and bcache-tools (and udev)).
+
+ * Long story short: kernel will continue to emit bcache udev events as
+ it did previously but now those events won't be used by anything - after
+ installing this SRU - because udev wrapper script is doing this job (and
+ doing it properly)
+
+ [Other Info]
+
+ - Original Description:
+
+
1.
root at ubuntu:~# lsb_release -rd
Description: Ubuntu Focal Fossa (development branch)
Release: 20.04
- 2.
+ 2.
root at ubuntu:~# lsb_release -rd
Description: Ubuntu Focal Fossa (development branch)
Release: 20.04
- root at ubuntu:~# apt-cache policy linux-image-virtual
+ root at ubuntu:~# apt-cache policy linux-image-virtual
linux-image-virtual:
- Installed: 5.4.0.12.15
- Candidate: 5.4.0.12.15
- Version table:
- *** 5.4.0.12.15 500
- 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
- 100 /var/lib/dpkg/status
- root at ubuntu:~# apt-cache policy linux-image-5.4.0-12-generic
+ Installed: 5.4.0.12.15
+ Candidate: 5.4.0.12.15
+ Version table:
+ *** 5.4.0.12.15 500
+ 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
+ 100 /var/lib/dpkg/status
+ root at ubuntu:~# apt-cache policy linux-image-5.4.0-12-generic
linux-image-5.4.0-12-generic:
- Installed: 5.4.0-12.15
- Candidate: 5.4.0-12.15
- Version table:
- *** 5.4.0-12.15 500
- 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
- 100 /var/lib/dpkg/status
+ Installed: 5.4.0-12.15
+ Candidate: 5.4.0-12.15
+ Version table:
+ *** 5.4.0-12.15 500
+ 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
+ 100 /var/lib/dpkg/status
3. mount /dev/bcache0 && ls -al /dev/bcache/by-uuid/
+ ls -al /dev/bcache/by-uuid/
total 0
drwxr-xr-x 2 root root 60 Feb 4 23:31 .
drwxr-xr-x 3 root root 60 Feb 4 23:31 ..
lrwxrwxrwx 1 root root 13 Feb 4 23:31 abdfd1f6-44ce-4266-91db-24667b9ae51a -> ../../bcache0
4.
root at ubuntu:~# ls -al /dev/bcache/by-uuid
ls: cannot access '/dev/bcache/by-uuid': No such file or directory
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: linux-image-5.4.0-12-generic 5.4.0-12.15
ProcVersionSignature: Ubuntu 5.4.0-12.15-generic 5.4.8
Uname: Linux 5.4.0-12-generic x86_64
ApportVersion: 2.20.11-0ubuntu16
Architecture: amd64
Date: Tue Feb 4 23:31:52 2020
ProcEnviron:
- TERM=xterm-256color
- PATH=(custom, no user)
- LANG=C.UTF-8
- SHELL=/bin/bash
+ TERM=xterm-256color
+ PATH=(custom, no user)
+ LANG=C.UTF-8
+ SHELL=/bin/bash
SourcePackage: linux-signed-5.4
UpgradeStatus: No upgrade log present (probably fresh install)
** Description changed:
[Impact]
- * bcache-tools udev created symlinks might disappear when other udev
+ * bcache-tools udev created symlinks might disappear when other udev
events are processed for the same devices.
- * after mkfs.XXX in /dev/bcacheY you might face a condition where
+ * after mkfs.XXX in /dev/bcacheY you might face a condition where
/dev/bcache/by-{uuid,label}/zzz symlinks are gone.
- * /dev/bcache/by-{uuid,label}/ symlinks are important so bcache devices
+ * /dev/bcache/by-{uuid,label}/ symlinks are important so bcache devices
can be addressed by their UUIDs and not the ordering they were assembled
(MAAS depends on this feature, for example).
- * it was also discussed in this bug that systemd-udev should *not*
+ * it was also discussed in this bug that systemd-udev should *not*
populate /dev/disk/by-uuid/ with symlinks of disks that were bcache
backing devices. this was turned into a discussion whether blkid should
report those or not, and this discussion "died" after sometime.
[Test Case]
- * The reproducer script is here:
+ * The reproducer script is here:
- https://paste.ubuntu.com/p/37KGy2Smnp/
+ https://paste.ubuntu.com/p/37KGy2Smnp/
+
+ * Bionic can't reproduce the issue with the 18.04 kernel, nor with the
+ HWE kernel. Nevertheless, it is preferable that Bionic also do the same
+ thing: to read bcache superblock and feed environment for
+ /dev/bcache/by-{uuid,label} symlinks creation.
[Regression Potential]
- * We are not depending on bcache device udev events any more when
+ * We are not depending on bcache device udev events any more when
creating the /dev/bcache/by-{uuid,label}/ symlinks. Instead, we are
depending on a wrapper script that heads bcache device superblock. If
there is a bug in this wrapper the symlinks wouldn't work.
- * Previously we were thinking in asking the kernel team to remove the
+ * Previously we were thinking in asking the kernel team to remove the
bcache udev event delta script they've done for previous case (LP:
#1729145). It creates the udev events that were being read and filling
the symlinks. We decided not to remove those (just from Groovy and on)
so we don't need to worry on Breaks/Conflicts in between the kernel
package and bcache-tools (and udev)).
- * Long story short: kernel will continue to emit bcache udev events as
+ * Long story short: kernel will continue to emit bcache udev events as
it did previously but now those events won't be used by anything - after
installing this SRU - because udev wrapper script is doing this job (and
doing it properly)
[Other Info]
- Original Description:
-
1.
root at ubuntu:~# lsb_release -rd
Description: Ubuntu Focal Fossa (development branch)
Release: 20.04
2.
root at ubuntu:~# lsb_release -rd
Description: Ubuntu Focal Fossa (development branch)
Release: 20.04
root at ubuntu:~# apt-cache policy linux-image-virtual
linux-image-virtual:
Installed: 5.4.0.12.15
Candidate: 5.4.0.12.15
Version table:
*** 5.4.0.12.15 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
100 /var/lib/dpkg/status
root at ubuntu:~# apt-cache policy linux-image-5.4.0-12-generic
linux-image-5.4.0-12-generic:
Installed: 5.4.0-12.15
Candidate: 5.4.0-12.15
Version table:
*** 5.4.0-12.15 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
100 /var/lib/dpkg/status
3. mount /dev/bcache0 && ls -al /dev/bcache/by-uuid/
+ ls -al /dev/bcache/by-uuid/
total 0
drwxr-xr-x 2 root root 60 Feb 4 23:31 .
drwxr-xr-x 3 root root 60 Feb 4 23:31 ..
lrwxrwxrwx 1 root root 13 Feb 4 23:31 abdfd1f6-44ce-4266-91db-24667b9ae51a -> ../../bcache0
4.
root at ubuntu:~# ls -al /dev/bcache/by-uuid
ls: cannot access '/dev/bcache/by-uuid': No such file or directory
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: linux-image-5.4.0-12-generic 5.4.0-12.15
ProcVersionSignature: Ubuntu 5.4.0-12.15-generic 5.4.8
Uname: Linux 5.4.0-12-generic x86_64
ApportVersion: 2.20.11-0ubuntu16
Architecture: amd64
Date: Tue Feb 4 23:31:52 2020
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
LANG=C.UTF-8
SHELL=/bin/bash
SourcePackage: linux-signed-5.4
UpgradeStatus: No upgrade log present (probably fresh install)
** Description changed:
[Impact]
* bcache-tools udev created symlinks might disappear when other udev
events are processed for the same devices.
* after mkfs.XXX in /dev/bcacheY you might face a condition where
/dev/bcache/by-{uuid,label}/zzz symlinks are gone.
* /dev/bcache/by-{uuid,label}/ symlinks are important so bcache devices
can be addressed by their UUIDs and not the ordering they were assembled
(MAAS depends on this feature, for example).
* it was also discussed in this bug that systemd-udev should *not*
populate /dev/disk/by-uuid/ with symlinks of disks that were bcache
backing devices. this was turned into a discussion whether blkid should
- report those or not, and this discussion "died" after sometime.
+ report those or not, and this discussion "died" after sometime. This
+ last item is what the systemd update is all about: to disallow /dev/disk
+ /by-XXX/yyyy creation for bcache backing devices (a simple change that
+ will reduce end users confusion).
[Test Case]
* The reproducer script is here:
https://paste.ubuntu.com/p/37KGy2Smnp/
- * Bionic can't reproduce the issue with the 18.04 kernel, nor with the
+ * Bionic can't reproduce the issue with the 18.04 kernel, nor with the
HWE kernel. Nevertheless, it is preferable that Bionic also do the same
thing: to read bcache superblock and feed environment for
/dev/bcache/by-{uuid,label} symlinks creation.
[Regression Potential]
* We are not depending on bcache device udev events any more when
creating the /dev/bcache/by-{uuid,label}/ symlinks. Instead, we are
depending on a wrapper script that heads bcache device superblock. If
there is a bug in this wrapper the symlinks wouldn't work.
* Previously we were thinking in asking the kernel team to remove the
bcache udev event delta script they've done for previous case (LP:
#1729145). It creates the udev events that were being read and filling
the symlinks. We decided not to remove those (just from Groovy and on)
so we don't need to worry on Breaks/Conflicts in between the kernel
package and bcache-tools (and udev)).
* Long story short: kernel will continue to emit bcache udev events as
it did previously but now those events won't be used by anything - after
installing this SRU - because udev wrapper script is doing this job (and
doing it properly)
[Other Info]
- Original Description:
1.
root at ubuntu:~# lsb_release -rd
Description: Ubuntu Focal Fossa (development branch)
Release: 20.04
2.
root at ubuntu:~# lsb_release -rd
Description: Ubuntu Focal Fossa (development branch)
Release: 20.04
root at ubuntu:~# apt-cache policy linux-image-virtual
linux-image-virtual:
Installed: 5.4.0.12.15
Candidate: 5.4.0.12.15
Version table:
*** 5.4.0.12.15 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
100 /var/lib/dpkg/status
root at ubuntu:~# apt-cache policy linux-image-5.4.0-12-generic
linux-image-5.4.0-12-generic:
Installed: 5.4.0-12.15
Candidate: 5.4.0-12.15
Version table:
*** 5.4.0-12.15 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
100 /var/lib/dpkg/status
3. mount /dev/bcache0 && ls -al /dev/bcache/by-uuid/
+ ls -al /dev/bcache/by-uuid/
total 0
drwxr-xr-x 2 root root 60 Feb 4 23:31 .
drwxr-xr-x 3 root root 60 Feb 4 23:31 ..
lrwxrwxrwx 1 root root 13 Feb 4 23:31 abdfd1f6-44ce-4266-91db-24667b9ae51a -> ../../bcache0
4.
root at ubuntu:~# ls -al /dev/bcache/by-uuid
ls: cannot access '/dev/bcache/by-uuid': No such file or directory
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: linux-image-5.4.0-12-generic 5.4.0-12.15
ProcVersionSignature: Ubuntu 5.4.0-12.15-generic 5.4.8
Uname: Linux 5.4.0-12-generic x86_64
ApportVersion: 2.20.11-0ubuntu16
Architecture: amd64
Date: Tue Feb 4 23:31:52 2020
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
LANG=C.UTF-8
SHELL=/bin/bash
SourcePackage: linux-signed-5.4
UpgradeStatus: No upgrade log present (probably fresh install)
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1861941
Title:
bcache by-uuid links disappear after mounting bcache0
Status in bcache-tools package in Ubuntu:
Fix Released
Status in systemd package in Ubuntu:
Fix Released
Status in bcache-tools source package in Bionic:
In Progress
Status in systemd source package in Bionic:
In Progress
Status in bcache-tools source package in Focal:
Fix Committed
Status in systemd source package in Focal:
In Progress
Bug description:
[Impact]
* bcache-tools udev created symlinks might disappear when other udev
events are processed for the same devices.
* after mkfs.XXX in /dev/bcacheY you might face a condition where
/dev/bcache/by-{uuid,label}/zzz symlinks are gone.
* /dev/bcache/by-{uuid,label}/ symlinks are important so bcache
devices can be addressed by their UUIDs and not the ordering they were
assembled (MAAS depends on this feature, for example).
* it was also discussed in this bug that systemd-udev should *not*
populate /dev/disk/by-uuid/ with symlinks of disks that were bcache
backing devices. this was turned into a discussion whether blkid
should report those or not, and this discussion "died" after sometime.
This last item is what the systemd update is all about: to disallow
/dev/disk/by-XXX/yyyy creation for bcache backing devices (a simple
change that will reduce end users confusion).
[Test Case]
* The reproducer script is here:
https://paste.ubuntu.com/p/37KGy2Smnp/
* Bionic can't reproduce the issue with the 18.04 kernel, nor with
the HWE kernel. Nevertheless, it is preferable that Bionic also do the
same thing: to read bcache superblock and feed environment for
/dev/bcache/by-{uuid,label} symlinks creation.
[Regression Potential]
* We are not depending on bcache device udev events any more when
creating the /dev/bcache/by-{uuid,label}/ symlinks. Instead, we are
depending on a wrapper script that heads bcache device superblock. If
there is a bug in this wrapper the symlinks wouldn't work.
* Previously we were thinking in asking the kernel team to remove the
bcache udev event delta script they've done for previous case (LP:
#1729145). It creates the udev events that were being read and filling
the symlinks. We decided not to remove those (just from Groovy and on)
so we don't need to worry on Breaks/Conflicts in between the kernel
package and bcache-tools (and udev)).
* Long story short: kernel will continue to emit bcache udev events
as it did previously but now those events won't be used by anything -
after installing this SRU - because udev wrapper script is doing this
job (and doing it properly)
[Other Info]
- Original Description:
1.
root at ubuntu:~# lsb_release -rd
Description: Ubuntu Focal Fossa (development branch)
Release: 20.04
2.
root at ubuntu:~# lsb_release -rd
Description: Ubuntu Focal Fossa (development branch)
Release: 20.04
root at ubuntu:~# apt-cache policy linux-image-virtual
linux-image-virtual:
Installed: 5.4.0.12.15
Candidate: 5.4.0.12.15
Version table:
*** 5.4.0.12.15 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
100 /var/lib/dpkg/status
root at ubuntu:~# apt-cache policy linux-image-5.4.0-12-generic
linux-image-5.4.0-12-generic:
Installed: 5.4.0-12.15
Candidate: 5.4.0-12.15
Version table:
*** 5.4.0-12.15 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
100 /var/lib/dpkg/status
3. mount /dev/bcache0 && ls -al /dev/bcache/by-uuid/
+ ls -al /dev/bcache/by-uuid/
total 0
drwxr-xr-x 2 root root 60 Feb 4 23:31 .
drwxr-xr-x 3 root root 60 Feb 4 23:31 ..
lrwxrwxrwx 1 root root 13 Feb 4 23:31 abdfd1f6-44ce-4266-91db-24667b9ae51a -> ../../bcache0
4.
root at ubuntu:~# ls -al /dev/bcache/by-uuid
ls: cannot access '/dev/bcache/by-uuid': No such file or directory
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: linux-image-5.4.0-12-generic 5.4.0-12.15
ProcVersionSignature: Ubuntu 5.4.0-12.15-generic 5.4.8
Uname: Linux 5.4.0-12-generic x86_64
ApportVersion: 2.20.11-0ubuntu16
Architecture: amd64
Date: Tue Feb 4 23:31:52 2020
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
LANG=C.UTF-8
SHELL=/bin/bash
SourcePackage: linux-signed-5.4
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bcache-tools/+bug/1861941/+subscriptions
More information about the foundations-bugs
mailing list