Persistent naming with three internal HDDs

Lysander666 · 01-11-2018, 07:34 AM

Before I start, I should note that this is probably going to be something of a lengthy post, lengthy in comparison to others of mine anyway. I should also note that I started a similar topic to this a few months ago. The reason why I am starting a new thread is because if I were to update the old one, people would most likely not look at the date of the OP and would respond to the content of the OP in that thread, which will be somewhat different to this one.

For reference, here is that old thread:

https://www.linuxquestions.org/quest...rt-4175612778/

With that out the way, this is about potentially moving to a Slack system with three internal hard drives. When I install a new OS, I unplug the two backup drives and install the OS on my main SSD. The reason for this is that I don’t want to wipe anything on the other two drives by mistake. I realise that there is probably a low chance of this, but it makes me more comfortable doing things this way.

When I last attempted this I installed Slack on my SSD with no issues, however, when I plugged my other drives in and rebooted, Slack threw a kernel panic and I was unable to boot. As we surmised in the other thread, this was most likely because the file names of the devices had changed. Fortunately I found a blog entry from someone who had exactly the same issue in 14.1 and was able to solve it with persistent naming. The entry is here from gegechris99:

https://www.linuxquestions.org/quest...rd-disk-36797/

The difference between this gentleman and me is that he appears to be using two partitions for his main HDD, whereas I tend to split things up into /, /home and /swap.

Now, there appear to be several stages to this

1] attaining persistent IDs
2] recreating initrd
3] editing lilo.conf
4] editing /etc/fstab

the difference between going this route and my previous attempt at persistant naming [which didn't work] is that I used UUIDs last time and though I updated fstab, I didn’t update lilo.conf.

So I suppose I had better run through my proposal for making this work with IDs.

1] attaining persistent IDs

This seems pretty simple, using the command ls -la /dev/disk/by-id I get

Code:

lysander@psychopig-xxxiii:~$ ls -la /dev/disk/by-id
total 0
drwxr-xr-x 2 root root 560 Jan 11 10:12 .
drwxr-xr-x 7 root root 140 Jan 11 10:12 ..
lrwxrwxrwx 1 root root   9 Jan 11 10:12 ata-Hitachi_HDP725032GLA360_GEC434RF1TAWGE -> ../../sda
lrwxrwxrwx 1 root root  10 Jan 11 10:12 ata-Hitachi_HDP725032GLA360_GEC434RF1TAWGE-part1 -> ../../sda1
lrwxrwxrwx 1 root root  10 Jan 11 10:12 ata-Hitachi_HDP725032GLA360_GEC434RF1TAWGE-part5 -> ../../sda5
lrwxrwxrwx 1 root root   9 Jan 11 10:12 ata-INTEL_SSDSA2M080G2GC_CVPO012502X3080JGN -> ../../sdc
lrwxrwxrwx 1 root root  10 Jan 11 10:12 ata-INTEL_SSDSA2M080G2GC_CVPO012502X3080JGN-part1 -> ../../sdc1
lrwxrwxrwx 1 root root  10 Jan 11 10:12 ata-INTEL_SSDSA2M080G2GC_CVPO012502X3080JGN-part2 -> ../../sdc2
lrwxrwxrwx 1 root root  10 Jan 11 10:12 ata-INTEL_SSDSA2M080G2GC_CVPO012502X3080JGN-part5 -> ../../sdc5
lrwxrwxrwx 1 root root  10 Jan 11 10:12 ata-INTEL_SSDSA2M080G2GC_CVPO012502X3080JGN-part6 -> ../../sdc6
lrwxrwxrwx 1 root root   9 Jan 11 10:12 ata-_NEC_DVD+RW_ND-2100AD -> ../../sr1
lrwxrwxrwx 1 root root   9 Jan 11 10:12 ata-_NEC_DVD_RW_ND-2510A -> ../../sr0
lrwxrwxrwx 1 root root   9 Jan 11 10:12 ata-SAMSUNG_HD160JJ_S08HJ1ULA30904 -> ../../sdb
lrwxrwxrwx 1 root root  10 Jan 11 10:12 ata-SAMSUNG_HD160JJ_S08HJ1ULA30904-part1 -> ../../sdb1
lrwxrwxrwx 1 root root  10 Jan 11 10:12 ata-SAMSUNG_HD160JJ_S08HJ1ULA30904-part2 -> ../../sdb2
lrwxrwxrwx 1 root root  10 Jan 11 10:12 ata-SAMSUNG_HD160JJ_S08HJ1ULA30904-part5 -> ../../sdb5
lrwxrwxrwx 1 root root   9 Jan 11 10:12 wwn-0x50000f001ba30904 -> ../../sdb
lrwxrwxrwx 1 root root  10 Jan 11 10:12 wwn-0x50000f001ba30904-part1 -> ../../sdb1
lrwxrwxrwx 1 root root  10 Jan 11 10:12 wwn-0x50000f001ba30904-part2 -> ../../sdb2
lrwxrwxrwx 1 root root  10 Jan 11 10:12 wwn-0x50000f001ba30904-part5 -> ../../sdb5
lrwxrwxrwx 1 root root   9 Jan 11 10:12 wwn-0x5000cca34dd92946 -> ../../sda
lrwxrwxrwx 1 root root  10 Jan 11 10:12 wwn-0x5000cca34dd92946-part1 -> ../../sda1
lrwxrwxrwx 1 root root  10 Jan 11 10:12 wwn-0x5000cca34dd92946-part5 -> ../../sda5
lrwxrwxrwx 1 root root   9 Jan 11 10:12 wwn-0x5001517959275320 -> ../../sdc
lrwxrwxrwx 1 root root  10 Jan 11 10:12 wwn-0x5001517959275320-part1 -> ../../sdc1
lrwxrwxrwx 1 root root  10 Jan 11 10:12 wwn-0x5001517959275320-part2 -> ../../sdc2
lrwxrwxrwx 1 root root  10 Jan 11 10:12 wwn-0x5001517959275320-part5 -> ../../sdc5
lrwxrwxrwx 1 root root  10 Jan 11 10:12 wwn-0x5001517959275320-part6 -> ../../sdc6
lysander@psychopig-xxxiii:~$

