How to boot from SD but run from USB?

I'm sure this is basically easy but I can't find a simple description of how to do it. If you search for anything about 'boot' and 'USB' you are immediately flooded with descriptions of how to boot from USB and that's not what I want.

I have an ancient Pi B+ that does all I need where it is but I'd like to be less reliant on the SD card. You can't (easily) boot such an old Pi from USB and I don't really need to, I just want to make it so that once booted all activity is on a USB drive.

Is it simply a matter of leaving /boot on the SD card and changing / to being a USB drive or does one need to edit something in /boot somewhere?

That would work, but I think there is an even simpler way:

Put only "bootcode.bin" on a FAT partition on the SD and a complete OS image on the USB drive.

When you see "/boot/bootcode.bin" on your USB drive being updated, update the other one too. A script for that should not need dark magic, but it still is on my to do list.

I know it had to be pretty simple! :-) I have some other old Pi systems lying around here so I can try it on them. The Pi that I actually want to do this on is in France and I won't be there for a couple of weeks.

A script to update the bootcode.bin on the FAT drive should be pretty simple, just put it in /etc/rc.local and it will be run every time you boot. It won't matter running it if /boot/bootcode.bin hasn't been updated, though I suppose you might complain that it's writing to the SD card unnecessarily. OK, use rsync and the file will only be written if it has changed.

I'd probably want to do that after any package updates, because there's a risk that the firmware files on the SD and USB become out of sync and that could cause a boot failure.

If you ran it on a cron job say once a day using rsync, it would reduce the chances of that happening. Or there may be a hook you can set to run it after apt upgrade.

Theo

AFAICR what you do is simply edit a file and tell it that / is not where it thinks it is

But it depends on exactly what you want to happen

The boot process is as follows (I think: Others will correct If I've got it wrong)

The Pi firmware looks on the SD card for a Vfat partition, and in there is a file called cmdline.txt

e.g. console=serial0,115200 console=tty1 root=PARTUUID=778a9e44-02 rootfstype=ext4 fs ck.repair=yes rootwait noswap=1

That file tells the boot loader wher the root directory is to be found that it is to grab the kernel off

the key thing is root=PARTUUID=

Now if the SD card does not have such a partition, the boot loader will look to see if e.g. a USB drive has, and use that instead.

Now on whatever partition it uses as the first stage root, it will have /etc/fstab e.g.

proc /proc proc defaults 0 0 PARTUUID=778a9e44-01 /boot/firmware vfat defaults 0 2 PARTUUID=778a9e44-02 / ext4 defaults,noatime 0 1

And at this point the booting system may, if you want, mount an entirely different root filesystem and carry on.

So if you edit the /etc/fstab on the SD card, and change the PARTUUID to a different drive, it will mount that instead. And never touch the SD card afterwards.

The easy way to do that is to boot the thing as normal, edit the fstab file to match the ID of the USB device and reboot, making sure that yiou have copied everything on te root partition of the SD card to the USB.

But frankly its almost always easier to install everything on the USB drive and remove the SDcard altogether.

Not quite. If you do it this way, the kernel comes from the SD card and the cmdline is the *kernel* command line, ie it tells that kernel where to find its root FS once it has started. That means you need to ensure that the kernel on the SD card remains updated, because any kernel on USB storage will be ignored.

If you did that way, you could set it up with just a FAT /boot partition on the SD and then your ext4 rootfs on USB, and adjust the cmdline and /etc/fstab to match. That way any updates would deploy the SD card /boot.

However if you ever want to re-image your rootfs you have to remember that you also need to re-image your SD and set up this arrangement again. Otherwise you'd be booting old kernels from SD with your new USB rootfs.

By using bootcode.bin only on SD (something I've not tried), you can use standard OS images on your USB without any changes. Or you could boot direct from USB on those Pis that support it with no SD.

Theo

Oh yes, you are right there. If you only adjust that line, you will still have the fstab on the USB drive mounting the SD boot partition in /boot/firmware. So the kernel will get updated OK automagically.

It is however needlessly messy which is why I went all USB/SSD and ditched the SDcard.

Yes. Exactly.

Ultimately, that is IMHO the better approach. As long as the Pi can recognise and boot from USB, leave the SD card out altogether.,

IIRC the most successful approach was in the end, for me, to simply install raspios on the USB drive and forget the SD card altogether.

Later Pis are perfectly happy to try the SD card like an old PC trying a floppy drive, to boot, but on failure simply look at the USB drives.

And the fact that the boot process uses PARTUUID rather then physical devices means its agnostic between SDCARD and USBdrive.

The only change I made somewhere was to stop the Pi endlessly trying to access the SDcard that was no longer there.

in /boot/firmware/config.txt

#since we are booting from SSD # disable constant SD scan # We wouldn't be here on an SD card boot

dtparam=sd_poll_once

I really do advise people not to try and split between SDcard and USB. Just install the OS on the USB to start with.

It works with later pis automatically

Yes, agreed. I suppose you could use inotify but I've never really got on very well with that.

As I understand it that's not possible with Pi before Pi 2 version 1.2 or something like that. Basically Pi 3 and onwards can simply boot from USB, earlier ones can't.

Yes, that is my understanding also. I think there was a time when you had to boot from SD and run a comm,and to change a flag in the firmware to allow USB only boot.

I have a Pi 4B and its supremely ecstatic booting from USB. And it's a totally simple setup

Yes, but my original question was (intended anyway) about booting an early Pi such that it actually runs from USB after booting from the SD card so that SD card wear isn't an issue.

Well I think that has been covered adequately as well.

Hack the boot partition on the SD card to tell it to use the USB for booting and hack the fstab entry to tell it to remount the USB as root after booting. Or a combination thereof

The SD card VFAT partition will remain mounted on /boot/firmware and so can be upgraded automagically

If it has bootcode.bin it should look at the USB to boot from.

Which works with middle aged pis.

Late models I believe don't need bootcode.bin. Very early models cant boot USB. There you have no option but to boot onto the SDcard and edit the SDCARD /etc/fstab to remount the USB drive as root.

Hello druck!

dr> dr> This is completely inappropriate for a Raspberry Pi, which does not dr> boot like a PC using grub.

oeps.. my bad ..

So the maybe is: do not try this ..

Thanks for correcting me.

Dennis

... Error 500: It's your problem now.

This is completely inappropriate for a Raspberry Pi, which does not boot like a PC using grub.

More bad advice.

See later in this thread for the actual answer.

---druck

LOL. Yup Arm/broadcomm based Pis 'do it their way'

It goes back to the chips inception as a set top box embedded processpor

Not to mention, USB sticks seem to be a lot more reliable than SD cards.

That doesn’t sound right to me. /etc/fstab is interpreted by a userland process (/sbin/init). That only starts running after the kernel has been booted. So mounting the boot partition at this point will make no difference to your running kernel. (Presumably /boot/firmware might contain firmware relevant to connected hardware and its drivers, but that’s a separate issue.)

(Not a Raspberry Pi user, but this should be basic Linux stuff common to all architectures.)

Was there some standard command-line tool for that?

I wrote my own Python wrapper

Also remember that GRUB depends on BIOS or UEFI, and the former is x86- specific -- not sure about the latter.

Basically, every vendor’s ARM chipset came up with its own way of booting. In the absence of a BIOS-style interface for querying what hardware is available, the Linux kernel is built with a “device tree” structure that hard-codes this information for your specific chipset.

There is now an equivalent spec standardized for the ARM world (adaptation of UEFI??), but I understand this is only in use on servers with AArch64, and the Raspberry Pi predates it anyway.