STICKY: HOWTO: Move the filesystem to a USB stick/Drive

[so-what]

Great tutorial, tried many of them and they never work. I just rebooted twice and still booting without problems. Only thing missing is the code for changing the bootfile;

Code: Select all

sudo nano /boot/cmdline.txt

tnx for your effort

[paulv]

Thank you for the tip, I've added the command to edit /boot/cmdline.txt.

[anderml1955]

Are the new boot options now in the mainstream kernel and bootloader? If so can we "unhold" then and revert to the normal apt-get updates.

Thanks,
Mark

[DougieLawson]

Are the new boot options now in the mainstream kernel and bootloader? If so can we "unhold" then and revert to the normal apt-get updates.

They're now available in 4.4.47+ and 4.4.47-v7+ kernels/bootcode which you'll get with sudo rpi-config. They are not yet in the main-stream apt-get kernel package.

[ilovemipi]

Excellent guide and bang up to date, thanks @paulv

Just a couple of points:

1. With gpu_mem set at anything less than 32 you will get a warning message on bootup as covered by the GitHub issue at https://github.com/raspberrypi/firmware/issues/428

2. I am getting a "Duplicate entry in /etc/fstab" message on bootup. I think this is because when I added the uuid entries for the 1st and 2nd USB partitions I forgot to comment out /dev/sda2. Even with it now commented out I am still getting the "Duplicate" warning and the 2nd partition isn't shown in df -h, but /mnt/my_data/ is actually available. Does anyone know what the fix is to remove the warning and for the 2nd partition to appear in df -h?

[kwalk]

Hello - I have a RPi 3 that I installed in a Pi-Top back in January (running Raspbian - not the Pi-Top software). After crashing the SD card a couple of times, I found this thread and decided to try out moving the file system to USB card. So following the instructions, everything works as advertised - with the exception that the system seems incredibly slow now. Some before / after times as example...

Boot-up = 24s to X-window using card / 55s to X-window using USB
Open terminal window = 1s / 40s!
Open Chromium web browser = 6s / 45s
Open Python = 6s / 21s
Shutdown (to red power light off) = 15s / 35s

Note, these seem to be "first to open" times. in other words, after I open the first Terminal window, if I open a second, it pops open almost immediately.

I'm pretty new to Linux, so am at a loss as to how to trouble shoot. I've done quite a bit of searching, but haven't found anything that helps.

Does anyone have suggestions on what my issue might be or where to look?

[sudhir_brahma]

I had a similar issue. Traced it to a slow USB drive. Changed it to a faster one now all ok.

[kwalk]

Thanks, Sudhir. I'll try a new USB this weekend. Was this USB spec related or a bad (slow) USB that didn't meet specs to begin with? My initial effort was with a brand new PNY USB 2.0 stick I bought from Office Max. I don't remember the specs on it, but could probably look them up from their website. RPi3 has only USB 2.0, so USB 3.0 stick won't necessarily be any faster, is that correct?

Thanks,
Keith

[sudhir_brahma]

I have noticed that a SD card reader (USB) works faster- its a USB2 card reader from SanDisk. I suppose since USB3 is backward compatible with USB2, atleast its speed will be 'good enough' or not be a bottleneck. I have ordered for a Quantum USB3 SD card reader to experiment. I must caution readers here that a micro-sd card (with a USB card reader) does not work good enough. It does not fail fully, but application starts misbehaving in unexpected places. Stick to a SD card and not a micro-sd...just my experience.

[elkberry]

Now that USB boot is also supported on the rpi-update main branch, I've successfully converted three Raspberry Pi 3s to USB boot from USB 3.0 memory thumb drives (16GB).

Thank you very much for this useful feature! Because my Raspberry Pis are demonstration systems to show and test certain network autoconfiguration magic, I need to change the OS configuration of the individual Pis. Before, this meant fiddling with the mSD cards, now it's a simple pull&plug. Much, much better.

I followed the instructions given in the official documentation here: https://www.raspberrypi.org/documentati ... des/msd.md

[sudhir_brahma]

I am unsure if partitioning of a flash drive - USB or micro SD into 2 partitions is the cause of unreliability we see in RPI in the first place. I would recommend having the preboot still on the microsd

[kwalk]

Thanks, Sudhir. I'll try a new USB this weekend. Was this USB spec related or a bad (slow) USB that didn't meet specs to begin with? My initial effort was with a brand new PNY USB 2.0 stick I bought from Office Max. I don't remember the specs on it, but could probably look them up from their website. RPi3 has only USB 2.0, so USB 3.0 stick won't necessarily be any faster, is that correct?

Thanks,
Keith

Follow-up - did this with two new USB sticks; one Sandisk USB3 and a cheap PNY USB2, both from Wal-mart. The USB3 resulted in similar performance to the microSD card, the USB2 card was extremely slow - similar to the performance noted in previous post. I assume this must be a "USB2 stick quality" issue and not a USB2 v USB3 issue, since the Pi3 doesn't have USB3 ports. At some point I may try a more expensive USB2 stick and see how it performs.

