Sunday 19 May 2024 - 03:41:14 UTC 
RSS Feed
SARPi Project - Slacking on a Raspberry Pi
Persistent Storage Device Naming
With Slackware Linux on Raspberry Pi computers, it's possible to refer to storage devices by means of persistent naming attributes using 'udev' instead of the more conventional block device nodes located in the '/dev/' directory - i.e. referencing storage devices and partitions using a disk label or UUID configuration that's guaranteed to remain the same over multiple system (re)boots, regardless of how many are connected.
You can use persistent storage device naming on any mass storage medium, including SD cards.
Traditionally, USB storage devices on Slackware Linux running on Raspberry Pi computers are identified by '/dev/sda', '/dev/sdb', '/dev/sdc', (etc.) and '/dev/sda1', '/dev/sdb2', '/dev/sdc3' (etc.) refer to the partitions which may be located on each storage device. Any microSD cards in a Raspberry Pi card slot are referenced as '/dev/mmcblk0' and any partitions are identified as '/dev/mmcblk0p1', '/dev/mmcblk0p2', '/dev/mmcblk0p3', etc. A NVMe SSD on the Raspberry Pi PCIe interface are referenced as '/dev/nvme0n1' and any partitions are identified as '/dev/nvme0n1p1', '/dev/nvme0n1p2', '/dev/nvme0n1p3', etc.
Why would Slackware Linux users want to change the traditional and standard method(s) of addressing the storage device(s) on their system? Under which circumstances could the order of storage devices ever change?
When booting the Raspberry Pi 4 from a USB storage device, such as a SSD or USB memory stick, then established block device node naming standards are not always guaranteed to remain the same throughout each and every (re)boot when more than one mass storage device is present. The order in which block device nodes are detected and/or allocated can vary.
If you've ever had a USB memory stick plugged in, or added an additional storage drive, and then (re)booted your Slackware Linux system, you may already know where this is going, and why under certain circumstances your operating system does not boot successfully. With ARM devices this can be a very frequent occurence, especially if you're constantly connecting storage devices to it and the order of device detection changes as a result. Storage device '/dev/sda' becomes '/dev/sdb' becomes '/dev/sdc', etc. Persistent storage device naming is the ultimate solution in such cases.
•
Requirements for Persistent Storage Device Naming
• Slackware Linux with udev running on a Raspberry Pi computer.
•
How to Setup Persistent Storage Device Naming
For the purpose of this guide we will be using 'root' user and our Slackware Linux system hostname is 'torq', on a Raspberry Pi 4. This system boots from a Kingston SSDnow V300 480GB 2.5" SSD (Solid State Drive) plugged into the USB3 port via a Startech USB3S2SAT3CB SATA-USB adapter.
IMPORTANT! : Before doing anything...
BACKUP the '/boot/cmdline.txt' and '/etc/fstab' files in the event that things go horribly wrong!
First we'll check any existing block device node settings in '/boot/cmdline.txt' and '/etc/fstab' using the following commands:
root@torq:~# cat /etc/fstab
Remember your results may differ from ours, which are:
So, from these results we can see that in the '/boot/cmdline.txt' file our root partition is referenced as 'root=/dev/sda3'.
In the '/etc/fstab' file we can see that '/dev/sda1' is our boot partition, '/dev/sda2' is our swap partition, and '/dev/sda3' is (again) our root partition.
We could have also used the 'lsblk' command to determine the available mass storage block devices on our system:
It's worth noting here that our '/boot' and '[SWAP]' partitions can be clearly identified under 'MOUNTPOINT'. The root partition is identified by the forward-slash "/", which is where our Slackware Linux operating system is located. This holds true for both outputs of the '/etc/fstab' file and 'lsblk' command.
NB: This is pretty much what to expect with device node naming conventions, according to established Slackware (and Unix) philosophy where everything is a file within the '/dev/' directory. Block devices are mass storage devices such as HDDs and SSDs. Character devices are basically anything else - except for network interfaces, which are sockets.
Now we're going to need some very precise information from the system. So we'll use the 'blkid' command for this purpose:
We use 'blkid' to view details on the available block devices on our system. It's a very handy Linux command that will list all the available devices with their Universally Unique Identifiers (UUID), and other information. Specific information within these results is what's needed for the next step in the process.
If you have (dis)connected a mass storage device and the list hasn't updated, use the 'blkid -g' command option to reset the blkid cache before running the 'blkid' command once again.
Listing specific storage device attributes using the 'blkid' command can be done like this:
blkid -s PARTUUID
blkid -s TYPE
blkid -s UUID
So, next we're going to edit the '/boot/cmdline.txt' file and use the 'PARTUUID' output from 'blkid' command to replace the 'root=/dev/sda3' path for our root partition. We also need to omit the double-quotes around the parameter.
In this file we need to replace 'root=/dev/sda3' with 'root=PARTUUID=35804286-03' to specify that this is the 'udev' epithet of our root partition instead of the block device name in the '/dev' directory. Nothing else needs to be done. As long as you have 'udev' running on your Slackware Linux system this is all that's required.
IMPORTANT! : MAKE SURE that you enter the correct 'PARTUUID' value for your ROOT "/" partition from the output of the 'blkid' command you previously ran. Or else, if you get this wrong you'll end up with a system that does not boot! Your UUID will most likely be different than the one shown here!
If this PARTUUID value is incorrect you will receive a "root filesystem not found" kernel panic error when booting your system!
Then we save and exit this file, and also double-check that it's correct, via the 'cat' command as before:
That looks perfect and was relatively easy to achieve.
Now we're going to edit the '/etc/fstab' file which contains a little more information but it's no less important that the correct 'UUID' values are specified. Note that we'll be dealing with 'UUID' values and not 'PARTUUID' in the '/etc/fstab' file.
As before, we need to omit the double-quotes from around the 'UUID' parameters in all instances within this file. So from the results of our 'blkid' command we need to replace the storage device node names with our 'UUID' values.
• Our boot partition parameter '/dev/sda1' is replaced with 'UUID=8C78-6397'
• Our swap partition parameter '/dev/sda2' is replaced with 'UUID=c7acb34a-6d27-4584-abe1-c55e52a1c468'
• Our root partition parameter '/dev/sda3' is replaced with 'UUID=a62a0930-a10d-410a-9a04-1aebd8807144'
IMPORTANT! : In the '/etc/fstab' file MAKE SURE that you enter the correct 'UUID' values for your partitions from the output of the 'blkid' command you previously ran. Remember that your results will most certainly be different from those displayed here, which are just examples of what needs to be done in order to be successful!
If the UUID settings are incorrect your system will not boot into the Slackware Linux operating system!
Once again, we double-check the file using the 'cat' command to make sure everything is correct.
That looks very good indeed. The 'UUID' values exactly match the output from our 'blkid' command, only with the double-quotes removed. This is precisely what we needed to achieve.
So, without further delay, let's reboot the system...
Now, we'll (hopefully) login... and then run a few checks on the system mass storage block device(s) attributes.
The above output is very much intended and according to plan. Now we can connect another storage device, such as a USB memory stick or HDD/SSD, and (re)boot the system without fear of a kernel panic or Slackware Linux operating system not loading due to another block device changing the corresponding device node order.
NB: From the range of Raspberry Pi single board computers, the Raspberry Pi 4 and Raspberry Pi 5 are the only models to feature a programmable boot EEPROM. When a bootable microSD card is detected on the Raspberry Pi computers it becomes the principle boot device. By default, the Raspberry Pi boot EEPROM configuration is designed to boot from the onboard SD card first, rather than any other storage device. It's possible to change this 'BOOT_ORDER' by modifying the Raspberry Pi boot EEPROM configuration.
•
Thanks!
Thank you for reading and taking part in this SARPi mini-project. We hope you enjoyed it and found it interesting and educational.
Thanks also to Patrick Volkerding, and the entire Slackware Team, for producing a truly wonderful OS. Without you, and the work you do, the SARPi Project would not exist.
If you have any questions or need help, visit the Slackware Linux Forum on Linux Questions. Or get in touch on the #SARPi IRC channel on irc.libera.chat.
•
