3

I have a pretty basic system running Ubuntu 16.04 (this question is not specific to Ubuntu, but rather ext4 partitions), 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.

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.

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 without reformatting my entire /home partition?

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!

  • Did you try a full fsck such as e2fsck -pf /dev/sda2 while unmounted? – Julie Pelletier May 12 '16 at 5:08
  • I did not, but managed to fix the problem another way. Thanks for the tip though! – Zzzach... May 12 '16 at 17:39
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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.