Persistent naming with multiple internal drives in Slackware

Pre-amble – skip to avoid the lead-in:

I told myself I’d write a post when I eventually got this sorted out. I’m not a long-term Linux user, I started in Feb 2017 with Ubuntu, moving onto Debian in April 2017 and Slackware in January 2018. I had been intrigued by Slackware for years and wanted to run it for as long: it was a like a geek-goal, some sort of nerd ambition. But I also knew that the road to doing so would be hard, and I’d have a steep learning curve and a lot of research to do [and a lot of mistakes to make].

To say I found Slackware trickier than Debian is an understatement. Since I don’t come from a *nix background, working successfully with Slackware is something that took time to do. Using it on my laptops was challenging, but using it on the desktop is altogether more so – especially when multiple internal drives are involved. I would say I'm now - almost - at cruising speed.

Why persistent naming is necessary in Slackware – the slightly non-technical version:

Persistent naming is the process whereby each drive [and/or each partition] is given its own unique identifier by the user so that SysV can locate the kernel, boot the OS and mount all drives. To give some idea as to why doing so is necessary in Slackware, it may be worth looking at a post from an old forum-friend of mine over on the Debian forums, dasein [RIP]. He stated the following about his experiences of old with reconnecting internal drives after an OS install:

In short, on the older *nix systems, device names can change. I’m not someone who installs a new OS with all drives in place, I have to install using my main hard drive and with the other two unplugged. I do this just in case an issue arises and the contents of those drives get wiped by mistake during an install. Apparently this is rather common [Slackware CAN do the install with everything plugged in, adding the other drives automatically to fstab, but I didn't want to try that - I thought I'd, somewhat masochistically maybe, run the gauntlet of learning this stuff myself].

Now, reconnecting those other drives is no issue in, say, Ubuntu or Debian: the OS recognises the new drives and does the work for the user. When ones reboots, there’s never an issue. In Slackware that’s not the case. Installing the OS onto the main drive, powering down, plugging in a new drive or two and rebooting will likely cede a kernel panic and SysV will hang interminably. The reason for this is because the main drive, which was e.g. sda, is now sdb and LILO can’t find the kernel to boot.

To remedy this we need a system whereby the drives are always recognised as the same, and don’t change. I should note that forum member bassmadrigal has written an excellent article about persistent naming on Slackdocs, which should definitely form a point of reference for anyone looking to learn more about it. Without looking at that, some of this blog post may seem unclear. This is no way meant to replace or act as a synopsis of his article, it’s purely what I did and what worked on my hardware. The same may not be true for you, the user, but this post should offer some guidance. I should also give thanks to user gegechris99 and his important blog post recounting his experiences with persistent naming using drive IDs.

NB: This guide references only IDs and UUIDs, though Labels, PartLabels and PartUUIDs can also be used. For further information, look at the Slackdocs article.

That said, I will run through the steps I took to get persistent naming working on my system. I use one SSD and two HDDs, with the former being my main install.

The 'drive' itself:

1. First of all I had to attain the Universal Unique Identifier [UUID] for each drive. I ran #blkid to get the UUIDs of the partitions in my main drive:

I then changed the device names in fstab accordingly:

This is relatively easy and now our partitions on the main drive are all set up for UUIDs which won’t change. But really our concern includes our other drives.

2. LILO has to know which drive to boot from, not which partition, so we can’t put a UUID in lilo.conf for this, we need the ID of the drive. To get this we use:

which will spit out a few IDs of the drives and the partitions, the main one I’m interested in is this one:

this then has to be added into lilo.conf like so:

notice that the old boot device has been commented out rather than removed for reference.

3. So now LILO knows to always boot from the same drive, but we need an initrd [boot loader initialized RAM disk], since the process won’t work without one. We can generate one in a similar way we would if we were about to upgrade the kernel, with

which on my machine, gives me the following instruction:

Now, notice in the above, the device is listed as /dev/sdc1. We need to replace this with the UUID of our / partition, in this case ff624ae7-b3d4-4ef5-887a-8d505669bfd0. I am also going to slightly amend the initrd instruction at the end to point to our current kernel:

See bass’s section on lilo.conf for more useful information on this here https://docs.slackware.com/howtos:sl...sistent_naming.

----EDIT Nov 2018: Since originally writing this article I've upgraded to 4.4.153 kernel and, I'll be honest, I can't remember if I did the above when upgrading the kernel and making the initrd. Though, as bassmadrigal says:

In short - for now, it's best to do it just in case. It won't hurt.----

4. Run the instruction. I should note that I previously also entered the UUID at the end of lilo.conf via:

however, bassmadrigal says this is not necessary since if we are using an initrd with the -r option, that entry will not be used.

5. Now the UUIDs of the other drives can be inserted into fstab. I should note that I took the UUIDs from my Debian install before moving to Slackware. If you have not made a note of them, read optional step 7. My other drives are ntfs, and ntfs does not support full UUIDs, but the ones I have are still usable.


I had a problem on boot with parse errors on lines 11 and 14 of my fstab since my drives names “Music and Media Drive” and “Backup Drive” caused issues. I therefore relabelled the drive names using

I then created new mount points at /media/<drivename> and inserted these new mount points into fstab as above.

6. Re-run LILO using lilo -v. On reboot, you should have a system with drive and partition names which don’t change.

7 [optional]. If you happen not to have made notes of the UUIDs of your other drives, don’t fret! If you have set up persistent naming correctly for your main drive, inserted your drive ID into lilo.conf, run the correct initrd instruction and re-run LILO, you should still be able to boot with all drives plugged in, and your other drives will then mount at /run/media/<user>. You can then change mount points and edit your fstab accordingly.

Wrap-up:

Persistent naming is not that easy a process to get to grips with, [it certainly wasn't for me, having worked with Slackware for many months], but it is absolutely vital when running a multi-drive system. Having said this, hopefully this blog entry will go a little way to making the process seem simpler and more accomplishable for others.

Afterword:

As an afterthought, here is my lilo.conf file for clarity. I have, since originally making this blog entry, added the generic kernel.