Moving a kernel image from IDE to SATA
 

Hi,

I have a 16MB image of a bare bones kernel installation that was previously created using a 2.4 kernel and runs off /dev/hda1. It works when I copy the image directly into a IDE device and boot off it. The boot loader is nuni, and I've also tried it with LILO.

I recently upgraded the kernel to 2.6.22.19, and it still works with IDE devices. However, I wish to also move to SATA drives. Without changing the root_dev of the image, I'm able to get the image working on SATA drives, provided the PC's BIOS is able to do IDE emulation with SATA devices.

However, not all PCs have this option. In fact most laptops will not be able to do this since their BIOS options are very limited. In this case I get a kernel panic when booting up.

Hence I wish to support SATA natively with the kernel/image. However, I haven't been successful in doing so. Here's how I'm doing it.

I try to boot up the SATA drive either in IDE emulation mode, or with bochs emulator in software(with the image file).

With LILO/nuni, I've tried passing root=/dev/sda1 as a kernel parameter by modifying lilo.conf/nuni.kcl, but LILO doesn't even allow me to write the MBR with that information because when I'm booted up with the device in IDE emulation mode, it's being recognized as /dev/hda, so LILO complains of no such device as /dev/sda. nuni allows me to write the MBR, but doesn't work after that.

I've also tried recompiling the kernel and manually making root_dev as /dev/sda(801), but this did not work either.

Does anyone know how I can solve my problem?

Thanks.

Just curious (and of course not answering your question).
Grub/lilo would put you out of you misery once and for all, albeit at the cost of a boot partition, I admit.
So why ?

Not sure what you mean. I tried using LILO but was not able to get it to work. The reason I'm using nuni is because I want to suppress all warning/error/misc messages, and this includes the LILO boot menu. AFAIK there's no easy way of doing so. nuni OTOH works.

OK, so I managed to enable the debug messages(previously suppressed them) and the I'm trying the original image on a system that has a BIOS who allows either native SATA or IDE emulation.

So the original image has the following properties:
Linux kernel x86 boot executable RO-rootFS, root_dev 0x301, swap_dev 0x2, Normal VGA

When booting up from it in IDE emulation mode, I'm able to get to the shell(busybox)

However, when booting up in native SATA mode, I get kernel panic:
kernel panic - not syncing:VFS:Unable to mount root fs on unknown-block(3,1)

I'm using LILO, and booting up with the following lilo.conf(relevant portion)

Any ideas on how to get it to work with native SATA?

Thanks.

You're almost there - but the 'root=' part is passed to the kernel; it has nothing to do with lilo, so don't name the device based on what lilo thinks it will be but what the kernel might think it is. That should get you as far as running /bin/sh as 'init'.

Thanks, do you mean change the /dev/hdaX to /dev/sdaX? If so, I have tried that too. However, the problem is that the only way I can get it to even boot up, is to run it as /dev/hda first. Once there, when I change it to /dev/sda and then run lilo, it complains that there's no such device as /dev/hda, hence it doesn't write the MBR. Seems like a chicken and egg problem to me :(

If you mean something else, then I don't get it, and would love to hear it.

Thanks again.

What mister pinniped (What the phoque ?) tries to suggest is that you change you lilo.conf file to this (area changed in italic bold):
The first "root" specification is to tell _lilo_ where to go, the second specification is actually a parameter passed to the _booting_kernel_.

OK, I have just tried that, but didn't work either. Here's my updated lilo.conf(relevant portions)

bzImage.2.6.22.19-opt is a kernel image that's configured to HDA:
testImage is a kernel image that's configured to SDA
When I boot up in BIOS emulated IDE mode, bzImage.2.6.22.19-opt boots up correctly. testImage doesn't

When I boot up in native SATA mode, both kernels get kernel panics, with similar errors.
For bzImage.2.6.22.19-opt, it is:
For testImage, it is:
What else am I missing here? I've tried reading the LILO user guide, but I don't see anything I'm missing.

I'm also quite confused why the "boot" and first "root" should tell LILO to check /dev/hda, when it is in native SATA mode. I've tried switching these to /dev/sda but no go either.

Any help would be greatly appreciated, really stuck here and out of ideas...

OK, I seem to have solved the problem.

Turns out SCSI and SATA support was set as modules and not compiled into the kernel. The image works once I compiled them into the kernel. Thanks to everyone who has provided help so far.

arg, i spoke too soon. The kernel boots up on 2 desktops and a laptop, but gives the same kernel panic message on a Lenovo Thinkpad X60. I've already enabled all SATA/PATA/SCSI drivers in the kernel, even the dubious ones. Does anyone know what's so special about the X60?

I did a lspci -v on the X60 and the got the following relevant output

I look at my .config file and ata_piix is already enabled, so I don't know why it's not working :(

EDIT: OK turns out the X60's SATA setting in BIOS was set to compatibility mode instead of native mode. I could've sworn it was set to native yesterday, so I didn't think of checking...turned it back to native mode and it works.

However, this brings up a question - is it possible for the kernel image to support both modes? I mean, my Mandriva 2008.1 that's installed on a HDD boots up regardless of SATA mode, and the drive that it's installed in always shows up as /dev/sda regardless. Why is it that my own kernel cannot do this?

Well, compiling the support of everything into the kernel is just going to lead to a bloated kernel, and some more headache because unless you compile _everything_ in the kernel, you are finally going to find a machine/bios setting that's going to defeat you particular configuration.
What you need to look into is the creation of an initrd (or initial ram disk: see man mkinitrd) that is going to contain all the modules you require on your hardware, and if you do not want to load extra modules, customise it depending on the configuration.
Another approach would be to create an initrd that load all the possible modules, and then create a script that unload the unused ones, if you really need to free up memory. It's relatively low-risk, because you cannot unload a module that is used: i.e. you cannot unload the sata-related modules if you have sata hd in use.
I know it's a bit fuzzy, but that's the kind of solution you particular situation requires.