Using LILO to boot disks by UUID

If you're plugging USB drives in an out and using LILO to boot a Linux distro (eg. Slackware) you may have ended up with a kernel panic because your /dev/sd# were shuffled around and the kernel was no longer able to find its root partition on the expected device. Of course, having Linux failing to boot just because you happened to plug an extra drive sucks big time, so we want to fix that.

The well known solution of course it to use UUIDs or labels, since these are fixed. However, while recent versions of LILO are supposed to support root partitions that are identified by UUID/Label, in practice, this doesn't work UNLESS you are using an initrd disk. I'm not sure who of LILO or the kernel is responsible for this new layer of "suck" (I'd assume the kernel, since the expectation is that LILO is using the dev mappings that are being fed by the kernel), but I can only say that there really are some areas of Linux that could still benefit from long awaited improvements...

Thus, to be able to use UUIDs or labels for your root partition in LILO, you must boot using an initrd. Worse, as previously documented, you will most likely need to compile a new kernel that embeds the initrd, lest you want to run into the following issue while running LILO:

Warning: The initial RAM disk is too big to fit between
the kernel and the 15M-16M memory hole.

In practice (as also illustrated by this post), this means you will need to:

1. Create an initrd cpio image that can be embedded into a kernel with:
   

   cd /boot
   mkinitrd -c
   cd initrd-tree
   find . | cpio -H newc -o > ../initrd.cpio

2. Recompile a kernel, while making sure that you have the General Setup → Initial RAM filesystem and RAM disk (initramfd/initrd) support selected, and then set General Setup → Initramfs source file(s) to /boot/initrd.cpio. 
   
   
3. Edit your /etc/lilo.conf and add an append = "root=UUID=<YOUR-DISK-GUID>" to your Linux boot entry. An example of a working lilo.conf is provided below. Note that you probably also want to use a fixed IDs for boot=, so that running LILO is also not dependent on the current /dev/sd# organization.. 
   
   
4. Run LILO, plug drives around and watch in amazement as your system still boots the Linux partition regardless of how the drives are assigned

Example lilo.conf:

# Start LILO global section
boot = /dev/disk/by-id/ata-ST3320620AS_ABCD1234
compact
lba32
# LILO doesn't like same volume IDs of RAID 1
disk = /dev/sdb inaccessible
default = Windows
bitmap = /boot/slack.bmp
bmp-colors = 255,0,255,0,255,0
bmp-table = 60,6,1,16
bmp-timer = 65,27,0,255
# Append any additional kernel parameters:
append=" vt.default_utf8=1"
prompt
timeout = 35
# End LILO global section

image = /boot/vmlinuz
  append = "root=UUID=2cc11aaf-f838-4474-9d9a-f3881569f97c"
  label = Linux
  read-only
image = /boot/vmlinuz.rescue
  append = "root=UUID=2cc11aaf-f838-4474-9d9a-f3881569f97c"
  label = Rescue
  read-only
other = /dev/sda
  # Windows doesn't go to S3 sleep and has issues with backup,
  # unless it sees its disk as first in BIOS...
  boot-as = 0x80
  label = Windows
other = /dev/disk/by-id/ata-ST3320620AS_ABCD1234-part4
  label = OSX

Oh, and of course, don't forget to edit your /etc/fstab as required, if you still use /dev/sdX# entries there.

LILO Warning: The initial RAM disk is too big

Just re-installed Slackware 13.0 x64 on the HTPC, this time using a small boot partition on the extra non fakeRAIDed HDD, which I recently added to the whole rig. This 4th HDD is now the boot disk for the whole rig, and contains the kernel and initrd (while the Linux partition itself is on the RAID5 set).

Install went without much of a hitch, and even the first few kernel recompilations we fine, but lately, after adding more kernel features, I got the following LILO warning and the kernel simply doesn't boot:

    Warning: The initial RAM disk is too big to fit between the kernel and
   the 15M-16M memory hole.  It will be loaded in the highest memory as
   though the configuration file specified "large-memory" and it will
   be assumed that the BIOS supports memory moves above 16M.

So much for checking the "Optimizing for size" kernel option.

The root of the matter seems to be that uncompressed kernel + uncompressed initrd must fit within the 0-15 MB low memory addresses, and it looks like a bzipped 4.5 MB kernel + a gzipped 1.4 MB initrd don't cut it, regardless of whether your BIOS has set a hole for the 15M-16M range.

Unlike what you might read elsewhere ("Remove options from your kernel to reduce its size! / Why are you using such a huge kernel?" - how's that helpful, guys?), there is a solution right there in the kernel conf, through the "General Setup -> Initramfs source file(s)" option.
Somehow when you do that, the kernel is able to find all the RAM it needs for the initrd.

Now, I'll grant you that this makes it less convenient to modify your initrd options on the fly, yet I believe this is better than being restricted in your choice of kernel features. Plus it appears that the kernel boots a little bit faster when using the emebedded initrd.

Of course, that means that you need to create your uncompressed cpio archive from your initrd-tree before you can point to it, which can easily be done as follows:

cd /boot/initrd-tree
find . | cpio -H newc -o > ../initrd.cpio

A farewell to LILO (One bootloader to rule them all, part 2)

As mentioned previously, I set up a bunch of disks in a mixed RAID configuration on my new P5B Deluxe system, and merrily went on installing OS after OS.

The point of this exercise was to have my main OS (probably Vista 32) as well as a near half-a-terabyte partition set in RAID 0 mode, for speed, while some other stuff, for which disk performance is not that critical (OS-X, XP, Linux, more space), would reside quietly on a 3rd non raid disk. And while I'm at it, I would also setup a RAID 1 partition, as the Intel ICH8R "controller" of the P5B is now nice enough to allow you to create both a RAID0 and RAID1 drive out of the same 2 disks RAID array.

Which leaves us with the obvious problem of booting that lot, a capital problem indeed ( especially now that Vista is being such an ass about its boot loader). As an aside, I would like to point out that this is what happens when a company has a near monopoly with regards to installed OS base: They will obviously do their darnedest to prevent ANY other OS from eating even the smallest part of their market share. And I could comment on OS-X too. What is wrong with a standard partition scheme that you will recognize once you get your hand forced anyway (but not any sooner)? Why are you not happy with a big fat bootable primary partition with af type setup for you with Linux's fdisk?
And much much worse, how comes the partitions OS-X creates end up on the exact same block as the start of the next partition (have a look at your fdisk results in Linux - What the hell?)? I might talk about that later on, because this headache resulted in recently losing both a fresh install of XP along with a data partition and, what's worse, my Linux system. As the old proverb go, "Install XP, lose your data"...

So, considering that I have now done this operation twice, let me give you the long awaited heads up on the one bootloader to rule them all...


Accessing the ICH RAID disks under Linux

o Compile kernel with device mapper
o Pick up the latest devmapper package from ftp://sources.redhat.com/pub/dm/
o Pick and compile dmraid
o dmraid -ay (if dmraid complains about missing kernel options, add them!)
o dmraid -s (Yay!) or ls /dev/mapper

And while you're at it, you can add something similar to this at the end of your /etc/rc.d/rc.local file (Slackware)

echo mounting RAID Volumes
dmraid -ay
mount -v -t ntfs /dev/mapper/isw_fhbagdjeh_Twix1 /mnt/vista32
mount -v -t ntfs /dev/mapper/isw_fhbagdjeh_Twix2 /mnt/vista64
mount -v -t ntfs /dev/mapper/isw_fhbagdjeh_Twix3 /mnt/strider
mount -v -t ntfs /dev/mapper/isw_fhbagdjeh_Secure1 /mnt/secure

Becomes simple enough... when you've done that twice.


So long LILO, and thanks for all the flawless boots...

One word if you stubbornly try to get LILO to boot one of the RAID0 partition as I did: Agh!!!

Fatal: Sorry, don't know how to handle device 0xfd02 => compile with latest source, as it will compile with devmapper (device-mapper or LVM2) if library is present. Look for -DDEVMAPPER when compiling.
OK then, added devmapper option, make all, make install and...
"Fatal : device mapper : only linear boot device supported"

Enought with this. I'm sure the LILO devs will add it some day, but for now grub it is then.


Pub grub?

GNU's versions: WTF? Pick up 1.95 and... configure: error: LZO library version 1.02 or later is required
OK then, http://www.oberhumer.com/opensource/lzo/download/ to eventually realize: You should NOT grub 1.95. It's really grub 2.0 and too spanking new to be of any use. Instead, pick up grub 0.97 and live happily ever after!

Now, some of you might see some mention of a grub 0.97 dmraid patch, but because I'm actually using the 3rd non RAID disk (actually 1st one on my system) to install the bootloader, as well as ultimately boot, patching grub is unnecessary. I guess it would be necessary if we were to use our RAID0 as the boot disk. I'll have to try RAID5 one day, just for kicks :D

So, without further adieu to LILO, and with thanks to the Gentoo users:

grub --device-map=/dev/null
# My actual non-RAID boot disk
grub> device (hd0) /dev/sda
# The RAID0 array where the Vista's reside
grub> device (hd1) /dev/mapper/isw_fhbagdjeh_Twix
# Let's first add Linux, so that we can then edit the menu.lst
# My Linux is on /dev/sda4, hence hd0,3 with zero based indexes
grub> root (hd0,3)
Filesystem type is xfs, partition type 0x83
grub> setup (hd0,3)
Checking if "/boot/grub/stage1" exists... yes
Checking if "/boot/grub/stage2" exists... yes
Checking if "/boot/grub/xfs_stage1_5" exists... yes
Running "embed /boot/grub/xfs_stage1_5 (hd0,3)"... failed (this is not fatal)
Running "embed /boot/grub/xfs_stage1_5 (hd0,3)"... failed (this is not fatal)
Running "install /boot/grub/stage1 (hd0,3) /boot/grub/stage2 p /boot/grub/menu
.lst "... succeeded
Done.
grub> quit

At this stage, you wanna check your /boot/grub/device.map file. If you don't see the /dev/mapper entry for (hd1) as expected, you will have to add it manually.

From then on, you can go on creating your /boot/grub/menu.lst, which might eventually look something like this:

default 2
timeout 3

title  Slackware Linux 11.0
kernel (hd0,3)/boot/vmlinuz root=/dev/sda4

title  Slackware Linux 11.0 (Rescue)
kernel (hd0,3)/boot/vmlinuz.rescue root=/dev/sda4

title  Vista (32 bit)
rootnoverify (hd1,0)
chainloader +1

title  Vista (64 bit)
rootnoverify (hd1,1)
chainloader +1

title  Windows XP
rootnoverify (hd0,1)
chainloader +1

title  MacOS 10.4.8
rootnoverify (hd0,0)
chainloader +1

Parting words

And thus, I will be leaving with a "so long old Friend..." Since 1995, there haven't been much of a PC installed by yours truly which didn't display the unmistakable red greetings, and I had become such an expert at writing a /etc/lilo.conf, I could have done it blindfolded.
Still, I gotta give it to the GNU guys... Their solution to the booting problem is deceivingly elegant. I'm especially impressed with the "modify menu.lst on the fly" aspect of things and the fact that dmraid "just" works...