SUMMARY For some reason KPMcore is unable to detect what file system types my partitions are. This makes both partitionmanager and Calamares unusable STEPS TO REPRODUCE 1. Launch any application depending on KPMcore, e.g. partitionmanager 2. Note in terminal the message 'unknown file system type "" on "/dev/partition"' OBSERVED RESULT No file system types are detected EXPECTED RESULT File system types to be detected SOFTWARE/OS VERSIONS Linux/KDE Plasma: Alpine Linux edge (available in About System) KDE Plasma Version: 5.18.2 KDE Frameworks Version: 5.67.0 Qt Version: 5.14.1 ADDITIONAL INFORMATION This system uses Musl rather than glibc, which may be the issue here
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