News How to Boot Raspberry Pi 4 From a USB SSD or Flash Drive

Page 2 - Seeking answers? Join the Tom's Hardware community: where nearly two million members share solutions and discuss the latest tech.
Status
Not open for further replies.
I have somewhat related questions but first here's where I'm currently at:

I have a brand new setup with a RPi4 (4GB) and a Samsung M.2 NVMe SSD (250GB) attached via components from Geekworm (X872/X735/X857-C1). I have a 32GB SD micro with NOOBS. I'm waiting for a cable to hook my rig up to a monitor that uses a DVI-D which should arrive Tuesday, June 9th. I have done nothing with this brand new setup other than assemble the hardware. In the meantime, I'm doing my homework and found this discussion.

My question is what should I do when initializing the M.2 SSD? Do I use MBR or GPT/GUID? If I need to use MBR, can I set up a small partition for the boot and use GPT/GUID for the rest of the drive partitions I make? There isn't a lot of discussion on these aspects of setting up an external SSD drive. I think this is because the M.2 NVMe and other SSD drive types are all throttled by the USB3 capabilities so perhaps there hasn't been enough people working with them to generate a lot of discussion.

Given that you'll be burning an image to the SSD (assuming this question is reference the topic of booting from external drive) it doesn't matter what, or if, you initialize the drive. That's all done during the image burn.

Now, if you're planning on using the external drive for "storage" it largely depends on whether it's traditional data or e.g. ROM storage for a RetroPie use. Although that is more on the file system you use than the drive format (i.e. NTFS for external ROM storage for newer RPI4, traditionally FAT32 for them, and of course a multitude of Unix/Linux based file systems if just being used as remote storage for Raspian.) Regarding MBR/GPT specifically, Linux can use either these days (MBR vs. GPT), both for booting and for data.
 
Related: The USB3 to 2.4GHz interference problem is very alive and not so well in the RPi4.
While I can very effectively boot from external drive/USB stick/etc. following the guide (thanks), if the external drive/USB flash drive in question is using the one of the USB3 ports, it causes massive interference with my 2.4GHz remote keyboard (skipped inputs, repeated keystrokes, etc. Problems that can seem symptomatic of low power/battery at first.) Doesn't seem to affect the 8bitdo remote controller (note that I am using their 8bitdo dongle rather than direct Bluetooth connection.)

When the boot drive is plugged into the USB2 ports - absolutely no issues, no interference. Of course, it's also not as fast as USB3. Generally not noticeable, and the benefits of using an SSD with the thousands of small files males it still more responsive and boot as quickly or quicker than the internal sdcard. With the benefit of larger storage.

Just thought the community should know as the USB3 to 2.4GHz interference is a known issue for many years, but most systems now separate the USB3 from WLAN or other devices to try and avoid this. The other USB ports as well as the WLAN antenna are of course much closer in the RPi, so it does cause an issue.

Thank you for replying to my other question. I have my Pi up and running now but have not attempted the boot from SSD yet. What has caught my attention is your topic here about the USB3 to 2.4GHz interference. I have noticed this happening with my Pi. I have components from Geekworm including the following:

X735 power management
X872 M.2 NVMe storage
X857-C1 case

The X872 and the Pi are connected using a USB bridge on the USB3 port. When it's plugged in, my wireless mouse (Logitech MK710) jumps, skips and at times seems to be frozen. When unplugged the mouse works fine. I have tried adding the USB polling setting to the cmdline.txt file and it helps a little bit.

I'm now wondering if buying a USB to USB cable so I can plug the X872 USB3 port to a USB2 port on the Pi might solve the problem (for now). Any thoughts?
 
I'm now wondering if buying a USB to USB cable so I can plug the X872 USB3 port to a USB2 port on the Pi might solve the problem (for now). Any thoughts?
I think that would help - based on similar issues I've had with USB3 flash drives interfering with my wireless mouse on a desktop - although I'd still try it in the USB3 port first. You could also try using a USB extension cable for the wireless mouse dongle to distance it from the Pi/M2 drive.

Apparently Logitech mice are most prone to this issue because they also use 2.4 GHz. Other mice brands may use a different frequency. A different, cheap wireless mouse may be the easiest solution.

- The interference issue I had with on my desktop was best solved by switching to a much better quality USB3 flash drive. The cheap one I was using caused issues, whilst the Sandisk Extreme Pro could be plugged in directly next to the mouse dongle without any apparent interference (and it was much faster). Although, that doesn't help in your case to determine if the interference is being generated by the Pi or the drive adapter...

With that in mind though, an external USB M2 enclosure may be better than the adapter you have - particularly if it is a metal enclosure.
 
I think that would help - based on similar issues I've had with USB3 flash drives interfering with my wireless mouse on a desktop - although I'd still try it in the USB3 port first. You could also try using a USB extension cable for the wireless mouse dongle to distance it from the Pi/M2 drive.

Apparently Logitech mice are most prone to this issue because they also use 2.4 GHz. Other mice brands may use a different frequency. A different, cheap wireless mouse may be the easiest solution.

- The interference issue I had with on my desktop was best solved by switching to a much better quality USB3 flash drive. The cheap one I was using caused issues, whilst the Sandisk Extreme Pro could be plugged in directly next to the mouse dongle without any apparent interference (and it was much faster). Although, that doesn't help in your case to determine if the interference is being generated by the Pi or the drive adapter...

With that in mind though, an external USB M2 enclosure may be better than the adapter you have - particularly if it is a metal enclosure.

Thanks...that's an interesting idea about isolating the dongle. All the components I bought are stacked vertically and enclosed inside a small case. The power manager has a button switch for turning on, rebooting, slow shutdown or forced shutdown via a script. I have not enable that yet as I have not tried to boot from the M.2 SSD. The whole setup can be viewed here:

RPi4/X735/X872 and X857-C1 Case

I may try the extension idea to preserve using the USB 3 port. If not that, then I can only see switching to a wired keyboard and mouse or attaching the X872 (M.2 board) to the RPi4 via a USB 3 to USB 2 port. I have asked Geekworm about this idea as well.
 
Adding a separate update to my reply (#29) above. I have isolated the wireless mouse dongle with a 6" USB extension cable and it works. But by surprise I also discovered something while trying out different locations for the Pi case to sit. I found I can use the Pi without the 6" extension cable if I move the computer at least 6" from the power cord to the monitor! I have that set up this way right now and it works fine. I'm keeping the extension cable as Plan B.

This makes me wonder how many have had the 2.4GHz interference when it could have been caused by where the Pi was positioned relative to any power cords.
 
The instructions worked for me when using the right usb3 to 2.5 SATA HDD/SSD cable.

(only I did a git clone in stead of downloading the zip file).

With an StarTech.com USB32SAT3CB it worked;
With an Delock product-No 62742 it did not.

Thanks for the clear instruction!
 
A new firmware up lets you use any USB device to boot a Raspberry Pi 4.

How to Boot Raspberry Pi 4 From a USB SSD or Flash Drive : Read more
While I managed to set up a raspberry pi4 with archlinux arm booting from an SSD following your advice, I would like to point out a few insights I gained in the process:

Setting up the partitions should be done with gdisk rather than fdisk (package name gptfdisk for arch), as booting with multiple disks connected may result in weird situations if /dev/sdx is used to address the boot device. Using PARTUUID is unique and works independent of usb port used. (blkid will display the necessary information)

Not only /boot/cmdline.txt needs to reflect the new device, but also /etc/fstab, otherwise we end up with weird effects, because /boot doesn't get mounted after the boot process. For instance on pacman -Syu the kernel will not get updated properly. Consequently the modules in /lib/modules don't match the kernel.

Anyway, thanks for providing us with this useful piece of information.
 
Great write up; got it to work first try on Netac 500GB Portable SSD, USB3.2 Gen2 10Gbps, Type-C PSSD
But it failed get it to boot from: SanDisk 500GB Extreme Portable External SSD.

Tested both on 2GB and 4GB rPi4’s; both boot from then Netac USB SSD, but both hang at “4 raspberries” when trying to boot from SanDisk.
Initially each set up with your procedures. After failing to boot SanDisk I used rPi SD imager to copy Netac image to SanDisk… Still failed to boot. So I guess it’s still somewhat hardware dependent.
both done with 2020-06-15 eeprom bootloader.
 
One suggestion I'd like to add. Do not underestimate your cables. Make sure you pick up a USB3.0 or 3.1 cable. Many fast charging cables are only USB2.0.

You can test the speed of your connection to your SSD by issuing 'lsusb -t' command. Alternatively the 'dmesg' command. If all is well then the bus speed should state 5000M. HOWEVER, If you're on USB 2 then you see 480M.

Hope it helps.

PS: curiously enough the correct USB3.1 data cable was in a bargain bin priced NZ$8, whereas fast charging cables were about 20bucks.
 
I try to install the updated bootloader. When i go check the the update is successful, the older bootloader version is still there.
 
Worked for me exactly as described. RPi 4 8gb. Running the latest raspbian 32. Used the util to exactly copy the sd card to my ssd. The only potential problem is whether it expanded the disk to fill the ssd. My card was 64 gig, my ssd is 120gb. I haven't checked that yet. Other than that, I am booting from the ssd.
 
Good day. I am greatful that I have stumbled upon this article. It's well-written (for noobs) and updated with the recent bootloader update to stable. I have finished the upgrading to 120GB SSD from 32GB microSD without any problems. My suggestion for others was that for your peace of mind, kindly create a copy of your microSD to another spare microSD before doing these commands. Keep this routine every before doing any major modifications to your boot drive. More power to the author of this article. Regards.
 
I followed the instruction here and made my PI boot from USB successfully.
A quick note, though.
  • The instruction gave out a typo command on step 3. sudo not Sudo
    • Code:
      sudo nano /etc/default/rpi-eeprom-update
  • I use rpi-clone found here https://github.com/billw2/rpi-clone to clone my whole SD-card to the new USB SSD.
    • rpi-clone will edit fstab (to reflect your new drive UUID) for you, so it's super easy.
  • After the clone, I just shutdown PI, remove SD-card, plug the SSD into a powered hub (to be sure), and it works!
I use rpi-clone as I did all these through SSH from my Windows box, I need a command line for cloning the SD-card.
 
Cannot get this to work at all. Updated everything. Copied over to USB flash drive. Wont boot. Put the original SD into a USB converter, that wont boot either. Last message I get is vcc-sd: disabling. Then just sticks there.

Still boots fine off SD card in the SD slot.

Raspberry Pi 4 Model B Rev 1.1

Sep 3 2020 13:11:43
version c305221a6d7e532693cc7ff57fddfc8649def167 (release)

BOOT_ORDER=0xf41

Fixed:

How is this step not in your tutorial? For me I had to change cmdline.txt.

From - root=/dev/mmcblk0p2.

To - root=/dev/sdb2.

I see that new installs from the latest Rasbian download puts this as - root=PARTUUID=d7ead7b2-02. Either way this will need to be changed, right? How are the directions, as is, working for people?
 
Last edited:
Just followed the instruction, and there needs to be a change to the raspi-config section - 1st Nov the latest raspi-config has changed and the boot option is not 3 any more, it's part of the menu 6 - Advanced Options - "a6 - Boot Order", "a7 - Boot Rom Version"
 
Status
Not open for further replies.