Skip to content

Instantly share code, notes, and snippets.

Last active October 13, 2023 12:38
Show Gist options
  • Save lucabelluccini/9a11c48dcf1d627bbcbd8213f6de3eae to your computer and use it in GitHub Desktop.
Save lucabelluccini/9a11c48dcf1d627bbcbd8213f6de3eae to your computer and use it in GitHub Desktop.
Raspberry Pi 4 - Boot from SD, Rootfs on USB

Raspberry 4B - Boot from SD and rootfs on USB


RPi4 now supports booting directly from USB. First update to get an eeprom which supports USB Boot, then configure the bootloader to boot from USB.

Original guide

  1. Download Raspbian from the official site

  2. Flash it to the USB drive following the procedure detailed here

  3. Fomat an SD Card 2/4 GB as FAT32, label "boot", flag "lba". Generate a UUID. You can use GParted for this task.

  4. Get the UUID of the USB drive and the SD Card partitions using sudo blkid.

  5. Copy the files from the /boot/ partition of the USB drive to the SD Card using rsync -rt <source> <dest>

  6. Modify the file cmdline.txt on the SD Card ensuring:

6.1. root=PARTUUID=<UUID of the USB drive rootfs partition> is present

6.2. rootdelay=5 to give more time to the Kernel to wait for the USB device

6.3. If you're using this USB drive adapter (use lsusb):

Bus 002 Device 002: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge

The disk is slow and reports errors in dmesg like the following:

[  543.071702] sd 0:0:0:0: [sda] tag#16 uas_eh_abort_handler 0 uas-tag 7 inflight: CMD IN 
[  543.071719] sd 0:0:0:0: [sda] tag#16 CDB: opcode=0x28 28 00 00 42 80 88 00 00 08 00
[  543.111634] scsi host0: uas_eh_device_reset_handler start
[  543.262296] usb 2-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[  543.297294] scsi host0: uas_eh_device_reset_handler success
[  573.776061] sd 0:0:0:0: [sda] tag#25 uas_eh_abort_handler 0 uas-tag 11 inflight: CMD IN 
[  573.776079] sd 0:0:0:0: [sda] tag#25 CDB: opcode=0x28 28 00 00 09 d4 40 00 00 08 00

Add usb-storage.quirks=152d:0578:u (link to Github, redhat bug report).

It must be disabled via kernel flags as it is built-in (sudo modprobe configs && zcat /proc/config.gz | grep USB_UAS).

6.4. Remove the init script to resize the drive. It doesn't work as the /boot and / do not belong to the same drive.

  1. On the USB drive, edit /etc/fstab:

7.1. Comment out the /boot partition of the USB drive

7.2. Add:

PARTUUID=<UUID of the SD Card boot partition> /boot vfat defaults 0 2

Useful links:

Copy link

The JMS578 doesn't need 'UAS blacklisting', what you experienced looks like a typical symptom of underpowering. See here for details:

Copy link

Well you can see the link "New firmware" points to the article. I am using the official USB-C power supply.

How would you explain the fact adding the USB quirk makes it work properly (I reach several hundreds of MB/s, works smoothly on desktop), while without it was constantly resetting?

Please keep in mind I am on Debian Buster.

Copy link

I'll test with iozone to see if under stress the errors show up again. If it is the case, then it's underpowering.

Copy link

How would you explain the fact adding the USB quirk makes it work properly

No idea, maybe your device runs with an old firmware? See how to check and update.

Copy link

I am going to:

  • check if a fw update is required on my USB adapter
    • if updated, I'll test out disabling quirks
  • stress the drive & check dmesg -T for errors

Thank you Thomas

Copy link

Just for the record: Transcend TS120GMTS420 SSD in JMS578 'enclosure' with JMS578 firmware v173.1.0.2 and VL805 firmware 013701 (the old one) no problems whatsoever:

Copy link

My USB3 to SATA cable has no external power. Still, the RPi4 has only a Logitech keyboard dongle & the USB 3 Drive connected.

Copy link

I've upgraded the firmware of the USB to SATA adapter

  1. Removed quirks = boots properly but resets start to show up as soon as the drive is under stress
  2. Keep quirks = boots properly, no resets even under hdparm & iozone tests
    There's a known issue with this kind of adapters (link).

Copy link

Aren't PARTUUID and UUID different things?

Copy link

I have been attempting to get a RPi4 (2GB) to use a SSD in a SEATAY case. On my Ubuntu 19.04 - lsusb reports ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge. If the SSD is attached to the RPi4 before boot fails with an error. If the SSD is attached after booting the command sudo blkid hangs and will not respond to or any other keyboard action. It does not hang the RPi4 just the terminal. I have attempted to update the firmware (using a RPi3B+) as Th.masKaiser suggests but the version of the firmware remains unchanged - v0.5.0.8 although all other messages report success. The pastebin file appears to have the actions on a Raspberry Pi but the web site referenced is something called odroid xu4. Is there another method (that works) to update the firmware? I have access to Windows 7 & 10, All versions of MacOS X and any x86 Linux but I have no idea what an odroid is. Any help would be appreciated

Copy link

elmicha commented Sep 27, 2019

If I remove the init script that resizes the drive in step 6.4, how will I resize the partition on the USB drive? Does raspi-config work in this configuration?

Copy link

DrYak commented Oct 23, 2019


  • UUID: the number that is set in the filesystem itself (ext4/btrfs/f2fs' UUID, FAT32's Volume ID, etc.)
  • PARTUUID: the number that is set in partition table (dos-type old-school mbr partition don't have any, GPT has UUID per partition, etc.)
  • UUID_SUB: for filesystems that can span multiple devices, each different block device that is a member of the same filesystem (of the same UUID) gets a separate different sub-UUID (e.g.: when using btrfs in RAID0/1 mode, etc.)

You can search for partition both by UUID, PARTUUID and a bunch of other things (See all the things in /dev/disk/by-*)

Because the /dev/sd{letter} numbering isn't stable (it's assigned in the order in which devices pop-up on the USB bus and that's unreliable), falling back upon ID inside the actual partitions (either from the partition table or from the filesystem) and increasing the wait delay time is better.

Copy link

@elmicha I think you'll be able to resize it at any time using gparted - I've not tried out raspi-config.

Copy link

Thank you, it worked for me!

Maybe you should clarify that we work with PARTUUID. (UUID is a different identifier...)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment