What partitions are used to make /dev/md1?
> Thus, lilo.conf looks like:
All my use of lilo and RAID is with boot=/dev/hda.
I guess the above should work if the system is setup to look for a boot
record on /dev/hda1 (or whichever is the name of a part of the RAID-1 mirror)
by having it marked active and having the Debian MBR, the DOS "fdisk /mbr" or
something similar. But why would you want to? Is the aim of this to enable
swapping /dev/hda and /dev/hdc (or whichever drives comprise the RAID-1)
without re-running LILO?
> % dpkg -s lilo
> Package: lilo
> Status: install ok installed
> Priority: important
> Section: base
> Installed-Size: 271
> Maintainer: Russell Coker <firstname.lastname@example.org>
> Version: 1:21.7-3
> Depends: libc6 (>= 2.2.1-2), debconf (>= 0.2.26), logrotate
> The debian version of lilo writes a boot sector that hangs hard for the
> above kernel+raid+lilo.conf configuration: specifically:
> LIL- after a reboot. Needless to say, recovery was painful. But I
> was able to verify that the redhat lilo rpm always functioned correctly,
> and the debian-unstable dpkg always hung in this way. Although at one
> point, during my twisting & turning, I got the debian lilo to get to only
> LI before hanging. I have no idea of what I did different to get to that
> as opposed to LIL-
LI The first stage boot loader was able to load the second stage boot
loader, but has failed to execute it. This can either be caused by a
geometry mismatch or by moving /boot/boot.b without running the map
LIL- The descriptor table is corrupt. This can either be caused by a
geometry mismatch or by moving /boot/map without running the map
The error "LI" is easy to cause. Just do mv /boot/boot.b.backup /boot/boot.b
As for "LIL-". Are you sure that everything is fine with your geometry?
Maybe your BIOS and the kernel have different ideas about how things are
supposed to be? I imagine that you installed a newer kernel etc at the time
of your upgrade from Red Hat to Debian so this could be a partial cause.
> BTW, I noticed that oddly, every time I ran lilo, and then ran lilo -q -v
> -v, it reported different sector numbers for the kernel images. This
> freaked me out at first, but I came to accept it as normal: doesn't affect
> bootability. But is this really w.a.d? (I was assuming, appearently
> erroneously, that lilo -q -v -v was reporting the physical location of the
> kernel image on the disk; but since the numbers bounce around, that can't
> be right. Or is this just weird bios head/cyl/sect math flakiness?)
I'll leave that for John to answer.
-- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to email@example.com More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/