Digging deeper and walking through this in a focal vm, I'm seeing some
strange things.
Starting with a clean disk, and just creating the backing device like
so:
make-bcache -B /dev/vdb
We see /dev/bcache0 get created with vdb as the backing device. Now,
after this, I see:
/dev/bcache/by-uuid/<dev.uuid> -> ../../bcache0
This is unexpected. It should *only* appear once the bcache0 device is
actively cached; that is the bcache driver should not emit CACHED_UUID,
until the UUID is actually cached, which only happens once we've
registered a cache device with the bcache0 device. We need to look at
the kernel source to see if the SAUCE patch isn't quite right, or some
other part of bcache code has changed.
Next issue, blkid now detects the bcache dev.uuid, and this shows up
like so:
# udevadm test-builtin blkid /sys/class/block/vdb
...
vdb: Probe /dev/vdb with raid and offset=0
ID_FS_UUID=d7d7e025-b8d2-43cb-a5df-c240ba1418dc
ID_FS_UUID_ENC=d7d7e025-b8d2-43cb-a5df-c240ba1418dc
ID_FS_TYPE=bcache
ID_FS_USAGE=other
Note, it shows up as an FS_UUID, but it is *NOT* an fs_uuid; there is no
filesystem on this device at all at this time; it does have a bcache
superblock, note the FS_UUID matches the dev.uuid of the backing device.
# bcache-super-show /dev/vdb
sb.magic ok
sb.first_sector 8 [match]
sb.csum 29D6774A332A280B [match]
sb.version 1 [backing device]
dev.label (empty)
dev.uuid d7d7e025-b8d2-43cb-a5df-c240ba1418dc
dev.sectors_per_block 1
dev.sectors_per_bucket 1024
dev.data.first_sector 16
dev.data.cache_mode 0 [writethrough]
dev.data.cache_state 0 [detached]
cset.uuid 37b37bc1-e185-4825-8900-579df102b7d6
It's also curious that cset.uuid has a UUID, as there are no csets
created; IMO this is also a bug and it should be 0, null, or empty.
Now, here's where the udev fights over the links. The backing device,
vdb, triggers this rule in 60-persistent-storage.rules:
# by-label/by-uuid links (filesystem metadata)
ENV{ID_FS_USAGE}=="filesystem|other|crypto", ENV{ID_FS_UUID_ENC}=="?*",
SYMLINK+="disk/by-uuid/$env{ID_FS_UUID_ENC}"
This creates confusion due to the CACHED_UUID also being emitted from
the kernel, like so:
root@ubuntu:/run/udev/links# ls -al
/dev/disk/by-uuid/d7d7e025-b8d2-43cb-a5df-c240ba1418dc
lrwxrwxrwx 1 root root 9 May 21 16:39
/dev/disk/by-uuid/d7d7e025-b8d2-43cb-a5df-c240ba1418dc -> ../../vdb
root@ubuntu:/run/udev/links# ls -al
/dev/bcache/by-uuid/d7d7e025-b8d2-43cb-a5df-c240ba1418dc
lrwxrwxrwx 1 root root 13 May 21 16:39
/dev/bcache/by-uuid/d7d7e025-b8d2-43cb-a5df-c240ba1418dc -> ../../bcache0
There we have two devices both claiming the backing devices dev.uuid
value, with two different block names.
So, in summary, there are two problems to fix:
1) blkid on bcache devices should not report FS_UUID values when
FS_TYPE=bcache; there is no filesystem on it; this will need to be
discussed upstream
2) our kernel (need to check mainline vs. ours) emits CACHED_UUID when
the bcache0 is created, but no cache is attached: see this udev event:
KERNEL[2217.605118] change /devices/virtual/block/bcache0 (block)
ACTION=change
DEVPATH=/devices/virtual/block/bcache0
SUBSYSTEM=block
DRIVER=bcache
CACHED_UUID=d7d7e025-b8d2-43cb-a5df-c240ba1418dc
CACHED_LABEL=
DEVNAME=/dev/bcache0
DEVTYPE=disk
SEQNUM=5890
MAJOR=251
MINOR=0
** Changed in: linux (Ubuntu Groovy)
Status: Invalid => New
** Changed in: linux-signed (Ubuntu Groovy)
Status: Invalid => New
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-signed 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 linux package in Ubuntu:
New
Status in linux-signed package in Ubuntu:
New
Status in systemd package in Ubuntu:
Invalid
Status in bcache-tools source package in Focal:
New
Status in linux source package in Focal:
Invalid
Status in linux-signed source package in Focal:
New
Status in systemd source package in Focal:
Invalid
Status in bcache-tools source package in Groovy:
Fix Released
Status in linux source package in Groovy:
New
Status in linux-signed source package in Groovy:
New
Status in systemd source package in Groovy:
Invalid
Bug 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/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
