Bug 400652

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.