Do I still need rpi-update if I am using the latest version of Raspbian?

Question

I have a 512MB Pi. I am trying to make sure I am getting the most out of it. I just downloaded the latest version of Raspbian and installed it on the Pi. Do I also need rpi-update? Is rpi-update meant for upgrading from one version of Raspbian to the next?

Answer 1

"In normal circumstances there is NEVER a need to run rpi-update as it always gets you to the leading edge firmware and kernel and because that may be a testing version it could leave your RPi unbootable". https://www.raspberrypi.org/forums/viewtopic.php?p=916911#p916911 Even the rpi-update documentation now warns "Even on Raspbian you should only use this with a good reason. This gets you the latest bleeding edge kernel/firmware." sudo apt-get update; sudo apt-get install --reinstall raspberrypi-bootloader raspberrypi-kernel will put it back to the latest supported kernel/bootcode.

I think you might be conflating two different operations.

• rpi-update is a tool to upgrade the firmware for your Raspberry Pi. Firmware is a small package of code that usually lives on a special chip of a computer that helps the software know how to talk to the hardware. However, in the case of the Raspberry Pi, the firmware will live on the first partition of the SD card.

• Raspbian is an operating system or the core software for your Raspberry Pi. Software (including the OS) lives on second partition of the SD card and is all the stuff that gets executed when you use your device.

Both of these need updating independently. For convenience, the rpi-update tool is included in the Raspbian distribution of Linux because it is a useful software tool that manages the firmware of your Pi's. You should only run it if you need to, as per the warning above! Do not use it regularly. Separately, you need to keep your software up to date using the standard Debian software management tools like sudo apt-get update && sudo apt-get upgrade.

Each of these functions is separate, and updating one will not update the other. Upgrading your distribution to the latest software packages might get you a new version of rpi-update, but unless you RUN rpi-update your firmware will not get updated.

Since the place the firmware is stored is actually flashed to the first partition of the SD card (sort of like a BIOS), you will not need to run this on every device. Once you load a new version of software or firmware onto an SD card, any device you plug that card into will be running that version.

Answer 2

raspbian package repo contains raspberrypi-bootloader package which contains firmware, kernel and kernel modules that rpi-update downloads. The version is not the latest, but files should be fine and stable. Now it shows a 20130902 version, so it's about 2 months old. The package is installed by default and is updated when a new version arrives in repo.

So you basically do not need rpi-update if you don't want the bleeding edge firmware and kernel, just stick with apt-get - it will update kernel, firmware and modules on its own. Actually I cannot find rpi-update on my Pi at all.

Answer 3

Meanwhile the kernel is part of the raspberrypi-kernel-package in Raspbian.

So rpi-update is not needed anymore to update the kernel.

There are several kernels in the package, that means it works on every hardware-version of the Pi (ARMv6, ARMv7 and ARMv8)

Just use this fancy one-liner to keep your Pi up-to-date:

apt-get update && apt-get dist-upgrade && apt-get clean

If you are worried about not-needed stuff, add this:

apt-get autoremove --purge && apt-get remove `deborphan` --purge

Answer 4

The answer marked as correct is in fact outdated, and in a problematic way: rpi-update will update the firmware to the latest published version, which has to be considered "not stable". So following the recipe given you might end up with an unstable system (has happened to me ;) ).

Answer 5

RPI-Update is used to update the Raspberry Pi to the latest version. You don't really need it, but it is a good idea to keep the Raspberry Pi updated. So you might as well install rpi-update.

Also if you don't really need your Raspberry Pi on the latest bleeding edge updates. Rather use the following command. This will update all installed packages to their stable current version

sudo apt-get update && sudo apt-get upgrade

Answer 6

If you look at your SD card after flashing it with the latest version of Raspbian you will actually see 2 partitions on your SD card. The first one is where the firmware is stored and the second one will be where the operating system (Raspbian) and your files are stored.

Therefore if the firmware on your SD card (first partition) is up to date then any Raspberry Pi using that SD card will be running the latest firmware version.

You can even update the firmware on the SD card by updating the files in that first partition with a Windows computer for example. (See: 3.2 Get the latest firmware version)

If the Raspbian team is using the latest firmware on their distribution though, that is a different question. In my opinion, to make sure you are running the latest firmware on your Raspi I would still use the rpi-update tool with any operating system distribution you choose.

In short, I would say the following phrase: Update the card, run everywhere.

Answer 7

I want to explain in detail what and why and what was missing in other answers, so a comment was not enough.

I can only state the same as others: Do not use rpi-update. As of 2023-07-23 (d873621b557928d397f3aa9707ce57d3ff313752) it made my PI400 behave sluggish. To get back into a stable clean system I had to use following commands:

