SUMMARY *** Basically I have a PM1733 NVME SSD, this SSD supports LBA size of 4096bytes, but it seems that KPMcore can't work on LBA of this size. *** STEPS TO REPRODUCE 1. nvme format /dev/nvme1n1 -l 2 2. Use partitionmanager. OBSERVED RESULT partitionmanager cannot operate this SSD. EXPECTED RESULT partitionmanager works fine. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION nvme id-ns /dev/nvme1n1 | grep LBA LBA Format 0 : Metadata Size: 0 bytes - Data Size: 512 bytes - Relative Performance: 0x1 Better LBA Format 1 : Metadata Size: 8 bytes - Data Size: 512 bytes - Relative Performance: 0x3 Degraded LBA Format 2 : Metadata Size: 0 bytes - Data Size: 4096 bytes - Relative Performance: 0 Best (in use) LBA Format 3 : Metadata Size: 8 bytes - Data Size: 4096 bytes - Relative Performance: 0x2 Good nvme format /dev/nvme1n1 -l 2
Would be nice to support this, but I don't have any hardware with LBA of 4096, so it would be nice if somebody who has it could add this and send merge request.
(In reply to Andrius Štikonas from comment #1) > Would be nice to support this, but I don't have any hardware with LBA of > 4096, so it would be nice if somebody who has it could add this and send > merge request. Does this mean that parted has similar flaws?
(In reply to daiaji from comment #2) > (In reply to Andrius Štikonas from comment #1) > > Would be nice to support this, but I don't have any hardware with LBA of > > 4096, so it would be nice if somebody who has it could add this and send > > merge request. > > Does this mean that parted has similar flaws? I don't know. And you haven't posted exact error that you are getting, so hard to tell. In general kpmcore tries to take care of sector size (it is not hardcoded to 512) but I guess you are hitting some bug.
(In reply to Andrius Štikonas from comment #3) > (In reply to daiaji from comment #2) > > (In reply to Andrius Štikonas from comment #1) > > > Would be nice to support this, but I don't have any hardware with LBA of > > > 4096, so it would be nice if somebody who has it could add this and send > > > merge request. > > > > Does this mean that parted has similar flaws? > > I don't know. And you haven't posted exact error that you are getting, so > hard to tell. > > In general kpmcore tries to take care of sector size (it is not hardcoded to > 512) but I guess you are hitting some bug. “There are already 0 primary partitions on this device. This is the maximum number its partition table type can handle. You cannot create, paste or restore a primary partition on it before you delete an existing one.“ I don't know how to export the bug report.
(In reply to daiaji from comment #4) > (In reply to Andrius Štikonas from comment #3) > > (In reply to daiaji from comment #2) > > > (In reply to Andrius Štikonas from comment #1) > > > > Would be nice to support this, but I don't have any hardware with LBA of > > > > 4096, so it would be nice if somebody who has it could add this and send > > > > merge request. > > > > > > Does this mean that parted has similar flaws? > > > > I don't know. And you haven't posted exact error that you are getting, so > > hard to tell. > > > > In general kpmcore tries to take care of sector size (it is not hardcoded to > > 512) but I guess you are hitting some bug. > > “There are already 0 primary partitions on this device. This is the maximum > number its partition table type can handle. > You cannot create, paste or restore a primary partition on it before you > delete an existing one.“ > > I don't know how to export the bug report. “There are already 0 primary partitions on this device. This is the maximum number its partition table type can handle. You cannot create, paste or restore a primary partition on it before you delete an existing one.“ I don't know how to export the bug report. I did some tests with gdisk and parted and also fdisk and they don't seem to have this failure.
Might be an issue here: https://invent.kde.org/system/kpmcore/-/blob/master/src/plugins/sfdisk/sfdiskbackend.cpp#L454 Can you try it with 4096 and 8191? You'll have to rebuild KPMcore. Note that this is just a quick check and will not work with 512 (I guess proper fix would be d.logicalSize() and d.logicalSize() * 2 - 1
(In reply to Andrius Štikonas from comment #6) > Might be an issue here: > > https://invent.kde.org/system/kpmcore/-/blob/master/src/plugins/sfdisk/ > sfdiskbackend.cpp#L454 > > Can you try it with 4096 and 8191? You'll have to rebuild KPMcore. Note that > this is just a quick check and will not work with 512 (I guess proper fix > would be d.logicalSize() and d.logicalSize() * 2 - 1 CopySourceDevice source(d, 4096, 1023); After modifying and compiling the source code here, this fault is eliminated.
(In reply to daiaji from comment #7) > (In reply to Andrius Štikonas from comment #6) > > Might be an issue here: > > > > https://invent.kde.org/system/kpmcore/-/blob/master/src/plugins/sfdisk/ > > sfdiskbackend.cpp#L454 > > > > Can you try it with 4096 and 8191? You'll have to rebuild KPMcore. Note that > > this is just a quick check and will not work with 512 (I guess proper fix > > would be d.logicalSize() and d.logicalSize() * 2 - 1 > > CopySourceDevice source(d, 4096, 1023); > > After modifying and compiling the source code here, this fault is eliminated. Can you please also test with qint64 sectorSize = d.logicalSize(); CopySourceDevice source(d, sectorSize, sectorSize * 2 - 1);
(In reply to Andrius Štikonas from comment #8) > (In reply to daiaji from comment #7) > > (In reply to Andrius Štikonas from comment #6) > > > Might be an issue here: > > > > > > https://invent.kde.org/system/kpmcore/-/blob/master/src/plugins/sfdisk/ > > > sfdiskbackend.cpp#L454 > > > > > > Can you try it with 4096 and 8191? You'll have to rebuild KPMcore. Note that > > > this is just a quick check and will not work with 512 (I guess proper fix > > > would be d.logicalSize() and d.logicalSize() * 2 - 1 > > > > CopySourceDevice source(d, 4096, 1023); > > > > After modifying and compiling the source code here, this fault is eliminated. > > Can you please also test with > > qint64 sectorSize = d.logicalSize(); > CopySourceDevice source(d, sectorSize, sectorSize * 2 - 1); https://github.com/daiaji/kpmcore/commit/47e1984febde6ade6740d89457cbf2892ec0d7cd After the source code is modified in this way, it seems that the devices with 4096 byte LBA and 512 byte LBA can normally use kpmcore to create new partitions. But it seems strange that an MBR partition table can be created on an SSD with an LBA of 4096 bytes, even without any modification to the source code, and partitions can also be created on the MBR partition table. Does this check only occur on the GPT partition table?
(In reply to daiaji from comment #9) > But it seems strange that an MBR partition table can be created on an SSD > with an LBA of 4096 bytes, even without any modification to the source code, > and partitions can also be created on the MBR partition table. Does this > check only occur on the GPT partition table? That's because MBR starts at the beginning of the disk (LBA 0). GPT leaves first sector for MBR data (for backward compatibility reasons) and GPT header is located on LBA 1.
Git commit 36881cde62503004a835080833985b32857b024f by Andrius Štikonas. Committed on 04/05/2022 at 16:49. Pushed by stikonas into branch 'master'. Fix location of GPT header on 4K LBA devices. M +2 -1 src/plugins/sfdisk/sfdiskbackend.cpp https://invent.kde.org/system/kpmcore/commit/36881cde62503004a835080833985b32857b024f
Git commit 82a6351bae64b99616249e44492259ec31a3b34e by Andrius Štikonas. Committed on 04/05/2022 at 16:49. Pushed by stikonas into branch 'release/22.04'. Fix location of GPT header on 4K LBA devices. M +2 -1 src/plugins/sfdisk/sfdiskbackend.cpp https://invent.kde.org/system/kpmcore/commit/82a6351bae64b99616249e44492259ec31a3b34e