Note this is just an example attained from my current Debian box.

Now the IDs here are for all three drives, but from what I can see from gegechris99’s post, I only need to focus on my main SSD that root will be installed on, which is

Code:

lrwxrwxrwx 1 root root  10 Jan 11 10:12 ata-INTEL_SSDSA2M080G2GC_CVPO012502X3080JGN-part1 -> ../../sdc1
lrwxrwxrwx 1 root root  10 Jan 11 10:12 ata-INTEL_SSDSA2M080G2GC_CVPO012502X3080JGN-part2 -> ../../sdc2
lrwxrwxrwx 1 root root  10 Jan 11 10:12 ata-INTEL_SSDSA2M080G2GC_CVPO012502X3080JGN-part5 -> ../../sdc5
lrwxrwxrwx 1 root root  10 Jan 11 10:12 ata-INTEL_SSDSA2M080G2GC_CVPO012502X3080JGN-part6 -> ../../sdc6

In this case, sdc1 is /root, sdc2 is extended partition, sdc5 is /swap and sdc6 is /home.

These will probably change since if/when I install Slack on my main box I will repartition, but I think the principle is still the same.

2] recreating initrd

this is the only part I don’t understand. Gegechris99 says

Quote:

As I use the generic kernel, I first had to recreate the initrd file.
Code:

mkinitrd -c -k 3.10.17 -m ext4 -f ext4 -r /dev/disk/by-id/ata-ata-TOSHIBA_MQ01ABF050_Z4ATT4FPT-part2 -o /boot/initrd.gz
The important change, here, is the -r option.

I don’t really understand if and why I have to do this. Furthermore will I be/am I running the general kernel? Not sure. Anyway, in the case that I do have to do this,

I think my command would be

Code:

mkinitrd -c -k 4.4.14 -m ext4 -f ext4 -r /dev/disk/by-id/ata-INTEL_SSDSA2M080G2GC_CVPO012502X3080JGN-part1 -o /boot/initrd.gz

