Lilo and root option
 

I'm trying to better understand how does lilo works. I've a question about
root=root-device option in lilo.conf. Documentation says that if we omit that option it "defaults to the root-device setting contained in the kernel image".
I'm wondering whats the exact vale of that setting and how is it evaluated & set when we run lilo:
1.) from "normal" HDD installed system
2.) from Live CD/DVD

Hello,

you may take a look at the kernel-sources to find the answer. Your question is not really lilo-related. The Option is a kernel-parameter. When you don't define a kernel-parameter in the configuration of your bootloader (or on the commandline), the kernel uses the default parameter. This is true for any kernel-parameter.

As of the "root" parameter. In the kernel-documentation (in the kernel-sources) you find a textfile named kernel-parameters.txt which leads you to the code in init/do_mount.c in the kernel-source. There you will find a detailed explanation as a comment.

Hope that helps

Markus

The Lilo configuration "root=" option identifies the disk to have the MBR overwritten. It has nothing to do with the root= kernel option.
reference: http://www.tldp.org/HOWTO/text/LILO

In the early days, the loaded kernel was directed to which disk was root by setting the device parameters in the kernel (I believe the command was "rdev") which modified the actual kernel binary. This was superseded by the more flexible root= option to the kernel, and over time the rdev utility dropped. It actually can't be used with most kernels as the kernel root is actually the ramdisk created from the initrd file.
reference: http://linux.about.com/library/cmd/blcmdl8_rdev.htm

A bootable CD/DVD is created using the mkisofs/genisoimage as the output file has to have the boot block set before the CD/DVD is written (I don't believe LILO can do it). An idea of the procedure is given in the reference, but I'm not sure of everything working the same on all systems (it ought to, but I haven't done it... and you can look up the syslinux boot reference). Using grub instead looks easier (but also look for a grub2 version, I'm not sure whether it is the same procedure)
reference: https://www.centos.org/docs/5/html/5...s-make-cd.html
https://www.gnu.org/software/grub/ma...D_002dROM.html

I don't think you're right. The option which tells lilo in which partitions MBR to install the bootloader is the "boot=" option.

I'd recommend to refer to the lilo.conf manpage and also the tldp-tutorial you refer to speaks of the boot-parameter.

Markus

Hmmm.. I think you are right, and it looks like I'm wrong. There have been changes to Lilo (and I still need to dig into the changes with v22 and later) to see what the changes were. I'm used to using the root= in both places, and getting the correct MBR set.

I guess I've been using grub for too long...

Apologies.

This may be a typo, but it is not correct. I think that you meant to say, "The Lilo configuration boot= option...", but that still would not be accurate as you limit it to the MBR.

The lilo boot= option specifies the device to which the boot sector (or, boot record) is to be written. Most commonly this is of the form /dev/sdx, in which case the MBR of the drive will be written. However, it may also be a specific partition such as /dev/sda5, in which case the MBR is not written.

I think the lilo.conf man page may be a little confusing for some people as well...

The first sentence is correct and complete. But there is really no reason to say that the boot-device in the lilo.conf file should be the currently mounted root partition. That conflicts with some common chain booting scenarios, for example, and precludes managing the boot record of one instance from another - something that I commonly do on multi-boot systems.

I cannot reconcile this part of the statement with my own lilo uses and suspect it is a leftover comment from the dim past... maybe if it said "is probably" or "is usually", instead of "should be" which infers that something is wrong if it isn't.

The notice is definitely old... and goes back to the issue of the bios functions not being able to load disk blocks that exceeded a 1024 cylinder boundary... (part of the reason for the /boot as a separate small partition too - originally I remember it having a relatively small root, with /usr, /var, /tmp mounted after the kernel started, and the kernel was stored in the root filesystem. the /dev, /etc, /lib, /sbin, and /bin held only what was needed to maintain/restore/mount /usr and any other filesystems.

But as shown, my memory is faulty...

I know the feeling!

If it weren't for my computer RAM, I would have no memory at all! ;)

Unfortunately we can't just swap out the bad sticks in our brains!

I think of it as a database... with a small memory leak, but the indexes are still mostly valid.. just that they link to the wrong records sometimes.

:)