[ Prev ] [ Table of Contents ] [ Front Page ] [ FAQ ] [ Next ]

(?) The Answer Guy (!)

By James T. Dennis, tag@lists.linuxgazette.net
LinuxCare, http://www.linuxcare.com/

(?) LILO Hangs in Switzerland

From Tom on Fri, 05 May 2000

Hi Jim (or James? Is Jim short for James?)

(!) Jim is short of James. I tend to go by Jim.

(?) First let me thank you for the work you're doing in the LG. I've read it for about 2 years now and have seen lots of tips. Even the AnswerGuy section is interesting, sometimes amusing... But let me come to the point now ;-)

I have Suse Linux 6.3, Kernel 2.2.13, with NCR SCSI and 2 disks. With fdisk I set Boot=Y on /dev/sda1.

mtab looks like:

/dev/sda1 /boot
/dev/sda2 /
/dev/sdb1 /home

But mtab will be processed after LILO has loaded the kernel, right?

(!) /etc/mtab is the file which contains a list of currently mounted filesystems. /etc/fstab is the list of filesystems which are "known" to the system. /proc/mounts is a virtual file, it is a dynamic representation of the kernel's mount table.
/etc/mtab might be out of sync with you /proc/mounts in cases where the system is in single user mode --- and the root filesystem is mounted read-only, or under other add circumstances. /proc might not be mounted in some other cases. The structure of the two files is similar, but not quite identical. I've experimented with making /etc/mtab a symlink to /proc/mounts (and adjusting a few startup scripts to cope with that). It seems to work.
The main commands that use /etc/mtab are the 'mount' command (when used with no arguments, to display the list of currently mounted filesystems) and the 'df' command (which displays the currently available free space on each mounted fs). Personally I think these (and any others that need this info) should be adjusted to use /proc/mounts in preference to /etc/mtab --- since this would be one step that might allow us to mount / in read-only mode.
Of course that should be abstracted through a library and it should still be able to use /etc/mtab for cases where /proc isn't available (particularly on some sorts of embedded systems).
But I digress.

(?)lilo.conf looks like:

initrd = /boot/initrd    # exists
boot = /dev/sda          # put the Bootstrap code here
image = /boot/vmlinuz    # exists
root = /dev/sda2         # the device holding /
label = lx               # short but unique :-)

When running lilo, it shows
Addes lx *

When rebooting the system, it hangs after printing LI. I've read the lilo-README. It says that this is caused by "geometry mismatch" or having moved "/boot/boot.b without running the map installer."

Uuuuh?!? What's the problem? I just don't get it ... Please help me. - Thank you!

Greez from Switzerland!

(!) Try adding the "linear" directive to the global section of your /etc/lilo.conf. That would be the part before the first "image=" directive.
Try running /sbin/lilo -v -v (should give more verbose output).

(?) LILO: linear Directive

From Tom on Mon, 08 May 2000

Hello Jim

Thank you for your quick response!

Try adding the "linear" directive to the global section of your /etc/lilo.conf. That would be the part before the first "image=" directive.

I've done that and ... it works! Why does it? Is there a general problem with SCSI-drive(r)s and the old style adressing C/H/S? AFAIK "linear" means that the sectors on a disk are counted from 0 to n, as the SCSI does itself on block devices. But now I'm digressing ;-)

Thanks again! Tom

(!) The failure mode you described (the LILO loader stops at just LI) is described in their documentation ("tech.dvi" or "tech.ps" depending on your distribution/source).
Basically the boot loader prints the letters LILO one at a time, and each at a specific point in its boot process. This is useful for debugging and troubleshooting. LI says the the first stage boot loader completed, and the second stage boot loader was found, but the mapping data (used to find the kernels, etc) was not. This is usually due to a problem where the BIOS and the LILO loader are using incompatible blocking addressing modes. (One is using CHS --- cylinder/head/sector --- while the other is using LBA/linear).
Sometimes SCSI expect linear addressing, some SCSI controllers or controller/drive combinations emulate the old WD1003 (ST506) interface closely enough that CHS addresses will do.
Sometimes you need to switch your CMOS/BIOS to use UDMA/LBA modes and/or add the "linear" to your /etc/lilo.conf --- sometimes you need to just take the "linear" directive out of /etc/lilo.conf (and re-run /sbin/lilo, of course).

Copyright © 2000, James T. Dennis
Published in The Linux Gazette Issue 54 June 2000
HTML transformation by Heather Stern of Tuxtops, Inc., http://www.tuxtops.com/

[ Answer Guy Current Index ] greetings   1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18 [ Index of Past Answers ]

[ Prev ] [ Table of Contents ] [ Front Page ] [ FAQ ] [ Next ]