Running Raspbian from USB Devices : Made Easy

[RonR]

A recurring topic of discussion is how to configure and reliably run Raspbian on a USB flash drive, USB hard drive, or USB SSD instead of an SD card.

A Raspberry Pi 3B+ has a native USB boot mode (this mode has to be manually enabled by setting an OTP bit on a Raspberry Pi 3B). This native USB boot mode has serious compatibility issues. A bootcode.bin file is available for older Raspberry Pi models. Unfortunately, both of these approaches have serious limitations and once working, can easily be broken by simply plugging in an additional USB storage device.

The easiest and most reliable way to run Raspbian on a USB device is to leave an SD card containing Raspbian in place, but use it only for starting Raspbian that is residing on a USB device. While setting up such a configuration is not rocket science, it can be confusing to a newcomer or someone unfamiliar with Linux internals. In an effort to simplify the task, I've created the attached script named 'usb-boot' to automate the process.

If usb-boot is running on a Raspberry Pi 3B+ or a Raspberry Pi 3B with its OTP bit set, usb-boot first prompts: 'Use SD card to boot the USB device (recommended)?'

If 'No' is selected, the SD card will not be altered, but booting the USB device may be limited and/or unreliable as described above.

usb-boot then presents a list of available USB mass storage devices and prompts: 'Select the USB mass storage device to boot'

Use the arrow keys on your keyboard to navigate to the desired device and press the spacebar to select it. Then use the tab key to navigate to the 'Ok' or 'Cancel' button and press the return key.

usb-boot will then prompt: 'Replicate BOOT/ROOT contents from /dev/mmcblk0 to /dev/sdX?'

/dev/mmcblk0 is the SD card and /dev/sdX is the USB device.

Select 'No' if the USB device already has Raspbian on it and you wish to use it (nothing will be copied).

Select 'Yes' if you want to copy the Raspbian on your SD card to the USB device (everything will be copied).

If you select 'Yes', you will be warned: 'All existing data on USB device /dev/sdX will be destroyed!' and prompted: 'Do you wish to continue?'

If you select 'Yes', the copy will begin. The time required for this process will depend on the amount of data on your SD card and the speed of your storage devices.

usb-boot will then complete the configuration process and warn you of any potential conflicts it detects.

When usb-boot has finished, you should be able to reboot and be running Raspbian on the USB device (first power off and remove the SD card if not using the SD card to boot the USB device).

=====

sdc-boot provides a convenient way to select which attached device will be booted.

Usage syntax is:

sdc-boot [ /dev/mmcblk0 | /dev/sdX | ptuuid=hhhhhhhh ]

/dev/mmcblk0 is the SD card

/dev/sdX is a USB device

ptuuid=hhhhhhhh is a USB device identified by its PTUUID

If no device is specified, the currently selected boot device will be displayed.

[HawaiianPi]

A Raspberry Pi 3 has a USB boot mode that has to be permanently enabled by setting an OTP bit. A bootcode.bin file is available for all Raspberry Pi models. Unfortunately, both of these approaches have serious limitations and once working, can easily be broken by simply plugging in an additional USB storage device.

Only true for bootcode.bin, as it simply checks the first USB storage device it finds. Pure USB boot works fine with multiple USB storage devices attached. I have done it and had no problems booting with an extra flash drive attached. My issue with pure USB boot was that restart and shutdown were unreliable (regardless of the number of USB storage devices).

So I agree that keeping /boot on the SD card is the most versatile and reliable way to do it, and have posted that very same sentiment many times.

A Raspberry Pi 3 has a USB boot mode that has to be permanently enabled by setting an OTP bit.

I'd just like to point out that setting the OTP USB boot bit has no permanent effect on the operation of the Pi3. There seems to some FUD that setting the OTP bit somehow changes the way you must use your Pi3, but that's not true. The Pi3 will default to booting from an SD card even with that bit set, so setting the bit does not REQUIRE you to boot from USB, it only enables it. If you want to experiment with USB boot, then go right ahead and set the bit, and if you find that USB boot does not suit your needs, then just insert a boot SD card and your Pi3 will boot from it exactly like it did before. USB boot does work for some people, I'm just not one of them. It all depends on your USB boot device. Some work, some don't.

And since you made a script to simplify the process, perhaps this should be in the beginners forum.

[RonR]

Only true for bootcode.bin, as it simply checks the first USB storage device it finds. Pure USB boot works fine with multiple USB storage devices attached. I have done it and had no problems booting with an extra flash drive attached. My issue with pure USB boot was that restart and shutdown were unreliable (regardless of the number of USB storage devices).

