Bug 418253

Looking through the code a bit, it seems KPMcore internally calls "udevadm info --query=property /dev/partition" which returns a result, but it's missing the "ID_FS_TYPE" and "ID_FS_VERSION" entries which KPMcore requires. Not sure why this happens.

Note that on Alpine Linux eudev is used rather than systemd's udev, the same as on Gentoo

Created attachment 126457 [details]
attachment-31326-0.html

Well, same as some Gentoo's... I have Gentoo myself but with systemd and it works fine.

It works fine on my GNU Guix installation which has eudev 3.2.9 and shepherd init system. Maybe alpine does something to eudev?



On 27 February 2020 13:02:58 GMT, Bart Ribbers <bugzilla_noreply@kde.org> wrote:
>https://bugs.kde.org/show_bug.cgi?id=418253
>
>--- Comment #2 from Bart Ribbers <bribbers@disroot.org> ---
>Note that on Alpine Linux eudev is used rather than systemd's udev, the
>same as
>on Gentoo
>
>-- 
>You are receiving this mail because:
>You are the assignee for the bug.

Nope, it's closed to unpatched. It only patches some udev rules.
https://git.alpinelinux.org/aports/tree/main/eudev?h=master

> It works fine on my GNU Guix installation which has eudev 3.2.9 and shepherd
> init system. Maybe alpine does something to eudev?

Nope, it's close to unpatched. It just patches some udev rules.
https://git.alpinelinux.org/aports/tree/main/eudev?h=master

