As mentioned in the previous post, the SD cards are not the best media for a large amount of read/writes, as used in the RPi. A USB flash drive is much better suited for this purpose. Plus, SD cards can get permanently damaged due to power spikes. USB drives are much more resilient to this. I bought this low-profile USB drive from Sandisk (USB Drive) and will use it to store the root partition for my RPi. The micro-SD card will thus be used only for the boot partition. This is unavoidable, since the booting requirement from the SD-card is hard coded in the Broadcom SoC in the RPi. But once we have this setup, the SD-card we use just needs to hold the boot data. So this card could be very small (even a 1GB card is large enough).
This procedure is a bit involved the first time, since we need to generate UUIDs. However, the blog by Mel Grubb describes it in a detailed but simple to follow manner, that I won’t bother to reproduce all the steps here. The blog post is here: RPi USB boot.
Following the steps in Mel’s blog, I was able to boot up from the USB drive correctly the first time! Thanks Mel!
1. When you start fresh with a new USB drive, make sure you delete all partitions and re-format it with a GPT type partition table. GPT is the modern replacement for the old MBR and is much more flexible and efficient. Steps to do that are described in detail here: Create GPT type partition table.
2. Before re-sizing the file system to the partition size, unmount it and do a check using:
sudo fsck -f /dev/sd(xx)
Now things become so much easier. I can easily move data to/from the USB drive and my laptop. More reliability, more flexibility, more space.
I’ve made a pdf from Mel’s post. All credit goes to him and the other sources he has referenced. To access the pdf, click here: RPi-boot pdf.
An explanation of the reason why the noatime attribute in /etc/fstab is important for the RPi (limited processing power) can be found here: The noatime attribute.
Also, general fstab reference: fstab
NB: These low-profile tiny USB 3.0 drives run very hot ♨️ This is normal, but be careful while touching them after a lot of activity.
NB 2: So I was wondering where the file system size is stored, in ext(n) file systems. It has something to do with the “block group descriptor table”. You can get this info by doing:
sudo dumpe2fs /dev/sda2 | more
The information will look something like this, for a file system size of around 2GB:
Block count: 516189
Reserved block count: 25809
Free blocks: 59818
Free inodes: 50516
First block: 0
Block size: 4096
The product of ‘block count‘ and ‘block size‘ should equal the file system size. After re-sizing the file system, the ‘block count’ should change.