https://bugs.kde.org/show_bug.cgi?id=527047
Bug ID: 527047
Summary: Queued move followed by grow can make filesystem move
copy from destination to itself
Classification: Applications
Product: partitionmanager
Version First 25.12.3
Reported In:
Platform: Fedora RPMs
OS: Linux
Status: REPORTED
Severity: grave
Priority: NOR
Component: general
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
DESCRIPTION
I encountered a filesystem move failure while reorganizing partitions from a
Fedora KDE 44 Live environment.
The disk is GPT/NVMe with a Windows/Fedora dual-boot layout. There was
approximately 244 GiB of unallocated space before the Fedora EFI, /boot, and
XFS root partitions.
I queued moves for the two small Fedora partitions first. I then moved the XFS
root partition to the left into the remaining free space and confirmed that
operation.
Without applying the pending operations, I immediately resized the same XFS
partition again by dragging its right edge to consume all remaining free space.
I then applied all queued operations together.
The two small partition moves completed successfully. When KDE Partition
Manager reached the XFS root partition, its filesystem check succeeded and the
partition geometry was changed, but the filesystem copy used the destination
offset as both the source and destination.
The operation report showed:
Copying 46,098 chunks (483,375,710,208 bytes)
from 276,742,275,072
to 276,742,275,072
direction: left
The operation therefore reported the filesystem move itself as completed, but
the following XFS check failed.
The GPT entry had been moved while the actual XFS filesystem remained at its
original disk location.
STEPS TO REPRODUCE
1. Boot a Fedora KDE Live environment and use KDE Partition Manager on an
unmounted GPT disk.
2. Start with a layout similar to:
[Windows partitions]
[large unallocated space]
[small EFI partition A]
[small /boot partition B]
[large XFS partition C]
[another partition]
3. Queue a move of partition A to the left into the unallocated space.
4. Queue a move of partition B to the left, immediately after partition A.
5. Move partition C to the left into the remaining unallocated space and
confirm the move.
6. Do not apply the pending operations yet.
7. Immediately resize the previewed partition C again, extending its right edge
to consume the remaining free space.
8. Apply all queued operations together.
OBSERVED RESULT
The moves of partitions A and B succeeded.
Before moving partition C, KDE Partition Manager successfully checked its XFS
filesystem.
For partition C, the original filesystem start sector was:
1052219392
The requested new start sector was:
540512256
With 512-byte logical sectors, the correct source byte offset was:
538736328704
and the correct destination byte offset was:
276742275072
However, the operation report showed:
from 276742275072
to 276742275072
The partition geometry was changed to:
Start sector: 540512256
Length: 944093184
but the actual XFS data was never copied from its original location.
The final xfs_repair check then failed and the partition was no longer detected
as XFS at its new GPT location.
EXPECTED RESULT
The filesystem move should use the original on-disk filesystem location as its
source:
from 538736328704
to 276742275072
A later queued resize/grow operation for the same partition should not change
the source address used by the earlier filesystem move.
Alternatively, if the move and grow operations are combined or otherwise
transformed internally, the original filesystem source geometry must still be
preserved until the filesystem has actually been moved.
SOFTWARE/OS VERSIONS
Operating System: Fedora Linux 44 (KDE Plasma Desktop Edition), Live ISO
KDE Plasma Version: 6.6.4
KDE Frameworks Version: 6.25.0
Qt Version: 6.10.2
KDE Partition Manager: 25.12.3-1.fc44
KPMCore: 25.12.3-1.fc44
Kernel: 6.19.10-300.fc44.x86_64
Partition backend: pmsfdiskbackendplugin
ADDITIONAL INFORMATION
This operation was performed from the Fedora KDE 44 Live ISO, not from my
installed Fedora system.
I verified the exact Live ISO package versions directly from the RPM database
inside its squashfs image:
plasma-desktop-6.6.4-1.fc44.x86_64
qt6-qtbase-6.10.2-2.fc44.x86_64
kf6-kcoreaddons-6.25.0-1.fc44.x86_64
kde-partitionmanager-25.12.3-1.fc44.x86_64
kpmcore-25.12.3-1.fc44.x86_64
kernel-core-6.19.10-300.fc44.x86_64
The generated KDE Partition Manager operation report itself displayed
"KDE Frameworks version: 6.23.0", while the Live ISO contains KDE Frameworks
6.25.0 packages.
The filesystem itself was fortunately still intact.
I read the original partition start sector (1052219392) directly and found the
XFS superblock ("XFSB"). I then mapped the original disk range read-only using
a loop device, and blkid detected the original filesystem correctly with its
expected XFS type, UUID and label.
Restoring the GPT entry to the original start sector immediately made the
filesystem visible again.
After recovery, I retried the final operation differently: instead of queueing
a move and then a separate grow, I configured the XFS partition as one combined
"move left + grow" operation.
That operation used the correct copy offsets:
from 538,736,328,704
to 276,742,275,072
direction: left
and completed successfully.
I no longer have the original HTML report file, but I still have screenshots
showing:
- the successful moves of the preceding partitions;
- the XFS pre-move check succeeding;
- the incorrect source == destination copy;
- the final XFS check failing;
- the recovered filesystem at its original location;
- and the later successful move using the correct source and destination.
I also checked the current upstream code after reproducing the problem.
As of KPMCore v26.08.2 and current master, MoveFileSystemJob still determines
the source range at execution time from:
partition().fileSystem().firstByte()
partition().fileSystem().lastByte()
rather than preserving the original filesystem source range when the move job
is created.
The relevant operation/preview logic also still uses mutable Partition /
FileSystem geometry.
Therefore, although I reproduced the failure on KPMCore 25.12.3 from the
Fedora 44 Live ISO, the underlying code path that appears to cause this bug is
still present in current upstream code, and I could not find a commit that
clearly fixes this issue.
I have not reproduced the destructive operation again on current upstream,
so this is based on source-code comparison rather than a second runtime
reproduction.
--
You are receiving this mail because:
You are watching all bug changes.