though I will be upgrading the kernel to 4.4.88 after this anyway.

EDIT I see now that the generic kernel is optional, and the huge kernel is installed by default

https://docs.slackware.com/slackware:beginners_guide see section "Switch to a generic kernel"

Furthermore I am a bit confused as to if I should use

Code:

dev/disk/by-id/ata-INTEL_SSDSA2M080G2GC_CVPO012502X3080JGN-part1

or

Code:

dev/disk/by-id/ata-ata-INTEL_SSDSA2M080G2GC_CVPO012502X3080JGN-part1

3] editing lilo.conf – this should look like this I think:

Code:

[...]
#boot = /dev/sdc
boot = /dev/disk/by-id/ ata-[ata-?]INTEL_SSDSA2M080G2GC_CVPO012502X3080JGN
[...]
# Linux bootable partition config begins
image = /boot/vmlinuz
# root = /dev/sdc1
  root = /dev/disk/by-id/ata-INTEL_SSDSA2M080G2GC_CVPO012502X3080JGN-part1
  initrd = /boot/initrd.gz
  label = Slackware
  read-only
# Linux bootable partition config ends

And then re-running lilo with lilo -v

4] editing /etc/fstab

Also pretty simple I think this should go:

Code:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
/dev/disk/by-id/ata-INTEL_SSDSA2M080G2GC_CVPO012502X3080JGN-part1               ext4    errors=remount-ro 0       1
# /home was on /dev/sda6 during installation
/dev/disk/by-id/ata-INTEL_SSDSA2M080G2GC_CVPO012502X3080JGN-part6           ext4    defaults        0       2
# swap was on /dev/sda5 during installation
/dev/disk/by-id/ata-INTEL_SSDSA2M080G2GC_CVPO012502X3080JGN-part5            swap    sw              0       0

of course this may change with a new install, but I am posting this to see that I have it correct in principle.

So is this correct and if not, what may I have done wrongly or missed out?

Darth Vader · 01-11-2018, 07:40 AM

Use the UUIDs, Luke!

Lysander666 · 01-11-2018, 07:56 AM

Quote:

Originally Posted by Darth Vader

Use the UUIDs, Luke!

i was wondering this, blkid gives

Code:

lysander@psychopig-xxxiii:~$ sudo blkid
[sudo] password for lysander: 
/dev/sda5: LABEL="Music and Media Drive" UUID="01C962C5B094A220" TYPE="ntfs" PARTUUID="45f6375f-05"
/dev/sdb1: LABEL="System Reserved" UUID="E01E06371E06076E" TYPE="ntfs" PARTUUID="35a9e319-01"
/dev/sdb5: LABEL="Backup Drive" UUID="01CB901A6E183220" TYPE="ntfs" PARTUUID="35a9e319-05"
/dev/sdc1: UUID="fd49c3f3-dec4-4f59-b2f3-5b9da1838144" TYPE="ext4" PARTUUID="760c1513-01"
/dev/sdc5: UUID="48548a61-e316-42e3-b7c1-e074029fa679" TYPE="swap" PARTUUID="760c1513-05"
/dev/sdc6: UUID="c6406cea-b96c-48c1-a33f-804c9f611ae6" TYPE="ext4" PARTUUID="760c1513-06"
lysander@psychopig-xxxiii:~$

So I should use those instead? Like this, e.g.

Code:

[...]
#boot = /dev/sdc
boot = [not sure about this part for UUID] 
[...]
# Linux bootable partition config begins
image = /boot/vmlinuz
# root = /dev/sdc1
  root = UUID=fd49c3f3-dec4-4f59-b2f3-5b9da1838144 
  initrd = /boot/initrd.gz
  label = Slackware
  read-only
# Linux bootable partition config ends

Code:

