Re: Re: hard disk move to another server

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On 27/02/07, dan1 <dan1@xxxxxxxxxxxx> wrote:
> dan1 spake the following on 2/20/2007 11:00 AM:
>> Hello everyone.
>>
>> I am looking for a way to move a CentOS 4 installed production hard disk
>> to another system (which has another hardware).
>> The first has an nvidia sata controller (sata_nv), but the second has a
>> via sata (sata_via).
>> For all the rest of the hardware it can upgrade well I know, but if the
>> sata driver is different, then the system doesn't boot because the
>> proper driver is not included in the initrd file (grub still boots OK).
>>
>> Here is the error message:
>> Uncompressing Linux... Ok, booting the kernel.
>> Red Hat nash version 4.2.1.8 starting
>> mount: error 6 mounting ext3
>> mount: error 2 mounting none
>> switchroot: mount failed: 22
>> Kernel panic - not syncing: Attempted to kill init!
>>
>> Does anyone know how I could upgrade easily this initrd file to contain
>> the proper driver, and even from another partition?
>> Would it be possible to keep an old config-xx file and do an rpm upgrade
>> which would automatically recompile a proper initrd-xx file for that new
>> system?
>>
>> Thanks for any help.
>> Daniel
> You could boot from a rescue disk, chroot to /mnt/sysimage, make sure that
> the
> proper driver shows in an lsmod, and re-install the current kernel rpm.
> That
> should redo the initrd. Somewhat easier than remembering the proper initrd
> commands.
>

Hello, Scott.
Thanks for the suggestion. I have tried what you said. This didn't work.
It did compile the new kernel, but has taken the other module, not the
correct one for the new system.
Maybe it did take the module from the old config file that it has found?
The /proc/modules directory was empty when chrooted, so I don't know if the
kernel installation could be done properly in such conditions, because the
'lsmod' when chroted was not able to open this directory to list the loaded
modules.
In any case, the initrd file of the new system (when working properly) is
different than the one reinstalled on the chrooted partition to upgrade with
the new module, and they should be the same.

Would you know what to do now by still using your interesting method?

It's been a little while since I've had to mess about with initrds but
if I recall correctly, don't you just need to add the new module to
/etc/modprobe.conf alongside the existing driver and then remake the
initrd with mkinitrd?

You can actually see what mkinitrd does as it's just a shell script
that pulls various bits and pieces together then creates a compressed
CPIO archive.

So add something like...

alias hostadapter2 sata_nv

Rebuilt a new initrd with, for example...

mkinitrd initrd-2.6.9-42.0.2.EL.sata_nv.img 2.6.9-42.0.2.EL

Then add a new Grub entry to try booting with that initrd? If that
doesn't help, there's a bunch of stuff in the list archives, just try
browsing through anything with a mention of mkinitrd in it.

Will.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux