How do you set vol-IDs & uuids during OS installation, is it possible? Or can you only do this manually? Does the MBR ever use vol-IDs & uuids or are they too big? Or does this go into what you mentioned as GPT a new version of labeling partition tables?

The IDs/UUIDs are generated and set when the partitions are created (I am not sure if formatting changes them, I do not think it does). I am also not really sure what you are calling vol-ID, that may be a GPT thing.

You can get the ID or UUID during installation, after formatting, using blkid or by simply ls -l /dev/disk/by-{id,uuid}.

The MBR will only have an ID, /dev/disk/by-id/... value as far as I know.

1 members found this post helpful.

@astrogeek
Here are my vol-IDs & how I got them:
Volume ID's are all unique. Think these show up in my Scrolling Bios... At least I think that is where I've seen them also in fdisk -l
Have to look again and make a note of where I see these vol-IDs the actual HDD ID like sda before adding a partition?
Question the MBR is not "Human Readable" is it? I'm also googling & referencing unix, linux, slackware books I have. Now that you have helped me understand what I'm looking at more comprehensively I can read about it too.[COLOR="Silver"]

Ah! I have not used the volume ID for anything since... forever... forgot that was even there.

According to man lilo, the vol-ID is four bytes in the MBR and can be written. I recall that fdisk has an option for setting the volume ID too. I suspect you could do it with tune2fs as well, but again I have not done so in recent memory (the only memory I have left!).

However, I don't know how you can use volume ID to reference drives in lilo or fstab.

I have used volume LABELs in fstab entries but swithced to UUIDs because all partitions will have UUIDs whereas LABELs must be explicitly set. Also, UUIDs are inherently tied to their partitions, whereas you may inadvertantly reuse a LABEL and further confuse yourself - I did! Although they are more human readable, I found the labels more tedious to manage in the end - YMMV.

In lilo configs, the boot device and image and initrd paths must reachable when lilo is run. The boot parameter would be the only one for which vol-ID might be applicable, but I am not sure how you might specify that as a device "path".

You could use /dev/disk/by-label/ for those that are set and assuming it is supported by your kernel (probably is).

I use UUIDs and IDs for my own configs, but if labels or vol-IDs work better for you then use them instead. The main point to remember is to NOT use the /dev/sdx paths as these are dependent on drive ordering, among other things, and subject to change - the source of much confusion and boot failure!

@astrogreek, roflmao recent memory is my wisenheimer, visits briefly if I don't engage it in repetition. I learn well but if I don't use it on a regular basis I forget.
I'm in the process of switching stuff on Slackware over to UUID & am excited over it now. Also tried a live cd for the 1st time, of linuxmint mate. Been downloading & burning DVDs got one out of 3 that works-mate 64-17.1
Cinnamon is 2 for 0. Downloading Cinnamon 64-17.2 see if I have better luck with that one. Live CD wows me

I'd laugh too, but I don't remember what the joke was...

I never had much luck with Live distros, but that is probably more related to the fact that I have not always had a working optical drive available. Similarly for booting from USB devices - I have been plagued with hardware that simply doesn't support it! In the last couple of years I have been able to get some newer hardware but now I dont have much interest in trying new distros - I am pretty much Slackware and FreeBSD only these days.

Let me know when you get Slackware converted to UUIDs and safely booting, and play with a bit to build your confidence - it will become second nature. Then move on to the next one! Before long you should have a full load of distros and disks easily booting from Lilo.

Just a vote for using LABEL-ing as opposed to UUID-ing. I've not run into any problems and the human readability, and instant recognition in any file manager, not to mention WAY shorter designations has served me well. I already voted for LILO above GRUB but will reiterate because it is just so simple and good and manual. I find most automation to be like a doting butler, far more often underfoot than a real help.

I use both; UUID for internal disks that won't normally change, and LABELS for external disks that are mounted and unmounted semi-frequently.

The external disks are mostly backup devices so I can run scripts that read the external drive disk LABEL to control the script logic.

The disk LABEL correlates to the physical printed "label" glued on the outside of the external disk case which makes it easier to transfer between server locations and bank safety deposit boxes.

Hi astrogeek, Started trying to use the uuid in lilo. Got the following
Is it required that the /etc/fstab file be in place before switching settings in lilo.conf
Have recheck syntax for using uuid in lilo.conf.
Also found 'lilo-uuid-diskid' tool - you know it?

1. No, fstab and lilo don't know anything about each other, you could use different path methods for each - but why would you?

2. The root spec in lilo needs to be quoted and spec'd like this...

3. Never heard of lilo-uuid-diskid. Is it included with Slackware?

1 members found this post helpful.

I am pretty sure the UUID is regenerated every time you run a mkfs (at least with ext4, but I'd imagine it is the same with most *nix filesystems). You can specify a specific UUID, if desired, with mkfs.ext4 -U UUID /dev/sda (or change one later using tunefs -U UUID /dev/sda). I did this on a drive when I repurposed it a few months ago so I could just change the mount point on the fstab rather than getting the new UUID (lazy, I know).

1 members found this post helpful.

@astrogeek it's a script in /usr/bin came across reference to it & checked man lilo-uuid-diskid. BTW I have extra hardware you are welcome to if you like. Older CPUs breaks my heart to just throw away. lol

Update space saver: Boot failure, so I'm in Live CD of LinuxMint-Mate. During Slackware boot I was asked to "Please append a correct "root=" boot option... it wasn't sufficient to just change from /dev/sda8 to UUID ..
the /boot = sda option had to change too???
Thought I could change lilo from live cd but my root passwrd isn't working for access.

Got back in with Slackware install dvd. Seems there is a lot more to switching to UUID than just changing /dev/sdx to UUIDs?

You need it to read root = "UUID=your-uuid" and you can't refer to the boot as a UUID since it is not a partition and doesn't have a UUID. You need to reference that by the disk-id (using astrogeek's example since I'm at work and can't grab mine easily): boot = /dev/disk/by-id/ata-WDC_WD3200AAJB-00J3A0_WD-WCAV2C573625

It'd be best to post your /etc/lilo.conf file so we can look over it and, if necessary, correct any mistakes. It's a lot easier than just guessing what your values are

Hi again NightSky! Sorry I was not here much yesterday...

No, it really is as easy as changing the references to IDs/UUIDs - you just have to use the right syntax and values. You can use my earlier example for syntax - it is actually working - and replace with your own values.

As bassmadrigal points out, the boot and root options are two different things and must use differing syntax as well.

Pretty easy - take a deep breath and try again! ;-)

If you are trying to install Slackware lilo from Live Mint boot, remember that the boot, image and initrd must be mounted and reachable, and will have same UUID but probably different paths from Mint!

I would suggest creating two lilo stanzas - the original with /dev/sdx refs, and the new with UUIDs. If you break the UUIDs you can simply reboot to Slackware with the original and not have to worry about alternate mount paths.