SUMMARY KDE Partition Manager does not detect all of my LUKS volumes. While it detects my oldest device with two LUKS partitions, it does not detect all my other volumes (with one LUKS partition). STEPS TO REPRODUCE 1. Create a LUKS volume from the command line like this: `sudo cryptsetup -v --cipher aes-xts-plain64 --key-size 512 --hash sha512 --iter-time 10000 --use-urandom --verify-passphrase luksFormat /dev/sdX` 2. Create a file system on it: `sudo cryptsetup open /dev/sdX NAME && sudo mkfs.ext4 /dev/mapper/NAME` 3. Restart system (probably optional) 4. Open KDE Partition Manager and click on the device where the LUKS volume was created OBSERVED RESULT KDE Partition Manager does not show the LUKS partition EXPECTED RESULT KDE Partition Manager should show the LUKS partition SOFTWARE VERSIONS (available in About System) KDE Plasma Version: 5.14.2 git stable KDE Frameworks Version: 5.52 git stable Qt Version: 5.11.2 ADDITIONAL INFORMATION
Do you see that partition at all? Or is it completely skipped. Can you post lsblk output and "sfdisk --json /dev/sdX"?
Hmm, it seems that the partitions that aren't shown don't have a partition table. They are completely skipped by Partition Manager. Output of lsblk: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdd 8:48 0 1,8T 0 disk └─luks-4e92a7a2-350a-47a1-8167-9377a352cccb 253:1 0 1,8T 0 crypt /media/user/Hitachi 2TB sde 8:64 0 2,7T 0 disk └─luks-deba0048-15b3-4f9a-a8b4-05e158ee76bc 253:2 0 2,7T 0 crypt /media/user/Hitachi 3TB Output of sfdisk --json /dev/sdd: sfdisk: /dev/sdd: contains no recognized partition table Still, these devices work normally and are properly recognized in GParted.
Oh yes, KPM does not yet recognize devices without partition table. That's a known issue. Gparted only implemented maybe 3 years ago if I remember correctly.
*** Bug 407713 has been marked as a duplicate of this bug. ***
I tried to get information about device as advised (https://bugs.kde.org/show_bug.cgi?id=407713#c1). $ lsblk /dev/sdb NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 1 29,1G 0 disk /media/andrey/5ACC5001CC4FD5C3 $ sudo sfdisk /dev/sdb --json { "partitiontable": { "label": "dos", "id": "0x6e697373", "device": "/dev/sdb", "unit": "sectors", "partitions": [ {"node": "/dev/sdb1", "start": 1936269394, "size": 1836016416, "type": "4f"}, {"node": "/dev/sdb2", "start": 1917848077, "size": 544437093, "type": "73"}, {"node": "/dev/sdb3", "start": 1818575915, "size": 544175136, "type": "2b"}, {"node": "/dev/sdb4", "start": 2844524554, "size": 54974, "type": "61"} ] } } Compare it with info from previous starts of GUI programs (/dev/sdc earlier and /dev/sdb now are the same device): https://bugsfiles.kde.org/attachment.cgi?id=120180 It means that some programs can ignore incorrect partition table.
(In reply to Andrius Štikonas from comment #3) > Oh yes, KPM does not yet recognize devices without partition table. That's a > known issue. Gparted only implemented maybe 3 years ago if I remember > correctly. Do you mean that bug? https://bugzilla.redhat.com/show_bug.cgi?id=1333586#c1 It's like on my situation, and Partition table has the same entries.
Git commit 034311a7cc158b9a2db1dfeb641594ce1bf4dacd by Andrius Štikonas. Committed on 03/10/2020 at 14:14. Pushed by stikonas into branch 'master'. Add support for whole disk file systems. M +26 -1 src/plugins/sfdisk/sfdiskbackend.cpp M +1 -0 src/plugins/sfdisk/sfdiskbackend.h https://invent.kde.org/system/kpmcore/commit/034311a7cc158b9a2db1dfeb641594ce1bf4dacd
It turned out that most of the work for adding support for whole disk filesystems turned out to be making code more readable (splitting big functions into smaller self-contained functions). After all that was done, it was just a fairly small commit.
Is the next version 3.4? Also, would you be at all interested in putting Partition Manager on the Release Service and using the common versioning convention? You wouldn't have to handle packaging anymore, and the app would get regular releases automatically, and it would be easier to predict what the next version would be. :)
(In reply to Nate Graham from comment #9) > Is the next version 3.4? Also, would you be at all interested in putting > Partition Manager on the Release Service and using the common versioning > convention? You wouldn't have to handle packaging anymore, and the app would > get regular releases automatically, and it would be easier to predict what > the next version would be. :) The next version is 4.2.0 (current version is 4.1.0) and I was going to release it on 16th October (I still need to email kde-i18n list about it). Putting it on Release Service might be OK, I'm not opposed (but not for 4.2.0 release, I want to get it out sooner rather than later) to it but this needs some further discussion with Adrian de Groot, as Calamares depends on it and there is a question of API/ABI stability, although I guess we don't need to be ABI stable as this is not a framework, I think some kdepim packages are in a similar position. What I would definitely suggest, is putting KTorent/Libktorrent on release service because KGet (which is part of release service) depends on libktorrent for bittorrent plugin, and I'm not even the main contributor, recently Alexander Trufanov was doing most of the work. By the way, adding support for whole disk partitions led me to notice a very curious sfdisk bug (https://github.com/karelzak/util-linux/issues/1156), sfdisk is unable to create MBR partition table if you have FAT/NTFS filesystem on whole device. And after looking at util-linux source code for some time it was "Of course..." (FAT and NTFS filesystems have MBR table inside them).
(In reply to Andrius Štikonas from comment #10) > Putting it on Release Service might be OK, I'm not opposed (but not for > 4.2.0 release, I want to get it out sooner rather than later) to it but this > needs some further discussion with Adrian de Groot, as Calamares depends on > it and there is a question of API/ABI stability, although I guess we don't > need to be ABI stable as this is not a framework, I think some kdepim > packages are in a similar position. Yeah maybe the app itself can be on the release service, but kpmcore can be a framework. Since it has an external user (Calamares), that seems like it could make some sense. > What I would definitely suggest, is putting KTorent/Libktorrent on release > service because KGet (which is part of release service) depends on > libktorrent for bittorrent plugin, and I'm not even the main contributor, > recently Alexander Trufanov was doing most of the work. Great! You can send an email to release-team@kde.org asking for this.