And that one seems, to be caused by an exemplary error, that is bad RAM in just one part.kraz wrote:Sorry, my link was wrong re the other user experiencing similar issues.
I meant this one:
http://www.raspberrypi.org/phpBB3/viewt ... 28&t=10581
also I always reboot cleanly my pi. Despite that fact, corruption arrises.
I had similar issues with SD card corruption. Two things I noticed: -kraz wrote: I understand that this may very well be an isolated incident or at least a rare case.
I consider the firmware to be the bootrom (built into the GPU), along with the files loader.bin, bootcode.bin, and start.elf that reside in the boot partition (/boot in Linux).kraz wrote:
Now maybe I am misunderstanding what "firmware" actually refers too in RasPi land. My understanding is that it is the bootcode.bin file present on the boot partition of the image.
Please correct me if I am wrong.
Are you able to force the failure of a card in a running system? My (very unscientific) approach was to boot to a command prompt, run 'find /' or 'ls -lR /' in a terminal (or on the console).kraz wrote: Why was this marked as solved? My problem remains.
My bad, removed the offending "(solved)" until all problems in this thread are solved.kraz wrote:
Why was this marked as solved? My problem remains.
IMHO They're doing early adopters a disservice because in many cases updating the firmware actually solves many problems people are experiencing. If you are having problems then dont be afraid to update the firmware!kraz wrote:The last item in the Raspbmc FAQ states that they are using a recent firmware and that generally I should not be mucking around with it.
http://www.raspbmc.com/wiki/user/freque ... questions/
You realize the 'latest firmware' is not necessarily the latest. In fact I ran rpi-update last night and it updated some stuff. Images can get out of date particularly in regards to firmware quite quickly.I am also experiencing the same issue with the beta wheezy image which AFAIK ships with one of the latest firmware.
I believe you are right... It resides in /boot or something. This means that everytime you re-image your SD card you need to redo the firmware updates. Unless you back up your image somehow.Now maybe I am misunderstanding what "firmware" actually refers too in RasPi land. My understanding is that it is the bootcode.bin file present on the boot partition of the image.
Please correct me if I am wrong.
Sounds promising.kraz wrote: So far the /root filesystem has survived a dozen reboots which is pretty good and I am not seeing anything peculiar in dmesg yet.
Hopefully I've cracked it. I'll keep you posted.
mahjongg wrote:If the PI ever boots, never just pull the plug afterwards, that will almost guarantee damage to the card contents!, as its last writes are probably still in the cache memory and will be lost when you pull the plug (mains or otherwise, doesn't matter) always do a software controlled shutdown, so in the shell do a:
sudo shutdown -h now
or shutdown from the GUI (start the GUI with startx)
Only pull the plug when the software says its ok to do so.
My extra precaution with the power strip is just that. Extra precaution.Alas... after only a few reboots of the system (and by reboot I certainly mean something gentle such as sudo /sbin/init 6 or shutdown -r NOW)
I read in a recent thread (which unfortunately I can't find now) that SD cards can be destroyed if they lose power at an inopportune moment during a write operation. Perhaps relatively unlikely, and I guess it might depend on the card's low-level firmware.kraz wrote: ...waiting for the machine to halt before powering it off is not entirely required with any journaling filesystem such as JFS, ext3 or ext4.
Is the corruption still there, or has your Pi been stable?kraz wrote: Still hacking at it and I'm going o try that newest firmware with dom's latest commit.
Even a non-journaled filesystem *SHOULD* be safe if it has had no writes for a few minutes because sync is (or should be) scheduled to run quite frequently.Besides, ext4 being journaling filesystem, it is designed to prevent filesystem corruption in such cases when the machine crashes or loses power in the middle of a write operation. In all fairness waiting for the machine to halt before powering it off is not entirely required with any journaling filesystem such as JFS, ext3 or ext4.
Users browsing this forum: asandford and 25 guests