:~$ cat /etc/fstab
# /dev/sdc1
UUID=fd49c3f3-dec4-4f59-b2f3-5b9da1838144      /            /    defaults,discard                     0 0
# /dev/sdc5
UUID=UUID="48548a61-e316-42e3-b7c1-e074029fa679      swap               ext4    defaults,noatime,discard             0 1
# /dev/sdc6
UUID=c6406cea-b96c-48c1-a33f-804c9f611ae6                       /home           ext4    defaults,noatime,discard             0 2
# /dev/sda5
LABEL=Data                                     /share/Music and Media Drive     ext4    defaults                             0 2
# /dev/sdb5
PARTLABEL="Linux filesystem"                   /share/Backup Drive  ext4    defaults                             0 2

bassmadrigal · 01-11-2018, 09:37 AM

I actually wrote up a page on this on SlackDocs. It should cover all of what you're wanting to do, however, I do realize it is long, so if you get stuck with something, feel free to ask questions.

https://docs.slackware.com/howtos:sl...sistent_naming

I do agree with Darth... I would use UUIDs over Device IDs.

A couple of things based on your last post, you have UUID=UUID= for your swap. You'll want to remove that extra UUID= if you want your swap to mount. I would also suggest verifying your PARTLABEL for /dev/sdb5, because I'm not seeing that in any of your output. But on top of that, I would especially steer away from using the default labels for mounting, because if you format another drive and don't change the label, it would default to "Linux filesystem" which could cause the wrong partition to be mounted. I would either use UUID or create a unique label to use.

Also, you don't need a root entry in your lilo.conf since you'll be using an initrd. Part of that initrd command creation should be to specify your root device, which you would do using -r "UUID=fd49c3f3-dec4-4f59-b2f3-5b9da1838144". Lilo will ignore that root entry and use whatever is set in the initrd, so you need to make sure that is set to the UUID and not the normal device name. Have a look at the LABEL and UUID section on the wiki page and that should cover the initrd creation in more detail.

If you need any further guidance, feel free to ask

Lysander666 · 01-12-2018, 05:02 PM

Great advice, thank you, bass. I hadn't actually noticed that about the duplicate UUID. I think the best thing for me to do is the post the lilo.conf from the install here when I have it, and from then on go about configuring it properly and attaching the drives after. Will report back.

ChuangTzu · 01-12-2018, 07:22 PM

only thing I would add is the option of generic or huge kernel is personal preference. I used to be a stickler for generic, but the older I get the more I stick with the huge kernel the difference between the two seemed marginal at best.

PS: that's some potential Slack you have there...the force may be strong with this one.

bassmadrigal · 01-12-2018, 09:25 PM

Quote:

Originally Posted by ChuangTzu

only thing I would add is the option of generic or huge kernel is personal preference. I used to be a stickler for generic, but the older I get the more I stick with the huge kernel the difference between the two seemed marginal at best.

If you're using UUIDs or labels in lilo, you're required to use an initrd, and at that point, you might as well use the generic kernel. Neither PARTUUID or PARTLABEL are supported by lilo, although, you can get around it with PARTUUID by using an addappends=" root=PARTUUID=yourpartuuidhere", but last I checked, PARTLABEL wouldn't work this way due to lack of support in the kernel for it.

But I do still use huge on my systems that don't need an initrd.

Richard Cranium · 01-12-2018, 10:29 PM

If you used LVM, you wouldn't care beyond your boot partition.

bassmadrigal · 01-12-2018, 11:08 PM

Quote:

Originally Posted by Richard Cranium

If you used LVM, you wouldn't care beyond your boot partition.

You'd have to do the same lilo stuff with lvm if there's a possibility of the device getting renamed. Otherwise, you'd still need to reference the drives to put them in fstab, whether you're using UUIDs, labels, or lvm containers... and then there's the extra complexity during installation to get lvm set up.

enorbet · 01-12-2018, 11:25 PM

Labels can be used without an initrd and with LILO, just check LILO documentation. I prefer LABEL over UUID for what I think is an important reason, possibly in line with OPs regard for safety. UUIDs have no meaning to humans. One can rarely tell exactly and at a glance which drive you are on. Labels solve that. I go the extra mile and label partitions in a matching manner and also match mount point labels. I always know instantly what drive and partition I am on in any application and that helps prevent me from making careless errors.

However typical device designation can be used in this manner as well. If one is careful about which hdd port one places each drive there is no problem even with good ol' /dev/sdx designation. Any problems created by external drives can be solved with something like this in LILO -

