SUMMARY When the user tries to resize a mounted ext4 filesystem , there is no warning to unmount it first, the sliders does not move to shrink similar to gparted. The user then unmounts the ext4 filesystem and do the shrink and apply. STEPS TO REPRODUCE 1. Unmount ext4 filesystem 2. Shrink ext4 filesystem 3. FS shrinked and mounted, fsck fails with error displayed OBSERVED RESULT Filesystem resized, but cannot be checked with fsck, error displayed EXPECTED RESULT SOFTWARE/OS VERSIONS Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.19.1 KDE Frameworks Version: 5.71 Qt Version: 5.14.2 ADDITIONAL INFORMATION KDE Partition Manager: SMART Status Report Date: 2020. 06. 23. 16:17 Program version: 4.1.0 Backend: pmsfdiskbackendplugin (1) KDE Frameworks version: 5.67.0 Machine: Linux dell6540 5.3.0-59-generic #53~18.04.1-Ubuntu SMP Thu Jun 4 14:58:26 UTC 2020 x86_64 Shrink partition ‘/dev/sda6’ from 78,76 GiB to 48,97 GiB Job: Check file system on partition ‘/dev/sda6’ Command: e2fsck -f -y -v /dev/sda6 Check file system on partition ‘/dev/sda6’: Success Job: Resize file system on partition ‘/dev/sda6’ to 102 701 056 sectors Resizing file system from 165 167 759 to 102 701 056 sectors. Command: resize2fs /dev/sda6 102701056s Resize file system on partition ‘/dev/sda6’ to 102 701 056 sectors: Success Job: Set geometry of partition ‘/dev/sda6’: Start sector: 334 950 400, length: 102 701 056 Command: sfdisk --force /dev/sda -N 6 Set geometry of partition ‘/dev/sda6’: Start sector: 334 950 400, length: 102 701 056: Success Job: Check file system on partition ‘/dev/sda6’ Command: e2fsck -f -y -v /dev/sda6 Check file system on partition ‘/dev/sda6’: Error Checking partition ‘/dev/sda6’ after resize/move failed. Shrink partition ‘/dev/sda6’ from 78,76 GiB to 48,97 GiB: Error
I'm not sure I fully understand your steps to reproduce. Did you unmount ext4 filesystem inside partitionmanager? What happens if you run e2fsck -f -y -v /dev/sda6 manually later? (I'm asking this to determine if fsck failure is just because of some race condition, maybe block device was not ready yet after sfdisk resized it).
.
Hi Andrius, No matter how I unmount the FS. I did it within Partition Manager and in Dolphin too. I did not try fsck manually afterwards, as the filesystem was mounted after resize by Partition Manager. I assume it is successful if the FS is not mounted.
(In reply to Laosom from comment #3) > Hi Andrius, > > No matter how I unmount the FS. I did it within Partition Manager and in > Dolphin too. > I did not try fsck manually afterwards, as the filesystem was mounted after > resize by Partition Manager. I assume it is successful if the FS is not > mounted. That is very strange. The filesystem should stay unmounted whether successful or not. KDE Partition Manager would not automount ext4. (It does automount some other filesystems like btrfs that can only be resized when mounted but not ext4.) Maybe something else is automounting fs on your system and interfered with resize2fs command? That might explain why there are fsck errors afterwards. I'm not sure what could be automounting. Partition Manager does try to disable KDE automounter.
I tried again. Dolphin was not open. I unmounted in PM. Same behaviour. I am running KDE Neon 5.19.2
I tried on ArcoB Plasma (5.19.2) and Manjaro KDE (5.18.5) latest. It was OK. No issues, which was surprising , but delightful. The resized ext4 filesystem was not in fstab. Retested in Neon. The resized filesystem(s) were in fstab. Unmounted and commented out. Same issue again. One filesystem is used for timeshift backups the other one is for virtual machines. I wonder what Neon (ubuntu ?) is doing.
(In reply to Laosom from comment #6) > I tried on ArcoB Plasma (5.19.2) and Manjaro KDE (5.18.5) latest. > It was OK. No issues, which was surprising , but delightful. > The resized ext4 filesystem was not in fstab. > > Retested in Neon. > The resized filesystem(s) were in fstab. Unmounted and commented out. > Same issue again. > One filesystem is used for timeshift backups the other one is for virtual > machines. > I wonder what Neon (ubuntu ?) is doing. Being in fstab shouldn't really be that important in this case (it may only be indirectly affecting this. For example if automounter reads fstab and mounts everything there)... Could you check what happens with plasma automounter on Neon. (You can see its status in System Settings -> Startup and shutdown -> Background services). If it is running, partitionmanager should stop it automatically using dbus).
Created attachment 129702 [details] PM error automounter
I checked and find it was not running.
(In reply to Laosom from comment #9) > I checked and find it was not running. ok. And can you run fsck manually afterwards? To see if it's still failing? As I've said before, maybe partition manager does not wait long enough for block device to get ready.
As I wrote the filesystem is mounted back again after it was extended and that's the reason for the error. Of course I can run fsck if I unmount it manually before running it. I did and it works this way.
Created attachment 129770 [details] 20200629_1
Created attachment 129771 [details] 20200629_2
I can try to reproduce this on Neon Live USB (maybe next weekend if I don't forget). Although, it is likely that it will work there and this is some system misconfiguration (as I've said I don't understand what is mounting it, plasma automounter seems to be off). If I can't reproduce this, then maybe worth asking Neon developers?
(changing bug state from needs info to reported.)
Could it be udisks2 automounting the partition? Check journalctl...
(In reply to Eric S from comment #16) > Could it be udisks2 automounting the partition? Check journalctl... Hmm, good idea! Definitely worth checking.
journatctl shows no sign of udisks2 2020. 07. 14. 18:12 partitionmanager "Add operation: Shrink partition ‘/dev/sda6’ from 78,76 GiB to 58,90 GiB" 2020. 07. 14. 18:12 partitionmanager "Applying operations..." 2020. 07. 14. 18:12 kwin_x11 qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 40090, resource id: 96469182, major code: 19 (DeleteProperty), minor code: 0 2020. 07. 14. 18:12 kwin_x11 qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 40094, resource id: 96469182, major code: 18 (ChangeProperty), minor code: 0 2020. 07. 14. 18:12 kwin_x11 qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 40101, resource id: 96469182, major code: 19 (DeleteProperty), minor code: 0 2020. 07. 14. 18:12 kwin_x11 qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 40102, resource id: 96469182, major code: 18 (ChangeProperty), minor code: 0 2020. 07. 14. 18:12 kwin_x11 qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 40103, resource id: 96469182, major code: 19 (DeleteProperty), minor code: 0 2020. 07. 14. 18:12 kwin_x11 qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 40104, resource id: 96469182, major code: 19 (DeleteProperty), minor code: 0 2020. 07. 14. 18:12 kwin_x11 qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 40105, resource id: 96469182, major code: 19 (DeleteProperty), minor code: 0 2020. 07. 14. 18:12 kwin_x11 qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 40106, resource id: 96469182, major code: 7 (ReparentWindow), minor code: 0 2020. 07. 14. 18:12 kwin_x11 qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 40107, resource id: 96469182, major code: 6 (ChangeSaveSet), minor code: 0 2020. 07. 14. 18:12 kwin_x11 qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 40108, resource id: 96469182, major code: 2 (ChangeWindowAttributes), minor code: 0 2020. 07. 14. 18:12 kwin_x11 qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 40109, resource id: 96469182, major code: 10 (UnmapWindow), minor code: 0 2020. 07. 14. 18:12 systemd Stopped File System Check on /dev/disk/by-uuid/e89658ee-a61a-49ce-bae0-d7463d1271bb. 2020. 07. 14. 18:12 systemd Starting File System Check on /dev/disk/by-uuid/e89658ee-a61a-49ce-bae0-d7463d1271bb... 2020. 07. 14. 18:12 systemd Started File System Check Daemon to report status. 2020. 07. 14. 18:12 systemd-fsck virtualmachines: clean, 34/3866624 files, 9188632/15440384 blocks 2020. 07. 14. 18:12 systemd Started File System Check on /dev/disk/by-uuid/e89658ee-a61a-49ce-bae0-d7463d1271bb. 2020. 07. 14. 18:12 systemd Mounting /virtual_machines... 2020. 07. 14. 18:12 kernel EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: (null) 2020. 07. 14. 18:12 systemd Mounted /virtual_machines. 2020. 07. 14. 18:12 ksystemstats could not find subsystem "pscount" 2020. 07. 14. 18:12 plasmashell Model size of -2147483647 is less than 0 2020. 07. 14. 18:13 xdg-desktop-portal-kde xdp-kde-background: GetAppState called: no parameters
Created attachment 130119 [details] journal
Created attachment 130120 [details] kpart
(In reply to Laosom from comment #18) > journatctl shows no sign of udisks2 > > 2020. 07. 14. 18:12 systemd Stopped File System Check on > /dev/disk/by-uuid/e89658ee-a61a-49ce-bae0-d7463d1271bb. > 2020. 07. 14. 18:12 systemd Starting File System Check on > /dev/disk/by-uuid/e89658ee-a61a-49ce-bae0-d7463d1271bb... > 2020. 07. 14. 18:12 systemd Started File System Check Daemon to report > status. > 2020. 07. 14. 18:12 systemd-fsck virtualmachines: clean, 34/3866624 files, > 9188632/15440384 blocks > 2020. 07. 14. 18:12 systemd Started File System Check on > /dev/disk/by-uuid/e89658ee-a61a-49ce-bae0-d7463d1271bb. > 2020. 07. 14. 18:12 systemd Mounting /virtual_machines... > 2020. 07. 14. 18:12 kernel EXT4-fs (sda6): mounted filesystem with ordered > data mode. Opts: (null) > 2020. 07. 14. 18:12 systemd Mounted /virtual_machines. > 2020. 07. 14. 18:12 ksystemstats could not find subsystem "pscount" > 2020. 07. 14. 18:12 plasmashell Model size of -2147483647 is less than 0 > 2020. 07. 14. 18:13 xdg-desktop-portal-kde xdp-kde-background: GetAppState > called: no parameters But I think it shows signs of systemd automounting sda6. Not sure why...
I see. I will set up a Neon VM too with the similar FS layout. Have you tested it yet ?
(In reply to Laosom from comment #22) > I see. I will set up a Neon VM too with the similar FS layout. > Have you tested it yet ? Sorry, not yet...
(In reply to Laosom from comment #22) > I see. I will set up a Neon VM too with the similar FS layout. > Have you tested it yet ? So I was not able to reproduce this on Neon. But I agree that something is auto-mounting that partition on your disk. Unfortunately, I don't really know what. Maybe there are some clues in systemd .mount files? (that should be generated from your fstab).