Possible to boot raspberry pi 4 from an external USB?

I look forward to it!

Unfortunately i don’t believe so much.

No detailed data is provided about mAh/Ah available on USB A Ports.

Here it is, as said the hard way… possible you can do it much easier with cloning software. But you be rewarded with a fresh, optimal aligned install on your SSD with really unique UUID for the disk and partitions!



First be sure your RPI4 has the latest EEPROM firmware.

[root@rpi4 ~]# vcgencmd bootloader_version
Dec 11 2020 11:15:17
version c3f26b6070054bca030366de2550d79ddae1207a (release)
timestamp 1607685317

To update the EEPROM you need the lastest Raspberry PI OS. (I used the minimal without GUI)

Doc’s from the Raspberry Pi Foundation and here to update to “stable” instead of “critical”.

On the RPI (OS does not matter now) downlaod the Nethserver image for the Raspberry PI: (At the time of writing RC2…)

wget https://github.com/NethServer/arm-dev/releases/download/7.9.2009_RC2/Nethserver-7.9.2009-RC2-RaspberryPi-img.raw.xz

decompress the image:

xz -d -T 0 -k Nethserver-7.9.2009-RC2-RaspberryPi-img.raw.xz

his may take a while… despite we are telling to use as many threats possible (-T 0) it seem to run just one.

now attach a loop-device to the decompressed image on the disk:

sudo losetup -f -P  Nethserver-7.9.2009-RC2-RaspberryPi-img

in this the -f is for find a available loopdevice and -P attech the partitions too. It finds most probably the first loop-device meaning /dev/loop0p1 and /dev/loop0p2 should exist now

make an (arbitrary) directory for the mount point of the source image:

mkdir source

and mount the loop-devices attached to the NS-image:

sudo mount /dev/loop0p2 source
sudo mount /dev/loop0p1 source/boot

Attach the SSD and partition it as you wish, but the first partition needs to FAT32 minimal 256MB (I made it 512MB), a second partition type linux. I like GPT partitiontables more (they live on both “sides” of the disk, you have an backup if you mess up) so used gdisk with this result:

