LILO drive choice issues
 

I recently rebuilt my home machine using Slackware. [Almost] Everything works well, but I added another SATA drive, and my system does not boot.

The BIOS selects the correct drive, LILO loads, but then I believe LILO tries to load my OS from the wrong drive. I don't remember the exact message, but it doesn't get far.

My configuration is set up to use /dev/sda1. How do I know which drive will be assigned sda1, sdb1, etc? Assuming sda1 will be either the drive the Bios boots from or the drive on SATA 1 doesn't seem to be a good assumption.

My system boots normal by disconnecting the SATA drive. I bet I can get this working by trial and error by repeatedly changing cables and my LILO config file, but I want to learn how to do it the right way.

Boot from the Slackware DVD and run:

# fdisk -l

for hints on the disks

You should also inspect the BIOS settings

Good idea, thanks!


What am I looking for?

You have to keep in mind that the hard disks are identified two different ways. During configuration and installation of LILO disks are identified by a device name, like "/dev/sda". During booting hard disks are identified by a BIOS drive ID, like 0x80 (hexadecimal 80).

0x80 First hard disk (default boot device)
0x81 Second hard disk
0x82 Third hard disk
0x84 Fourth hard disk

Lilo usually can figure out which device name corresponds to which BIOS drive ID. In cases where Lilo can't figure that out, you can tell Lilo the assignments in "lilo.conf.

For example:

How a BIOS assigns drive IDs is totally up to the BIOS, but the default boot hard disk is always assigned an ID of 0x80. That means if you change which drive boots first, it is going to change the drive assigned to ID 0x80. Also, changing the boot order of other drives may change the drive IDs assigned to the other drives. In some cases, even selecting a boot device from a BIOS boot menu will rearrange drive IDs. For example the device you choose may be assigned ID 0x80, moving other drives around.

Usually the order that a BIOS assigns drive IDs is in the boot priority order that you specified. That is not a rule, but it is very common. We are talking about disk drives "/dev/sda", "/dev/sdb", etc. and not partitions.

Once you set up Lilo, you should not change the BIOS device boot order. If you do change the BIOS settings, put them back the way they were before booting with Lilo or reinstall Lilo. When you chain from a different boot-loader to LILO, be careful. If the disk with Lilo is not at the ID where it was installed, then it won't be able to boot. For example, you can't just change your second drive to be the default boot device and then chain boot to Lilo on the first drive.

Some boot-loaders will also let you swap drive IDs before chaining to another boot-loader. In other words, you could swap IDs so that Lilo sees the expected assignments before chaining to Lilo.

The same drive ID issues apply to Windows, since it loads some of the operating system using BIOS drive IDs.

If Lilo is loading Linux from a particular disk, then it saves the BIOS drive ID for that disk. You won't be able to boot that Linux system if the ID of that disk drive has changed.

Partitions are only important to LILO during installation and configuration. Lilo converts everything to sector addresses, and only the sector addresses are used at boot time. If you do things that change the position of partitions or files, you have to reinstall Lilo. Even copying or updating the kernel file can change its location and prevent Lilo from loading that Linux system. Make sure that you always use the "lilo" command AFTER you make changes to the kernel files or file locations.

I don't know of any way to list the BIOS drive ID assignments. You can look at the order that the BIOS messages are displayed when it detects the disks. You can also boot GRUB in "native" command mode (not running in Linux) and search for files like "/boot/vmlinuz" to determine the drive IDs. GRUB uses names like (hd0) and (hd1) and those correspond to the BIOS drive IDs. When running the GRUB command from Linux, GRUB is guessing the drive IDs just like Lilo. To use GRUB in "native" command mode, boot to the GRUB menu and then press "C" to get into command mode. You can boot from a GRUB boot floppy or CD rather than installing GRUB to the hard disk.

When you are diagnosing boot problems look to see what is able to display messages. If you see the Lilo boot menu then LILO was able to load. You should use a menu time-out that is at least a few seconds so you can see the menu during testing. If you don't see any kernel messages at all, then the menu entry may be incorrect, the Linux system drive ID may have changed or the files for the Linux system may have been moved. If you see some kernel messages then you should look to see what error is displayed last. The kernel parameters in the Lilo menu entry specify the device name (including partition number) for the root file-system. If that device name is wrong, the kernel will display an error because it can't mount the root file-system. After the root file-system is mounted, usually kernel errors are due to something besides Lilo or menu entries.

Erik_FL, that's a really nice explanation of something which most folks find hard to understand.
"I don't know of any way to list the BIOS drive ID assignments." I've looked, but not found, a way to find out 'what the BIOS thinks' about disk order, but it seems it must be specific to the BIOS, so no universal scheme exists. I wished that dmidecode might be helpful, but it is not, so far.

I used to use UUIDs in lilo.conf and fstab when I had multiple hard disks - what are the opinions on that?

Unfortunately, my system doesn't work this way. If I have all my drives (that I currently have) hooked up, the only drive I can boot from is the one that ends up as sdb. If I take out the drive it assigns as sda, it assigns sda to the drive that was sdb. So if I hook up my system so it can boot, it works fine, I won't be able to boot without changing LILO should something happen to either hard disk - including 1 that doesn't have any part of my OS on it. I am hoping a BIOS flash will fix this.


Does that mean everyone here is reinstalling LILO every time they add, remove or change a SATA device?


Sounds like using the drive IDs is not a good idea if you want a system that can boot.


I don't think this is true for ANY version of Windows, at least unless it uses multiple drives. With a whole Windows System on a single drive, I have never seen a problem like this as long as that bios selects the correct drive to boot. Of course, this is a goofy BIOS and I haven't had a Windows System on it.

Try reversing the cable connections for the two drives. Some BIOS will assign drives in the order they are found.

Suppose I have only 2 drives, a LinuxDrive and a DataDrive and only 2 SATA slots, giving only 2 possible configurations that use both drives. In one configuration, it attempts to boot from DataDrive, which isn't bootable, and hangs before LILO gets loaded. In the other configuration, it boots from LinuxDrive, loads LILO, but assigns sdb to LinuxDrive. If I use the 2nd configuration and set up LILO to load Linux as sdb, everything works - however should DataDrive get removed at some point in the future (or should it fail), then LinuxDrive gets assigned sda and I won't be able to boot.

In reality, I have about 6 SATA connections and 4 SATA drives, but the problem is the same.

Hey,
Take a look at:-
http://www.linuxquestions.org/questi...1/#post4754397

These are my experiences with the Thinkpad w530. I describe how to use UUID's to reference your disks both in lilo and in fstab. This means that the references are independent of the order in which the disks are discovered. I find this particularly useful because although I have the boot drive set to my msata drive in the BIOS, this disk appears as /dev/sda if it is the only disk in the laptop, as /dev/sdb when I have an internal disk installed, and as /dev/sdc if I have a second disk in the ultrabay. Using UUID's means that you need an initrd because accessing drives via UUID's requires udev to be active prior to the access. Hope this helps. As always YMMV

cheers
pete

pete hilton
saruman@ruvolo-hilton.org

True. In fact you have to keep watch of FOUR naming schemes.

(1) the kernel naming scheme at lilo installation time
(2) the BIOS numbering at boot time
(3) the kernel naming scheme at kernel boot time (since the "root=" parameter is eveluated at that point)
(4) any references in the mounted file systems after boot (like in /etc/fstab)

At certain times (like when the PATA driver was changed in the kernel) it can be quite a brain-twister to fix problems in that area. :p

I was dealing with this as well, with an eSATA HDD, and finally just installed grub2. Say what you will about it, but it handles this sort of situation with no headaches.

It has been a while since I encountered this problem, but I now reference my boot and root devices by UUID in order to avoid this very situation.

Referencing them by UUID removes the device assignment ambiguity.

It sounds like you have two different SATA controllers, and the two drives are connected to different controllers. The controller that the BIOS detects first will be assigned the first set of device IDs. the controller that it detects second will be assigned the second set of device IDs.

You need to make sure that the boot disk (containing all your boot loaders and the MBR where they are installed) is always assigned drive ID 0x80. That may require changing the BIOS settings, or even connecting your boot disk to a specific controller. I doubt that this is your problem, because the fact that LILO starts up and displays a menu means the drive was assigned ID 0x80.

You can install GRUB or Lilo to a disk with a different ID than 0x80. That is useful mainly for chaining to GRUB/LILO from some other boot loader that is on ID 0x80. The BIOS might not let you boot directly from a disk unless that disk has drive ID 0x80. It's less confusing to just make sure that the boot disk is always drive ID 0x80.

Linux may be loading the drivers in the reverse order from the BIOS. That means if you remove the second disk, the device name of the first disk will change. This scenario seems to fit the problem that you described. To avoid boot problems in that case you have a few choices.

Use an "initrd" ram disk and create "udev" rules to force the desired device name assignments. You also have to create "udev" rules in the operating system "/etc/udev/rules.d" directory.

Refer to the root file-system and other partitions using the UUID (Universally Unique ID) assigned to the file-system. Linux will locate the correct partition no matter what device name it has.

Change the order that Linux loads the drivers. This can be done by building the first (boot) controller into the kernel and loading the second (data) controller as a module.

People generally install LILO to the hard disk on the first port of the first disk controller. In that case adding and removing drives has no effect on the drive IDs. A lot of people have just one hard disk and put all their operating systems and boot-loaders on that disk.

Most people do not have the sort of situation that you describe. I have that kind of situation with my computer, since it has two SATA controllers and an IDE controller. I use GRUB and have GRUB swap the BIOS device IDs in cases where that is needed (booting Windows from the second hard disk). I've also patched the Windows partition boot sector to start the Windows boot loader from the third hard disk.

Unfortunately there is no way to avoid using drive IDs because the first part of a boot-loader uses the BIOS to read from the boot disk. The only way that I know to avoid drive IDs is with a newer motherboard that supports UEFI. UEFI has its own set of different problems with finding boot devices.

Both GRUB and LILO use drive IDs to locate the kernel files, though GRUB 2 can "find" files at boot time and conceivably adjust for changes. GRUB (legacy) is my preferred boot loader. GRUB understands file-systems and does not care if the locations of files on a disk have changed. GRUB has a "native" command mode that allows one to manually enter boot commands or edit the boot menu entries.

Windows has the same sorts of BIOS ID problems as Linux (even worse because it assumes the boot loader is always on BIOS ID 0x80). When the BIOS changes the ID of the Windows system files, Windows will not boot. You have to edit "BOOT.INI" or use the "BCDEDIT" program (Vista and later) to change the boot configuration. Windows uses disk signatures to locate file-systems later on during booting. Using the UUID in Linux to mount file-systems does essentially the same thing.

If you install Windows with two drives connected, and then remove one of the drives (even not the OS drive) then Windows might not boot until you adjust the boot configuration. That is only likely to happen where you have multiple disk controllers and you are not booting Windows from the one that Windows detects first. Removing a drive can also cause Windows Activation to detect a change and require you to re-activate Windows. In that case you can't even log on until you re-activate Windows.

Linux cleanly separates the BIOS ID portion of loading from the file-system portion of loading. The boot-loader, kernel and initrd files are all loaded using the BIOS drive ID. The files inside the "initrd" are loaded using the "initrd" file-system. The rest of Linux is loaded using the virtual file-system. Linux really does not care if the device names change, as long as the correct devices are mounted for the root file-system and other mount points. The key to making Linux start up is getting the correct devices mounted at the correct places (use UUIDs or udev rules to make them consistent).

Windows uses a hybrid approach. The Windows boot-loader, the kernel, and some of the windows files are loaded using the BIOS drive ID. Critical drivers and the boot device driver are loaded using kernel device names E.X. "\\.\PHYSICALDRIVE2\PARTITION2". The remaining files and drivers are loaded using a DOS device name E.X. "C:\". How Windows ties all the names together is not well known. Windows does not detect device configuration changes until after it has booted. That means you can only boot from the single boot device that was installed by Setup in the configuration that it had when it was installed by Setup. Windows does not tolerate drive letter changes for the Windows drive. If you install Windows to drive D: then Windows will always use drive D:. If the configuration changes in such a way that a different letter is assigned, then Windows will not boot. You can edit the registry off-line using another OS or make minor adjustments to fix some Windows boot problems, but major changes require re-installing Windows. I have used the trick of letting Windows detect new hardware plugged into a computer BEFORE changing the system to boot from that new hardware.

The problems you are seeing are not unusual for systems that have multiple disk controllers. A lot of retail computer systems avoid those problems by having just one disk controller, built into the chip-set to save money. Deluxe motherboards or server motherboards often have multiple controllers. I've built my own home systems many times, and run into a number of boot issues because of the multiple controllers. PCs have been diverging further and further from the original "IBM PC" hardware. Windows has made that problem worse, because retailers assume that everything will run Windows and are happy to make the hardware on every computer different as long as Windows works with it.

The original BIOS did not take multiple disk controllers into account. At the time, having even one hard disk was a luxury. There are a lot of undocumented BIOS design assumptions and manufacturers can honor them or not. Often it is a matter of ignorance rather than intention. The UEFI standard requires that device names are assigned in a consistent manner in spite of hardware changes. Whether computer manufacturers will honor that requirement is another matter.

@Eric FL
Your insight and knowledge about boot problems are impressive - infact, I would recommend _anyone_ with the slightest hint of boot-problems to read your postings here - the moderators should make it sticky!

I pride myself to be able to solve most boot-problems, and like you, I prefer legacy grub and chainloading (always having at least 2-3 distro's on each disk) *chuckles*
But also I have run into problems - like using slackware on a big (like 32 gigs) usb-stick and hoping to boot it on any computer ... the problem being that uuid's are not known until the kernel (or initrd) is loaded. When you boot from a usb-stick and use bios to select it - initially it is 0x80, but then, as things load, it will end up as sdb, sdc etc - dpeneding on the number of hard-disks in your system *sigh* - it certainly is hard to get it right. What I did in my particular case was to assume only one harddisk in the host and when it failed to boot - to pay attention to where it ended up - then reboot and edit the grub 'kernel'-entry *lol* - it works ...

USB sticks is an interesting subject for another thread. I've run into the problems you describe as well as a few others. Windows, for example, refuses to see more than a single partition on a removable drive. Add to that the complication that some BIOS software does not consider a USB drive a boot device unless it sees multiple partitions. There are the older computers that don't support USB disk booting at all; Some that only support USB CD booting; And some that have horribly slow USB emulation, making a CD actually faster than USB sticks. I'm still learning about making USB boot media. Here are a few links that you may find useful.
Explanation of U3 vs other flash drives
Tools to make custom U3 CD images
USB CD Rom Emulator
ISO Stick