Keith

[elkberry]

Well, it may be a flash write performance issue or a crappy flash controller thing, too. There are several factors in the game, so it's difficult to guess beforehand.

I had multiple Lexar USB 3.0 thumb drives, which performed fair, but have broken flash controllers: flashing an image with a few sectors to much now causes them to fail and resetting now in normal operations. No way to bring them back to reliable operation, even zeroing out makes them fail. I'm now using SanDisk 3.0 UDB thumbdrives, which are performing better under normal conditions.

On a side note, I had bad experiences with mSDs from SanDisk in the past for recording video on HD Heros, where basically two loosers met each other. But the SanDisk USB 3.0 thumb drives 16GB works decently, so it's a game of hit and miss.

[gkreidl]

Update warning removed because the problem has been solved and is not related to running the file system from USB.

See: viewtopic.php?f=66&t=176437

[paulv]

I just updated/upgraded to 4.4.50+ #970, and when running raspi-config, there is indeed nothing yet about the new booting from other devices than the SD card in there. Still not "main-stream".

[SomniusX]

Well i've had OTP as 0x1020000a

I'm using one Intel SS series ssd 128gb connected to sata3 to usb interface, went thru the whole process but the pi (rpi3) pings back on the network but doesn't let me log in, not by flashing clean system on the sd, not by connected the ssd disk at even the same usb port..

So.. i'm a bit frustrated that the my pi had something done to it by me wrongfully using this guide..

Any ideas?

[SomniusX]

My sd died on me, other sd did the job.. used the guide and now have the ssd working!

[paulv]

I have updated the header of the original post somewhat to bring it more in line with the UUID vs /dev/sd* changes for the filesystem identifiers, now that the Foundation changed to the more robust method since the 2017-04-10 version. I also updated the link to the Model 3 description for booting from a USB drive.

At a later date, when the new method is more established and most users will have migrated, I will remove the "simple" method.

Enjoy!

paulv

[anderml1955]

Regarding performance of flash drives. I did some testing last year and landed on a Sandisk Extreme 128GB drive. Info is in this link - https://www.raspberrypi.org/blog/pi-3-b ... nt-1265809

[PeterO]

I have updated the header of the original post somewhat to bring it more in line with the UUID vs /dev/sd* changes for the filesystem identifiers, now that the Foundation changed to the more robust method since the 2017-04-10 version. I also updated the link to the Model 3 description for booting from a USB drive.

At a later date, when the new method is more established and most users will have migrated, I will remove the "simple" method.

Enjoy!

paulv

It looks good, but I have not read it from start to finish (TL:DR being a good thing in this case).

Have you covered the case where you can just "dd" the new raspbian image file onto a blank HDD ? I believe this works and will create a small boot partition and use the rest of the drive for the root file system (which may not be an ideal situation IMO).

I'll be trying it in the next few days when I but a new HDD to replace the one I dropped the other day

PeterO

[PeterO]

Have you covered the case where you can just "dd" the new raspbian image file onto a blank HDD ? I believe this works and will create a small boot partition and use the rest of the drive for the root file system (which may not be an ideal situation IMO).
I'll be trying it in the next few days when I but a new HDD to replace the one I dropped the other day

As expected this "just works"
PeterO

[ahmedawad]

This is really wonderful thank you very much! This can be useful when some one would like to have multiple OSes on the SAME SD CARD.

Many Thanks for the more than excellent work!

[Severian]

This procedure will allow you to run Debian from a USB connected drive, instead of the SD card.

Starting with the 2017-04-10 kernel version, the Foundation changed to a more reliable way of using drive identifiers. This post still shows both methods, but note that using /dev/sd* for the filesystem is no longer recommended. Please implement the procedure for "Multiple Drives" further down. to stay compatible.
Paul

Is using the more reliable /dev/sda method going to break something? I regularly have to fix debian/ubuntu systems that by default use uuids to identify drives to switch to the more reliable /dev/sdx method. It is more reliable, because I make drive backups using image copies of the drive and when you swap to a different drive, the uuid will change and the system won't boot. Using /dev/sdx, either drive boots fine.
Thanks for the article.

[dvaitman]

Hi there,

noticed you update for :"Multiple Drives" using UUIDs instead of /dev/sd*
But I believe in your instructions you are still booting from an SD card.
If I want to boot from a USB with a RPi3, how would the process change?
I know the rpi foundation changed the image burning process to make it seamless to use an SD or USB, but other distributions haven't and I'm struggling to make the Google AIY image to work from a USB. Any help would be appreciated.
thanks,

[paulv]

Hi there,

If I want to boot from a USB with a RPi3, how would the process change?

If you look at the very first post, there is a note about booting directly from a disk for the RPi Model 3.
It's still not main-stream, but seems to work reliably for many users.
Just follow the link to get to the information.

Good luck!