[root@rpi4 ~]# gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.10

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 976773168 sectors, 465.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 85B4599F-8B98-4F9F-A907-70D2C33AE3EE
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 976773134
Partitions will be aligned on 2048-sector boundaries
Total free space is 908615661 sectors (433.3 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB   0700  Microsoft basic data
   2         1050624        68159487   32.0 GiB    8300  Linux filesystem

format the disks: (in here /dev/sda is assumed to be the SSD check this!!)

sudo mkfs.msdos /dev/sda1
sudo mkfs.ext4 /dev/sda2

make an (arbitrary) directory for the mount point of the SSD and mount the partitions:

mkdir target
sudo mount /dev/sda2 target
mkdir target/boot
sudo mount /dev/sda1 target/boot

copy the content from source to target

sudo cp -rp source/* target/.

(this takes a while… we are allmost done :grinning:)

now we need disk-id’s (UUID) and the part-id of the new rootfs which is /dev/sda2 .

On my system: (Note this system boots without SD-Card hence it does not show up)

[root@rpi4 ~]# sudo blkid
/dev/sda1: UUID="D17B-9F4F" TYPE="vfat" PARTLABEL="Microsoft basic data" PARTUUID="6995254a-06c6-44d0-ab93-b9fb910f257e"
/dev/sda2: UUID="c64adf56-cf9f-46ef-9751-5f119dae26ad" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="45e458a4-8f16-4b32-a61e-45d34b51f28a"
/dev/zram0: UUID="4e7e5bcd-c0aa-4c99-bc9c-f69743189e67" TYPE="swap"

edit the kernel command line so the kernel can find the rootfs, look for root= and change it to root=PARTUUID= and make it to fit your PARTUUID, Here is mine:

sudo nano target/boot/cmdline.txt

here is mine: (substitute your PARTUUID of /dev/sda2)

console=serial0,115200 console=tty1 root=PARTUUID=45e458a4-8f16-4b32-a61e-45d34b51f28a rootfstype=ext4 elevator=deadline rootwait

and edit the fstab to match your disks

sudo nano target/etc/fstab

Again here is mine : (substitute your UUID’s )

UUID=c64adf56-cf9f-46ef-9751-5f119dae26ad  / ext4    defaults,noatime 0 0
UUID=D17B-9F4F  /boot vfat    defaults,noatime 0 0

THAT’S IT :grinning:

Well you may want to remove the “first-boot” flag so you can reboot your RPI without running system-init.

sudo rm target/var/spool/first-boot

Poweroff end remove the SD-Card and power on again:
If your systems boots from SSD and you are happy:

touch /var/spool/first-boot

And reboot…


IIRC it’s max 1 amp for al the USB ports combined IF you use a good => 3A power supply

USB - Wikipedia
Well… this seems “debatable”.
Wikipedia reports for USB 2.0, 0.5A each port; 0.9 for USB 3 (port A), 1.2A for BatteryCharging protocol, 3A for USB-C (without PowerDelivery enabled, which could switch to different voltage than 5.)

Ouf of that standards, some computers provide up to 1A on each port, USB 2 or 3 Type A connector (desk, tower, and so).

Sometimes, connecting a “greedy” 2.5 HD Drive make a Y-cable needed to feed enough power for controller and SATA drive.

Well, you should not connect a hyperfast random read/write 7200 rpm spinning drive;
also recommend to stay a way from m.2 NMVe SDD’s, waist of money used in a USB3 application and power greedy.

Out of curiosity attached 2 WD blue nand-ssd’s in a sata-to-USB3 enclosure and copied aprox 250GB of data without a glitch, wasn’t very fast in sata therms thought.

Run one RPI4 for quite a while as aarch64 build-node, which means quite a lot of disk read/writes while compiling without issues.
For testing this build-node is also used as a KVM/QEMU/Libvirt hypervisor to fire up armhfp and aarch64 vm’s with snapshots to go back and forth…

In short: Tend to say it’s tested and proven to work well :grinning:

1 Like

Thanks for your experience, @mark_nl but using WD Blue SSD is quite “cheating” :wink:

3.8 W of maximum consumption, AKA 0,7A@5 volt :slight_smile:
Perfectly into specs without third USB interface :wink:
1 Like

You are right, it was (is) a deliberate choice. :face_with_monocle:

OK - have done what I thought was right and am up to the first reboot without the SD-Card and get to

Any idea what has gone wrong?


hard to say, best guess is the kernel cannot find the root_fs

Can you boot it from a sd-card and mount sda2 and sda1 again:

then look if it resembles a rootfs: ls target/

EDIT: ls target/ (without the *) should look like this:

bin   dev  home  lost+found  mnt  proc  run   srv  tmp  var
boot  etc  lib   media       opt  root  sbin  sys  usr

if so… can you post the blkid’s : sudo blkid

and post your kernel commandline and fstab:

cat target/boot/cmdline.txt
cat target/etc/fstab

I missed the PARTUUID= specification in the cmdline.txt. Put it in and all good other than I get given the default address of, despite the DHCP quite happily handing out a 192.168.178.xx address previously…

1 Like

Did you remove the first-boot flag or is system-init already done?

I did as below:

So does this mean system-init isn’t done?

If you did this:

Yes after aprox 2 minutes it’s done…

Note: this is valuable information in the proces to go to “final” :+1:
the network scrips (ifup / ifdown) have problems with the eth0 of the RPI4.
In my case it works out fine as it did @royceb, but not all dhcp servers are the same,;
So we need to take more precautions after-all

I repeated it i.e. touched the file to create it and then rebooted - it didn’t seem to do anything extra or different. Is there a simple way to find out if it has done its work?

Secondly, if its not doing what it should with the ethernet, what should I do?


Do I even need to log in to the console, or should I just leave it for a few minutes at the console prompt and then try to connect via a web browser (assuming it gets the right address).

First the analysis what went wrong: during system init Network-manager is stopted and network.service takes over. In your case network.service was not able to fetch a ip from the dhcp server. system-init gave it the most common ip out there:

A hack to salvage your install: nano /etc/sysconfig/network-scripts/ifcfg-eth0
And give it a fixed IP and network properties matching your situation:

here is mine:
cat /etc/sysconfig/network-scripts/ifcfg-eth0


then restart network: systemctl restart network
check your ip : ip a

Go to the web interface (on his IP) and assign your fixed ip again there.

1 Like

It all seems to be going OK now - many thanks for all your help.

Is there a better place to put all the raspberry pi nethserver questions?

1 Like

Glad you are sorted out ! and as said the feedback is valuable :+1:

No it’s fine here, you may give the extra tag arm:

This triggers the arm team to have an look, and others know it may be arm specific.

Could you mark the write-up form my (poor) memory as the solution of the topic, after all it did get the RPI4 booting from the USB dive :slight_smile:

I meant mark it a solution here:

So other people can find a answer quickly without reading the hole post. :upside_down_face: