1

I have a pretty basic system running Ubuntu 16.04, 1 HDD, running a few partitions:

sda1 - EXT4 - 100G   - /
sda2 - EXT4 - 723.5G - /home
sda3 - NTFS - 100G   - (windows)
sda5 - SWAP - 8G

Whenever I try to access one of 3-4 files in a specific directory in the /home partition, (the specific folder causing the issues is /home/path/to/broken/folder), the /home partition will error and remount read-only. dmesg shows the following errors:

EXT4-fs error (device sda2): ext4_ext_check_inode:497: inode #1415: comm rm: pblk 0 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
Aborting journal on device sda2-8.
EXT4-fs (sda2): Remounting filesystem read-only
EXT4-fs error (device sda2): ext4_ext_check_inode:497: inode #1417: comm rm: pblk 0 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
EXT4-fs error (device sda2): ext4_ext_check_inode:497: inode #1416: comm rm: pblk 0 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)

So I understand what is going on...some bad block is causing an error and is remounting the drive read-only to prevent further corruption. I know it is these specific files because I can undo the error by

  1. Logging in as root
  2. Running sync
  3. Stopping lightdm (and all sub-processes)
  4. Stop all remaining open files on /home by finding them with lsof | grep /home
  5. Unmounting /home
  6. Running fsck /home (fixing the errors)
  7. Remount /home

Everything is fine again, read and write, until I try to access the same files again, then this entire process is repeated to fix it again.

The way I've tried to access the files is by running ls /home/path/to/broken/folder and rm -r /home/path/to/broken/folder, so it seems any kind of HDD operation on that part of the drive errors it and throws it into read-only again.

I honestly don't care about the files, I just want them gone. I am willing to remove the entire /home/path/to/broken/folder folder, but every time I try this, it fails and throws into read-only.

How can I fix this without re-formatting the entire /home drive?


EDIT 1:

I ran badblocks -v /dev/sda2 on my hard drive, but it came out clean, no bad blocks. Any help would still be greatly appreciated.


EDIT 2:

Still looking for a solution to this. Some information that might be useful below:

$ debugfs -R 'stat <1415>' /dev/sda2
debugfs 1.42.13 (17-May-2015)
Inode: 1415   Type: regular    Mode:  0644   Flags:  0x80000
Generation: 0    Version: 0x00000000
User:     0   Group:     0   Size: 0
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 0
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x5639ad86 -- Wed Nov  4 01:02:30 2015
atime: 0x5639ad86 -- Wed Nov  4 01:02:30 2015
mtime: 0x5639ad86 -- Wed Nov  4 01:02:30 2015
Size of extra inode fields: 0
EXTENTS:

Now I looked at this myself and compared it to what I suspect to be a non-corrupted inode:

$ debugfs -R 'stat <1410>' /dev/sda2
debugfs 1.42.13 (17-May-2015)
Inode: 1410   Type: regular    Mode:  0644   Flags:  0x80000
Generation: 0    Version: 0x00000000
User:     0   Group:     0   Size: 996
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 0
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x5639ad31 -- Wed Nov  4 01:01:05 2015
atime: 0x5639ad31 -- Wed Nov  4 01:01:05 2015
mtime: 0x5639ad31 -- Wed Nov  4 01:01:05 2015
Size of extra inode fields: 0
EXTENTS:
(0):46679378

I have bolded what I believe are the key differences here. I looked at other non-corrupted inodes and they display something similar to the 1410 that has a non-zero size and an extent.

Bad header/extent makes sense here...it has no extent....how do I fix this?

I really feel like I've handed this question to someone smarter than me on a silver platter, I just don't know what the meal (answer) is!

1 Answer 1

1

Finally found the answer from somebody else on another site, just zeroed the inodes and rechecked the system, that was all!

debugfs -w /dev/sda2
:clri <1415>
:clri <1416>
:clri <1417>
:q
fsck -y /dev/sda2

To anybody else with this issue, I found my bad inodes using find on the bad mount, then checked dmesg for errors on the bad inodes.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .