Running Raspberry Pi 4 from SSD

I’ve been a Home Assistant user for years now, and have gone through using RPi 2, RPi 3, VMware, Intel NUC and various Lenovo’s. Except for SD-card wearout it worked ok with the older Raspberries. However, as I needed more cpu power I upgraded to more powerful gear along the way.

My current setup is a Lenovo Yoga460, and works ok. However, with the RPi 4 I believe I can save some power and have some fun along the way, tinkering with new stuff.

First goal was to get the RPI to run from an SSD, giving me far more I/O capabilities than the regular SD cards.

I found two sites giving me all relevant information, and for my own convenience and future reference I made a short version. All information and more are to be found on the following sites


Steps to make your RPi shine like a star with a fast SSD and USB 3 adapter

  1. Flash both SD and SSD with the latest Raspian of your choice
  2. Boot the RPI with the SD card only and wait until login prompt appears
  3. Login as «pi» and connect your SSD through one of the USB3-ports (the blue ones)
  4. Find your adapter with
    $ sudo lsusb
    Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
     Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
     Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
     Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
     Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

    Mine is the ASMedia, and you also get the ID listed (174c:55aa)

  5. Add the «usb-quirks» part to /boot/cmdline.txt with the ID from your adapter, plus «:u» to unblock it
    usb-storage.quirks=174c:55aa:u console=serial0,115200 console=tty1 root=PARTUUID=6c586e13-02 rootfstype=ext4 elevator=deadline rootwait
  6. Reboot the PI and verify that the settings works (if no boot – remove the SD-card and edit the /boot/cmdline.txt on a different computer). It should look something like this if successful
    sudo dmesg | grep usb
     [    1.332924] usb 2-1: New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00
     [    1.332957] usb 2-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
     [    1.332983] usb 2-1: Product: ASM105x
     [    1.333006] usb 2-1: Manufacturer: ASMT
     [    1.333028] usb 2-1: SerialNumber: 123456789B79F
     [    1.335967] usb 2-1: UAS is blacklisted for this device, using usb-storage instead
     [    1.336071] usb 2-1: UAS is blacklisted for this device, using usb-storage instead
     [    1.336103] usb-storage 2-1:1.0: USB Mass Storage device detected
     [    1.336479] usb-storage 2-1:1.0: Quirks match for vid 174c pid 55aa: c00000
     [    1.336611] scsi host0: usb-storage 2-1:1.0
  7. The next step is to make the PI run the OS from your SSD. For this to work properly you should change the PARTUUID of the SSD. I follow the instructions from James Chambers and use d34db33f. Run the following command:
    $ sudo fdisk /dev/sda
     Welcome to fdisk (util-linux 2.33.1).
     Changes will remain in memory only, until you decide to write them.
     Be careful before using the write command.
     Command (m for help): p
     Disk /dev/sda: 238.5 GiB, 256060514304 bytes, 500118192 sectors
     Disk model: ASM105x
     Units: sectors of 1 * 512 = 512 bytes
     Sector size (logical/physical): 512 bytes / 512 bytes
     I/O size (minimum/optimal): 512 bytes / 512 bytes
     Disklabel type: dos
     Disk identifier: 0x6c586e13
     Device     Boot  Start       End   Sectors   Size Id Type
     /dev/sda1         8192    532479    524288   256M  c W95 FAT32 (LBA)
     /dev/sda2       532480 500118191 499585712 238.2G 83 Linux
     Command (m for help): x
     Expert command (m for help): i
     Enter the new disk identifier: 0xd34db33f
     Disk identifier changed from 0x6c586e13 to 0xd34db33f.
     Expert command (m for help): r
     Command (m for help): w
     The partition table has been altered.
     Syncing disks.


  8. Verify that the changes are working
    $ sudo blkid
    /dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="5203-DB74" TYPE="vfat" PARTUUID="6c586e13-01"
    /dev/mmcblk0p2: LABEL="rootfs" UUID="2ab3f8e1-7dc6-43f5-b0db-dd5759d51d4e" TYPE="ext4" PARTUUID="6c586e13-02"
    /dev/sda1: LABEL_FATBOOT="boot" LABEL="boot" UUID="5203-DB74" TYPE="vfat" PARTUUID="d34db33f-01"
    /dev/sda2: LABEL="rootfs" UUID="2ab3f8e1-7dc6-43f5-b0db-dd5759d51d4e" TYPE="ext4" PARTUUID="d34db33f-02"
  9. Now you have to tell the bootloader which partition the PI should use as «root». Edit /boot/cmdline.txt again and replace the partuuid with the one you just changed. It should look something like this, and
    usb-storage.quirks=174c:55aa:u console=serial0,115200 console=tty1 root=PARTUUID=6c586e13-02 rootfstype=ext4 elevator=deadline rootwait quiet init=/usr/lib/raspi-config/

    Replace it with this

    usb-storage.quirks=174c:55aa:u console=serial0,115200 console=tty1 root=PARTUUID=d34db33f-02 rootfstype=ext4 elevator=deadline rootwait quiet init=/usr/lib/raspi-config/


  10. Reboot the PI and verify that you are now using the SSD
    $ findmnt -n -o SOURCE /


  11. The update /etc/fstab to reflect the changes you’ve made. It should look like this
    cat /etc/fstab
    proc            /proc           proc    defaults          0       0
    PARTUUID=6c586e13-01  /boot           vfat    defaults          0       2
    PARTUUID=6c586e13-02  /               ext4    defaults,noatime  0       1

    Replace the second line reflecting the «root partiton» with the new partuuid

    proc            /proc           proc    defaults          0       0
    PARTUUID=6c586e13-01  /boot           vfat    defaults          0       2
    PARTUUID=d34db33f-02  /               ext4    defaults,noatime  0       1

    The final step is to resize the partition on your bright and shiny SSD

  12. Log in and become root ($ sudo su -). The run the following commands
    cp /usr/bin/raspi-config ~ 
    sed -i 's/mmcblk0p/sda/' ~/raspi-config
    sed -i 's/mmcblk0/sda/' ~/raspi-config

    Then run the modified version of raspi-config


    Once it launches, go to Advanced Options and then Expand Filesystem. This may take a while, depending on your attached USB storage device. Once it’s finished, you’ll see the following message:

After a final reboot you should see the partition fully expanded


Change disk sector size from 520 bytes to 512 bytes

If you happen to have an old SAN which contains perfectly usable disks, you might experience that hooking these disks onto youe SAS HBA/Raid-controller won’t work out of the box. I recently pulled 11 disks from an old EMC AX-4 for reuse in a PowerEdge 720XD (10 disks for RAID-10 plus 1 hotspare and 1 SSD for CacheCade), and noticed that the disks had an unsupported formatting. I forgot to screenshot the info from my disks, so I snipped the info from

From dmesg

[ 86.717949] Vendor: IBM Model: IC35L146 CLAR146 Rev: R58A 
[ 86.717970] Type: Direct-Access ANSI SCSI revision: 03 
[ 86.720959] sdb : unsupported sector size 520. 
[ 86.720966] SCSI device sdb: 0 512-byte hdwr sectors (0 MB) 
[ 86.722822] sdb: Write Protect is off 
[ 86.722828] sdb: Mode Sense: e3 00 00 08 
[ 86.725797] SCSI device sdb: drive cache: write through 
[ 86.725908] sd 0:0:1:0: Attached scsi disk sdb 
[ 86.726103] sd 0:0:1:0: Attached scsi generic sg1 type 0

As can be seen – these disks had an unsupported sector size (520 vs the regular 512). In order to get the disks working I installed the sg3_utils on my CentOS machine.

Perform a scan and see the disks available for a sector size change

# sg_scan -i
/dev/sdb: scsi channel=0 id=2 lun=0
Vendor: IBM Model: IC35L146 CLAR146 [rmb=0 cmdq=1 pqual=0 pdev=0x0]

As said – my output wasn’t exactly like this, but you get the idea… Then perform the sector size change

# sg_format –format –size=512 /dev/sdb
Vendor: IBM Model: IC35L146 CLAR146 peripheral_type: disk [0x0]
Mode Sense (block descriptor) data, prior to changes:
Number of blocks=573653847 [0x22314357]
Block size=520 [0x208]
A FORMAT will commence in 10 seconds
ALL data on /dev/sg8 will be DESTROYED
Press control-C to abort

I had Seagate 600GB 15k disks, and I believe the formatting was close to 60 minutes per disk. I had 11 of these, and to speed things up I just did’em all in parallell 😉 The PERC complains about unsupported disks, but I imagine these disks will work just fine in our dev-environment.

2022 Update

Tried the same procedure with some old SAN SSDs, and the command now (Ubuntu Server 20.04) is

sg_format -v –format –size=512 /dev/sgX

root@ubnt20:~# sg_format -v --format --size=512 /dev/sg4
TOSHIBA 5SRB384C EMC3840 PC4A peripheral_type: disk [0x0]
<< supports protection information>>
Unit serial number: 87J0A06XT3EE
LU name: 58ce38e07c9000ed
mode sense(10) cdb: 5a 00 01 00 00 00 00 00 fc 00
Mode Sense (block descriptor) data, prior to changes:
block count maxed out, set <<longlba>>
mode sense(10) cdb: 5a 10 01 00 00 00 00 00 fc 00
<<< longlba flag set (64 bit lba) >>>
Number of blocks=7348420608 [0x1b6000000]
Block size=520 [0x208]
mode select(10) cdb: 55 11 00 00 00 00 00 00 24 00

Windows Storage Spaces 2012 – some references

Just a few links and references that I’ve found helpful…

Administrasjon av ZFS og cache

En liten reminder for meg selv hvordan dette gjøres på f eks FreeNAS, OpenIndiana og OmniOS