Hi,

On Mon, Sep 22, 2025 at 09:54:58AM +0100, Henrik Morsing wrote:
> morsing@laptop:~$ su - Password: root@laptop:~# blkid

[sdb6 not listed]

I am unsure if "blkid" is trying to read from the devices itself or only
giving what udev has (or doesn't have, in this case).

> root@laptop:~# tune2fs -l /dev/sdb6 | grep UU
> Filesystem UUID:          23ba8ae2-5f38-43e7-959a-8495f6889302

Yep, you've shown us that the UUID really is set as far as the
filesystem is concerned.

> root@laptop:~# grep UUID /etc/fstab # device; this may be used with UUID= as
> a more robust way to name devices
> UUID=bf15ddf4-5d58-4048-a23f-36261dbbd60c /          ext4    
> errors=remount-ro 0       1
> #UUID=23ba8ae2-5f38-43e7-959a-8495f6889302 /home      ext4    defaults        
> 0       2
> UUID=3e79cbc6-22d3-4b7c-9da5-89f8f3ded61b none            swap    sw          
>     0       0

I don't think you need to be concerned about fstab, initramfs and
things like that. The problem here is that udev isn't reading a UUID
from this filesystem and without that nothing else works. As you have
rebooted, it also isn't just a case of giving udev a kick, because after
boot it still doesn't read it.

> root@laptop:~# lsblk --fs
> NAME   FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% 
> MOUNTPOINTS
> sda
> ├─sda1 vfat   FAT32       640F-F0C9
> └─sda2 ntfs         Vida  60F07CFFE675BC45
> sdb
> ├─sdb1 ext4   1.0         bf15ddf4-5d58-4048-a23f-36261dbbd60c    5.2G
> 51% /
> ├─sdb2
> ├─sdb5 swap   1           3e79cbc6-22d3-4b7c-9da5-89f8f3ded61b
> [SWAP]
> └─sdb6                                                           87.7G     1% 
> /home

So again, udev only knows there is a block device/partition, not even
what filesystem is on it let alone that it has a UUID. None of this is
going to work until the output of the above command shows the full
details for sdb6 because without that, the links in /dev/disk/by-… won't
be there.

> None of the partitions show labels using tune2fs or e2label.

Okay, well that's expected as you aren't using labels. I'm guessing
even if you did, udev might not work that out for sdb6. Let's not muddy
the waters by going down that route…

> root@laptop:~# udevadm info --query=property --name=/dev/sdb6 | grep -E 
> "LABEL|UUID|DEVLINKS"
> ID_PART_TABLE_UUID=a1771adb
> DEVLINKS=/dev/disk/by-path/pci-0000:00:1f.2-ata-2.0-part6 
> /dev/disk/by-diskseq/2-part6 /dev/disk/by-id/wwn-0x50026b766b039cd2-part6 
> /dev/disk/by-path/pci-0000:00:1f.2-ata-2-part6 
> /dev/disk/by-id/ata-KINGSTON_SV300S37A120G_50026B766B039CD2-part6 
> /dev/disk/by-path/pci-0000:00:1f.2-ata-2.0-part/by-partnum/6

So udev knows just the very basics about sdb6.

I am a bit stumped for now. I think I'd submit a Debian bug against udev
(reportbug udev) saying that it can't detect a UUID or filesystem on
sdb6 but does on other partitions. Use tune2fs, lsblk and "udevadm
info" output to demonstrate the discrepancy.

Let us know the number of it if you do — I'll be interested to follow
it!

Good luck,
Andy

PS in the mean time if you are having actual problems with the disk that
   your /home is on being given a different device node thus not
   mounting, you could in /etc/fstab use one of the stable DEVLINKs that
   you *do* have, ugly as they are. So for example

   /dev/disk/by-id/ata-KINGSTON_SV300S37A120G_50026B766B039CD2-part6

   or

   /dev/disk/by-id/wwn-0x50026b766b039cd2-part6

   They are at least available to you and remain stable.

   I'd obviously still want to get to the bottom of not being able to
   use UUID/LABEL here though.

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
[email protected]
https://mailman.lug.org.uk/mailman/listinfo/gllug

Reply via email to