Red Hat Bugzilla – Bug 1282655
EXT4 error while resizing and moving partitions
Last modified: 2015-11-17 11:16:20 EST
Description of problem:
Dropped to tty1 and get messages about ext4 after resizing and moving external drive with gparted.
Version-Release number of selected component (if applicable):
Fedora 23 on live USB
Have only tried once
Steps to Reproduce:
1. Boot live USB
2. sudo dnf install gparted
3. sudo gparted
4. Resize and move a partition at once
5. Wait about 2 hours
6. This happened during the move, after the resize
6. Get dropped to tty1 and see errors
Dropped to tty1 and get following
[13017.508117] EXT4-fs error (device dm-0): ext4_find_entry:1451: inode #10009:
comm systemd-logind: reading directory lblock 0
[13017.510023] EXT4-fs (dm-0): previous I/O error to superblock detected
[13017.510823] Buffer I/O error on dev dm-0, logical block 0, lost sync page write
[13017.518851] systemd-logind: Failed to remove runtime directory /run/user/1000: Permission denied
[16223.059494] systemd-logind: Failed to execute operation: Unit poweroff.target failed to load: Input/output error. See system logs and 'systemctl status poweroff.
target' for details.
I can switch to the other tty1-6 but they all say
[16223.059494] systemd-logind: Failed to start email@example.com: Unit firstname.lastname@example.org failed to load: Input/output error. See system logs and 'systemctl statu
s email@example.com' for details.
I am not sure if gparted continued trying to move or not. I left it open in case it worked.
This is similar to Bug 639733 but when switch ttys I am not getting what firstname.lastname@example.org reported, he said
"then after a few seconds the following displays right below the msg above:
Ext4-fs error (device dm-0): ext4_find_entry: reading directory #82757 offset 0"
but I got the I/o error.
Filesystem is just component with basic directory layout. It has nothing to do with ext4 filesystem. Reassigning to kernel, filesystem subcomponent - and to Eric as ext4 specialist.
Something happened before the log snippet you mention:
> [13017.510023] EXT4-fs (dm-0): previous I/O error to superblock detected
So attach full kernel logs please, as well full details of the move you attempted.
gparted book says:
"Before before performing this task, we highly recommend that you backup your data. This task involves moving the start of a partition boundary, which is a high risk activity. "
So it's possible that gparted may have caused corruption, and nothing ext4 can do about that. But let's see the logs...
I rebooted and continued the install process. The data that was lost didn't matter that much. Would the logs be on the live USB? And where would I find them. I assumed there was no way to get them but if there still is I will post them. If I can't get the logs I agree that this bug report is pretty useless.
If you rebooted, I'm afraid the logs are lost, so there probably isn't much to go on here...