2

This card has been working well and is running Raspbian. I keep it well updated, although recently I had an issue where I had an error in the /var/lib/apt/lists/ and had to purge all those files before the last update.

I'm also using the 1000 clock speed with force_turbo, but this isn't supposed to invalidate the warranty.

Then today one of the kids wanted to "play games" on the RPi (it's connected to the TV and I usually just run headless). And it had a blank screen. Nothing particular had been done on the machine/drive, certainly no partition modifying operations.

I noticed my always-up terminal had an error:

pi@raspberrypi:/boot$ Write failed: Broken pipe

When I power-cycled it, I saw it was unable to boot.

I am able to boot another SD with an old Occidentalis image, so I think the hardware is OK.

I put the SD in my Ubuntu and set the config.txt back to 700MHz, but the problem persisted and I put the card back into the Ubuntu system and I seem to be unable to mount the second partition on that SD card. It should mount with ext3 or ext4 right?

This Sandisk 8GB card has been reliable (I bought 2 2-packs, so I have 4 of them with various distros on them) - I guess it's possible that the problems with the apt-get file lists might have been a sign that something was physically failing.

So the culprits could be:

  • Overclocking
  • Bad card
  • a hack? (it's still set as pi/raspberry, but shouldn't be accessible to the Internet - I only have some port forwarding to my Panasonic IP cameras)
  • something else?

Looking for some ideas if there's something I need to avoid before I reformat and rebuild because I'm going to use the latest image and manually rebuild the system.

UPDATE: I did apparently void the warranty by overclocking with some incorrect settings when the authorized turbo mode was first publicized - not sure what I did, but I put on Raspcontrol and it was from there I saw that one of my RPis had a valid warranty and one did not. I assume this contributed to the SD failures (I had one since this one). I no longer overclock and am waiting to see improvements from the RPF for the USB and SD behavior.

Improve this question
5
  • Overclocking and Overvolting may not void the warranty, but it doesn't mean that the resulting system will be stable. You may want to back off a little on the amount of overclocking/volting applied to improve system stability. Also anytime you don't have a clean shutdown you run the risk of filesystem damage that prevents the system from booting.
    – Steve Robillard
    Sep 23, 2012 at 20:03
  • 1
    Please post some logging, otherwise we can just try to guess. If you plug HDMI/composite, can you see it booting, or the problem is in the bootloader? An hardware-independent alternative could be also to create an ARM virtual machine (maybe with qemu?) and try to boot the SD with that to see what happens.
    – Avio
    Sep 23, 2012 at 21:20
  • @SteveRobillard THe FAT boot partition seems fine, but I think the root filesystem is bad - I think it crashed sometime last night in some way which corrupted the partition. I can't mount it on another machine, so I'm not sure how to find any logs of the events leading up to the issue.
    – Cade Roux
    Sep 24, 2012 at 0:02
  • @Avio Is there any way to capture the log of the boot process you see on screen to the FAT partition when it's not getting to the point of booting from the root fs? The "problem reading SD status register is the first error" but other errors are shown when trying to mount root.
    – Cade Roux
    Sep 24, 2012 at 0:03
  • Well, there are ways to do that, but actually there isn't any "easy enough" way to capture kernel's early boot messages. So probably your best options are: 1) create an ARM virtual machine and try to see what the kernel says in there. And 2) simply connect a monitor to the raspberry and take some photo of the boot process.
    – Avio
    Sep 24, 2012 at 8:49

2 Answers 2

Reset to default
2

Just an idea. I don't know if this is your problem, but it is worth a try.

There are known cases of corruption of the filesystem when overclocking with the new "turbo mode". The theory is that the timings for the communications with the SD-card is coming out too short due to the BogoMips value being produced at the slowest clock rate. Read more about it here: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=29&t=6201&start=425.

If you are experiencing these problems you will have errors in /var/log/messages, but since your filesystem is most likely corrupted, you are not able to inspect this file, so the first step would be to try to repair it from another Linux machine. However, if the file system is heavily corrupted, it might not be possible to fix it at all. If that is the case you have to start all over again with a new image.

If you manage to sort it out. There is a new setting for /boot/config.txt called initial_turbo that enables the full clock rate for the given number of seconds after boot and this will make the BogoMips value come out right.

initial_turbo=60

So after you have run rpi-update, you can add it to config.txt, reboot and your SD-card will probably work from now on.

Improve this answer
4
  • I think it probably is the overclocking then - it was shortly after I decided to start using the new settings. I still have the problematic card in case I want to investigate before overwriting it, but I loaded a new image on another card. I'll have to look in to the new settings to make sure I don't whack this card.
    – Cade Roux
    Oct 6, 2012 at 2:23
  • Without reading the forum post, I'm sceptical. The SD card communication is a hardware implementation and so I doubt it could be affected by a Linux parameter. Furthermore, everyone knows BogoMIPS is not very useful...
    – Alex Chamberlain
    Oct 6, 2012 at 9:25
  • So you mean that the mmc driver is not involved in the data transfer to/from the SD-card? Also (as you probably mean) BogoMips is not a very useful way to compare the performance of different machines, but that is not what it is intended for either. Its purpose is to let the kernel adjust its non-busy delay loops.
    – Joppe
    Oct 6, 2012 at 15:15
  • You can read more about the purpose of BogoMips here clifton.nl/bogo-faq.html.
    – Joppe
    Feb 14, 2015 at 13:03
1

I had the exactly same problem. I ended up replacing PSU, replacing SD-card, shorting my polyfuses when finally I managed to find the issue.

It was the ethernet cable, it was too long. Replaced it with a shorter one and it works without an error.

Improve this answer

Your Answer

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

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