4

How I hosed my ext4 file system in the first hour with Raspbian:

I have always used shutdown -r now. I tried this after editing my overclocking parameters manually. I remember setting arm_freq to 900 and sdram_freq to something (!), carefully of course. I followed with

shutdown -r now

The screen froze, no response from keyboard or mouse. A power off was the only option. On restart I've got ext4 errors and eventually I decided it required a re-image. I notice a lot of people use:

halt or reboot

but I still assume shutdown is fine. Do you have any ideas on what could go wrong?

UPDATE: This happened with a Maplin build of Raspbian. With the latest downloaded build, could not reproduce this.

4
  • So, basically, you edited config.txt in order to overclock your RaspberryPi and it wasn't able to boot up after this change, right? Turning power off and on again did not help? Commented Oct 16, 2012 at 10:47
  • @Krzysztof No. It would be more correct to say it didn't shutdown gracefully after changing the config file. Which had a knock on effect of corrupting the FS. Subsequent power ons did not help Commented Oct 16, 2012 at 11:12
  • Did you do anything other than editing config.txt file last time it was able to boot correctly? Commented Oct 16, 2012 at 14:03
  • An new image first, probably a later build. Then I ran raspi-config and chose Turbo. Commented Oct 16, 2012 at 16:55

1 Answer 1

4

shutdown, halt and reboot should all safely close you system before turning it of (or rebooting). So it's definitely not the cause of your problem. So it's either because of overclocking or some other error you did when trying this.

We can't check that since you already overwritten the card contents. Next time you have similar problem, you can first investigate the /boot/ partition content using SD card reader on other computer and try to recover config.txt from backup or remove it to get default values. This way you can be sure that it was not the issue with wrong config.txt options. You can also use jumper to run emergency mode (see my answer to this question).

10
  • Are you suggesting that restoring config.txt in any way would assist in repairing a corrupted root file system? Commented Oct 16, 2012 at 13:42
  • 2
    @ScrollerBlaster: No, i don't think so. But I think it may be possible ext4 errors could be caused by some wrong firmware configuration and not because of real corruption. However it is possible that I didn't understand your problem correctly . Commented Oct 16, 2012 at 13:48
  • The only thing that would fix a corrupted file system is a repair process which probably wouldn't even be successful. Changing config.txt is no use after the file system became corrupt. The change to config.txt may have caused the crash at shutdown, but the file system corruption is permanent. Unless you are suggesting that a driver is returning incorrect data from a perfectly sound disk. That is unlikely. Next time I will save a copy of config.txt. Commented Oct 16, 2012 at 13:59
  • 1
    @ScrollerBlaster What if the ext4 errors aren't real, but caused by overclocking and dodgy firmware? Commented Oct 16, 2012 at 14:00
  • 1
    @ScrollerBlaster: Ext4 filesystem is quite robust and it should be able to recover from unclean shutdown. Commented Oct 16, 2012 at 14:05

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.