Hi, * Marc Lehmann <[email protected]> [200504 02:44]: > On Sun, May 03, 2020 at 09:01:49PM +0200, Chris Hofstaedtler > <[email protected]> wrote: > > > /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
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 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
