Bug#935725: util-linux: lsblk sometimes gives wrong pttype "dos" for gpt partitions
Hello Václav, Marc, * Václav Doležal [210410 19:15]: > > Thanks for your followup. The original submitter sent this info in > > message #27: > > > > > ># 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? > Otherwise, I think that the log matches the behaviour of libblkid prior to > cdb9140967. Thanks, Chris
Bug#935725: util-linux: lsblk sometimes gives wrong pttype "dos" for gpt partitions
Hello Chris. > Thanks for your followup. The original submitter sent this info in > message #27: > > ># 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
Bug#935725: util-linux: lsblk sometimes gives wrong pttype "dos" for gpt partitions
Hello Václav Doležal, * Václav Doležal [210409 19:39]: > 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 sda18:1 part gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd c845ed61-afd2-4437-8db8-cd22b74daf1d EFI vfat /dev/sda2 sda28:2 part gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd e6a8207b-c4da-44ac-8a04-8f68cf15c119 LVM2_member /dev/sda3 sda38: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
Bug#935725: util-linux: lsblk sometimes gives wrong pttype "dos" for gpt partitions
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
Bug#935725: util-linux: lsblk sometimes gives wrong pttype "dos" for gpt partitions
On Mon, May 04, 2020 at 12:19:43PM +0200, Chris Hofstaedtler wrote: > > 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: Studying the manpage, I tried LSBLK_DEBUG, and I think it gives a good hint: http://data.plan9.de/lsblkbug.txt 539: lsblk: DEV: [0x55596de0]: add 'sda3' to scols 539: lsblk: DEV: [0x55596de0]: refer data[0]="/dev/sda3" 539: lsblk: DEV: [0x55596de0]: refer data[1]="sda3" 539: lsblk: DEV: [0x55596de0]: refer data[2]=" 8:3 " 539: lsblk: DEV: [0x55596de0]: refer data[3]="part" 539: lsblk: DEV: [0x55596de0]: /dev/sda3: properties requested 539: lsblk: DEV: [0x55596de0]: sda3: found udev properties 539: lsblk: DEV: [0x55596de0]: from udev 539: lsblk: DEV: [0x55596de0]: 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:
Bug#935725: util-linux: lsblk sometimes gives wrong pttype "dos" for gpt partitions
On Mon, May 04, 2020 at 12:19:43PM +0200, Chris Hofstaedtler wrote: > > 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: 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 sda18:1 part gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd c845ed61-afd2-4437-8db8-cd22b74daf1d EFI vfat /dev/sda2 sda28:2 part gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd e6a8207b-c4da-44ac-8a04-8f68cf15c119 LVM2_member /dev/sda3 sda38:3 part dos 81be6e1d-066c-45eb-a13d-53fc8e4730bd e744ce6f-6ba9-43a2-b36e-ebd019e0b20d SSDCERntfs /dev/sde sde 8:64 disk gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd /dev/sde1 sde18:65 part gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd c845ed61-afd2-4437-8db8-cd22b74daf1d /dev/sde2 sde28:66 part gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd e6a8207b-c4da-44ac-8a04-8f68cf15c119 /dev/sde3 sde38: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). -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#935725: util-linux: lsblk sometimes gives wrong pttype "dos" for gpt partitions
On Mon, May 04, 2020 at 12:19:43PM +0200, Chris Hofstaedtler wrote: > > On Sun, May 03, 2020 at 09:01:49PM +0200, Chris Hofstaedtler > > wrote: > > > 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: 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 sda18:1 part gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd c845ed61-afd2-4437-8db8-cd22b74daf1d EFI vfat /dev/sda2 sda28:2 part gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd e6a8207b-c4da-44ac-8a04-8f68cf15c119 LVM2_member /dev/sda3 sda38: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. > 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. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#935725: util-linux: lsblk sometimes gives wrong pttype "dos" for gpt partitions
Hi, * Marc Lehmann [200504 02:44]: > On Sun, May 03, 2020 at 09:01:49PM +0200, Chris Hofstaedtler > wrote: > > >/dev/sda sda 8:0 disk gpt > > > 81c62d1c-b086-4f48-b1e9-b8ae2d457f91 > > >/dev/sda1 sda18:1 part gpt > > > 81c62d1c-b086-4f48-b1e9-b8ae2d457f91 cf573ead-cdeb-42d5-9d75-aee9ceec3370 > > >/dev/sda2 sda28:2 part gpt > > > 81c62d1c-b086-4f48-b1e9-b8ae2d457f91 89a285e0-09ca-44eb-b7ca-e1261a5e2f07 > > > USBEFI vfat > > >/dev/sda3 sda38:3 part dos > > > 81c62d1c-b086-4f48-b1e9-b8ae2d457f91 d7f7dfdf-a2a6-4097-9975-c09fa73b19b3 > > > DATAntfs > > > > 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): > >PATHKNAME MAJ:MIN TYPE PTTYPE PTUUID > PARTUUID LABEL FSTYPE >/dev/sdasda 8:0 disk gpt > 81be6e1d-066c-45eb-a13d-53fc8e4730bd >/dev/sda1 sda18:1 part gpt > 81be6e1d-066c-45eb-a13d-53fc8e4730bd c845ed61-afd2-4437-8db8-cd22b74daf1d EFI > vfat >/dev/sda2 sda28:2 part gpt > 81be6e1d-066c-45eb-a13d-53fc8e4730bd e6a8207b-c4da-44ac-8a04-8f68cf15c119 > LVM2_member >/dev/sda3 sda38:3 part dos > 81be6e1d-066c-45eb-a13d-53fc8e4730bd e744ce6f-6ba9-43a2-b36e-ebd019e0b20d > SSDCERntfs > > gdisk -l: > >Number Start (sector)End (sector) Size Code Name > 12048 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 Which fdisk is this, because it omits important info (partition table type) and also doesn't show the GPT partitions? > 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 gptdef286d3-d999-df4d-a92d-73845df2bff0 /dev/loop0p1 loop0p1 259:3 part gptdef286d3-d999-df4d-a92d-73845df2bff0 3779f912-554e-5e48-b6ee-d33add2eec4c /dev/loop0p2 loop0p2 259:4 part gptdef286d3-d999-df4d-a92d-73845df2bff0 34b76cd2-ae27-e348-9786-f2f930209438 /dev/loop0p3 loop0p3 259:5 part gptdef286d3-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
Bug#935725: util-linux: lsblk sometimes gives wrong pttype "dos" for gpt partitions
On Sun, May 03, 2020 at 09:01:49PM +0200, Chris Hofstaedtler wrote: > >/dev/sda sda 8:0 disk gpt81c62d1c-b086-4f48-b1e9-b8ae2d457f91 > >/dev/sda1 sda18:1 part gpt > > 81c62d1c-b086-4f48-b1e9-b8ae2d457f91 cf573ead-cdeb-42d5-9d75-aee9ceec3370 > >/dev/sda2 sda28:2 part gpt > > 81c62d1c-b086-4f48-b1e9-b8ae2d457f91 89a285e0-09ca-44eb-b7ca-e1261a5e2f07 > > USBEFI vfat > >/dev/sda3 sda38:3 part dos > > 81c62d1c-b086-4f48-b1e9-b8ae2d457f91 d7f7dfdf-a2a6-4097-9975-c09fa73b19b3 > > DATAntfs > > 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): PATHKNAME MAJ:MIN TYPE PTTYPE PTUUID PARTUUID LABEL FSTYPE /dev/sdasda 8:0 disk gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd /dev/sda1 sda18:1 part gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd c845ed61-afd2-4437-8db8-cd22b74daf1d EFI vfat /dev/sda2 sda28:2 part gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd e6a8207b-c4da-44ac-8a04-8f68cf15c119 LVM2_member /dev/sda3 sda38:3 part dos 81be6e1d-066c-45eb-a13d-53fc8e4730bd e744ce6f-6ba9-43a2-b36e-ebd019e0b20d SSDCERntfs gdisk -l: Number Start (sector)End (sector) Size Code Name 12048 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, -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#935725: util-linux: lsblk sometimes gives wrong pttype "dos" for gpt partitions
Control: tags -1 + upstream moreinfo Hi March Lehmann, thank you for your report, however see my reply below. * 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 gpt81c62d1c-b086-4f48-b1e9-b8ae2d457f91 >/dev/sda1 sda18:1 part gpt81c62d1c-b086-4f48-b1e9-b8ae2d457f91 > cf573ead-cdeb-42d5-9d75-aee9ceec3370 >/dev/sda2 sda28:2 part gpt81c62d1c-b086-4f48-b1e9-b8ae2d457f91 > 89a285e0-09ca-44eb-b7ca-e1261a5e2f07 USBEFI vfat >/dev/sda3 sda38:3 part dos81c62d1c-b086-4f48-b1e9-b8ae2d457f91 > d7f7dfdf-a2a6-4097-9975-c09fa73b19b3 DATAntfs >/dev/sr0 sr011: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
Bug#935725: util-linux: lsblk sometimes gives wrong pttype "dos" for gpt partitions
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 gpt81c62d1c-b086-4f48-b1e9-b8ae2d457f91 /dev/sda1 sda18:1 part gpt81c62d1c-b086-4f48-b1e9-b8ae2d457f91 cf573ead-cdeb-42d5-9d75-aee9ceec3370 /dev/sda2 sda28:2 part gpt81c62d1c-b086-4f48-b1e9-b8ae2d457f91 89a285e0-09ca-44eb-b7ca-e1261a5e2f07 USBEFI vfat /dev/sda3 sda38:3 part dos81c62d1c-b086-4f48-b1e9-b8ae2d457f91 d7f7dfdf-a2a6-4097-9975-c09fa73b19b3 DATAntfs /dev/sr0 sr011: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 libselinux12.8-1+b1 ii libsmartcols1 2.33.1-0.1 ii libsystemd0241-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 -- debconf information excluded