sudo apt install --reinstall rpi-update raspberrypi-bootloader raspberrypi-kernel

Reboot

sudo rm -f /boot/.firmware_revision

Afterwards the system worked again as before rpi-update.

Full story and caveats see below

---

TL;DR

---

What happened

I ran rpi-update. The PI rebooted and came up again. However some commands were slower than expected. For example, exiting a program back to the command prompt took .. time .. sometimes. Like some sync going on behind. Looks like the filesystem driver. Also name resolution (the PI uses my router) was slower than expected, too. So I suspect some delay in networking.

I am a die-hard commandline user, so I do not use the GUI/X11.

However I was able to max out the network interface (utilize the full 100 MBit/s of my Internet line), so perhaps that is just subjective. But I wanted to see what to do, came here and did not find the full truth. Therefor I write this here as a reminder to myself.

The full truth is in here

What rpi-update does

As of 2023-07-23. The URLs are the browsable version, not the version really downloaded

It updates itself from https://github.com/raspberrypi/rpi-update and installs that version in /usr/bin/rpi-update

It installs the latest firmware from https://github.com/raspberrypi/rpi-firmware

Then it tags the installed firmware in /boot/.firmware_revision which contains the commit SHA d873621b557928d397f3aa9707ce57d3ff313752.

This refers to the bootloader and the kernel. The kernel installed was 6.1.39-v8+ (it's a PI400).

Note for rpi-update to work correctly, you must have mounted partition 1 of your SD-card correctly to /boot. Like that:

# grep /boot /proc/mounts 
/dev/mmcblk0p1 /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,flush,errors=remount-ro 0 0

It may look a bit different at your side. Usually /boot is mounted after you booted the PI. But who knows what happened since then?

So if in doubt first reboot your PI, then use rpi-update. If things go catastrophically wrong, see below.

What does this mean?

cat /boot/.firmware_revision gives d873621b557928d397f3aa9707ce57d3ff313752 . This translates to commit https://github.com/raspberrypi/rpi-firmware/tree/d873621b557928d397f3aa9707ce57d3ff313752

This is true for 2023-07-23. Tomorrow things may be something completely different.

This number is a git SHA1, which means, it uniquely identifies the installed firmware. This SHA is a cryptographic hash which means, with the help of git it authenticates all the files. So if you have the SHA and anybody changes a single bit in the files, you can detect that (as long as nobody breaks this specific SHA).

I do not know how to authenticate the SHA itself, as, according to GitHub, this SHA itself is not signed. However having it signed still does not mean it is authentic, for this you must authenticate the signature and the process, which created the signature. Cryto ain't easy. So listing the SHA somewhere safe (couch .. blockchain .. couch) usually is a better way to go today than using some untrusted keyservers.

How to check

There is a tool called debsums which you can install with sudo apt install debsums. This tool checks the integrity of your install.

Sort of. If you are not paranoid does not mean they are already after you. So if debsums tells everything is ok this does not ensure, that your running kernel is not compromized and cheats to the user space programs like debsums, so these cannot find any fault. But that's unlikely .. today .. perhaps.

I do not use debsums -c in following, because I wanted to show the FAILED.

# debsums | grep -v 'OK$'
/boot/fixup.dat                                                           FAILED
/boot/fixup4.dat                                                          FAILED
/boot/fixup4cd.dat                                                        FAILED
/boot/fixup4db.dat                                                        FAILED
/boot/fixup4x.dat                                                         FAILED
/boot/fixup_cd.dat                                                        FAILED
/boot/fixup_db.dat                                                        FAILED
/boot/fixup_x.dat                                                         FAILED
/boot/start.elf                                                           FAILED
/boot/start4.elf                                                          FAILED
/boot/start4cd.elf                                                        FAILED
/boot/start4db.elf                                                        FAILED
/boot/start4x.elf                                                         FAILED
/boot/start_cd.elf                                                        FAILED
/boot/start_db.elf                                                        FAILED
/boot/start_x.elf                                                         FAILED
/boot/bcm2710-rpi-2-b.dtb                                                 FAILED
/boot/bcm2710-rpi-3-b-plus.dtb                                            FAILED
/boot/bcm2710-rpi-3-b.dtb                                                 FAILED
/boot/bcm2710-rpi-cm3.dtb                                                 FAILED
/boot/bcm2710-rpi-zero-2-w.dtb                                            FAILED
/boot/bcm2710-rpi-zero-2.dtb                                              FAILED
/boot/bcm2711-rpi-4-b.dtb                                                 FAILED
/boot/bcm2711-rpi-400.dtb                                                 FAILED
/boot/bcm2711-rpi-cm4.dtb                                                 FAILED
/boot/bcm2711-rpi-cm4s.dtb                                                FAILED
/boot/kernel8.img                                                         FAILED
/boot/overlays/README                                                     FAILED
/boot/overlays/allo-katana-dac-audio.dtbo                                 FAILED
/boot/overlays/i2c-fan.dtbo                                               FAILED
/boot/overlays/i2c-mux.dtbo                                               FAILED
/boot/overlays/i2c-pwm-pca9685a.dtbo                                      FAILED
/boot/overlays/i2c3.dtbo                                                  FAILED
/boot/overlays/i2c4.dtbo                                                  FAILED
/boot/overlays/i2c5.dtbo                                                  FAILED
/boot/overlays/i2c6.dtbo                                                  FAILED
/boot/overlays/jedec-spi-nor.dtbo                                         FAILED
/boot/overlays/miniuart-bt.dtbo                                           FAILED
/boot/overlays/mipi-dbi-spi.dtbo                                          FAILED
/boot/overlays/pitft28-resistive.dtbo                                     FAILED
/boot/overlays/pitft35-resistive.dtbo                                     FAILED
/boot/overlays/spi3-1cs.dtbo                                              FAILED
/boot/overlays/spi3-2cs.dtbo                                              FAILED
/boot/overlays/spi4-1cs.dtbo                                              FAILED
/boot/overlays/spi4-2cs.dtbo                                              FAILED
/boot/overlays/spi5-1cs.dtbo                                              FAILED
/boot/overlays/spi5-2cs.dtbo                                              FAILED
/boot/overlays/spi6-1cs.dtbo                                              FAILED
/boot/overlays/spi6-2cs.dtbo                                              FAILED
/boot/overlays/uart2.dtbo                                                 FAILED
/boot/overlays/uart3.dtbo                                                 FAILED
/boot/overlays/uart4.dtbo                                                 FAILED
/boot/overlays/uart5.dtbo                                                 FAILED
/usr/bin/rpi-update                                                       FAILED

Note that you don't see /boot/.firmware_revision in there, as this is not managed by packet management.

How to revert

Run this as root, you can use sudo -i to change in root context

First, do a reboot of your PI to make sure, it is in the right condition:

reboot

Then revert back to the stable firmware:

apt update
apt install --reinstall rpi-update raspberrypi-bootloader raspberrypi-kernel

Don't panic! This outputs a lot of things ("Diversion") I could explain, but these is not relevant here and a Debianism. Just leave it time! It takes more than 5 minutes and slowly outputs its progress.

Do not interrupt the process! Afterwards check, that things are sane again:

# debsums -c
#

This should not output anythings. If it does print some lines, be sure that it comes from something different than the installed code.

You can find the package affected with dpkg -S ENTRY where ENTRY is one of the lines from debsums. Example:

# dpkg -S /usr/bin/rpi-update
rpi-update: /usr/bin/rpi-update

Then you can list all the files of a package with dpkg -L PACKAGE. Example:

# dpkg -L rpi-update
/.
/usr
/usr/bin
/usr/bin/rpi-update
/usr/share
/usr/share/doc
/usr/share/doc/rpi-update
/usr/share/doc/rpi-update/LICENSE
/usr/share/doc/rpi-update/changelog.gz
/usr/share/doc/rpi-update/copyright

Or get some information about package with apt-cache show PACKAGE. Example:

# apt-cache show rpi-update
Package: rpi-update
Version: 20210618
Architecture: all
Maintainer: Serge Schneider <[email protected]>
Installed-Size: 31
Depends: binutils, curl
Homepage: https://github.com/Hexxeh/rpi-update
Priority: optional
Section: admin
Filename: pool/main/r/rpi-update/rpi-update_20210618_all.deb
Size: 7920
SHA256: 2ba9bb67f738e55e5cc01d824f5e06a7b2a21be08335a4319d723150aff62a65
SHA1: 5041928a40ae6ed6628dcf76acdb3702248db8ee
MD5sum: 4287fb050695576e177c786e84769630
Description: Raspberry Pi firmware updating tool
 Tool to get the latest bleeding-edge firmware and kernel for your Raspberry Pi
Description-md5: ced3073817fabb94e13f93f6e05d5c15

When it is finished, do a reboot:

reboot

If things catastrophically go wrong

You used rpi-update and it does not boot anymore? Or the revert process did not work out and stuck somewhere, and you do not know how to proceed?

Sorry for that, I cannot help directly. However there are some clues.

Basics

The RPI boots up as follows:

• Boot the builtin eeprom
• Boot the bootloader from SD-card partition 1
• The bootloader then boots the Linux kernel

Partition 1 is what you see in /boot (usually).

The booted kernel is in /boot/kernel*.img (at my side: /boot/kernel8.img. YMMV)

If something goes wrong with rpi-update, this usually only affects your SD-card. So the easiest way is just to change the SD-card!

Change SD-card

Buy another SD-card. BUT DO NOT BUY STANDARD SD-CARDS!

You definitively need an SD-card with Wear Leveling. Normal SD-cards do not have that feature and can wear out within days. Some SD-cards last longer. SD-cards with Wear Leveling will nearly last forever.

Abstain from unbranded or generic SD-cards which you might find in your local grocery. They are almost never worth their price. If you are in deep trouble, you can go with such a card, of course, but only use it for recovering your PI, do not run the PI permanently with it. Such no-name cards are good for "write once, read multiply", but not a good thing for daily use like as a SD card for your mobile phone or PI.

And even many branded cards (most notably SanDisk) are plain crap. You have been warned. (Note that there are certainly some good products from SanDisk. The problem is to find them, as SanDisk has so many similar look-alike similarly named crap products, so I constantly failed to get something from them, that worked for me).

Usable SD-Cards must use similar technology as SSD, and are usually named similarly to their SSD counterparts. Like the Samsung EVO Plus microSDXC SD-card or Samsung PRO Endurance. (I am not sure that the "Samsung EVO Select" also has wear leveling, but it is very likely. Sorry, I only use Samsung cards, since I had very bad experience with other brands like SanDisk. Best of the bads was Transcend, as their cards did not die, they just went RO. This is not an advertisement, just my observation and recommendation.)

At least buy 32 GB. It should cost less than $10. Including shipping. If you no more find 32 GB, as these get rare nowadays, just go bigger.

If the eeprom PI is recent enough, booting it from a blank SD-card brings up a downloader, which allows you to install a fresh OS onto the SD-card.

Then install a fresh RPI os on the card and boot the RPI.

If everything is good, your RPI is ok and you do not have to worry much.

Get some USB SD-card reader to access your old SD-card from the RPI.

This here is about how to recover your PI, not on how to recover your data. So sorry, if you do not know how to copy data from one SD to another under Linux, get some help elsewhere.

What about the eeprom?

If a fresh SD-card does not help, then perhaps you need to recover the eeprom. That is builtin and usually not updated at all!

There is help on https://github.com/raspberrypi/rpi-eeprom/

Get some SD-card or USB stick

• As this card only needs to hold the image and the image itself does not write to the SD-card, cheap/unbranded SD-cards can be used here.
• With the USB image, you can also use some USB stick
• 1 GB should be enough (the recovery-image is less than 1 GB)

Download the recovery image from https://github.com/raspberrypi/rpi-eeprom/releases

I do not know how to authenticate these images. Sorry.

So if somebody evil manages to upload trojaned versions to GitHub, I really do not know how to prevent evil happens.

• Unzip it
• Write it on the USB stick or SD-card

Then plug in the Stick/Card into your PI and boot it up.

Usually the power led of the PI starts blinking after a short while. Also the screen usually shows a big green rectangle. This means the eeprom was updated successfully.

Do not switch off early. If in doubt, wait 30 minutes before powering off.

Remove the card/stick and restart your PI. If no SD-card is inserted, you should see the new PI screen with the image downloader. Press and hold the Shift key to go into the downloader.

Note that it needs an Ethernet cable connection. Downloading via wLAN or BlueTooth is not supported. Yet.

How to write the image?

No good guide here as I never found something more suitable than the commandline. Sorry.

Note that you need to write the image directly to the card/USB stick, not onto the filesystem. So Windows usually cannot do it out of the box.

On Linux this looks like:

!!!WARNING!!!* Using following command wrongly may destroy your system!

Be sure that the target device is the real device you want to overwrite. If you are unsure or inexperienced, try with some image writer application. As I am not in UI, I cannot recommend anything here, sorry.

Also do not blindly follow recipes found in the Internet, as they may install a virus on your computer. You have been warned!

dd if=rpi-boot-eeprom-recovery-2023-01-11-vl805-000138c0-sd.img of=/dev/sdZZ

where /dev/sdZZ must be replaced by the device name of your SD-card-reader or USB-stick. Usually you find the device with the command dmesg:

dmesg -w

Then plugin your device. Usually you see something like sde or similar, then the device is /dev/sde.

What if that does not work

I am out of clues. You then probably need a serial debug cable, open your PI, attach (solder?) the cable and use a serial debugger.

You need to go to the PI wiki for that. I never needed it, so I have no experience with that yet.