On Mon, May 04, 2020 at 12:19:43PM +0200, Chris Hofstaedtler <z...@debian.org>
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 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).
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schm...@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
