Raspberry Pi 4 USB Boot Config Guide for SSD / Flash Drives

Raspberry Pi 4 with Samsung 950 Pro NVME SSD
Raspberry Pi 4 with Samsung 950 Pro NVME SSD

The Raspberry Pi 4 is finally here and has a lot of exciting changes. One very major downside is that it doesn’t support true USB booting yet out of the box (like the 3 series did). The Raspberry Pi foundation states that it is being worked on and will be added back with a future update. No timeline has been given yet for that to happen but they state it’s one of their top priorities.

Most of my projects heavily depend on having good performing storage so sitting and waiting was not an acceptable solution. In this guide I’ll show you a workaround to use USB devices as your rootfs device and use a Micro SD card as bootloader only which gives us full SSD performance after boot! To see exactly how much of a performance difference this makes (spoiler: it’s gigantic) check out the Raspberry Pi Storage Benchmarks.

I highly recommend doing this on a completely new install. If you try to upgrade your old ones and something goes wrong there’s a good chance you might lose data. We will be modifying the boot partition, resizing partitions, etc. so don’t use a drive with any data on it unless you are positive you have all of the steps down!

Compatible USB 3.0 Adapters

The Raspberry Pi 4 is proving to be picky about what SATA, M.2, etc. adapters will work in the USB 3.0 port. The USB 3.0 ports are the ones in the middle that are blue inside. The black ones are USB 2.0 and won’t give you the faster speeds the new Pi offers.

It’s very likely that some of these will be fixed via software and firmware updates and the Raspberry Pi Foundation has several open known issues related to USB 3. Until that happens though I will maintain a list here of known working ones and known problematic ones. It’s still very early in the release of the Pi 4 so we still have a lot to learn about which adapters work / don’t work. If you have working and nonworking adapters leave a comment and I’ll add it in this list.

If the adapters worked before on older Pis then one thing you can try is putting them in the black USB 2.0 ports. Obviously this is stupid because we all want the Pi 4 performance gains but if you end up needing to buy a new adapter this will give you a workaround until a replacement arrives!

Find USB adapter chipset

There are certain chipsets used in adapters that are known to be working/not working.

pi@raspberrypi:~ $ 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

This is a lsusb dump of all my connected USB devices. I have bolded the line with the USB bridge device. We can see that the chipset is ASM1153E

Known Good Chipsets

  • ASMedia ASM115X (StarTech 2.5″ SATA)

Known Working Adapters

2.5″ SATA

StarTech.com 2.5″ SATA to USB Cable

Confirmed working by dzm in the comments

ELUTENG 2.5″ SATA to USB 3.0

The ELUTENG is one of the known working 2.5″ SATA to USB 3.0 adapters for the Pi 4.

CSL SL – USB 3.0 auf SATA Adapter

The CSL SL adapter is confirmed to be working by Krikitt in the comments. Might not be available in the US.

M.2 Adapters

Shinestar M.2 NVME to USB Adapter

This is the adapter I’m using in the picture at the top of the article. It is for NVME M.2 drives.

QNINE M.2 SATA to USB Adapter

I used this adapter to benchmark M.2 SATA Lite-On and SanDisk drives — working great in 3.0 ports.

mSATA

Tanbin mSATA Micro SATA to USB Adapter

I used this mSATA to USB adapter for my Crucial M550 benchmark — working in 3.0 ports.

fe2008 mSATA to USB 3.0 Adapter

Confirmed working in comments by Nico

Power Adapters

Canakit USB-C Raspberry Pi 4 Power Supply

Known Problematic Adapters

