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.

ScrollerBlaster
  • 489
  • 1
  • 5
  • 12
  • 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? – Krzysztof Adamski Oct 16 '12 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 – ScrollerBlaster Oct 16 '12 at 11:12
  • Did you do anything other than editing config.txt file last time it was able to boot correctly? – Krzysztof Adamski Oct 16 '12 at 14:03
  • An new image first, probably a later build. Then I ran raspi-config and chose Turbo. – ScrollerBlaster Oct 16 '12 at 16:55

1 Answers1

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).

Community
  • 1
Krzysztof Adamski
  • 9,615
  • 1
  • 37
  • 53
  • Are you suggesting that restoring config.txt in any way would assist in repairing a corrupted root file system? – ScrollerBlaster Oct 16 '12 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 . – Krzysztof Adamski Oct 16 '12 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. – ScrollerBlaster Oct 16 '12 at 13:59
  • 1
    @ScrollerBlaster What if the ext4 errors aren't real, but caused by overclocking and dodgy firmware? – Alex Chamberlain Oct 16 '12 at 14:00
  • I did not consider that option, being new to over-clocking. An ext4 corruption would not be unusual if the OS doesn't get to shutdown gracefully. So it appears to be the most likely cause? How do you check your firmware? Guess I can Google. – ScrollerBlaster Oct 16 '12 at 14:02
  • 1
    @ScrollerBlaster: Ext4 filesystem is quite robust and it should be able to recover from unclean shutdown. – Krzysztof Adamski Oct 16 '12 at 14:05
  • Now I'm intrigued. I am willing to experiment at the risk of hosing another system. Any suggestions for the greater good of community learning? – ScrollerBlaster Oct 16 '12 at 14:06
  • The Raspbian version I had the problem with was shipped by Maplin. I have since downloaded the 18 Sept build, so I must have the best firmware now. – ScrollerBlaster Oct 16 '12 at 14:19
  • @ScrollerBlaster: Chances are probably small but you could try to reproduce the problem once again. I doubt it was purely because of overclock values you where trying to set but you could try to set them one more time. – Krzysztof Adamski Oct 16 '12 at 16:40
  • One further view into this: What if there was a problem with the card that caused to corruption and the initial crash? Quite a bit of luck to have it happen at such a confusing time :) – XTL Oct 19 '12 at 12:17