On Sun, May 03, 2020 at 09:01:49PM +0200, Chris Hofstaedtler <z...@debian.org>
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
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
-=====/_/_//_/\_,_/ /_/\_\