Code:

### /etc/lilo.conf ###
disk = /dev/sda
bios = 0x80
disk = /dev/sdb
bios = 0x81
disk = dev/sdc
 inaccessible

It is worthy of note that the external drive becomes only inaccessible to LILO, not the system.

bassmadrigal · 01-13-2018, 12:16 AM

Quote:

Originally Posted by enorbet

Labels can be used without an initrd and with LILO, just check LILO documentation.

lilo is able to use both UUID and labels, however, the documentation wouldn't take into account whether initrds would need to be used or not as that is not related to lilo. It is just able to use those designators to be able to reference the filesystem when writing to the MBR.

Code:

              The root filesystem may also be specified by a LABEL= or UUID= directive, as in '/etc/fstab'.  In this case, the argument to root= must be  enclosed  in  quotation
              marks, to avoid a syntax error on the second equal sign, e.g.:

                   root="LABEL=MyDisk"
                   root="UUID=5472fd8e-9089-4256-bcaa-ceab4f01a439"

When I did my research for the SlackDocs article, I remember reading you needed the initrd to be able to read labels and UUIDs since they were part of the filesystem and not the partition (in relation to PARTUUID and PARTLABEL), so I assume it needed the filesystem tools that are presumably provided in the initrd. It is possible the kernel now has support to read labels (or the sites I read were outdated), although, I've never tested it with labels. The last time I did test it with UUIDs, an initrd was required (and I've used it ever since).

Richard Cranium · 01-13-2018, 04:41 PM

Quote:

Originally Posted by bassmadrigal

You'd have to do the same lilo stuff with lvm if there's a possibility of the device getting renamed. Otherwise, you'd still need to reference the drives to put them in fstab, whether you're using UUIDs, labels, or lvm containers... and then there's the extra complexity during installation to get lvm set up.

Umm, no.

The physical volumes assemble themselves via their metadata. The logical volumes assemble themselves via their metadata.

Yes, it's more complex to use LVM during installation; I won't argue otherwise. But later operations (including moving content from an old physical volume to a new one as well as adding new logical volumes on the fly) are easy as eating pie.

I dithered around and didn't use LVM thinking that it would add levels of complexity. It also *removes* complexity in other areas and (IMO) was an overall reduction in maintenance complexity.

bassmadrigal · 01-13-2018, 05:26 PM

Quote:

Originally Posted by Richard Cranium

Umm, no.

The physical volumes assemble themselves via their metadata. The logical volumes assemble themselves via their metadata.

What I meant is you still need to reference the /boot/ partition, right? And as far as I know, that is referenced as a normal device on the system, not as an LVM (since I'm pretty sure it can't reside in an LVM). So, if that device name changes, you'd be in the same boat of an unbootable system?

I will admit, I don't know much about LVM, but I think I understand the basics of it, but if I'm wrong, feel free to correct me

Nevermind... I had a brainfart. You're absolutely correct that this wouldn't be an issue on an LVM system since root would point to an LVM container and the /boot/ partition, which contains the kernel and initrd, would be mounted when you ran lilo, which has no effect during the bootup process.

Thanks for the smack upside my head to knock some sense into me

I may need to look into LVM and see if it's beneficial for my usage and worth the effort of switching my system to it.

enorbet · 01-14-2018, 04:07 PM

Merely anecdotal but I have used LILO almost always for ~18 years on multiboot systems (whenever any tested distro allows for it), often use LABELS and never once invoked LVM NOR an initrd. I don't encrypt drives and don't do RAID so it is a simple setup but the point is it works. It is possible.

bassmadrigal · 01-14-2018, 07:02 PM

Quote:

Originally Posted by enorbet

Merely anecdotal but I have used LILO almost always for ~18 years on multiboot systems (whenever any tested distro allows for it), often use LABELS and never once invoked LVM NOR an initrd. I don't encrypt drives and don't do RAID so it is a simple setup but the point is it works. It is possible.

It must've just been a site with wrong information... Thanks for the update. I'll try to get the SlackDocs page updated soonish (so many projects going on at the house).