USB Boot Instructions

  1. Prepare Bootloader SD Card – Image your SD card with the latest Raspbian 10 “Buster” release (I prefer Raspbian Lite) however you would normally do it.
  2. Prepare SSD / Flash Drive – Image your SSD or Flash Drive. Make sure you create the empty file named “ssh” on the boot partition of both drives.
  3. Boot / Update Raspberry Pi – Start up your Raspberry Pi with only the SD card in the slot. After the Pi finishes booting up plug in your SSD / Flash drive.
  4. Run sudo blkid – With your SSD / Flash drive plugged in type the command “sudo blkid” (example below)
  5. Identify drive – Your list will contain /dev/mmcblk0p1 and 2 (SD card) and your SSD / Flash drive (usually/dev/sda1 and 2).
    We are looking for the PARTUUID of your flash / SSD drive’s second partition (rootfs). This will end with -02. Here is an example:
    /dev/sda2: LABEL=”rootfs” UUID=”638417fb-7220-47b1-883c-e6fee02f51ac” TYPE=”ext4″ PARTUUID=”0634f60c-02″
    Save or white a note somewhere of the values for both drives. We will use both PARTUUIDs for /dev/sda* and dev/mmcblk* later.
  6. Edit /boot/cmdline.txt – First make a backup by typing: sudo cp /boot/cmdline.txt /boot/cmdline.txt.bak
    Now type “sudo nano /boot/cmdline.txt” – Change your boot command to load the partition from the SSD / Flash drive instead of your SD card.
    Before: dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=af1800e7-01 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
    After: dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=0634f60c-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
  7. Reboot Pi – If your Pi won’t boot put your micro SD into a computer and restore /boot/cmdline.txt.bak to get back into the Pi.
    Note: the first boot with your SSD / Flash drive will be slow the first time as it runs fsck on the drive and other first boot configuration.
    It can take over a minute or two sometimes for really big drives so give it a little bit of time here before assuming it didn’t work
  8. Update fstab – Change /etc/fstab entry for /boot to point to the SD card to ensure that firmware and bootloader updates retrieved — detailed example/instructions in section below. Reboot after updating fstab.
  9. Resize file system – Upon first startup the size of your root (/) filesystem partition will only be 1.8G no matter how big your drive is — see section below for detailed example/instructions
  10. Update Pi – Type “sudo apt-get update && sudo apt-get dist-upgrade” to update the system and firmware.

Your system will now be running completely from your USB drive! To verify this, run the command “findmnt -n -o SOURCE” / to ensure your root partition has switched over as shown below to /dev/sda2 instead of /dev/mmcblk0p2.

pi@raspberrypi:~ $ findmnt -n -o SOURCE /
/dev/sda2

Updating fstab

Right now your fstab file on the USB drive is automounting the /boot/ partition from the USB drive even though it isn’t being used. We need to update this to your SD card so that firmware/bootloader updates are actually utilized.

Get Device PARTUUIDs

First lets get a list of all storage devices attached to the Pi and their IDs (we will use these later). Type the following command:

lsblk -o name,label,partuuid

This will output a device tree with the name and label of each partition and the PARTUUID. The tree looks like this:

NAME        LABEL       PARTUUID
sda
├─sda1      system-boot 20945b24-01
└─sda2      writable    20945b24-02
mmcblk0
├─mmcblk0p1 system-boot f65c7036-01
└─mmcblk0p2 writable    f65c7036-02

We see that we have two storage devices attached (sda and mmcblk0). Each of these devices also has two partitions. Notice that both devices have a partition with the label “system-boot”. This is our target.

Edit /etc/fstab File

We are now ready to edit the /etc/fstab file. To begin editing the file type:

sudo nano /etc/fstab

Your current file will look like this:

cat /etc/fstab
proc                  /proc           proc    defaults          0       0
PARTUUID=20945b24-01  /boot           vfat    defaults          0       2
PARTUUID=20945b24-02  /               ext4    defaults,noatime  0       1

We want to change the /boot partition (ending with -01) to load our Micro SD cards PARTUUID instead of the USB drives. To do this simply replace the PARTUUID field on the line that has /boot in it with the PARTUUID from mmcblk0p1. After making the change my /etc/fstab file looks like this:

proc                  /proc           proc    defaults          0       0
PARTUUID=f65c7036-01  /boot           vfat    defaults          0       2
PARTUUID=20945b24-02  /               ext4    defaults,noatime  0       1

Press Ctrl+X to tell nano to save our changes.

Now type sudo reboot to restart the Pi.

Enable SSH on Micro SD Partition

Make sure the SD card and new drive both have a blank “ssh” file if you want to keep SSH enabled. Even if you had it on your USB storage device if you didn’t create one on your SD card the next time you reboot you won’t be able to SSH in.

ot. After reboot typing: “df -H” should show /boot/ as being the SD card again (mmcblk0). Now we can be sure that any updates to the /boot/ partition from apt-get are applying to our system.

Resizing Filesystem

By default the partition on the SSD / Flash drive will only be 1.8G. The Pi expands this automatically on micro SD drives but we will need to do it ourselves for a SSD / Flash drive. To do this we need to expand the partition and then resize the file system.

First let’s open fdisk and print the partitions:

pi@raspberrypi:~ $ 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: 2115
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 33553920 bytes
Disklabel type: dos
Disk identifier: 0x0634f60c
Device     Boot  Start     End Sectors  Size Id Type
/dev/sda1         8192  532480  524289  256M  c W95 FAT32 (LBA)
/dev/sda2       540672 4292607 3751936  1.8G 83 Linux

