Created attachment 133713 [details] Screenshot of the comparision SUMMARY After checking a disk resized with KDE partition manager with gparted, that tool shows 6 MiB of available space on that disk and allows to expand 6 MiB further. On the other hand the KDE partition manager shows no available space and allows no further expansion.
Can you attach partitioning info from some low level tool instead of screenshots. E.g. sudo sfdisk --json /dev/sda
In the meantime I already fully expanded the disk size with gparted to also contain those "missing" 6 MiB displayed there. The output of the command you gave is: { "partitiontable": { "label":"dos", "id":"0x9456c874", "device":"/dev/sda", "unit":"sectors", "partitions": [ {"node":"/dev/sda1", "start":2048, "size":33550336, "type":"83", "bootable":true} ] } } Another discrepancy between KDE partition manager and gparted is the displayed used disk size. That still differs alot also after "fully" expanding with gparted.
(In reply to Claudius Ellsel from comment #2) > Another discrepancy between KDE partition manager and gparted is the > displayed used disk size. That still differs alot also after "fully" > expanding with gparted. Used disk size is hard to estimate and might certainly differ based on which source you use. KDE Partition Manager has a few sources itself (depending on whether partition is mounted or not). Some filesystems themselves don't know exact amount of used/free space and show only estimates (this is especially true for btrfs with its subvolumes). How much is the difference though? And regarding original problem: argh, sfdisk does not show size of whole device when you use MBR (it did show for me with GPT). Maybe you can paste sudo fdisk /dev/sda instead (you need to press "p" for info).
Output with sudo fdisk /dev/sda: Festplatte /dev/sda: 15,102 GiB, 17179860992 Bytes, 33554416 Sektoren Festplattenmodell: VBOX HARDDISK Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes Festplattenbezeichnungstyp: dos Festplattenbezeichner: 0x9456c874 Gerät Boot Anfang Ende Sektoren Größe Kn Typ /dev/sda1 * 2048 33552383 33550336 16G 83 Linux
(In reply to Andrius Štikonas from comment #3) > Used disk size is hard to estimate and might certainly differ based on which > source you use. KDE Partition Manager has a few sources itself (depending on > whether partition is mounted or not). > > Some filesystems themselves don't know exact amount of used/free space and > show only estimates (this is especially true for btrfs with its subvolumes). > How much is the difference though? Ah that makes sense then. You can see the difference of the estimates before fully expanding in the attached screenshot (7.47 GiB gparted vs. 7.28 GiB KDE partition manager). Currently after expanding with gparted it is 7.71 GiB gparted vs. 7.40 GiB KDE partition manager.
Closing this (reason for discrepancies is explained in the previous comments).
Mh, the thing is that it is a bit weird that gparted allowed me to increase the size further. Not sure whether that had a real effect, though.
(In reply to Claudius Ellsel from comment #7) > Mh, the thing is that it is a bit weird that gparted allowed me to increase > the size further. Not sure whether that had a real effect, though. Yeah, that was strange... I can't see why would it happen though. For MBR partition tables we define lastUsableSector = diskDevice->totalSectors(); So that wouldn't limit it in any way. Maybe something wrong in sector alignment calculation: https://invent.kde.org/system/kpmcore/-/blob/master/src/core/partitionalignment.cpp#L127
Maybe it is something special with the Virtualbox disk image.
(In reply to Claudius Ellsel from comment #9) > Maybe it is something special with the Virtualbox disk image. Unlikely. Anyway, let's keep it open maybe, I'll find some media where I can reproduce this...
Alright, thanks for your efforts! The exact procedure was: - Have a KDE Neon installation on Virtualbox (I guess 8GiB total size of the image) - Resize that image to (I guess) 16 GiB - Expand the partition from within the session with KDE Partition Manager to all available space - Launch gparted (I also ran into https://bugs.kde.org/show_bug.cgi?id=429771 during this, so maybe something went wrong during the resize?)
(In reply to Claudius Ellsel from comment #11) > (I also ran into https://bugs.kde.org/show_bug.cgi?id=429771 during this, so > maybe something went wrong during the resize?) My guess would be that partition was resized but filesystem wasn't. But I don't understand how you got into that state... If everything finished without errors, you shouldn't be in semi-resized state. Unfortunately, at the moment KDE Partition Manager can't tell if partition size == filesystem size (Gparted can).
Ah thanks for the insight. I did not know that there is a difference between filesystem and partition. That might be an explanation for that behavior. I did not notice an error when resizing the partition in KDE partitionmanager.
Another note: When setting the size to resize to, the field behaved a bit sluggish. I did not want to use the arrows until I got to the desired size, so I typed it in and tried to estimate where the exat size was. I think after that I was in a state where I think I couldn't use the arrows to fine tune anymore and thought that I had reached the maximum size. However, another explanation might be that the number I typed in caused a bug to appear and that was the reason why I couldn't use the arrows to modify the number anymore. I don't really remember that, though I am not sure whether what I write in this comment is really how things behaved.