- Package:
- util-linux
- Source:
- util-linux
- Description:
- miscellaneous system utilities
- Submitter:
- Marc Lehmann
- Date:
- 2021-04-11 12:25:12 UTC
- Severity:
- normal
- Tags:
Dear Maintainer, I have a script that gathers information using lsblk., It specifically needs the partition table type, uuid and partition uuid. It uses something like this: lsblk -o PATH,KNAME,MAJ:MIN,TYPE,PTTYPE,PTUUID,PARTUUID,LABEL,FSTYPE This works mostly fine, except on some disks, it gives a bogus PTTYPE of "dos" when it should be "gpt" for example: PATH KNAME MAJ:MIN TYPE PTTYPE PTUUID PARTUUID LABEL FSTYPE /dev/loop4 loop4 7:4 loop USBROOT btrfs /dev/sda sda 8:0 disk gpt 81c62d1c-b086-4f48-b1e9-b8ae2d457f91 /dev/sda1 sda1 8:1 part gpt 81c62d1c-b086-4f48-b1e9-b8ae2d457f91 cf573ead-cdeb-42d5-9d75-aee9ceec3370 /dev/sda2 sda2 8:2 part gpt 81c62d1c-b086-4f48-b1e9-b8ae2d457f91 89a285e0-09ca-44eb-b7ca-e1261a5e2f07 USBEFI vfat /dev/sda3 sda3 8:3 part dos 81c62d1c-b086-4f48-b1e9-b8ae2d457f91 d7f7dfdf-a2a6-4097-9975-c09fa73b19b3 DATA ntfs /dev/sr0 sr0 11:0 rom Here, /dev/sda3 has a bogus pttype of "dos", but correct PTUUID and PARTUUID values (mbr entries don't have uuids).
Hi March Lehmann, thank you for your report, however see my reply below. * Marc Lehmann <debian-reportbug@plan9.de>: I agree this is weird. Can you check if this still happens with the current util-linux, and if so, file a report with upstream? I guess they'd ask for more details about the actual GPT and (possibly hybrid) MBR, too. Thanks, Chris
I'm a bit reluctant to upgrade util-linux soon on the machine where
it happens, but I still have the disk where it happens (but obviously,
util-linux is still the version from buster), so I don't think I can do
this anytime soon for the upstream version, which is presumably newer.
For what it's worth, here is gdisk -l ands fdisk -l for the disk above.
Current lsblk output (similar to the above, but the disk was blkdiscard'ed
since then and re-done from scratch, so is a bit different):
PATH KNAME MAJ:MIN TYPE PTTYPE PTUUID PARTUUID LABEL FSTYPE
/dev/sda sda 8:0 disk gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd
/dev/sda1 sda1 8:1 part gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd c845ed61-afd2-4437-8db8-cd22b74daf1d EFI vfat
/dev/sda2 sda2 8:2 part gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd e6a8207b-c4da-44ac-8a04-8f68cf15c119 LVM2_member
/dev/sda3 sda3 8:3 part dos 81be6e1d-066c-45eb-a13d-53fc8e4730bd e744ce6f-6ba9-43a2-b36e-ebd019e0b20d SSDCER ntfs
gdisk -l:
Number Start (sector) End (sector) Size Code Name
1 2048 526335 256.0 MiB EF00 EFI System
2 526336 3565684735 1.7 TiB 8E00 Linux LVM
3 3565684736 3907029134 162.8 GiB 0700 Microsoft basic data
fdisk -l:
Disk /dev/sda: 2000.3 GB, 2000398934016 bytes
256 heads, 63 sectors/track, 242251 cylinders
Units = cylinders of 16128 * 512 = 8257536 bytes
Device Boot Start End Blocks Id System
/dev/sda1 1 242252 1953514583+ ee EFI GPT
I wouldn't assume this is necessary, though, as this is almost certainly
a relatively simple bug to fix - since the partition type differs for
partitions on the same disk it is unlikely to be caused by something weird
in the partition tables. That, or the algorithm is completely hosed, as it
shouldn't depend on the partition at all, only on the disk.
Hope this helps,
Hi, * Marc Lehmann <schmorp@schmorp.de> [200504 02:44]: Which fdisk is this, because it omits important info (partition table type) and also doesn't show the GPT partitions? Well, I tried recreating your setup on a loop blockdev, and it works for me: % lsblk -o PATH,KNAME,MAJ:MIN,TYPE,PTTYPE,PTUUID,PARTUUID,LABEL,FSTYPE /dev/loop0 PATH KNAME MAJ:MIN TYPE PTTYPE PTUUID PARTUUID LABEL FSTYPE /dev/loop0 loop0 7:0 loop gpt def286d3-d999-df4d-a92d-73845df2bff0 /dev/loop0p1 loop0p1 259:3 part gpt def286d3-d999-df4d-a92d-73845df2bff0 3779f912-554e-5e48-b6ee-d33add2eec4c /dev/loop0p2 loop0p2 259:4 part gpt def286d3-d999-df4d-a92d-73845df2bff0 34b76cd2-ae27-e348-9786-f2f930209438 /dev/loop0p3 loop0p3 259:5 part gpt def286d3-d999-df4d-a92d-73845df2bff0 8bb332ae-4577-3e42-a747-691f8997dc71 So either this is fixed in 2.35.1-1 (please try it!), or we're missing further info. Thanks, Chris
Hi, and thanks for your efforts. I jumped the gun and upgraded to testing, and the bug still exists - at this point, I assume lsblk somehow looks at the partition data to detect PTTYPE (which makes no sense to me), or maybe it looks at some gpt data not visible in gdisk output: # lsblk --version lsblk from util-linux 2.35.1 # lsblk -o PATH,KNAME,MAJ:MIN,TYPE,PTTYPE,PTUUID,PARTUUID,LABEL,FSTYPE PATH KNAME MAJ:MIN TYPE PTTYPE PTUUID PARTUUID LABEL FSTYPE /dev/sda sda 8:0 disk gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd /dev/sda1 sda1 8:1 part gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd c845ed61-afd2-4437-8db8-cd22b74daf1d EFI vfat /dev/sda2 sda2 8:2 part gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd e6a8207b-c4da-44ac-8a04-8f68cf15c119 LVM2_member /dev/sda3 sda3 8:3 part dos 81be6e1d-066c-45eb-a13d-53fc8e4730bd e744ce6f-6ba9-43a2-b36e-ebd019e0b20d SSDCER ntfs I might be able to creat some test image, or maybe I'll look at the util-linux sources to see what issue is going on here, but either will take some time for me. Oh right, sorry - that is actually fdisk v1.17.3, which I use because it doesn't support gpt and also lacks many of tghe safeguards of newer versions that kept getting into my way. I use it for so long I forgot it's not the debian one :(). OTOH, the current fdisk version doesn't show the mbr data on -l, so maybe that was a good thing after all.
As an intermediate result, I did sgdisk -R /dev/sde /dev/sda, and the problem does not travel: # lsblk -o PATH,KNAME,MAJ:MIN,TYPE,PTTYPE,PTUUID,PARTUUID,LABEL,FSTYPE /dev/sda /dev/sde PATH KNAME MAJ:MIN TYPE PTTYPE PTUUID PARTUUID LABEL FSTYPE /dev/sda sda 8:0 disk gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd /dev/sda1 sda1 8:1 part gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd c845ed61-afd2-4437-8db8-cd22b74daf1d EFI vfat /dev/sda2 sda2 8:2 part gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd e6a8207b-c4da-44ac-8a04-8f68cf15c119 LVM2_member /dev/sda3 sda3 8:3 part dos 81be6e1d-066c-45eb-a13d-53fc8e4730bd e744ce6f-6ba9-43a2-b36e-ebd019e0b20d SSDCER ntfs /dev/sde sde 8:64 disk gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd /dev/sde1 sde1 8:65 part gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd c845ed61-afd2-4437-8db8-cd22b74daf1d /dev/sde2 sde2 8:66 part gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd e6a8207b-c4da-44ac-8a04-8f68cf15c119 /dev/sde3 sde3 8:67 part gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd e744ce6f-6ba9-43a2-b36e-ebd019e0b20d So I guess replicating this is not trivial. I think it would be more fruitful for somebody who knows the code to look at this, as obviously lsblk takes information from some place that is not the disk partition info, which should be more obvious (i.e. PTTYPE should simply not differ between partitions on the same disk).
Studying the manpage, I tried LSBLK_DEBUG, and I think it gives a good hint: http://data.plan9.de/lsblkbug.txt 539: lsblk: DEV: [0x555555596de0]: add 'sda3' to scols 539: lsblk: DEV: [0x555555596de0]: refer data[0]="/dev/sda3" 539: lsblk: DEV: [0x555555596de0]: refer data[1]="sda3" 539: lsblk: DEV: [0x555555596de0]: refer data[2]=" 8:3 " 539: lsblk: DEV: [0x555555596de0]: refer data[3]="part" 539: lsblk: DEV: [0x555555596de0]: /dev/sda3: properties requested 539: lsblk: DEV: [0x555555596de0]: sda3: found udev properties 539: lsblk: DEV: [0x555555596de0]: from udev 539: lsblk: DEV: [0x555555596de0]: refer data[4]="dos" I don't know how to exactly interpret this, but it seems this info comes from udev. And indeed: udevadm info /dev/sda3 [...] E: ID_PART_TABLE_UUID=81be6e1d-066c-45eb-a13d-53fc8e4730bd E: ID_PART_TABLE_TYPE=dos So maybe this is a bug in udev (otoh, udev might use blkid, I have no clue :). [... later ...] poking around in systemd sources, it does use blkid, although it is not clear to me whether it uses libblkid or rolls it's own, but util-linux's blkid also says PTTYPE="dos". Deleting /run/blkid/blkid.tab and running blkid with doesn't show anything obvious to me (http://data.plan9.de/blkidbug.txt), except that it wrongly detetcs pttype as dos: 3900: libblkid: LOWPROBE: Resetting partitions values 3900: libblkid: LOWPROBE: --> starting probing loop [PARTS idx=-1] 3900: libblkid: BUFFER: reuse: off=0 len=1024 (for off=0 len=1024) 3900: libblkid: BUFFER: reuse: off=0 len=1024 (for off=0 len=1024) 3900: libblkid: BUFFER: reuse: off=0 len=1024 (for off=0 len=1024) 3900: libblkid: BUFFER: reuse: off=0 len=1024 (for off=0 len=1024) 3900: libblkid: LOWPROBE: magic sboff=510, kboff=0 3900: libblkid: LOWPROBE: dos: ---> call probefunc() 3900: libblkid: BUFFER: reuse: off=0 len=1024 (for off=0 len=512) 3900: libblkid: BUFFER: reuse: off=0 len=1024 (for off=0 len=1024) 3900: libblkid: BUFFER: reuse: off=0 len=1024 (for off=0 len=1024) 3900: libblkid: BUFFER: reuse: off=0 len=1024 (for off=0 len=1024) 3900: libblkid: BUFFER: reuse: off=0 len=1024 (for off=0 len=1024) 3900: libblkid: BUFFER: reuse: off=0 len=1024 (for off=0 len=1024) 3900: libblkid: BUFFER: reuse: off=0 len=1024 (for off=0 len=1024) 3900: libblkid: BUFFER: reuse: off=0 len=1024 (for off=0 len=1024) 3900: libblkid: LOWPROBE: magic sboff=0, kboff=0 3900: libblkid: BUFFER: reuse: off=0 len=1024 (for off=0 len=512) 3900: libblkid: BUFFER: reuse: off=0 len=1024 (for off=0 len=512) 3900: libblkid: LOWPROBE: returning TYPE value 3900: libblkid: LOWPROBE: dos: <--- (rc = 0) 3900: libblkid: LOWPROBE: assigning PTTYPE [partitions] 3900: libblkid: LOWPROBE: <-- leaving probing loop (type=dos) [PARTS idx=3] 3900: libblkid: LOWPROBE: parts: start probing for partition entry 3900: libblkid: DEVNO: found devno 0x0800 as /dev/sda 3900: libblkid: LOWPROBE: allocate a wholedisk probe 3900: libblkid: LOWPROBE: allocate a new probe 3900: libblkid: LOWPROBE: zeroize wiper 3900: libblkid: LOWPROBE: ready for low-probing, offset=0, size=2000398934016 3900: libblkid: LOWPROBE: whole-disk: YES, regfile: NO 3900: libblkid: LOWPROBE: partlist reset 3900: libblkid: LOWPROBE: parts: initialized partitions list (size=0) 3900: libblkid: LOWPROBE: --> starting probing loop [PARTS idx=-1] 3900: libblkid: LOWPROBE: read: off=0 len=1024 3900: libblkid: BUFFER: reuse: off=0 len=1024 (for off=0 len=1024) 3900: libblkid: BUFFER: reuse: off=0 len=1024 (for off=0 len=1024) 3900: libblkid: BUFFER: reuse: off=0 len=1024 (for off=0 len=1024) 3900: libblkid: LOWPROBE: magic sboff=510, kboff=0 3900: libblkid: LOWPROBE: dos: ---> call probefunc() 3900: libblkid: BUFFER: reuse: off=0 len=1024 (for off=0 len=512) 3900: libblkid: LOWPROBE: probably GPT -- ignore 3900: libblkid: LOWPROBE: dos: <--- (rc = 1) 3900: libblkid: LOWPROBE: gpt: ---> call probefunc() 3900: libblkid: BUFFER: reuse: off=0 len=1024 (for off=0 len=512) 3900: libblkid: LOWPROBE: #1 valid PMBR partition 3900: libblkid: LOWPROBE: checking for GPT header at 1 3900: libblkid: BUFFER: reuse: off=0 len=1024 (for off=512 len=512) 3900: libblkid: LOWPROBE: read: off=1024 len=16384 3900: libblkid: LOWPROBE: parts: create a new partition table (type=gpt, offset=512) 3900: libblkid: LOWPROBE: parts: add partition (start=2048, size=524288) 3900: libblkid: LOWPROBE: parts: add partition (start=526336, size=3565158400) 3900: libblkid: LOWPROBE: parts: add partition (start=3565684736, size=341344399) 3900: libblkid: LOWPROBE: gpt: <--- (rc = 0) 3900: libblkid: LOWPROBE: <-- leaving probing loop (type=gpt) [PARTS idx=4] 3900: libblkid: LOWPROBE: partitions probe done [rc=0] 3900: libblkid: LOWPROBE: returning partitions binary data 3900: libblkid: LOWPROBE: trying to convert devno 0x803 to partition 3900: libblkid: LOWPROBE: searching by offset/size 3900: libblkid: LOWPROBE: assigning PART_ENTRY_SCHEME [partitions] 3900: libblkid: LOWPROBE: assigning PART_ENTRY_NAME [partitions] 3900: libblkid: LOWPROBE: assigning PART_ENTRY_UUID [partitions] 3900: libblkid: LOWPROBE: assigning PART_ENTRY_TYPE [partitions] 3900: libblkid: LOWPROBE: assigning PART_ENTRY_NUMBER [partitions] 3900: libblkid: LOWPROBE: assigning PART_ENTRY_OFFSET [partitions] 3900: libblkid: LOWPROBE: assigning PART_ENTRY_SIZE [partitions] 3900: libblkid: LOWPROBE: assigning PART_ENTRY_DISK [partitions] 3900: libblkid: LOWPROBE: parts: end probing for partition entry [success] 3900: libblkid: LOWPROBE: partitions probe done [rc=0] 3900: libblkid: LOWPROBE: end probe 3900: libblkid: LOWPROBE: zeroize wiper 3900: libblkid: LOWPROBE: returning LABEL value 3900: libblkid: TAG: [0x55555557ab40]: alloc 3900: libblkid: TAG: [0x55555557ab40]: setting (LABEL) 'SSDCER' 3900: libblkid: TAG: [0x55555557aba0]: alloc 3900: libblkid: TAG: [0x55555557aba0]: creating new cache tag head LABEL 3900: libblkid: LOWPROBE: returning UUID value 3900: libblkid: TAG: [0x55555557ac20]: alloc 3900: libblkid: TAG: [0x55555557ac20]: setting (UUID) '25E09C2A0B0B294A' 3900: libblkid: TAG: [0x55555557ac80]: alloc 3900: libblkid: TAG: [0x55555557ac80]: creating new cache tag head UUID 3900: libblkid: LOWPROBE: returning TYPE value 3900: libblkid: TAG: [0x55555557ad00]: alloc 3900: libblkid: TAG: [0x55555557ad00]: setting (TYPE) 'ntfs' 3900: libblkid: TAG: [0x55555557ad60]: alloc 3900: libblkid: TAG: [0x55555557ad60]: creating new cache tag head TYPE 3900: libblkid: LOWPROBE: returning PTTYPE value 3900: libblkid: TAG: [0x55555557ade0]: alloc 3900: libblkid: TAG: [0x55555557ade0]: setting (PTTYPE) 'dos' 3900: libblkid: TAG: [0x55555557ae40]: alloc 3900: libblkid: TAG: [0x55555557ae40]: creating new cache tag head PTTYPE This is all I can provide for the moment.
Hello, can you verify that the bug is still present in current libblkid? It should be fixed since commit cdb9140967 [1] (v2.35 or higher). Regards, Václav Doležal [1] https://github.com/karelzak/util-linux/commit/cdb91409674cfb5d94a374b1e3b2bf1869ecfec7
Hello Václav Doležal, * Václav Doležal <fire256@seznam.cz> [210409 19:39]: Thanks for your followup. The original submitter sent this info in message #27:---- # lsblk --version lsblk from util-linux 2.35.1 # lsblk -o PATH,KNAME,MAJ:MIN,TYPE,PTTYPE,PTUUID,PARTUUID,LABEL,FSTYPE PATH KNAME MAJ:MIN TYPE PTTYPE PTUUID PARTUUID LABEL FSTYPE /dev/sda sda 8:0 disk gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd /dev/sda1 sda1 8:1 part gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd c845ed61-afd2-4437-8db8-cd22b74daf1d EFI vfat /dev/sda2 sda2 8:2 part gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd e6a8207b-c4da-44ac-8a04-8f68cf15c119 LVM2_member /dev/sda3 sda3 8:3 part dos 81be6e1d-066c-45eb-a13d-53fc8e4730bd e744ce6f-6ba9-43a2-b36e-ebd019e0b20d SSDCER ntfs ---- Looks like the referenced commit doesnt fix it for them. Chris
Hello Chris.
Yes, I noticed. But the bug is in libblkid, lsblk just displays info passed by
udev.
Log in msg#37 (http://data.plan9.de/blkidbug.txt) starts with
5575: libblkid: INIT: library version: 2.33.1 [09-Jan-2019]
so I think only util-linux package was upgraded.
Otherwise, I think that the log matches the behaviour of libblkid prior to
cdb9140967.
Regards,
Václav
Hello Václav, Marc, * Václav Doležal <fire256@seznam.cz> [210410 19:15]: Ah indeed, thanks for pointing this out. Marc, could you try again with a fully-upgraded system? Thanks, Chris