Bug#935725: util-linux: lsblk sometimes gives wrong pttype "dos" for gpt partitions

[Marc Lehmann]

Package: util-linux
Version: 2.33.1-0.1
Severity: normal

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).

-- System Information:
Debian Release: 10.0
APT prefers stable
APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, x32

Kernel: Linux 5.1.21-050121-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages util-linux depends on:
ii fdisk 2.33.1-0.1
ii libaudit1 1:2.8.4-3
ii libblkid1 2.33.1-0.1
ii libc6 2.28-10
ii libcap-ng0 0.7.9-2
ii libmount1 2.33.1-0.1
ii libpam0g 1.3.1-5
ii libselinux1 2.8-1+b1
ii libsmartcols1 2.33.1-0.1
ii libsystemd0 241-5
ii libtinfo6 6.1+20181013-2
ii libudev1 241-5
ii libuuid1 2.33.1-0.1
ii login 1:4.5-1.1
ii zlib1g 1:1.2.11.dfsg-1

util-linux recommends no packages.

Versions of packages util-linux suggests:
ii dosfstools 4.1-2
ii kbd 2.0.4-4
pn util-linux-locales <none>

-- debconf information excluded

[Chris Hofstaedtler]

Control: tags -1 + upstream moreinfo

Hi March Lehmann,

thank you for your report, however see my reply below.

Post by Marc Lehmann
Package: util-linux
Version: 2.33.1-0.1
Severity: normal
Dear Maintainer,
I have a script that gathers information using lsblk., It specifically needs
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
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).

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

[Marc Lehmann]

Post by Chris Hofstaedtler

Post by Marc Lehmann
/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

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'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,

[Chris Hofstaedtler]

Hi,

Post by Marc Lehmann

Post by Chris Hofstaedtler

Post by Marc Lehmann
/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

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'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
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
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
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

Which fdisk is this, because it omits important info (partition
table type) and also doesn't show the GPT partitions?

Post by Marc Lehmann
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.

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

[Marc Lehmann]

Post by Chris Hofstaedtler

Post by Marc Lehmann
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.

Well, I tried recreating your setup on a loop blockdev, and it works

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.

Post by Chris Hofstaedtler
Which fdisk is this, because it omits important info (partition
table type) and also doesn't show the GPT partitions?

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.

[Marc Lehmann]

Post by Chris Hofstaedtler

Post by Marc Lehmann
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.

Well, I tried recreating your setup on a loop blockdev, and it works

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).

[Marc Lehmann]

Post by Chris Hofstaedtler

Post by Marc Lehmann
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.

Well, I tried recreating your setup on a loop blockdev, and it works

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.

[Václav Doležal]

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

[Chris Hofstaedtler]

Hello Václav Doležal,

Post by Václav Doležal
can you verify that the bug is still present in current libblkid?
It should be fixed since commit cdb9140967 [1] (v2.35 or higher).

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

[Václav Doležal]

Hello Chris.

Post by Chris Hofstaedtler
Thanks for your followup. The original submitter sent this info in
----
# lsblk --version
lsblk from util-linux 2.35.1

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

[Chris Hofstaedtler]

Hello Václav, Marc,

Post by Václav Doležal

Post by Chris Hofstaedtler
Thanks for your followup. The original submitter sent this info in
----
# lsblk --version
lsblk from util-linux 2.35.1

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.

Ah indeed, thanks for pointing this out.

Marc, could you try again with a fully-upgraded system?

Post by Václav Doležal
Otherwise, I think that the log matches the behaviour of libblkid prior to
cdb9140967.

Thanks,
Chris