On Tue, 12 Dec 2000, Crossfire wrote:
> > I've got HPT366 support compiled into a 2.4 kernel, and I use append
> > ide=reverse to get it to boot of the linux hd. This also has the effect
> > of switching the controllers locations, so that /dev/hda is now the
> > linux drive and /dev/hde the win2k. I've tried switching all the drives
> > in fstab and lilo.conf and not using reverse, but lilo hangs at LI.
>
> ide=reverse is not necessary - it only changes the order in which the linux
> kernel sees the devices. This is not needed except in a few rare
> circumstances. It holds no bearing on the boot process itself.
That makes sense, it was my original mental model, but then I'm not sure
why removing it and changing fstab back to the normal settings causes
lilo to hang.
> I can see two solutions:
>
> 1) [more involved, less complicated, more likely to work out of the box]
>
> Use partition magic to free up a tiny 20MB slice on the Win2k disk (if you
> haven't got a copy yet, buy or borrow one - either that, or nuke/rebuild a
> partition to make the space). Create an ext2 parition in that space, copy
> /boot to it, and then mount it under /boot at boot time. Make sure the
> kernel images you wish to boot are in that directory. Stop using
> ide=reverse, and unbreak your fstab. fix lilo.conf to reflect the new
> location of / and where the boot disk really is [/dev/hda]. Make sure you
> have lba32 enabled too. Run lilo -v, make sure everything is being found
> correctly.
>
> This should work a charm.
This is a solution I had thought of, but one I am loath to implement. I
realise that from a 'nix perspective physical drives don't matter so
much, but I would like to be able to put my linux drive in another
machine and boot it, so I am really loath to leave /boot on another
drive. Also, it seems like it might be a nice think to have on a raid
device.
> 2) [quicker to implement, more hackish, more complicated, more likely to
> fsck up whilst getting it right]
>
> Alternatively, you can might be able to get away by overrideing what LILO
> thinks the bios translation map should look like.
>
> I'm assuming that /dev/hda and /dev/hde are the only devices visable to the
> BIOS.... [if you have other drives, then you'll need to work out what
> device BIOS sees your linux disk as]
>
> in which case, including
>
> disk=/dev/hde
> bios = 0x80
> disk=/dev/hda
> bios = 0x81
>
> in lilo.conf [with ide=reverse still enabled] might fix your problem.
This sounds like a really good solution. True to your post though, it
did fsck up when I tried it. Not only did lilo hang, but linux refused
to boot from my rescue disk. I had to reattach the linux hd to the
non-raid controller to rescue it :( I'm thinking it's just probably that
the bios addresses for the disks are wrong. I only have the two drives
mentioned, and a CDROM as master on the second non raid controller, and
a floppy on a floppy controller. Is there any way I can find out the
exact bios translation map so I can get the above options right?
> Why It Isn't Working: [or (more correctly), why it shouldn't be working]
>
> LILO uses BIOS calls to load kernels from disk. the LILO installer
> [/sbin/lilo] has troubles translating devices to bios device numbers under
> certain circumstances. Furhtermore, BIOS can only access the first 4 drives
> in your system. By placing /boot and lilo on your real first disk, and not
> doing stupid things with IDE device reordering, LILO can map the BIOS id to
> the device properly, and access the kernel stored on that disk.
The BIOS for this mobo seems to be able to access the other drives, it
can specify booting the raid controller, for example. Do you know if
Grub would also have the same problems translating devices to bios
device numbers? If not, I might try to get my head around it instead of
lilo.
Thanks for your reply btw, it was really detailed and very helpful.
--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug
