Bug 400652

Summary: Partition Manager does not support whole disk partitions
Product: [Applications] partitionmanager Reporter: Gery <bugzilla>
Component: generalAssignee: Andrius Štikonas <andrius>
Status: RESOLVED FIXED    
Severity: wishlist CC: nate, pseudo-account
Priority: NOR    
Version: Git   
Target Milestone: ---   
Platform: Neon   
OS: Linux   
Latest Commit: Version Fixed In: 4.2.0
Sentry Crash Report:

Description Gery 2018-11-04 10:26:59 UTC
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
Comment 1 Andrius Štikonas 2018-11-04 15:30:48 UTC
Do you see that partition at all? Or is it completely skipped.

Can you post lsblk output and "sfdisk --json /dev/sdX"?
Comment 2 Gery 2018-11-04 15:47:53 UTC
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.
Comment 3 Andrius Štikonas 2018-11-04 17:16:39 UTC
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.
Comment 4 Andrius Štikonas 2019-05-19 09:54:14 UTC
*** Bug 407713 has been marked as a duplicate of this bug. ***
Comment 5 Andrey E. 2019-05-19 13:20:27 UTC
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.
Comment 6 Andrey E. 2019-05-19 14:26:51 UTC
(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.
Comment 7 Andrius Štikonas 2020-10-03 14:15:35 UTC
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
Comment 8 Andrius Štikonas 2020-10-03 14:18:58 UTC
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.
Comment 9 Nate Graham 2020-10-05 16:35:23 UTC
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. :)
Comment 10 Andrius Štikonas 2020-10-05 16:53:55 UTC
(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).
Comment 11 Nate Graham 2020-10-05 17:42:21 UTC
(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.