I just replaced most of my hardware, (motherboard, graphics card, cpu). now my system won't boot. all hardware is detected, and the system checks for bootable cd's, before trying to load lilo, which is where it stops. No kernel panic (dkeyboard still responds), no error message of any kind, . the old system was an AMD AthlonXP 2500+, while the new one is an AMD-64 3700+.

this is what I see on my screen
I tried booting from an old morphix disc I found in a drawer, it worked fine, so the hardware is connected properly. anyone ever heard of a similar situation? what will I need to do?


edit: by the way, I am using Mandriva 2006.0, free version, with a custom kernel, not that this should matter since lilo does not get started.

Try to rescue Mandriva with a Live CD.

Task B3 of "just booting tips" in my signature refers.

All the commands are there.

I tried to use cd1 of the x86_64 install set, and select rescue. the result: it loads the kernel (alt0) and the bottom line of the screen says "ready" then everything stops, same symptoms as before.

edit: seems I found at least part of the problem: I pulled my secondary controller card (IDE) and now rescue starts fine.

edit2: so does the system, up to the point where disks are to be mounted, shockingly, the system cannot check the disks that were connected to the controller card... is it possible to bypass fstab, or at least have it ignore all disks not conected?

You can put a # in front of the line in fstab to temporarily disable the partitions you don't want it to mount.

Would benefit from a Grub bootable disk so that you can boot the system up manually.

I have moved hard disk, with 25 to 35 Linux inside, from PC to PC and I would say 1 in 10 only needs a re-install.

I experimented some more, and came up with the following:

the controller card is fine, but if I connect any of the disks that are supposed to connect to it, boot fails.

Some searching revealed that the lilo bot code "LIL" means that the secondary loader was started but cannot load the descriptor table from the map file. typically caused by media failure or geometry mismatch. not sure what the last means, but all the partitions mount fine when the disk is connected by usb.

Did you boot the same disk by USB before?

the bootable disk(hda) is fine, the problems are with disks hde, hdf and hdg, when connected to a pci controller card. when I connect each these disks by an ide-to-usb cable to my laptop and mount one partition at a time, I can read the contents fine. Even when boot fails, the disks are detected. the problem is, as I wrote above, when lilo tries to work with the disks. they are connected in the same order as before I changed motherboard.

As far as I am aware Linux installed in an internal hard disk does not boot in an external disk via a USB cable because special tweaked kernel and ramdisk are needed for such an application.

The fact that hda boots successfully confirms there is no problem with the hardware.

Is this your first attempt to boot the systems up via the USB connection? The speed of the CPU and the drive do come into consideration whenever a USB device is booted and many distros have to switched to a different boot loader in such a situation.

you misunderstand: I do not attempt to boot from usb, I used usb to check that the disks are in fact not broken. the usb enables me to change the disks while my laptop is on,saving lots of time.
my problem is that the system fails to boot if I connect these disks to my controller card.

the disks are fine, the system itself is good, the controller card is working, but when I connect the disks to the controller card, lilo is unable to finish booting the system. the problematic drives contain various video, audio, etc.nothing critical for booting.

You changed something in the setup of the disks, I guess. Lilo is not very sophisticated and uses physical locations on the disk to get to working boot. My guess is that if you boot with a rescue/boot disk (now you know what those were for) and run lilo again you will be fine(if the location of the drives has not changed, probably they have. Edit lilo.conf in that case).
Or switch to grub, that would at least have given you a way to repair the boot ad-hoc.

booting into rescue mode from a setup cd when the troublesome drives are connected, results in the kernel being loaded, then "ready" at the bottom of the screen, and then nothing.

I booted the rescue without them, and checked lilo.conf, there is no reference whatsoever to any other drive than hda. running lilo is not possible with the drives connected, since the boot never gets to a point where I have access to a command line.

In that case refer to Task B3 in my signature on the link of

Just Booting Tips

It describes the commands to restore Lilo using a Live CD.

I also described using a rescue CD to do the same job in Task D4.

If you cannot get a livecd to boot on the system I gues it is your hardware that is causing trouble(as you have alreasdy indicated yourself). If you kept the master slave settings as they were and the bios does not swap the disk around with the extra controller, and you still are not able to acces the other disks, then you have a controller that does not play nice with your new MB. I don't think it has much to do with linux.

Didn't help. lilo.conf and all related settings appear to be technically sound, and the hardware seems to be good.

when I boot the system without the controller card installed, the system boots fine.

when I boot with the controller card installed but with no disks attached, the system boots fine.

but when I connect one or more disks to the card, all looks good while the bios handles things. the moment lilo takes over, boot stops.

it seems that somehow lilo has become incompatible with this controller after I changed motherboard. (old was NF7, new is NF8-ultra, both from ABIT). it has worked with the same order of disks for months, same lilo setup, same disks.

I did a quick test, even a reinstall of the system will not work, the boot loader on the install cd cannot handle the extra disks either.

seems you are right, I have seen a couple of references to trouble with the KN8-ultra motherboard and the promise ATA133 controller, but I have not yet pinpointed any details, because the pages are unavailable. (google links outdated)