Disassociating kernel/boot loader from drive position
Linux - KernelThis forum is for all discussion relating to the Linux kernel.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Disassociating kernel/boot loader from drive position
It seems that the kernel and boot loader are both associated with the drive position/device name. For example if I have 2 SATA hard drives with Linux installed in each of them as the boot drive(/dev/sda), and I try to plug them both into 1 PC, only the one plugged into the lower SATA port would work as it would resolve to /dev/sda, while the other would resolve to /dev/sdb. Is there a way without recompiling the kernel and rerunning LILO that this could be done automatically?
It isn't clear what exactly you want to do. The boot disk is determined by the host BIOS, at least in the case of a typical desktop PC. The BIOS finds a bootloader on the Master Boot Record of the first disk. From there, a boot loader must be able to find a boot directory, on a filesystem type known to it. That includes most common filesystems, but not Logical Volumes as used by the LVM system. In the case of the grub bootloader, it has it's own vision of a 'root' filesystem, which you can manipulate in grub-install.
This defines where grub will look for kernels and it's config file, grub.conf.
Grub sets up the root/first partition for the kernel, and is subject to your control by modifying grub.conf:
You can use any partition that is readable by grub (LVM restictions).
The way you tell the kernel to find it's root directory is via commandline arguments, and this can be modified in grub.conf.
I cannot remember if LILO is as flexible. I do know that you would need to re-run LILO to modify the boot capabilities.
You do not need to rebuild kernels just to put them in a different boot directory, but you may have to tell it where to find its root directory.
Thanks. Sorry for not being clear. Here's my problem.
I have a couple of SATA storage devices that boot up to an application, i.e. not a full fledged Linux OS with full user control, but simply uses Linux as the OS to boot up a specialized application. Think of them as kiosk applications, such as ATM, or something like that.
I'm using a custom built Linux 2.6 kernel whose rootdev is set to sda. I'm using LILO as the boot loader, and lilo.conf points to the kernel and root is set to sda also.
From my own experiments, the way sda/sdb is assigned depends on the which SATA port the device is connected to. A lower number SATA port will have a lower alphabet assignment. For example, if device 1 is connected to the SATA0 port and device 2 is connected to the SATA2 port, and nothing else is connected, then device 1 will resolve to sda and device 2 to sdb. Take away device 1 and reboot, and device 2 will now be sdb even though it's in the SATA2 port, because nothing is connected to a lower SATA port.
In the above example, if I set the BIOS 1st boot priority to device 1, everything is fine as device 1 resolves to sda. However, if I set the 1st boot priority to device 2, it will kernel panic while booting up since device 2's boot loader expects to find the kernel in sda, however it is actually sdb now.
So, I'm asking if there is a way to solve this problem automatically w/o having to rerun LILO or recompiling the kernel or even having the user choose from the menu which kernel to boot. Since this is for a kiosk like application it needs to be transparent to the user.
Okay, I understand. To re-state your question, you want to know if/how the BIOS &/or bootloader can have a 'fallback' or ordered preference of boot devices. This would operate in principle like the usual BIOS 'Boot Order' system where you specify typically 'Floppy - CD/DVD - Hard-disk' boot device order.
AFAIK, this is not a feature supported by common bootloaders, although it may be supported by many BIOSes, where there is the capability to have multiple hard-disks in the ordered list of boot preference. In principle, where this capability is present, you can get what you want, as long as all of the necessary boot-time ingredients are present on the 'backup' (SDB, in your example) drive. These ingredients would include, at least,
1. MBR flagged as bootable (so BIOS knows to expect a bootloader).
2. A full /boot directory, correctly configured to provide a root directory on the remaining drive.
3. The specified kernel and its parts, loaded on the /boot directory.
4. A functional root directory for the kernel to boot from.
You should be able to use either Grub or Lilo as bootloaders in this scenario. To get such a configuration assembled, I believe you would have to modify the hardware configuration once or twice to use Lilo. To use grub, you should only need to modify the grub-install script to create the bootloaders on each disk.
I use this method for dual-booting Windows and Linux. The Windows disk is a fully independent drive, and when not booted by grub on the main boot disk, it will self-boot as the primary disk, as long as the BIOS treats it as the 'first' disk. I guess having a second Linux bootable drive would/could work the same way.