Welcome to the most active Linux Forum on the web.
Go Back > Blogs > Lysander666
User Name


Rate this Entry

Persistent naming with multiple internal drives in Slackware

Posted 08-07-2018 at 02:52 PM by Lysander666
Updated 08-08-2018 at 09:19 AM by Lysander666 (spelling + added conclusion)
Tags fstab, lilo

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:

During boot, identification of those PATA drives was basically tied to their cable position. And before UUID (or better still, LABELs), fstab basically hard-coded device references for each mount point. So every time I'd reconnect the OS/2 drive, hda *became* hdb; result: kernel panic. (I remember seething at the sheer stupidity of hard-coding devices in fstab, basically turning it into an unnecessary point of failure.)
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:

/dev/sdc1: UUID="ff624ae7-b3d4-4ef5-887a-8d505669bfd0" TYPE="ext4" PARTUUID="760c1513-01"
/dev/sdc2: UUID="3973ae50-15b7-4d57-a211-54b4cf951506" TYPE="swap" PARTUUID="760c1513-02"
/dev/sdc3: UUID="3a2a529f-9216-43f6-9458-ae64cca849a2" TYPE="ext4" PARTUUID="760c1513-03"
I then changed the device names in fstab accordingly:

#below partition is /dev/sda2 - swap
UUID=3973ae50-15b7-4d57-a211-54b4cf951506  swap  swap  defaults  0  0

#below partition is /dev/sda1 - root
UUID=ff624ae7-b3d4-4ef5-887a-8d505669bfd0  /  ext4  defaults  1  1

#below partition is /dev/sda3 - home
UUID=3a2a529f-9216-43f6-9458-ae64cca849a2  /home  ext4  defaults  1  2
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:

ls -la /dev/disk/by-id
which will spit out a few IDs of the drives and the partitions, the main one Iím interested in is this one:

lrwxrwxrwx 1 root root   9 Aug  7 18:45 ata-INTEL_SSDSA2M080G2GC_CVPO012502X3080JGN -> ../../sdc
lrwxrwxrwx 1 root root  10 Aug  7 18:45 ata-INTEL_SSDSA2M080G2GC_CVPO012502X3080JGN-part1 -> ../../sdc1
lrwxrwxrwx 1 root root  10 Aug  7 18:45 ata-INTEL_SSDSA2M080G2GC_CVPO012502X3080JGN-part2 -> ../../sdc2
lrwxrwxrwx 1 root root  10 Aug  7 18:45 ata-INTEL_SSDSA2M080G2GC_CVPO012502X3080JGN-part3 -> ../../sdc3
this then has to be added into lilo.conf like so:

append=" vt.default_utf8=0"
#boot = /dev/sdc
boot = /dev/disk/by-id/ata-INTEL_SSDSA2M080G2GC_CVPO012502X3080JGN
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

/usr/share/mkinitrd/ -k 4.4.144
which on my machine, gives me the following instruction:

root@psychopig-xxxiv:~# /usr/share/mkinitrd/ -k 4.4.144
# revision 1.45
# This script will now make a recommendation about the command to use
# in case you require an initrd image to boot a kernel that does not
# have support for your storage or root filesystem built in
# (such as the Slackware 'generic' kernels').
# A suitable 'mkinitrd' command will be:

mkinitrd -c -k 4.4.144 -f ext4 -r /dev/sdc1 -m xhci-pci:ohci-pci:ehci-pci:xhci-hcd:uhci-hcd:ehci-hcd:hid:usbhid:i2c-hid:hid_generic:hid-cherry:hid-logitech:hid-logitech-dj:hid-logitech-hidpp:hid-lenovo:hid-microsoft:hid_multitouch:jbd2:mbcache:ext4 -u -o /boot/initrd.gz
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:

mkinitrd -c -k 4.4.144 -f ext4 -r ďUUID=ff624ae7-b3d4-4ef5-887a-8d505669bfd0Ē -m xhci-pci:ohci-pci:ehci-pci:xhci-hcd:uhci-hcd:ehci-hcd:hid:usbhid:i2c-hid:hid_generic:hid-cherry:hid-logitech:hid-logitech-dj:hid-logitech-hidpp:hid-lenovo:hid-microsoft:hid_multitouch:jbd2:mbcache:ext4 -u -o /boot/initrd-4.4.144.gz
See bassís section on lilo.conf for more useful information on this here

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

# root = /dev/sdc1
  root = /dev/disk/by-uuid/ff624ae7-b3d4-4ef5-887a-8d505669bfd0
  label = Linux
# Linux bootable partition config ends
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.

#below partition is /dev/sda2 - swap
UUID=3973ae50-15b7-4d57-a211-54b4cf951506  swap  swap  defaults  0  0

#below partition is /dev/sda1 - root
UUID=ff624ae7-b3d4-4ef5-887a-8d505669bfd0  /  ext4  defaults  1  1

#below partition is /dev/sda3 - home
UUID=3a2a529f-9216-43f6-9458-ae64cca849a2  /home  ext4  defaults  1  2

UUID=01C962C5B094A220  /media/Media  ntfs  defaults,noauto  0  2

UUID=01CB901A6E183220  /media/Backup  ntfs  defaults,noauto  0  2

#/dev/cdrom      /mnt/cdrom       auto        noauto,owner,ro,comment=x-gvfs-show 0   0
/dev/fd0         /mnt/floppy      auto        noauto,owner     0   0
devpts           /dev/pts         devpts      gid=5,mode=620   0   0
proc             /proc            proc        defaults#below partition is /dev/sda2 - swap
UUID=3973ae50-15b7-4d57-a211-54b4cf951506  swap  swap  defaults  0  0

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

#ntfslabel /dev/sdX/ <drive name>
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.


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.
Posted in Uncategorized
Views 101 Comments 0
« Prev     Main     Next »
Total Comments 0




All times are GMT -5. The time now is 01:36 AM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration