Raspberry Pi 4 - Boot from SD, Rootfs on USB

rpi4.boot-from-sd-rootfs-on-usb.md

Raspberry 4B - Boot from SD and rootfs on USB

Update

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.

7. 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:

• SBC Bench
• New firmware

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).

Aren't PARTUUID and UUID different things?

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

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?

@jeremy-creator:

• 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.

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

Thank you, it worked for me!

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