Rpi's that wont boot

[321]

I have some rpi B's that wont boot up with the latest OS's, yet will boot up with some sd cards that were in the rpi when they were hacked.
This seems to be a firmware issue. What can I do?

[DougieLawson]

Get the very latest Raspbian or NOOBS 2.1 from https://www.raspberrypi.org/downloads/raspbian/ or https://www.raspberrypi.org/downloads/noobs/

That should boot on ANY raspberry.

[321]

Havent tried noobs, but I've got most of the rpi distro's since they were released.
I've got two possibilities.
Either the FAT is being modified when the img is written and this is not being picked up by my AV. Hashing the fat img doesnt show any differences.
Maybe the pc's uefi/bios is compromised which will not get picked up by the AV.
Or
The RPI firmware has been messed with.

If its the rpi firmware, how can I verify its ok? Can I hook it up to another pi and access the firmware through the gpio pins for example, like you can flash some pc bios using spi?
Is there any way I can hash the firmware like I can download the uefi/bios and hash it with flashrom or any other file for that matter?

[davidcoton]

ALL the Pi's software and firmware is on the SDCard. Nothing (except the most primitive bootstrap in masked ROM) is on the SOC. So the firmware hasn't been "messed with". Any new Raspbian image should run on any Pi (IIRC there was briefly one recent image that didn't boot properly in some circumstances, but it was replaced very quickly). If not, there's a problem either with the image itself or a hardware problem (SDCard, PSU, microUSB cable, etc).

[321]

So what can I look for on the SD card then?

[rpdom]

If you have installed plain Raspbian or Raspbian Lite without using NOOBS, you can just plug the card into any PC and you should see a small FAT partition of about 80MB with the following contents:

Code: Select all

bcm2708-rpi-b.dtb       bcm2710-rpi-cm3.dtb  fixup_cd.dat  kernel7.img       start_cd.elf
bcm2708-rpi-b-plus.dtb  bootcode.bin         fixup.dat     kernel.img        start_db.elf
bcm2708-rpi-cm.dtb      cmdline.txt          fixup_db.dat  LICENCE.broadcom  start.elf
bcm2709-rpi-2-b.dtb     config.txt           fixup_x.dat   LICENSE.oracle    start_x.elf
bcm2710-rpi-3-b.dtb     COPYING.linux        issue.txt     overlays

Those are all the files needed for the Pi to start booting into Linux. Some might not be needed, depending on the setup and model of your Pi (kernel.img is for Pi 1 and Zero, kernel7.img is for Pi 2 and Pi 3, for example).

[DougieLawson]

Those are all the files needed for the Pi to start booting into Linux. Some might not be needed, depending on the setup and model of your Pi (kernel.img is for Pi 1 and Zero, kernel7.img is for Pi 2 and Pi 3, for example).

Don't forget that you also need /lib/modules/$(uname -r) that matches the kernel.img or kernel7.img that you're booting. Else you get a Linux kernel running that can't work with any of your hardware.

[jamesh]

Easiest thing is just to reinstall the OS from scratch. That way you can be sure you have a valid SD card.

[321]

I have been reinstalling the OS's from scratch with Win32DiskImager but some just dont boot up, thats why I have posted here, I'm trying to find out why they dont boot. Now if everything including the firmware ie the RPI equivalent of a bios is also in this FAT partition then I need to find out what files are different, so I'll go through these and hash them and then use a live cd to hash the files from a mounted img. That way I can eliminate the writing process on Windows.

One thing I have noticed is sometimes when writing to the SD card, the speed of the write is less than a MB in speed, whilst other times I'm writing to the same SD card it flies along at around 20MB/s. Its really weird not to mention variable, I dont think the AV is scanning the SD card as its being written, but when I touch files the AV does seem to upload something about the img zip files to themselves which is really noticable as these files are so big compared to most files.

I've only been using lite at the moment as its smaller and quicker to write to the SD card as well.


As some of these pi's have not had rpi-update run on them since I got them could that be an issue preventing them from booting when looking at this thread? viewtopic.php?t=58963

I cant honestly say whether all of them have had an apt-get update run on them either because I would typically work on one pi, which means its connected to the net and would have had apt-get update run on it, and once the system is set up how I like, I'd make a copy of the image and then burn it DVD for a backup and then to other SD cards plugged into other pi's, so these "offline" pi's wouldnt have been online to have had anything updated on its chip. But if all the firmware is contained in the fat partition and loaded at boot up, then I'm still puzzled.

[DougieLawson]

Buy some new factory fresh, branded, genuine, full price SDCards. Stop using the cheap Chinese fakes or any worn out ones.

You may want to run h2testw to check whether your cards are fake or worn out.
https://sosfakeflash.wordpress.com/h2testw/
https://sosfakeflash.wordpress.com/2008 ... it-drives/

[texy]

As some of these pi's have not had rpi-update run on them since I got them could that be an issue preventing them from booting when looking at this thread? viewtopic.php?t=58963
.

The Pi itself doesn't have any memory on it that can be reprogrammed or updated via rpi-update or any other method. All the updatable code is on the SD card only.
If you have an SD card that works on one pi, it should work on another. Once you have a working SD car, pop it into the other pi's you are testing. If they don't boot up then they (probably) have a hardware issue and should be considered trash.
Also to confirm that if you have recently downloaded Raspbian it will work on any Pi version.
Texy

[jahboater]

Sounds like you are other-thinking the problem.

This Raspbian image has been available since 1st November last year and I am sure that quite literally millions of users have downloaded and installed it.
If there were a problem it would have come to light long ago. Also the supplied images are well tested, I would be astonished if I downloaded one and it didn't boot.

As Dougie and JamesH say, get the latest image and write it to a decent SD card and it will work.

[davidcoton]

This doesn't appear to fit your situation, but it's still worth saying: it is possible that old images won't run on newer hardware. The firmware has been updated as different RAM (for example) has been introduced to manufacture. It is important to test with a new fresh Raspbian before considering the possibility of hardware failure.

It is also important to test with a known good PSU (for a Pi3B, capable of 2.4A at 5V, as measured at the Pi). With a known good (short and thick) microUSB cable. Something that works on a Pi0, or even a Pi3B with no peripherals, may not work when a USB HDD is added.

[mahjongg]

Don't forget to read the boot problem sticky. It will enlighten you.
viewtopic.php?p=437084#p437084

[FTrevorGowen]

I have some rpi B's that wont boot up with the latest OS's, yet will boot up with some sd cards that were in the rpi when they were hacked.
This seems to be a firmware issue. What can I do?

What model of "rpi B's" (ie. B1, with or w/o USB polyfuses, or B2).
Are the booting "sd cards" SD, SDHC (SDXC) and what size?
Similarily for the "non-booting" cards.
What did you mean by "when they were hacked"?
Any signs of mechanical stress/damage to the SD card socket on the (mainly) non-booting Pi's? (The sockets did fail on some "early B & A" Pi's ) Were uSD(HC) cards + adapters in use?
Trev.
** eg. as shown here:
http://www.cpmspectrepi.uk/raspberry_pi ... ilure.html

[321]

What model of "rpi B's" (ie. B1, with or w/o USB polyfuses, or B2).
Are the booting "sd cards" SD, SDHC (SDXC) and what size?

http://www.raspberrypi-spy.co.uk/2012/0 ... d-version/

pi@raspberrypi:~ $ cat /proc/cpuinfo
processor : 0
model name : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS : 697.95
Features : half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xb76
CPU revision : 7

Hardware : BCM2708
Revision : 100000f
Serial : 0000000047c186ea
pi@raspberrypi:~ $

The above is from one of the piB+'s I'll have to check the rest when I can get onto them and I'll post if there are any differences as I buy in batches incase of a failure.

All class 10, different brands & from different sources online as well as visiting different retailers after reading this. https://www.bunniestudios.com/blog/?p=3554
The microsd teardown is also worth reading. http://www.bunniestudios.com/blog/?page_id=1022
PCWorld, Tesco & Sainsbury only seem to sell Sansdisk products in-store now so theres no other brands I can obtain offline but I'm always keeping my eyes open, but Sansdisk are not excluded from the inconsistent write speeds.

What did you mean by "when they were hacked"?

The inconsistent writing to the SD & MicroSd card is the clue there's something up as noted in the BunniesLab blog posting, but I'm trying to establish where the problem is, ie is it the SD card(s), my windows software or raspbian software, or my PC's, because despite numerous reinstallations of different versions of the UEFI/bios for my motherboards, along with DD /dev/zero hd's and then reinstalling OS's or even trying to boot from silver (unburnable) linux live cd's obtained from the front of linux magazines, the motherboards are still not right, in that in one example my blueray and dvd burners will only work when plugged into two out of six specific sata ports on the motherboard on one computer and they didnt use to do this.

