I have a weird problem with my Pi since a few days:

A lot of commands result in "segmentation fault". Any "apt-get install" does, some normal programs do.

I've googled it and found out it might be a broken file system, so I tried $ sudo fsck.ext4 -pfvc /dev/sde2 on a linux computer. That command returned /dev/sde2: Updating bad block inode., but this did not fix the issue.

Anything I can do about that without re-flashing a backup onto the SD card? And, why does my Pi always "eat" (destroy) my SD cards in a short amount of time? I've reinstalled the Pi like four months ago ...

1 Answer 1


AFAIK there is no simple fix. If you have another Linux system you could try disk repair, but this appears not to have worked. Presumably some of the files have been damaged. You may be able to replace from a known good image.

This has happened to me once in 2 years, during an upgrade. I restored from a backup. The Pi is no different to any other system, if it contains anything important make backups.

Other than the failure above, I have had no other problems (unless I have done something wrong), and one new card which totally failed (couldn't be re-imaged) which was replaced under warranty. If you buy reputable brand cards, use a reliable power supply, and shutdown properly you should have no need to re-image. Even if you don't shutdown properly the chance of damage should be slight.

  • You said I might be able to replace damaged files from a good image. But how do I know what files are damaged? Or is it better to re-flash a backup and just copy over the recently changed files? Nov 17, 2015 at 4:36
  • I am not sure if rsync would help here, but you could try checksumming all files. I wouldn't bother unless I had special reasons. By all means backup your home directory, and any particular customisation. You may be interested in trying to backup files using raspberrypi.stackexchange.com/questions/5427/…
    – Milliways
    Nov 17, 2015 at 4:54
  • I'd say if you can access and copy them out they are at least viable, it's up to you to decide beyond that. I think that files left over after a completed fsck can be considered undamaged in a sense; files that aren't coherent are placed as chunks into lost+found. They could always, of course, have corrupted bytes in them at any point -- there's no way to tell except some comparison such as checksumming; fsck's job is just to leave things coherent. There are some filesystems that will do checksum inherently (zfs?) but such is not the case here.
    – goldilocks
    Nov 17, 2015 at 15:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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