SARPi Project - Slackware ARM on a Raspberry Pi

Persistent Storage Device Naming

On Slackware ARM, 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 HDDs, SSDs, and USB memory sticks, via a 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 [onboard] SD cards.

Traditionally, mass storage devices on Slackware are identified by '/dev/sda', '/dev/sdb', '/dev/sdc', (etc.) and '/dev/sda1', '/dev/sdb2', '/dev/sdc3' (etc.) refer to the filesystem partitions which may be located on each storage device. Any SD card in the SD card slot on a Raspberry Pi is usually referenced as '/dev/mmcblk0' and filesystem partitions therein are identified as '/dev/mmcblk0p1', '/dev/mmcblk0p2', '/dev/mmcblk0p3', etc.

Why would Slackware ARM 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, 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 system, you may already know where this is going, and why under certain circumstances it can be fatal to the successful boot operations of your OS. 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 solution in such cases.

Requirements for Persistent Storage Device Naming

• Slackware ARM with udev running.

How to Setup Persistent Storage Device Naming

For the purpose of this guide we will be using 'root' user and our Slackware ARM 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 adapter cable.

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 /boot/cmdline.txt
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 ARM OS 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:

root@torq:~# blkid

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.

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.

root@torq:~# nano -w /boot/cmdline.txt

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 ARM 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 not, you will end up with a system that does not boot! Yours will most certainly be different than the one shown here!

If this PARTUUID value is incorrect you will receive a kernel panic for root filesystem not found!

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.

root@torq:~# nano -w /etc/fstab

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 ARM OS!

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 Slackware ARM system...

root@torq:~# reboot

Now we'll (hopefully) login... and 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 ARM OS not loading due to another block device changing the corresponding device node order.

NB: When a bootable SD card is inserted into the Raspberry Pi 4's SD card slot it becomes the principle boot device. By default, the Raspberry Pi 4 bootloader configuration is designed to boot from the onboard SD card rather than a USB mass storage device. It's possible to change the 'BOOT_ORDER' but the EEPROM configuration would need to be modified. It's not adviseable to make changes to the EEPROM configuration properties unless you know exactly what you're doing!


The SARPi Project hopes the information in this guide was useful. If you have any questions, or would like to contribute in any way, please use the Linux Questions Slackware ARM Forum.

Thanks for your interest!


SARPi Project Team

Back to Top

Updated: 2021-04-06 13:44:58 UTC

Disclaimer: The SARPi Project website is for non-commercial and general information purposes only. The content is provided by Penthux.NET and while we endeavour to keep information up to date and correct, we make no representations or warranties of any kind, express or implied, about the completeness, accuracy, reliability, suitability or availability with respect to the website or any information, software, products, services, or related graphics which is available on the website for any purpose. Any reliance you place on such information is therefore strictly at your own risk. In no event will Penthux.NET be liable for any loss or damage including without limitation, indirect or consequential loss or damage, or any loss or damage whatsoever arising from loss of data or profits arising out of, or in connection with, the use of this website or any of its contents. Through this website you are able to visit other websites which are not under our control. Penthux.NET has no influence over the nature, content or availability of any external URLs. The inclusion of any URLs does not necessarily imply a recommendation or endorsement of any content therein. Every effort is made to ensure the SARPi Project website remains accessible. However, Penthux.NET takes no responsibility for, and will not be liable for, the SARPi Project website being temporarily unavailable due to technical issues beyond our control. Penthux.NET is in no way affiliated with Slackware Linux, Inc, or the Linux Foundation, or the Raspberry Pi Foundation, or any of their members, trustees, partners, or associates.

SARPi Project uses cookies for website traffic & data analysis. [ Cookie Policy ]