I am working on a embedded debian linux device. Owing to the power being pulled at any time resulting in a sudden power loss, we have set FSCKFIX from "no" to "yes" in the /etc/default/rcS file. Without this I have encountered errors where the system drops to a terminal waiting for the user (on a serial term) to manually run fsck to repair the disk (since the device has no terminal in normal operation this effectively bricks the box). Also the card has been made RO, being remounted RW as needed for updates, but that is not related to my problem I don't think.

I have been trying to make a unit test for this which will corrupt the sdcard, then we should be able to put the card back into the embedded device and it should repair and boot itself as normal.

Initially I have been only interested in reliably generating the failure I sometimes see with FSCKFIX=no, ie dropping to a terminal to fix the card manually via fsck. I tried the suggestions here and here, but those methods either make the card completely unbootable or seem to be ignored/fixed and the system boots normally without kicking me to a terminal to run fsck. So it seems I need to damage the disk in a very specific way to force fsck to need manual intervention with FSCKFIX=no. Can anyone tell me how to do this ????


  • This looks like what I want, but I have run this from the starting count=10 upto a count of 512M so far without getting a error from e2fsck on this 8gig card ill keep going though – othane Oct 14 '13 at 23:47
  • What I really need to know is how does fsck detect ext3 partitions are corrupt, I have read ext3 does not checksum the data, then does it just check the inodes make sense? If I can understand this I can possibly invoke a failure. – othane Oct 14 '13 at 23:55

OK so technically I got my anwser from that link Iain posted (cheers!), I just had to make count huge and ensure I called e2fsck with the -f & -F option as well as -p to get fsck to see the problem.

sudo dd if=/dev/zero of=/dev/mmcblk0p4 bs=1 count=4096 seek=10000; sync sudo e2fsck -f -F -p /dev/mmcblk0p4; echo $? /dev/mmcblk0p4: Resize inode not valid.

/dev/mmcblk0p4: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. (i.e., without -a or -p options) 4

Although this got me the result I am looking for (a busted sd card) I would really love a anwser to how fsck actually detects the ext3 partition is corrupt when it does not use checksums of the data, and if it uses the journal, then how does it work for ext2 or ext3 wo journaling?

Cheers again

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.