[doveman2]

The problem being that the Pi may already be overclocked by the time it works out it needs to perform an update of the SD card (certainly if initial_turbo is specified) and would then have to modify config.txt in an overclocked state - thus writing to the SD card, and potentially corrupting config.txt - in order to disable overclocking for the next boot...

It seems that writing to the SD card is pretty safe provided that it has been initialised correctly, and the fact that it sometimes isn't initialised correctly is the crux of the problem. Automatically rebooting the Pi when the SD card isn't initialised properly is the workaround that works for me.

Ah, I forgot the overclock settings are stored in a file on the SD Maybe this should be moved to the ext4 partition on the USB then, which would allow the overclock to be enabled/disabled without writing/corrupting the SD.

---

The problem being that the Pi may already be overclocked by the time it works out it needs to perform an update of the SD card (certainly if initial_turbo is specified) and would then have to modify config.txt in an overclocked state - thus writing to the SD card, and potentially corrupting config.txt - in order to disable overclocking for the next boot...

You can disable overclock at runtime by switching governor from ondemand to conservative.
Either suggest people with sdcard corruption problems avoid initial_turbo, or include a (up to 60 second) delay before updating firmware if initial_turbo is in config.txt.

So if I don't have initial_turbo in my config.txt, what does that do? Does it mean the overclock only kicks in once XBMC has loaded and as the updating process is all done before XBMC loads, that the updating/writing will all be done with the overclock disabled? If initial_turbo is in config.txt, how would delaying for 60s before updating help as surely the overclock would be enabled from boot (and how would we tell it to delay for 60s before updating but not when there's no update to do anyway?)

As for disabling overclock at runtime by switching governor from ondemand to conservate, I'm not sure what you mean by "runtime" but presuming you mean whilst XBMC is running I'm not sure that would help avoid corruption during the updating process, as surely when it reboots to do the update it will re-enable the overclock based on the config.txt.