Only by unplugging devices (HD's, graphics cards, usb printers & other usb devices) which are normally plugged in all the time and left alone for months on end and then plugging them into different ports to mix things up did I start to spot this, same goes with moving the add on graphics card from one pci slot to another. It seems anywhere you can update the firmware without having to short/jump any pins, theres a risk, especially when looking at Flashrom which I discovered recently.

Some of the things that have happened are HD's have been encrypted including one running my firewall, pwd's changed and to be honest no telling what my computers have been up to or sending out.
No physical damage although I have noted the Pi3 doesnt have any locking mechanism when inserting the microsd card.
And thats just an example of the online stuff. I've found one purchase, a blue ray burner I made from a UK retailer online, is not even sold in the UK when I contacted the manufacturer about ways to verify the firmware, so I'm wondering if there has been some sort of MITM on some of my online purchases.
Someone has also been running a stingray/IMSI interception/fake mobile cell tower when I live. I noticed this when I bought a new basic Nokia 105 mobile phone and was getting a full signal. The problem is here in the countryside, the mobile phone tower is some distance and we normally get 0 or 1 bar of signal strength. You would not spot this in a town or city as your mobile will swap towers to balance the traffic flow, unless you download an android app which can let you override this and fix to particular mobile tower. Besides you can build these fake mobile phone towers for under £100 now, so well within the reach of anyone. Look for Software Defined Radio if interested.

I found & watched this yesterday, its about stuxnet https://www.youtube.com/watch?v=0X0Teo5AxQM

Personally I think theres newer versions of this stuxnet code running wild in millions of systems which could explain the news going on about Russian hacking so much, banks like Tesco's getting hacked along with other high profile companies like Yahoo, but as no company is legally obliged by law to announce they have been hacked and they may not always know they have been hacked, its not something we will hear much about until said company is confident their systems are secured and want to divulge this news.

[Heater]

321,

That was an amazing brain dump of all your troubles in PC world.

I could not follow all of it but if 1% of what you say is happening to you then I guess writing a Raspi SD card is the least of your worries.

[321]

Someone has been trying to put me out of business for a long time now, but these things are sent to test us.

What I have found useful, is the laymans way to spot this sort of stuff happening, but you need to be observant, little clues could be extra light activity on things like your switches, ethernet powerline adapters, your hard drive lights flashing for longer than normal before the uefi/bios screen shows up. What ever this malicious code is its rewriting the firmware of some hard drives as I tested one USB stick I suspected in an old pc built in 2004 and as that bios stops on a floppy disk error ie I took the floppy disk drive out, you can see the make and model of the hard disk has been changed. You cant see this now with UEFI/bios because of the way its designed to work, but it also works on the rpi's so I'm concentrating on trying to make my pi's secure because sometimes less is more.

[Heater]

321,

I have no idea what your business is, but yeah, that is what competing businesses do.

Now, you talk of floppies, and USB sticks and hard drives in a very confusing way. But I find it vanishingly unlikely that anyone has hacked the make and model of your hard disk.

All sounds a bit paranoiac to me.

Perhaps the best thing is to order a new Pi with ready made SD card from a reliable source.

Throw all your other computers in the crusher because they have obviously been compromised.

[321]

So I'm looking at this website http://www.raspberrypi-spy.co.uk/2012/0 ... d-version/
and its suggesting the piB's should be

Model B Rev 2 512MB 000d
Model B Rev 2 512MB 000e
Model B Rev 2 512MB 000f
Model B+ 512MB 0010
Model B+ 512MB 0013

and my hardware revision code is showing 100000f, how can I check this is correct? This is from one running the latest lite downloaded from the website last night.

On the top of the pi its got
RaspberryPi
(c) 2011.12
e1.

So I'm not sure if the cat /proc/cpuinfo shows information that can be modified or not.

[Heater]

No idea.

As far as I know there is nothing on a Pi, outside the SD, that can be "hacked".

Except some talk of "fuse" bits that may get blown if you overclock the thing above spec. I have never paid any attention to such things.

By the way. How do you know any of your Pi has been hacked?

Make yourself a good SD card image and I'm sure those old Pi will boot just fine.

[rpdom]

my hardware revision code is showing 100000f, how can I check this is correct?

That would be a "Model B Rev 2 512MB 000f" possibly with the warrantee bit set to say it has been overclocked beyond the recommended at some point.

Try this to see what model it is (if running the right firmware)

Code: Select all

echo $(cat /sys/firmware/devicetree/base/model)

[321]

Code: Select all

echo $(cat /sys/firmware/devicetree/base/model)

Raspberry Pi Model B Rev 2

Ok, so the 1 at the beginning of the revision code is the cpu clocking bit when I have over clocked it. Thats understandable as I have them ticking over at 2/300Mhz with the OnDemand governor up to 1Ghz before becoming unstable.

[Heater]

Hmm...Am I to understand you have previously overclocked Pi that no longer boot with new Raspi images on SD cards?

I have no idea if or why that might matter.

But by some rare chance there might be a clue there.

It would be odd to find that you have hacked yourself

[321]

Some Pi's work with what I suspect is a hacked version of Raspbian on a SD card (lets call this Raspbian & SD card setup A), but when I put a new SD card in with the lastest copy of Raspbian (lets call this setup B) the pi's dont boot up, I dont see the rainbow screen.

Some other Pi's I have that run the new SD cards (setup B) with the latest version of Raspbian lite also run the suspected hacked SD cards (setup A)

Thats what I have observed at the moment, and I'm still trying to figure out where its going wrong.

So yes its possible I may have hacked myself, this is what I'm trying to figure out.