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@ubuntu:~# lsb_release -rd
  Description:  Ubuntu Focal Fossa (development branch)
  Release:      20.04
  
- 2. 
+ 2.
  root@ubuntu:~# lsb_release -rd
  Description:  Ubuntu Focal Fossa (development branch)
  Release:      20.04
- root@ubuntu:~# apt-cache policy linux-image-virtual 
+ root@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@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@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@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@ubuntu:~# lsb_release -rd
  Description:  Ubuntu Focal Fossa (development branch)
  Release:      20.04
  
  2.
  root@ubuntu:~# lsb_release -rd
  Description:  Ubuntu Focal Fossa (development branch)
  Release:      20.04
  root@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@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@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@ubuntu:~# lsb_release -rd
  Description:  Ubuntu Focal Fossa (development branch)
  Release:      20.04
  
  2.
  root@ubuntu:~# lsb_release -rd
  Description:  Ubuntu Focal Fossa (development branch)
  Release:      20.04
  root@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@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@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
Touch seeded packages, 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@ubuntu:~# lsb_release -rd
  Description:  Ubuntu Focal Fossa (development branch)
  Release:      20.04

  2.
  root@ubuntu:~# lsb_release -rd
  Description:  Ubuntu Focal Fossa (development branch)
  Release:      20.04
  root@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@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@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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to