Bug 1282655 - EXT4 error while resizing and moving partitions
EXT4 error while resizing and moving partitions
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Eric Sandeen
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2015-11-16 19:58 EST by John Andersen
Modified: 2015-11-17 11:16 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-11-17 11:16:20 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description John Andersen 2015-11-16 19:58:26 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

How reproducible:
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

Actual results:
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[1090]: Failed to remove runtime directory /run/user/1000: Permission denied
[16223.059494] systemd-logind[1090]: 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[1090]: Failed to start autovt@tty4.service: Unit getty@tty4.service failed to load: Input/output error. See system logs and 'systemctl statu
s getty@tty4.service' for details.

Expected results:
Format completes

Additional info:
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 skeeter9807@hotmail.com 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.
Comment 1 Ondrej Vasik 2015-11-17 01:53:40 EST
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.
Comment 2 Eric Sandeen 2015-11-17 09:46:32 EST
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...
Comment 3 John Andersen 2015-11-17 10:37:49 EST
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.
Comment 4 Eric Sandeen 2015-11-17 10:46:27 EST
If you rebooted, I'm afraid the logs are lost, so there probably isn't much to go on here...
Comment 5 John Andersen 2015-11-17 11:16:20 EST
Yes :(

Note You need to log in before you can comment on or make changes to this bug.