Raspberry Pi 4 and SSD – Miracles at Last?

I’ve just been watching a video by Andreas Speiss – and I agree with him, USB boot on the Raspberry Pi has taken FAR too long and we are NOT a tiny minority in favour of USB boot, contrary to comments in the Pi forums.

The PI3 had USB2 boot and so it was/is entirely reasonable IMHO to expect a product touted as the next generation of Raspberry Pi to boot from USB3 (which now has enough speed to make it worthwhile) and yet the Pi team apparently consider this a low priority – many months after launch.

As Andreas quite rightly points out, SDs are well suited to cameras where they get read often but over-written to rarely (photos tend to stay put and new photos tend to occupy new space) whereas computers write constantly – often over-writing the same location. In addition, SDs are somewhat prone to failure if power is lost – and last month for the first time I lost my setup over in Spain while I was in the UK, thanks to dodgy mains power which also took out my router. Thankfully I had a backup on USB but this meant a friend over there in Spain bringing back the Pi (as he was visiting the UK) and posting it to me so I could thoroughly check the setup using the backup USB. The Pi4 itself was and is fine, the SD was irretrievably ruined. The backup, thankfully was fine and once again everything works.

Whwn my friend Antonio pointed out that Andreas had posted a video with a solution, I was all ears.

At this point I’m not sure if this applies onto to a new installation or if we can include existing installations (a new-only route would be useless to me). It always amazes me how often people (including the Pi team) concentrate on new installations as if nothing we already have in place is relevant. I have spent a lot of time upgrading my home control to the latest versions of everything without starting from scratch and I don’t intend to start now.

However it seems all academic as this does NOT looks like a true SSD boot scenario, I guess we will just have to wait for the RPI team to finish the job.

Facebooktwitterpinterestlinkedin

21 thoughts on “Raspberry Pi 4 and SSD – Miracles at Last?

  1. I bought a Pi4 in January and found James Chambers blog while googling for SSD boot. I’ve had it running with a very second hand SSD for a month now, no problems. I’m trying to use this as a desktop, so it does get powered off/on a couple of times a day. Next step is to replace an old Pi2 running WeeWx weather station (lots of read/writes) and I might try copying the existing card, fingers crossed!

    PS will you be hit by the 90 days in 180 rule spending time in Spain after 31.12.20? In the process of becoming resident in Greece while we can….

  2. you can move your actual installation to usb or ssd using same procedure… the way Andreas did (using partition IDs instead of device) makes it more SECURE: if you attach 2 usb dongles, rpi could mess around swapping device names (sdb and sdc, for example) depending on the order IT decides to recognize and name them… with part IDs, you don’t have this problem, the id is in the partition itself and it’s always the same wherever you attach that disk…

    just do as he did, install a brand new raspbian on an usb or ssd drive, then just empty the new partition and copy your boot part to the fat32 part, and the ext4 data to the second part (using rsync, for example)…

    i did this many times in the past on rpi3, no problems… Andreas method is nothing new (actually it’s been on raspberry forums for more than 2 years, now: https://www.raspberrypi.org/forums/viewtopic.php?t=196778 ), but works and the sd card is used in readonly mode just on boot time, so it will last forever…

    1. I’ve had real problems with rootfs on both an HDD and SSD using DietPi in the last month. I think it is a kernel problem. But yes, the DietPi utility to mount drives and move the rootfs or user data is really good.

    2. problem Pete has is that he has a VERY COMPLEX setup, so moving from his actual distro (raspbian) to dietpi or anything else is not as easy… otherwise, for sure the best option will be to move to a containerized setup, as i did: this way you can easily backup/restore snapshots and data, and even move to new hardware, even of different architecture, in a breeze…

      G.C. Garner did an EXCELLENT job in porting almost everything Pete’s script does to Docker, including backup scripts and other cool stuff… take a look at Andreas’ video about it: https://www.youtube.com/watch?v=a6mjt8tWUws

      and at gcgarner project: https://github.com/gcgarner/IOTstack

      personally i use HASSIO as a base and all the other stuff using its own addons, all integrated…

  3. Antonio, I second your comments about Graham Garners excellent work. IMHO it gives the best of both worlds because if you run some of his containers outside Hass.iO he includes volumes with a /data directory that is accessible from outside the container. In my specific case I run Node-RED outside Hass.IO in a container, from Node-RED I write data into a database in the Node-RED volume. I can then access the stored data from anywhere on my network. I know one could add volumes to containers in Hass.IO if one knew how to – I don’t!
    I found Graham Garner’s set up very easy and I think it is the closest containerized set up to Peter’s scripted set up.

    1. It is not by chance that Graham’s project resembles Peter’s script. I actually asked him to include all the goodies Peter’s script includes. So, Peter (and Antonio) definitively are the fathers of this project.

      1. At the moment I am trying to make a system as a copy of Pete’s ingredients. It is however largely different. You have to jump quite a number of hoops to get a backup to Google Drive. Needs quite some changes to system files, additions of them. So this does not fit into the advertized way of a backup because thes e fall outside the volumes and oar not included in the backup script. Still a lot of study. However Node-RED is fully functional after a short time. It is now running on a pi3B+ with a 2,5 inch HD. SSD on order from China. Just fun to lear a little bit more of linux things, but feels like learning a trick to a monkey.

        1. Leo, why on earth buy SSD’s fron China? I just bought three from Amazon UK. One was 120Gb Kingston A400 (£18.00) and two Crucial 120 GB models one was £20.00, the other £22.00. The prices increased over two days. Point is one can buy top quality products for little money and easy return if they are faulty. The SSD is so critical to the Pi reliability, I cannot see the point of using cheaper less well known devices. I believe you are in the Netherlands so Amazon as a supplier is likely not a problem.

          1. as in comics: “mumble mumble”… (brain gears rolling and a lamp over the head)…
            i was thinking about linux software raid, connecting 2 different ssd and have them replicate one each other… have to search…

      2. Graham’s project works elsewhere as does Peter’s.
        I am running Graham’s on proxmox at the moment as a test and thus no Pi involved to fail.
        I will go back to the Pi eventually. My point there are other ways around the sdcard.
        Any yes I also use the old way on an older Pi used for streaming to boot sdcard and run from USB. Has worked for years.

  4. I agree that mass storage should have been more of a priority long ago.

    I developed an automation system for my business using node-red running on a Pi 3+ and a micro SD card. It works great and it’s pretty stable but twice in 6 months the SD card died. This wasn’t a big problem since I was doing regular data backups and had saved images of the SD card, which isn’t a big deal since the card was only 8gb. Since then I have replaced the SD card with an SSD module and things got way more stable. It’s been running nearly a year with no issues.
    My question is, how can I backup my pi image without backing up the whole SSD card. Backing up 128Gb is not trivial and seems like there must be a better way.
    Does anyone know how to do a full backup of just the contents of the pi image?

    1. Hi Bruce – there will be those who wonder why I bang on about this. You are of couse right – RPICLONE makes backups a doddle – but putting them in place when you are thousands of miles away from the PI is a big problem. I had a helpful not-that-technical neighbour in Spain (actually a good friend) send me the PI to the UK where I checked the backup (using that little Friendlyarm OpenWrt router as a pretend Spain network) and shipped it back. Hardly convenient though.

      I’m pondering the idea of a second identical Pi, both on Sonoff Basics + Tasmota – on normally off, the other normally on. Any thoughs/ideas most welcome.

    2. where’s the most of your stuff? I suppose in /home… so, the easier way is just a tarball of that (and /etc) to put elsewhere… there are a lot of options for backing up, if you are “in place” where the device is, or you can easily reach it to swap some sdcars…
      an easy: sudo tar cvzfp /opt/myhome.tgz /home/pi
      for example… or using rsync on a network share… or try the already available (in beta) network boot for rpi4, and have it without ANY sdcard, but you’ll need a separate device which shares an nfs folder via pxe+tfboot…

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.