(Reported downstream; I don't know kpm version) > formatting a microsd and adding one fat16 600MB partition with the rest of space unallocated is not possible with kpartitionmanager. The screenshot in the downstream report shows error output from the command `sfdisk --force --append /dev/sdb`. *Failed to add partition 'New Partition' to device '/dev/sdb'.* and also */dev/sdb2: Failed to add #2 partition: Invalid argument*. I have not yet tried to reproduce it myself, though.
Partition in question was fat32 but it shouldn't really matter.
Tried it once with openSUSE tumbleweed, but that -- strangely -- ships an old KPMcore. The downstream report now contains additional information, and should be reproducible with a recent Manjaro, partitionmanager 4.1.0-1 kpmcore 4.1.0-1.1 kio 5.72.0-1 util-linux 2.35.2-1.1 So I'll install that on some real hardware and see what happens.
- I installed Manjaro with an image from here: https://manjaro.org/downloads/official/kde/ , that gets me Manjaro 20.0.3 KDE - installed packages are as listed, except I have kio 5.70.1 - inserted 16GB USB stick - used partitionmanager to create new partition table (GPT) and applied that. Quick partitionmanager. - used partitionmanager to create one fat16 600MB partition on the stick. Apply leads to failure. I'll attach log and screenie shortly.
Created attachment 131145 [details] Error screenie
Created attachment 131146 [details] Error log
Created attachment 131147 [details] Error log Trying to fix bugzilla preview for error log file.
Just a quick comment without digging to much in: The error message comes from util-linux/libfdisk/src/gpt.c fdisk_warnx(cxt, _("Sector %ju already used."), (uintmax_t)pa->start); I'm a bit surprised that we are trying to use sector 0. GPT sector 0 is Protective MBR header, we definitely can't have partition there.
By the way, is partition alignment enabled or disabled in settings?
- updated system to latest, include util-linux 2.36-1 - same problems persists I notice that running sfdisk on the command-line shows that *part* of the things being done go over stdin/stdout, which isn't shown in the partitionmanager log. That makes it harder to try to recreate the problem. The code (in kpmcore) does this: ``` if ( createCommand.write(QByteArrayLiteral("start=") + QByteArray::number(partition.firstSector()) + type + QByteArrayLiteral(" size=") + QByteArray::number(partition.length()) + QByteArrayLiteral("\nwrite\n")) && createCommand.start(-1) ) { ``` So I tried to re-create that from shell as follows: - in the create-partition dialog, under *Advanced*, I see *First sector* 0 (alarm bells start ringing) - in the shell, I did `{ echo "start=0 size=600M" ; echo "write" ; } | sfdisk --force --append /dev/sdb` which is basically what kpmcore is going to be doing This naturally fails, because 0 is a **bad** starting sector. The GPT table itself takes up 2048 sectors (?), so any starting sector < 2048 is not acceptable. Changing the `start=` in the shell command, or in partitionmanager under the *Advanced* tab, fixes the problem. Partitionmanager should be smart enough to know that the lowest usable block on GPT is 2048 (or whatever).
I have (*Settings* -> *Configure KDE Partition Manager* -> *General Settings* tab) *Align partitions per default* is checked. It doesn't seem to make a difference except when I do something like enter "70" as a starting sector. Going to the *Advanced* part of the new-partition dialog and setting *First sector* manually to 2048 (so there's the 1MiB GPT space below it) makes it work fine. (So basically we've both identified the source of the problem)
(In reply to groot from comment #9) > I notice that running sfdisk on the command-line shows that *part* of the > things being done go over stdin/stdout, which isn't shown in the > partitionmanager log. That makes it harder to try to recreate the problem. Sometimes stdin might contain confidential information (passphrases), so at the moment it is excluded. You can print it to stdout of partitionmanager if you set KPMCORE_DEBUG=y environmental variable.
Fixed in https://invent.kde.org/system/kpmcore/-/commit/6aa9d9372876484f8fe647c9d9e79de8c3f073b9
Also fixed in util-linux (the underlying cause of the problem is when sfdisk was producing invalid json for the disk, the startlba was not being picked up).