(In reply to Bart Ribbers from comment #5)
> > It works fine on my GNU Guix installation which has eudev 3.2.9 and shepherd
> > init system. Maybe alpine does something to eudev?
> 
> Nope, it's close to unpatched. It just patches some udev rules.
> https://git.alpinelinux.org/aports/tree/main/eudev?h=master

I think you should still submit this bug to alpine developers.

Gentoo works fine,both with systemd and eudev. And so does Guix. Maybe it's a combination of eudev and musl or something more complicated, but so far no other distro exhibits this bug.

I've figured out part of the problem, missing runtime dependency on sfdisk :facepalm:

Primary partitions are now recognized, but it still doesn't recognize anything on LVM volumes. It reports a warning that LVM tools are not installed but reading through the code it just checks for the "lvm" command which _is_ available.

(In reply to Bart Ribbers from comment #7)
> I've figured out part of the problem, missing runtime dependency on sfdisk
> :facepalm:
> 
> Primary partitions are now recognized, but it still doesn't recognize
> anything on LVM volumes. It reports a warning that LVM tools are not
> installed but reading through the code it just checks for the "lvm" command
> which _is_ available.

Do you mean it does not recognize LVM logical volumes, or does not see LVM at all (e.g. no Volume Groups either)?

Currently it doesn't recognize LVM at all. Partitionmanager just shows the partition as "encrypted", guess it can't figure out the LUKS partition (on which the LVM resides) has been unlocked either.

(In reply to Bart Ribbers from comment #9)
> Currently it doesn't recognize LVM at all. Partitionmanager just shows the
> partition as "encrypted", guess it can't figure out the LUKS partition (on
> which the LVM resides) has been unlocked either.

Have you actually decrypted LUKS partition? Maybe you can paste lsblk output?

Of course I have. I'm running the system on which I'm typing this from it ;)

▶ lsblk
NAME             MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                8:0    0 931.5G  0 disk  
└─sda1             8:1    0 931.5G  0 part  
  └─hdd          253:3    0 931.5G  0 crypt 
    ├─hdd-home   253:4    0   750G  0 lvm   /home
    └─hdd-games  253:5    0 181.5G  0 lvm   /games-hdd
sr0               11:0    1  1024M  0 rom   
nvme0n1          259:0    0 238.5G  0 disk  
├─nvme0n1p1      259:1    0     1G  0 part  /boot
└─nvme0n1p2      259:2    0 237.5G  0 part  
  └─ssd          253:0    0 237.5G  0 crypt 
    ├─ssd-rootfs 253:1    0    50G  0 lvm   /
    └─ssd-data   253:2    0 187.5G  0 lvm   /games-ssd

(In reply to Bart Ribbers from comment #11)
> Of course I have. I'm running the system on which I'm typing this from it ;)
> 
> ▶ lsblk
> NAME             MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
> sda                8:0    0 931.5G  0 disk  
> └─sda1             8:1    0 931.5G  0 part  
>   └─hdd          253:3    0 931.5G  0 crypt 
>     ├─hdd-home   253:4    0   750G  0 lvm   /home
>     └─hdd-games  253:5    0 181.5G  0 lvm   /games-hdd
> sr0               11:0    1  1024M  0 rom   
> nvme0n1          259:0    0 238.5G  0 disk  
> ├─nvme0n1p1      259:1    0     1G  0 part  /boot
> └─nvme0n1p2      259:2    0 237.5G  0 part  
>   └─ssd          253:0    0 237.5G  0 crypt 
>     ├─ssd-rootfs 253:1    0    50G  0 lvm   /
>     └─ssd-data   253:2    0 187.5G  0 lvm   /games-ssd

let's try this (this is the command that partitionmanager runs to get LUKS mapped block device name which in turn determines if LUKS partition is shown as opened or closed)

lsblk --list --noheadings --paths --json --output type,name /dev/sda1

I expect you should see something like 

      {"type":"crypt", "name":"/dev/mapper/hdd"},

▶ lsblk --list --noheadings --paths --json --output type,name /dev/sda1
{
   "blockdevices": [
      {"type":"part", "name":"/dev/sda1"},
      {"type":"crypt", "name":"/dev/mapper/hdd"},
      {"type":"lvm", "name":"/dev/mapper/hdd-home"},
      {"type":"lvm", "name":"/dev/mapper/hdd-games"}
   ]
}

(In reply to Bart Ribbers from comment #13)
> ▶ lsblk --list --noheadings --paths --json --output type,name /dev/sda1
> {
>    "blockdevices": [
>       {"type":"part", "name":"/dev/sda1"},
>       {"type":"crypt", "name":"/dev/mapper/hdd"},
>       {"type":"lvm", "name":"/dev/mapper/hdd-home"},
>       {"type":"lvm", "name":"/dev/mapper/hdd-games"}
>    ]
> }

So this part is fine. Then I'm confused why Partition Manager shows partition as  encrypted and closed.

Any chance you can post a screenshot?

Created attachment 126501 [details]
Screenshot of Partitionmanager which doesn't detect unlocked partition

Attached a screenshot

(In reply to Bart Ribbers from comment #15)
> Created attachment 126501 [details]
> Screenshot of Partitionmanager which doesn't detect unlocked partition
> 
> Attached a screenshot

Oh it does detect that LUKS partition is unlocked. But for some reason it fails to recognize it as LVM Physical Volume. And I think that might be related to your previous udev problem.

can you run

udevadm info --query=property /dev/mapper/ssd

Here I have the following fields:
ID_FS_VERSION=LVM2 001
ID_FS_TYPE=LVM2_member


I can see from the screenshot that LVM volume groups are detected.

Yeah I already figured those were missing from my output.

▶ udevadm info --query=property /dev/mapper/ssd
DEVLINKS=/dev/mapper/ssd
DEVNAME=/dev/dm-0
DEVPATH=/devices/virtual/block/dm-0
DEVTYPE=disk
DM_NAME=ssd
DM_SUSPENDED=0
DM_UDEV_DISABLE_DISK_RULES_FLAG=1
DM_UDEV_DISABLE_OTHER_RULES_FLAG=1
DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
DM_UDEV_RULES_VSN=2
DM_UUID=CRYPT-LUKS1-2c1843d17b0c4d7b902a37b498dcf650-ssd
MAJOR=253
MINOR=0
SUBSYSTEM=block
USEC_INITIALIZED=16624357

I've added fallback detection with blkid in case udevadm fails.

https://invent.kde.org/system/kpmcore/-/blob/d396e56694fc4fca61260f23509fa4c423ed4071/src/plugins/sfdisk/sfdiskbackend.cpp#L507

(And also made code more readable).

Hopefully, this will solve your problem (although, blkid might not be able to distinguish FAT12).

Git commit 924830ebbd9e22d3b1c88181886b1f609aff7756 by Andrius Štikonas.
Committed on 04/10/2020 at 17:34.
Pushed by stikonas into branch 'master'.

When falling back to blkid for filesystem type detection, distinguish between FAT16/32.

M  +1    -1    src/plugins/sfdisk/sfdiskbackend.cpp

https://invent.kde.org/system/kpmcore/commit/924830ebbd9e22d3b1c88181886b1f609aff7756