LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
LinkBack Search this Thread
Old 01-15-2013, 11:44 AM   #1
bvbellomo
LQ Newbie
 
Registered: Dec 2012
Posts: 23

Rep: Reputation: Disabled
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.
 
Old 01-15-2013, 12:56 PM   #2
ChrisAbela
Member
 
Registered: Mar 2008
Location: Malta
Distribution: Slackware 14.1
Posts: 467

Rep: Reputation: 87
Boot from the Slackware DVD and run:

# fdisk -l

for hints on the disks

You should also inspect the BIOS settings
 
Old 01-15-2013, 01:05 PM   #3
bvbellomo
LQ Newbie
 
Registered: Dec 2012
Posts: 23

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by ChrisAbela View Post
Boot from the Slackware DVD and run:

# fdisk -l

for hints on the disks
Good idea, thanks!


Quote:
Originally Posted by ChrisAbela View Post
You should also inspect the BIOS settings
What am I looking for?
 
Old 01-15-2013, 10:12 PM   #4
Erik_FL
Member
 
Registered: Sep 2005
Location: Boynton Beach, FL
Distribution: Slackware
Posts: 793

Rep: Reputation: 245Reputation: 245Reputation: 245
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:

Code:
disk=/dev/sda
     bios=0x80
disk=/dev/hda
     bios=0x81
disk=/dev/sdb
     inaccessible
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.
 
5 members found this post helpful.
Old 01-16-2013, 02:52 AM   #5
gnashley
Amigo developer
 
Registered: Dec 2003
Location: Germany
Distribution: Slackware
Posts: 4,725

Rep: Reputation: 450Reputation: 450Reputation: 450Reputation: 450Reputation: 450
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.
 
Old 01-16-2013, 05:13 AM   #6
cynwulf
Senior Member
 
Registered: Apr 2005
Distribution: OpenBSD
Posts: 1,103

Rep: Reputation: 333Reputation: 333Reputation: 333Reputation: 333
I used to use UUIDs in lilo.conf and fstab when I had multiple hard disks - what are the opinions on that?
 
Old 01-16-2013, 09:17 AM   #7
bvbellomo
LQ Newbie
 
Registered: Dec 2012
Posts: 23

Original Poster
Rep: Reputation: Disabled
Quote:
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.
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.


Quote:
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.
Does that mean everyone here is reinstalling LILO every time they add, remove or change a SATA device?


Quote:
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
Sounds like using the drive IDs is not a good idea if you want a system that can boot.


Quote:
The same drive ID issues apply to Windows, since it loads some of the operating system using BIOS drive IDs.
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.
 
Old 01-16-2013, 10:59 AM   #8
dwblas
Member
 
Registered: Jun 2011
Posts: 51

Rep: Reputation: Disabled
Quote:
If I take out the drive it assigns as sda, it assigns sda to the drive that was sdb.
Try reversing the cable connections for the two drives. Some BIOS will assign drives in the order they are found.
 
Old 01-16-2013, 11:13 AM   #9
bvbellomo
LQ Newbie
 
Registered: Dec 2012
Posts: 23

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by dwblas View Post
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.
 
Old 01-16-2013, 12:56 PM   #10
bimboleum
Member
 
Registered: Oct 2009
Posts: 38

Rep: Reputation: 4
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
 
Old 01-16-2013, 01:30 PM   #11
Martinus2u
Member
 
Registered: Apr 2010
Distribution: Slackware
Posts: 339

Rep: Reputation: 42
Quote:
Originally Posted by Erik_FL View Post
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
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.
 
Old 01-16-2013, 02:09 PM   #12
Beelzebud
Member
 
Registered: Oct 2010
Distribution: Arch & Slackware
Posts: 95

Rep: Reputation: 22
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.
 
Old 01-16-2013, 02:31 PM   #13
astrogeek
Senior Member
 
Registered: Oct 2008
Distribution: Slackware: 12.1, 13.0, 13.1, 13.37, 14.0, 64-14, -current
Posts: 1,509

Rep: Reputation: 509Reputation: 509Reputation: 509Reputation: 509Reputation: 509Reputation: 509
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.
 
Old 01-16-2013, 02:36 PM   #14
Erik_FL
Member
 
Registered: Sep 2005
Location: Boynton Beach, FL
Distribution: Slackware
Posts: 793

Rep: Reputation: 245Reputation: 245Reputation: 245
Quote:
Originally Posted by bvbellomo View Post
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.
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.

Quote:
Originally Posted by bvbellomo View Post
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.
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.

Quote:
Originally Posted by bvbellomo View Post
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.
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.
 
1 members found this post helpful.
Old 01-16-2013, 07:55 PM   #15
perbh
Member
 
Registered: May 2008
Location: Republic of Texas
Posts: 204

Rep: Reputation: 32
@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 ...
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
RAID 1 hard drive choice and sata expansion issue macdudeosx Linux - Hardware 1 03-07-2011 07:00 PM
lilo issues millionknives Slackware 3 08-21-2008 09:56 PM
External Hard Drive Enclosure of Choice? DragonM15 Linux - Hardware 7 08-22-2007 11:35 AM
Toshiba SPM30 DVD Drive choice and HDD noise and linux 8 boot problems goldorak Linux - Hardware 2 04-20-2004 03:01 AM
no choice for lilo- now can't dual boot netwench Linux - Newbie 10 06-30-2003 10:10 AM


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

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