rpi-update

[cashaw]

OK, slowly getting there with getting my Rpi up and running.

But, when installing and running rpi-update for the first time, I am getting the below error.
I've done a google and can find no mention of it, so does anyone have any ideas ?

root@raspberrypi:/usr/bin# rpi-update
Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS
Performing self-update
Using ARM/GPU memory split of 192MB/64MB
We're running for the first time
Setting up firmware (this will take a few minutes)
Using SoftFP libraries
/opt/vc/sbin/vcfiled: error while loading shared libraries: libvchiq_arm.so: cannot open shared object file: No such file or directory
If no errors appeared, your firmware was successfully setup
A reboot is needed to activate the new firmware

[cashaw]

OK, not sure what the root cause of the problem is but typing 'ldconfig' solved the issue for me.

[grumpyoldgit]

There is at least one other thread that discusses this. Look towards the bottom of the thread.

http://www.raspberrypi.org/phpBB3/viewt ... led#p84715

[piglet]

I think the message is just saying that it couldn't find the file to check the timestamp. The end result was good - in my case that was the particular file I needed to run the edid parser, and after the update it was present.

[cashaw]

Thanks all !!!

Everything seems to be working fine. In fact I am amazed that within an hour, I have setup VNC, setup a wifi adaptor and it is doing exactly what I ask of it!

[beardy]

Sorry to hijack the thread: I'm having the exact same issue as the OP - the console output of rpi-update is exactly as above. Every time I run the updater on Debian, the result is a card which no longer boots, no OK light or anything. Running ldconfig prior to rpi-update doesn't seem to achieve anything in my case, and the libvchiq_arm.so is indeed missing, though its .a relative is present. Anyone got any ideas?

[RaTTuS]

I can confirm that as from nowish - running this will result in a unbooting sd card on debian
replacing the boot partition with the previous one will get it back working .

[RaTTuS]

and it's now working again

[beardy]

Isn't much of the firmware stored in the boot partition? Is there any benefit at all from running rpi-update and then restoring the older boot partition?

[mrlinux2u]

Also ran the rpi-update today and it resulted in a non-booting sd card, but I also found the /boot partition had become read-only for some reason.

The only way to fix it was to copy a backup /boot image to the sd card and all was well again.

Any ideas why /boot went read-only and is this cause of the non-booting?

[Threlkeld]

Just to say that I got this message and the update rendered my card unbootable also. Next time, I'll make sure I have a backup card ready before I start trying to update the one I'm using!
Or, if it is read-only, exactly how do I copy a backup boot image?

[dom]

and it's now working again

Well, the files haven't changed in the last couple of days, so it must be something wasn't written properly in the update procedure.
You can see when things change:
https://github.com/Hexxeh/rpi-update/commits/master
https://github.com/Hexxeh/rpi-firmware/commits/master

I have just tried an rpi-update (on raspian) and it worked fine.

So, when it fails make a note of what distribution you are running. How old the previous firmware was, and ideally take a copy of file in boot partition when it doesn't boot and again when you get it working and do a diff of the files.
Possibly a file is not getting written by the script, or it is getting corrupted.

[beardy]

It bricks 100% of the time for me. I've only ever done it on the 19/04 build of Debian, because I've only had my Raspi a couple of weeks. Out of curiosity I tried a vanilla image (as opposed to the one I've been fiddling around with) and running rpi-update on that straight away* and it still bricks. As I said above, I get the error about the libvchiq_arm.so file in both cases.

I haven't yet run a comparison between the before and after files, but will do so. Out of curiosity, would it be possible to unset the read-only status of /boot after the update?

* = well, after installing ca-certificates and git, since they're required.

[grumpyoldgit]

I am also on Debian6 19-4-2012 and have been attempting to install and run rpi-upgrade.
In the end I had to do

git
ca-certificates
upgrade
update
(not necessarily in that order)
before rpi-update would install and run properly.
I now do not get any error messages.

[beardy]

Interesting. My standard image has been updated & upgraded several times, as well as lots of other rubbish I've installed. But the result is always the same.

[texy]

It also bricked my SD card today. It's the only time I've used it.
Back to debian19042012 for me.
Texy

[SN]

I am going for consistency at the moment and steering well clear of rpi-update
I shall wait for the next proven release - either via an update (using rpi-update) or a fresh build

[grumpyoldgit]

I am not entirely sure what the rpi-update does but presumably it is just restricted to those few files in the FAT partition. If you copied fresh files to FAT, surely your remaining installation would remain intact. It would be interesting if someone could confirm that as it would save people a lot of time and effort.

[nick.mccloud]

It also updates module files aka drivers plus the developer sdk files - your own files remain untouched and in theory if the update is borked it should still startup as all the important stuff is in the kernel.

[bredman]

Is there a chance that the /boot partition is not being synced properly?

As far as I know, the only safe way to sync this partition is to reboot or halt. For the people who have a corrupted partition, how are you shutting down or rebooting? I hope you are not just pulling the power cable.

[beardy]

Haha! A measure of success! I ran the updater again, same process as usual, and again got a non-booting card. I checked whether /boot was read-only, and it wasn't. Putting the card back in the Raspi and powering it up after it had been in another machine brought up the test pattern for some bizarre reason (never had that before). I compared the old and new versions of start.elf and noticed a filesize difference - 1.95MB for the updated one, 1.92MB for the old one. I overwrote start.elf with the original version and now it boots perfectly - issues I was having previously have been corrected by the update, and it's working better than ever.

[dom]

@beardy
Do you have a config.txt? If so can you post it's contents.
HDMI or composite? Can you download latest start.elf from GitHub and compare it to (failing) version on sdcard.

[beardy]

@dom - I do have a config.txt, and the contents are:
config_hdmi_boost=4
hdmi_force_hotplug=1
hdmi_drive=2
... though when I've tried running the update on a virgin install, the config.txt file has been blank/non-existent. As you might have guessed, I'm using HDMI. I no longer have the non-working start.elf files because... er... they weren't working. I'll see if I can retrieve them and compare them.

[piglet]

I did an update yesterday evening. No error messages. sudo restart left me with what appeared to be an unresponsive brick. (At which point I remembered this thread and said a rude word). Power off and back on again and it booted with no problems.

[dom]

@beardy
It would be helpful if you could run rpi-update again.
I need to know if the new start.elf is incompatible with your setup, or whether sometimes start.elf gets corrupted when updating.

The start.elf you end up with should look identical to:
https://github.com/Hexxeh/rpi-firmware/ ... _start.elf
(assuming you were running with the 192M memory split originally).

You can download it for comparison if you click "view raw".