You are not logged in.
Pages: 1
I discovered, that on my system lsblk does not provide correct PARTUUIDs:
$ lsblk -o NAME,PARTUUID
NAME PARTUUID
sda 4dad192a-e1d5-4d22-bf46-430135984159
├─sda1 4dad192a-e1d5-4d22-bf46-430135984159
└─sda2 4dad192a-e1d5-4d22-bf46-430135984159
└─ssd_root 4dad192a-e1d5-4d22-bf46-430135984159
sdb 4dad192a-e1d5-4d22-bf46-430135984159
├─sdb1 4dad192a-e1d5-4d22-bf46-430135984159
├─sdb2 4dad192a-e1d5-4d22-bf46-430135984159
├─sdb3 4dad192a-e1d5-4d22-bf46-430135984159
├─sdb4 4dad192a-e1d5-4d22-bf46-430135984159
├─sdb5 4dad192a-e1d5-4d22-bf46-430135984159
├─sdb6 4dad192a-e1d5-4d22-bf46-430135984159
├─sdb7 4dad192a-e1d5-4d22-bf46-430135984159
├─sdb8 4dad192a-e1d5-4d22-bf46-430135984159
└─sdb9 4dad192a-e1d5-4d22-bf46-430135984159
$ blkid -s PARTUUID
/dev/sda1: PARTUUID="07665db4-7eb5-44fc-8859-8a3100a99ce9"
/dev/sda2: PARTUUID="17f4623f-e766-4018-8106-d894eae22ddd"
/dev/sdb1: PARTUUID="9ff8ff37-ab19-464c-9d84-e9c0f83f9d5c"
/dev/sdb2: PARTUUID="5074a9f5-b3c4-3d41-aa01-2bcd8b4515b6"
/dev/sdb3: PARTUUID="6d923031-a4ec-4cf2-8e5c-36a66a67904c"
/dev/sdb4: PARTUUID="9ea63089-e7e1-40b2-a259-1d59c028a8b2"
/dev/sdb5: PARTUUID="4dad192a-e1d5-4d22-bf46-430135984159"
/dev/sdb6: PARTUUID="933616c1-d588-e44f-be3b-17266bad6109"
/dev/sdb7: PARTUUID="2d8f25b2-3e1a-624f-95e3-fa35f56e278f"
/dev/sdb8: PARTUUID="ad68dfee-4c2a-4fdd-8a86-08af918ff790"
/dev/sdb9: PARTUUID="4ab59f1e-56ec-4210-86c7-1d5c0f4b76a6"Wut? How?
The reported PARTUUID is of sdb5, my /home partition, but I don't think it is special in any way.
$ uname -a
Linux LenovoPC 5.11.5-arch1-1 #1 SMP PREEMPT Tue, 09 Mar 2021 18:56:28 +0000 x86_64 GNU/Linux
$ lsblk --version
lsblk from util-linux 2.36.2
$ blkid --version
blkid from util-linux 2.36.2 (libblkid 2.36.2, 12-Feb-2020)Is it something to be reported somewhere? Or is is the correct behavior of lsblk?
Last edited by Mikle_Bond (2021-03-11 20:58:14)
Offline
Maybe try 'sudo lsblk'.
sys2064
Offline
Oh wow. I found how to get the debug logs:
LSBLK_DEBUG=all lsblk --nodeps -o +PARTUUID /dev/sda? https://termbin.com/kf2f.
There's this among the lines:
.....
/dev/sda1: properties requested
sda1: found udev properties
from udev
refer data[7]="4dad192a-e1d5-4d22-bf46-430135984159"
.....
/dev/sda2: properties requested
sda2: found udev properties
from udev
refer data[7]="4dad192a-e1d5-4d22-bf46-430135984159"
.....lsblk takes those PARTUUIDs from udev. Quick check shows:
$ udevadm info /dev/sda1 | grep -i part | grep -i uuid
S: disk/by-partuuid/07665db4-7eb5-44fc-8859-8a3100a99ce9
E: ID_PART_TABLE_UUID=fd677e9d-9bbe-492a-8544-93b8269bd142
E: ID_PART_ENTRY_UUID=4dad192a-e1d5-4d22-bf46-430135984159
E: DEVLINKS=/dev/disk/by-uuid/869A-8E15 /dev/disk/by-partlabel/ssd_efi /dev/disk/by-id/ata-Netac_SSD_128GB_YS005566600090001642-part1 /dev/disk/by-partuuid/07665db4-7eb5-44fc-8859-8a3100a99ce9 /dev/disk/by-label/SSD_EFI /dev/disk/by-path/pci-0000:00:1f.2-ata-2-part1 /dev/disk/by-path/pci-0000:00:1f.2-ata-2.0-part1The ID_PART_ENTRY_UUID is the one that is showed by lsblk.
What am I supposed to do with this all stuff now? Is it something to be reported as a bug? Or am I getting ahead of myself?
Offline
So the error seems to happen in udev somewhere?
I can't reproduce your problem here on my installation. I get correct PARTUUID output in lsblk, same numbers as what blkid prints. When I look through udevadm info output, I don't have problems there, the ID_PART_ENTRY_UUID lines show the same as what's in blkid.
The uname -a and lsblk --version output here for me is same as yours, it's kernel 5.11.5 and util-linux 2.36.2. That said, I don't use exactly the Arch 5.11.5 kernel, I use Arch's PKGBUILD to compile it myself with the config slightly tweaked. I guess you could try an alternative kernel package to make sure it's not the kernel causing the issue.
I'm not sure where you'd go to report a bug. If the problem is in udev then it would be the systemd project's bug tracker?
Offline
I guess you could try an alternative kernel package to make sure it's not the kernel causing the issue.
Thank you for a hint. I tried linux-lts, and the kernel itself doesn't seem to change a thing. The initcpio, on the other hand, seems to change something.
I have two sets of those, both busybox- and systemd-based. This is a remnant of the times when I was comparing encrypt and sd-encrypt hooks. I've been using systemd-based one all this time.
I tried to boot with busybox-based initramfs and here's what I've got:
$ lsblk -o NAME,PARTUUID
NAME PARTUUID
sda 4dad192a-e1d5-4d22-bf46-430135984159
├─sda1 07665db4-7eb5-44fc-8859-8a3100a99ce9
└─sda2 4dad192a-e1d5-4d22-bf46-430135984159
└─ssd_root 4dad192a-e1d5-4d22-bf46-430135984159
sdb 4dad192a-e1d5-4d22-bf46-430135984159
├─sdb1 4dad192a-e1d5-4d22-bf46-430135984159
├─sdb2 4dad192a-e1d5-4d22-bf46-430135984159
├─sdb3 4dad192a-e1d5-4d22-bf46-430135984159
├─sdb4 4dad192a-e1d5-4d22-bf46-430135984159
├─sdb5 4dad192a-e1d5-4d22-bf46-430135984159
├─sdb6 933616c1-d588-e44f-be3b-17266bad6109
├─sdb7 4dad192a-e1d5-4d22-bf46-430135984159
├─sdb8 4dad192a-e1d5-4d22-bf46-430135984159
└─sdb9 4dad192a-e1d5-4d22-bf46-430135984159As you can see, two more of them now have correct PARTUUIDs...
This behaviour is identical for both linux and linux-lts kernels.
The systemd-based config:
HOOKS=(base systemd keyboard autodetect sd-vconsole modconf block filesystems btrfs sd-encrypt)The busybox-based config:
in mkinitcpio.busybox.conf:
HOOKS=(base consolefont keyboard udev resume autodetect btrfs modconf block filesystems sleep encrypt)
....
in boot entry:
options cryptdevice=PARTLABEL=ssd_cryptroot:ssd_root sleepdevice=/dev/sdc cryptkey=/dev/sdc:17408:7680 root=LABEL=SSD_ROOT resume=LABEL=HDD_SWAP rw i915.fastboot=1
....I tried to look for udev in logs during startup, but it doesn't seem to mention anything suspicious.
Offline
I use systemd in my initramfs. My config looks like this:
HOOKS=(base systemd autodetect modconf block filesystems keyboard)I don't use compression here as it's a desktop PC at home. Maybe something about the compression is causing the issue with udev? My /dev/mapper/ folder here is empty.
To be clear about what I'm seeing here, in the output of that "lsblk -o NAME,PARTUUID" command every single PARTUUID is unique, there's no repetition at all. What's also strange: for you there's a PARTUUID printed for the "sda" and "sdb" names in the lsblk output. That's not normal, I think? You should only have something for the sda1, sda2, sdb1, etc. names and nothing for the sda, sdb names.
Offline
any custom udev rules on your system?
Offline
Pages: 1