There is the line we need. Our start value for /dev/sda2 (rootfs) is 540672. Next we need to remove and recreate the partition as a larger size. If you make any mistakes during this command just close fdisk by pressing q. The changes won’t be written to disk. If you mess up any of the commands the drive will no longer boot and you’ll have to start over again so be careful!

Command (m for help): d
Partition number (1,2, default 2): 2
Partition 2 has been deleted.
Command (m for help): n
Partition type
    p   primary (1 primary, 0 extended, 3 free)
    e   extended (container for logical partitions)
Select (default p): p
Partition number (2-4, default 2): 2
First sector (532481-500118191, default 589815): 540672 (enter the start value exactly as it was, the default will be wrong)
Last sector, +/-sectors or +/-size{K,M,G,T,P} (540672-500118191, default 500118191): (press enter to accept default which is the full disk)
Created a new partition 2 of type 'Linux' and of size 238.2 GiB.
Partition #2 contains a ext4 signature.
Do you want to remove the signature? [Y]es/[N]o: n (don't remove signature)

If everything went well then type “w” and press enter. Otherwise press “q” to quit and try again. Once you enter “w” the changes will be permanently written to disk!

Now reboot the system. Type “df -h” to view the current disk:

pi@raspberrypi:~ $ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       1.8G  1.2G  450M  73% /
devtmpfs        866M     0  866M   0% /dev
tmpfs           995M     0  995M   0% /dev/shm
tmpfs           995M  8.4M  987M   1% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           995M     0  995M   0% /sys/fs/cgroup
/dev/sda1       253M   40M  213M  16% /boot
tmpfs           199M     0  199M   0% /run/user/1000

We can see our disk is still 1.8G even after resizing the partition. That’s because we still have one more step! We need to resize the filesystem to fill our new partition space. For this we will use “sudo resize2fs /dev/sda2”:

sudo resize2fs /dev/sda2
resize2fs 1.44.5 (15-Dec-2018)
Filesystem at /dev/sda2 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 15
The filesystem on /dev/sda2 is now 62447190 (4k) blocks long.

Now let’s check df -h again:

Filesystem      Size  Used Avail Use% Mounted on
/dev/root       235G  1.2G  224G   1% /
devtmpfs        866M     0  866M   0% /dev
tmpfs           995M     0  995M   0% /dev/shm
tmpfs           995M  8.4M  987M   1% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           995M     0  995M   0% /sys/fs/cgroup
/dev/sda1       253M   40M  213M  16% /boot
tmpfs           199M     0  199M   0% /run/user/1000

And that’s it! You will now be using all of your space on your SSD / Flash drive.

Conclusion

The Samsung 950 Pro NVME drive in the featured picture scored a 9189 on the Raspberry Pi Storage Benchmark. The previous all-time record score on a Pi 3B+ was 3561. The performance gains are very real and very dramatic.

For me getting this performance is well worth having to waste a micro SD card just to be a bootloader. I am largely after the USB 3.0 bus and gigabit ethernet performance improvements and using this method I am able to achieve the performance I was after without waiting an indeterminate amount of time for the feature to be added back in!

Although there are ongoing compatibility issues and we lack the super easy native USB booting support we had before I’m more than willing to go through the growing pains to finally get rid that ancient USB 2.0 bus! Just make sure if you are planning to build a system you plan your adapters and parts accordingly.

142 thoughts on “Raspberry Pi 4 USB Boot Config Guide for SSD / Flash Drives”

  1. Avatar for Dave

    Hi Guys I followed these instructions having set up Ubuntu on my pi 4. So I now need Ubuntu to boot from usb but cmdline.txt does not contain any uuid for any drives for me to re-point the thing to use usb instead. Has anyone got any advice please?

    1. Avatar for jamesachambers

      Hey Dave,

      Check out my reply to DerFritz below, basically just change root=/dev/sda2 instead of using PARTUUIDs on the cmdline.txt for Ubuntu

  2. Avatar for Bruce Schneider

    I’m trying to put your ubuntu image(V12) on a ssd and boot from buster lite on sd. Fails with a fails with ‘kernel panic – not syncing’. No luck… Worked OK with buster on sd and ssd. Any suggestions???

    1. Avatar for jamesachambers

      Ubuntu works a little bit differently. For that one you may want to try /dev/sda2 like this:

      dwc_otg.fiq_fix_enable=2 console=serial0,115200 console=tty1 root=/dev/sda2 rootfstype=ext4 rootwait rootflags=noload net.ifnames=0

  3. Avatar for JeffHart

    Thanks all for your tips & guidance. Made it work the hard way, for some reason having issues (cerebral flatulence) on getting the rsync exclude to properly exclude, but was able to bypass by using remote rsync of /boot to an SSD attached to another rPi4, move the drive to the intended rPi4, update cmdline.txt and fstab and so far it’s working, booting from microSD with rootfs on SSD. Used a StarTec USB cable and a Crucial BX500 240GB drive.

    Since I’ve already purchased some of the Sabrent SATA to USB, I decided to risk pulling the SSD from the StarTec and installing it in the Sabrent SATA to USB enclosure and luckily it booted. Checked syslog and didn’t appear to be anything different in the boot process between the two controllers. lsusb shows the Sabrent as “JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge”

    While that worked far a lite image, doing a full image would be very painful, so instead attached an SSD with two partitions to the rPi4 booted from a clean full image on a microSD. Copied the full image zip from my PC to a flash drive, installed and mounted the flash drive on the rPi4 and copied the zip to the second partition that will eventually be a data store. Unzipped the image, mounted it and am rsyncing between two partitions on the same SSD drive in USD 3.0 port with Sabrent SATA to USB, still taking longer than I’d hoped; after two hours has transferred 1.6GB of 5.7GB

    Will update with results and if they’re good, with more details on mounting the image file, etc.

    1. Avatar for jeffhart

      Quick update as to not lead anyone else down this rabbit hole – systems are all unstable, have tried adding “usb-storage-quirks=aaaa:bbbb” with with the correct vendor and product ID’s ( 152d:0578) for the Sabrent/JMicron to cmdline.txt to no avail. I’m working on setting up a Kubernetes on Ceph cluster so too many moving parts, am going to need to drop back and diagnose methodically. Will update if I find anything that may be helpful.

  4. Avatar for Phil Bolduc

    I installed and tried Win32DiskImager, however, when flashing the .img I only got a single partition. It is really strange because when I had tried your instructions previously using an Orico adapter, I had different PARTUUIDs, but could not get it to work. So I ordered the ELUTEN ones. Now I am only getting MBR partitions. I spent an hour trying this morning at couldn’t get it working. I hope to find more time this next week to try again. I will continue following this page for any updates.

  5. Avatar for Phil Bolduc

    Does anyone else have the problem that the external drive has the same PARTUUID as the SD card? I tried using sgdisk, etc. I dont understand why my external SSD has the same PARTUUID as the SD card. Any suggestions?

    pi@raspberrypi:~ $ 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

    pi@raspberrypi:~ $ 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=”6c586e13-01″
    /dev/sda2: LABEL=”rootfs” UUID=”2ab3f8e1-7dc6-43f5-b0db-dd5759d51d4e” TYPE=”ext4″ PARTUUID=”6c586e13-02″
    /dev/mmcblk0: PTUUID=”6c586e13″ PTTYPE=”dos”

    1. Avatar for jamesachambers

      If you are using MBR instead of GPT then you need to use fdisk’s advanced menu to change the PARTUUID. Using MBR is also why the PARTUUIDs are the same. If you google “PARTUUID same” you’ll see all Raspberry Pi posts going back for years as this has been a problem ever since Raspbian started using PARTUUIDs instead of the old /dev/mmcblk2p1 way.

      Give fdisk’s expert menu a go instead of gdisk and I think you’ll be all set!

      I’m going to add this to the instructions (it looks like from the comments there’s a couple other things I need to edit in there as well that come up a lot).

    2. Avatar for Phil Bolduc

      This is really odd. Maybe it is the flasher I am using. I changed my external SSD to GPT using Windows and confirmed in the PI,

      pi@raspberrypi:~ $ 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/mmcblk0: PTUUID=”6c586e13″ PTTYPE=”dos”
      /dev/sda1: PARTLABEL=”Microsoft reserved partition” PARTUUID=”f0045a2f-9945-47d6-a37c-3afa339052cb”

      Then I used balena-etcher (1.5.57) to flash 2019-09-26-raspbian-buster-lite.zip to the SSD. When mounting it back in the Raspberry Pi, it was back to MBR,

      pi@raspberrypi:~ $ 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/mmcblk0: PTUUID=”6c586e13″ PTTYPE=”dos”
      /dev/sda1: LABEL_FATBOOT=”boot” LABEL=”boot” UUID=”5203-DB74″ TYPE=”vfat” PARTUUID=”6c586e13-01″
      /dev/sda2: LABEL=”rootfs” UUID=”2ab3f8e1-7dc6-43f5-b0db-dd5759d51d4e” TYPE=”ext4″ PARTUUID=”6c586e13-02″

      Perhaps there is a different flashing utility I should be using? It seems balena-etcher always writes as MBR? I am flashing my SD and SSD on a Windows machine.

  6. Avatar for ciB

    I flashed bot SSD and SD card with etcher, but now both my devices have the same partuuuid. I tried changing it with gdisk, but my drives are using mbr and not gbt. How should I proceed? could I use the UUID instead?

  7. Avatar for Mario

    I just tested “Sabrent 2.5-Inch SATA to USB 3.0 Tool-Free External Hard Drive Enclosure” and it boots perfectly from USB 3.0 port.
    https://www.amazon.com/gp/product/B00OJ3UJ2S

    I fixed the problem of keyboard and mouse not working in Buster (Desktop version). It turns out I updated the system on micro SD card too early. I just had to overwrite boot contents on micro SD with the ones from SSD that was just freshly flashed. Hope this helps some folks.

  8. Avatar for Markus

    Thank you for that very good explanation. But one question remains. Do I still need the SD card in the Raspberry Pi slot?

    1. Avatar for jamesachambers

      Hey Markus,

      This is still necessary as a workaround for now until the Pi 4 official USB booting support is released

  9. Avatar for Mario

    Buster desktop booted fine off SSD but keyboard and mouse is not working. I am running the latest firmware version. Please help.

    1. Avatar for jamesachambers

      Hey Mario,

      This happens if apt-get upgrade is ran before the final step. The reason is if you update before everything else is in place things like kernel8.img won’t be the same on both the SD card and the USB drive which will cause the kernel modules to fail to load (breaking your USB).

      Wait until the very final step before upgrading anything. Ignore any prompts that you get saying there’s updates available, etc. until after the very final step and you won’t encounter this!

  10. Avatar for dave

    hi I have the startech usb adapter and a 128gb ssd attached following the instructions it reboots after changing the config.txt to boot to the new drive.
    upon rebooting I can see the First line of text that flashes through failed to load kernel modules! it continues to boot to the ssd but I get no mouse or keyboard working and cannot connect via ssh even though the screen says its loaded but the password needs changing from default
    have I done something wrong?

    many thanks

    1. Avatar for jamesachambers

      Hey dave,

      This means that apt-get upgrade was ran before the final step so your SD card and your SSD no longer match. Don’t update until after the very final step and you will be fine!

  11. Avatar for Mikel Finch

    Great article. My only change is that I setup my USB HDD by hand and copy data via rsync.

    So, my setup that follows assumed you have a big USB HDD with one huge partition (/dev/sda1). Imaging my HDD is a bad idea since I need a GUID partition table. I setup ssh to edit fstab and cmdline.txt

    Steps are…

    – image microsd
    – boot from microsd
    – setup ssh / hostname and reboot (sudo raspi-config)
    – connect and prepair USB HDD (fdisk, mkfs -t ext4)

    sudo mount /dev/sda1 /media/new

    – copy microsd to USB HDD

    sudo rsync -avx –exclude=’/media/’ / /media/new

    – setup for USB boot (boot/cmdline.txt and /etc/fstab)

    sudo blkid

    /dev/sda1: UUID=”e4cd2f42-6785-42e5-9de1-56282d3ffd0a” TYPE=”ext4″ PARTUUID=”36af4b27-4fc2-af4f-9ae2-804b8226f594″

    cd /boot
    sudo cp cmdline.txt cmdline.txt.back
    sudo vi cmdline.txt

    dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=36af4b27-4fc2-af4f-9ae2-804b8226f594 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

    cd etc
    sudo cp fstab fstab.bak
    sudo vi fstab

    PARTUUID=36af4b27-4fc2-af4f-9ae2-804b8226f594 / ext4 defaults,noatime 0 1

    sudo reboot

    – verify setup

    findmnt -n -o SOURCE /
    /dev/sda2

    1. Avatar for jamesachambers

      Hey Mikel,

      Thanks for sharing your steps! I had not done it this way before but I’m sure this will help a lot of people who also need/want to maintain their existing partition table.

    2. Avatar for Craig

      Hi Mikel, that’s an awesome addition to this guide. Had to read your commands and the detailed guide by James together to work it out but I’ve migrated my Pi4 without having to reinstall the OS and Hassbian/Home Assistant. Performance improvement is massive due to the SSD.

      1. Avatar for jamesachambers

        I agree! It’s so awesome that it’s going to go in the guide as this step has been burning a lot of people and this works even if apt-get upgrade runs and essentially lets you fix it without starting over.

Leave a Comment

Your email address will not be published. Required fields are marked *

Type here..