I suspect you were lucky in that the desired USB storage device happened to be the first one to come ready and therefore booted successfully. If some other bootable USB device had come ready first, it would have booted instead since the 'Pure USB boot' has no idea which of your multiple devices is the desired one. If the first one to come ready is not configured properly for booting, I'd bet things would hang.

[rpdom]

I suspect you were lucky in that the desired USB storage device happened to be the first one to come ready and therefore booted successfully. If some other bootable USB device had come ready first, it would have booted instead since the 'Pure USB boot' has no idea which of your multiple devices is the desired one. If the first one to come ready is not configured properly for booting, I'd bet things would hang.

I believe "bootable" in this case means "is a FATxx partition with a bootcode.bin file in it".

[RonR]

I suspect you were lucky in that the desired USB storage device happened to be the first one to come ready and therefore booted successfully. If some other bootable USB device had come ready first, it would have booted instead since the 'Pure USB boot' has no idea which of your multiple devices is the desired one. If the first one to come ready is not configured properly for booting, I'd bet things would hang.

I believe "bootable" in this case means "is a FATxx partition with a bootcode.bin file in it".

I'm not sure what your point is, but I do know that the 'standalone' bootcode.bin fails when the first USB storage device to come ready is anything other than a properly configured boot device. For example, if the first device to come ready is a USB flash drive with a single partition formatted NTFS, your system won't boot until you remove that USB flash drive. I'd be very surprised if the RPi-3 OTP boot is any smarter.

[HawaiianPi]

I'm not sure what your point is, but I do know that the 'standalone' bootcode.bin fails when the first USB storage device to come ready is anything other than a properly configured boot device. For example, if the first device to come ready is a USB flash drive with a single partition formatted NTFS, your system won't boot until you remove that USB flash drive. I'd be very surprised if the RPi-3 OTP boot is any smarter.

When I was testing USB boot I had an SSD and a USB flash drive connected. I booted the system dozens of times and it never failed to boot from the SSD, but the USB flash drive was almost always mounted as /dev/sda1, so it would seem that the SoC boot code is a bit smarter. My flash drive was even formatted FAT32, it just didn't have any boot code.

On the other hand, an SD card with bootcode.bin failed to boot every time with the flash drive and SSD connected.

[RonR]

When I was testing USB boot I had an SSD and a USB flash drive connected. I booted the system dozens of times and it never failed to boot from the SSD, but the USB flash drive was almost always mounted as /dev/sda1, so it would seem that the SoC boot code is a bit smarter. My flash drive was even formatted FAT32, it just didn't have any boot code.

On the other hand, an SD card with bootcode.bin failed to boot every time with the flash drive and SSD connected.

Even if the SoC boot code is a bit smarter and can skip over certain non-bootable storage devices, you still don't have any control over which bootable device is booted (presumably it's the first one to come ready, not necessarily the one you want booted).

My issue with pure USB boot was that restart and shutdown were unreliable (regardless of the number of USB storage devices).

It's unclear to me why you're defending a method that you've found to be seriously flawed. This discussion appears to be of little value when the tried and proven method of keeping an SD in place is 100% reliable and provides full control over which USB device is booted. A dirt-cheap 4GB SD card is all that's needed and since there will be no writes to it, it's likely to last forever. Yes, you can get by with a smaller SD card if you whittle things down to just the boot partition, but it's hardly worth all the effort. Plus, if you have a problem with your USB device, you've got a bootable system on the SD card that you can quickly and easily press into service for troubleshooting purposes.

[rpdom]

Even if the SoC boot code is a bit smarter and can skip over certain non-bootable storage devices, you still don't have any control over which bootable device is booted (presumably it's the first one to come ready, not necessarily the one you want booted).

I'm wondering why you think people may have multiple "bootable" devices connected and what you class as "bootable" anyway.

[RonR]

[I'm wondering why you think people may have multiple "bootable" devices connected and what you class as "bootable" anyway.

Simply writing a Raspbian image to a USB device makes it a bootable device. Having multiple bootable USB flash drives is probably not at all uncommon. Plugging more than one of them in at a time to copy files or customize configurations should not cause a failure to boot or boot the wrong device unless/until you remove them.

Why would you build and configure a system in a manner that's unreliable and/or unpredictable under perfectly reasonable conditions? It's just as easy to do it such that you avoid all the confusion, failures, and frustration.

[k-pi]

I've not had any problems booting from pendrives, since setting that OTP bit on my RPi3.

I really don't understand why you would have multiple boot devices connected at any one time, it makes no sense at all.

If I want to use a different OS, I just power off, change pendrive & restart, it's as simple as that.

Also, when using a powered USB hub as the power supply for my RPi3 & an external HDD, it's the same, just power off, change OS pendrive, restart.

[RonR]

I've not had any problems booting from pendrives, since setting that OTP bit on my RPi3.

I really don't understand why you would have multiple boot devices connected at any one time, it makes no sense at all.

If I want to use a different OS, I just power off, change pendrive & restart, it's as simple as that.

Also, when using a powered USB hub as the power supply for my RPi3 & an external HDD, it's the same, just power off, change OS pendrive, restart.

If you have a rule that you will never ever for any reason plug in a second one of those pen drives that has Raspbian or another O/S on it, then you might not have any problems. But if you reboot without first removing that additional pen drive, there's an excellent chance that your RPi will boot the wrong one or not boot at all. I frequently have a need to plug in an additional pen drive that just happens to have Raspbian on it. I don't want to have to worry that if I forget to remove it before rebooting, my system might boot the wrong device or not boot at all. My only point is I don't care to have such a limitation and vulnerability when I can just as easily have a system that does the right thing no matter how many additional devices (bootable or not) I plug in.

If there were some huge savings or other benefit for abandoning a method that's 100% reliable and predictable for one that's seriously limited and flawed, I'd understand the argument. But to introduce potential problems without a good reason makes no sense to me. It's obviously a personal choice, and I choose reliability and predictability.

[HawaiianPi]

Pi3 USB boot is a bit picky about the device it's booting from. Not everyone has the problems I had. It works fine for some people. However, I did say that I agreed with you that keeping /boot on the SD card was the most versatile and reliable way, since it works with every Pi model and should work with any bootable USB device (and if you use UUID or PARTUUID it will always boot from the correct device, no matter what else is connected).

I don't agree that having more than 1 bootable device connected is common (or not at all uncommon, as you put it). I suspect it's exceedingly rare, actually. But if you have a need for it, then yes, keeping /boot on the SD card is the way to go, and your script would be a handy way to switch boot devices.

You seem awfully sensitive to criticism. There's an old saying, you can't please everyone, so don't sweat the nay-sayers. I'm sure someone will find your script useful.

[BetterWang]

I'm not sure what your point is, but I do know that the 'standalone' bootcode.bin fails when the first USB storage device to come ready is anything other than a properly configured boot device. For example, if the first device to come ready is a USB flash drive with a single partition formatted NTFS, your system won't boot until you remove that USB flash drive. I'd be very surprised if the RPi-3 OTP boot is any smarter.

When I was testing USB boot I had an SSD and a USB flash drive connected. I booted the system dozens of times and it never failed to boot from the SSD, but the USB flash drive was almost always mounted as /dev/sda1, so it would seem that the SoC boot code is a bit smarter. My flash drive was even formatted FAT32, it just didn't have any boot code.

On the other hand, an SD card with bootcode.bin failed to boot every time with the flash drive and SSD connected.

If you have working OS installed on both USB devices, which one will be booted?
Is it predictable?
What if you swap the USB port, would the booting order swapped as well?

[RonR]

If you have working OS installed on both USB devices, which one will be booted?
Is it predictable?
What if you swap the USB port, would the booting order swapped as well?

If you use the usb-boot script, it won't matter how many USB devices have a working (or non-working) OS on them and you will always boot the one you selected with usb-boot, regardless of the USB port things are plugged into.

[HawaiianPi]

If you have working OS installed on both USB devices, which one will be booted?
Is it predictable?
What if you swap the USB port, would the booting order swapped as well?

It would not be 100% predictable. The majority of the time my system boots with the flash drive as /dev/sda and the SSD as /dev/sdb, but on the odd occasion they flip. I suspect that swapping ports would not matter, as it's likely the flash drive is simply "ready" before the SSD drive, so it gets detected first. The SSD drive is not connected directly to USB like the flash drive, it is a SATA device on a SATA-to-USB converter, which may affect the time it takes to be seen by the USB ports. However, the difference must be small enough that the SSD does pop up first occasionally.

It should be possible to create some kind of bootloader, but it would need to be installed on each device, and it all gets way more complicated than just having an SD card which tells the system exactly which device to boot (ideally the bootloader would be on the SD card).

Such bootloaders are common in the world of Linux outside of Raspbian. Most of my x86 computers boot into GRUB (the GRand Unified Boot-loader) that allows me to choose which OS to boot. The machine I'm typing this reply on has Windows 10 and two different flavors of Linux (Mint and Slackware).

In our little ARM corner of the Linux word there is NOOBS and Berryboot, of which only the latter is a true bootloader, and it's supposed to be able to work with USB devices, but I have no experience with Berryboot myself.

[GGEZ]

This method screws up raspi-config. I had to take out the SD card and edit config.txt on my computer. Still not sure how to use raspi-config. It caused me hours of frustration + 1 week of thinking to fix the downstream problem this caused.

[RonR]

This method screws up raspi-config. I had to take out the SD card and edit config.txt on my computer. Still not sure how to use raspi-config.

Your problem is not related to the usb-boot script provided in this topic.

raspi-config does not know how to resize Raspbian when it's running from a USB drive, regardess of the method used to put Raspbian on a USB drive.

The attached fix-rc archive (download/file.php?id=19959) contains two solutions to this problem:

1. raspi-config-usb makes a temporary copy of raspi-config, patches it to work, runs the temporary copy, then deletes the temporary copy.

2. patch-rc copies raspi-config to raspi-config-original and patches raspi-config to work.

[fbe]

Your problem is not related to the usb-boot script provided in this topic.

Some settings in raspi-config are stored in /boot/config.txt and your script configures the Pi to mount the first partition on the USB device to /boot. If the system boots from SD card (and this happens if you leave it in your Pi) changes by raspi-config to /boot/config.txt will be ignored.

[RonR]

usb-boot (usb-boot.zip attached to the first message in this topic) has been updated.

usb-boot now mounts the BOOT partition of the SD card (/dev/mmcblk0p1) on /boot instead of the BOOT partition of the USB device (/dev/sdX1).

If you used the original version of usb-boot, you may find it beneficial to modify the /boot line of the /etc/fstab file on your USB device to the following:

Code: Select all

/dev/mmcblk0p1        /boot           vfat    defaults          0       2

[ToPro]

usb-boot now mounts the BOOT partition of the SD card

Does this mean that we now need SD card?

[RonR]

usb-boot now mounts the BOOT partition of the SD card

Does this mean that we now need SD card?

The premise put forth in the first post of this topic is that the easiest and most reliable way to run Raspbian from a USB device is to leave an SD card in place to perform the initial steps of the booting process. To that end, the purpose of the usb-boot script is to facilitate that approach.

If you are able to boot a USB device directly without an SD card attached and are not concerned with the limitations of that approach, then the boot partition of the USB device should be mounted on /boot.

[XP1]

Instead of replicating a live installation from the SD card, is it possible to adapt the script to read from the original IMG file?

This accomplishes two goals:

1. It is simpler to start off with the common use case of a clean install. Why go through the trouble of writing the IMG to the SD card, booting the OS, copying the script, and then running the script on Raspian? Just skip all those steps and write the original IMG to USB directly.
2. Writing the IMG to the SD card is too much data for small SD cards. If the SD card is only used for booting, why do we need the entire Raspian OS on the SD card? I need to use those small 1GB SD cards, which are useless for anything else.

[PeterO]

Instead of replicating a live installation from the SD card, is it possible to adapt the script to read from the original IMG file?

There should be no need to use this "script" anymore. Simply copy the image file to your USB device with dd or etcher, and on a 3P+ just plug it in (without and SD card) and it should boot.
On a 3B you will need to set the One Time Programmable (OTP) boot enable bit. (see here https://www.raspberrypi.org/documentati ... des/msd.md ).
PeterO

[XP1]

There should be no need to use this "script" anymore.

Thanks, I just found out about the modern way of booting by reading the "Special bootcode.bin-only boot mode" section:
https://www.raspberrypi.org/documentati ... /README.md

Just format an SD card as FAT32 and copy on the latest bootcode.bin.

I have a Pi 1, and the instructions are so simple. After formatting the SD card, I just download the "bootcode.bin" file and saved it to the SD card.

Don't need the script.

[RonR]

I have a Pi 1, and the instructions are so simple. After formatting the SD card, I just download the "bootcode.bin" file and saved it to the SD card.

Don't need the script.

If you don't mind the limitations, that may be true.

A Raspberry Pi 3 has a USB boot mode that has to be permanently enabled by setting an OTP bit. A bootcode.bin file is available for all Raspberry Pi models. Unfortunately, both of these approaches have serious limitations and once working, can easily be broken by simply plugging in an additional USB storage device.