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
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.
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?
On 27/02/07, dan1 dan1@edenpics.com 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.
On 27/02/07, Will McDonald wmcdonald@gmail.com wrote:
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.
Just quickly testing this, it doesn't appear to include the module unless it's explicitly preloaded with...
mkinitrd --preload sata_nv -v wmcd.img 2.6.9-42.0.2.EL
Compare...
[root@stella boot]# mkinitrd --preload sata_nv -v wmcd.img 2.6.9-42.0.2.EL | grep ata Looking for deps of module sata_nv libata scsi_mod Looking for deps of module libata scsi_mod Using modules: ./kernel/drivers/scsi/scsi_mod.ko ./kernel/drivers/scsi/libata.ko ./kernel/drivers/scsi/sata_nv.ko ./kernel/drivers/md/dm-mod.ko ./kernel/fs/jbd/jbd.ko ./kernel/fs/ext3/ext3.ko ./kernel/drivers/md/dm-mirror.ko ./kernel/drivers/md/dm-zero.ko ./kernel/drivers/md/dm-snapshot.ko copy from /lib/modules/2.6.9-42.0.2.EL/./kernel/drivers/scsi/libata.ko(elf32-i386) to /tmp/initrd.r10911/lib/libata.ko(elf32-i386) copy from /lib/modules/2.6.9-42.0.2.EL/./kernel/drivers/scsi/sata_nv.ko(elf32-i386) to /tmp/initrd.r10911/lib/sata_nv.ko(elf32-i386) Loading module libata Loading module sata_nv
With...
[root@stella boot]# mkinitrd -v wmcd.img 2.6.9-42.0.2.EL | grep ata
Will.
dan1 spake the following on 2/27/2007 1:30 PM:
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?
Sorry for the mis-lead. I haven't had to do it in such a long time that I probably missed a step. I think the modules need to be listed in modules.conf, which should be on your chroot. You will probably need to edit it to add the module you need. This also implies that the module you need is in a stock kernel.
On Tue, 2007-02-20 at 20:00 +0100, dan1 wrote:
Hello everyone.
<snip>
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?
You can at least try to prepare a new initrd (name it differently and create a different entry in grub.conf) with mkinitrd. mkinitrd has a nice feature called --with=module so you can try to mkinitrd --with=sata_via to include this module even if not 'already' specified in /etc/modprobe.conf (don't forget also to change this after the machine has correctly booted : 'alias scsi_hostadapter=') I've never tested such hdd migration but it should work ...
You can at least try to prepare a new initrd (name it differently and create a different entry in grub.conf) with mkinitrd. mkinitrd has a nice feature called --with=module so you can try to mkinitrd --with=sata_via to include this module even if not 'already' specified in /etc/modprobe.conf (don't forget also to change this after the machine has correctly booted : 'alias scsi_hostadapter=') I've never tested such hdd migration but it should work ...
Hello, Fabian.
Sorry for the very late answer. You are right, this did the trick. However, there was a thing to add to make it work, we need to mount the /proc filesystem on the destination root directory for the mkinitrd to work properly. Else, thank you very much for the help you provided!
The quick fix is to simply copy the /boot/initrd-xx.img file from a working installated drive on the destination server to the old drive partition, and it will work (you must update the grub entry of course). However, if you don't have such a working hard drive, you will need to recompile this initrd file. Therefore I post the complete procedure below to move a hard disk drive with a working CentOS 4 system from one server to another one, not having the same SATA chips, or from a PATA to an SATA or vice/versa. If you don't do this, then you might receive this kind of error:
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!
Here is my procedure for those who would need it:
1. To recreate the initrd file, we will do it by booting from a successful boot partition on the destination server, like the CentOS live CD for example, or any other hard drive a hard drive which has been installed with the CentOS installer on the destination server.
We will mount the destination (failing) boot filesystem to /mnt/boot, and also its associated destination root filesystem, with these commands: mkdir /mnt/boot mkdir /mnt/root mount /dev/sda1 /mnt/boot mount /dev/sda3 /mnt/root
2. We must now change the root directory so that we can have access to the latest kernel sources which is always in /lib/modules. However, we must first create the /proc filesystem on the chrooted partition, else the compilation won't work properly: mount -t proc none /mnt/root/proc
3. Then, we can chroot to that partition like this: chroot /mnt/root
4. We then rebuild an initrd file by typing the following: mkinitrd --with=sata_via /initrd-new.img 2.6.9-42.0.10.EL
To know the proper kernel version to use (last number of the command line), you need to use an existing directory listed in the /lib/modules directory. Normally you should take the last one. the --with=sata_via is to force specifying the right hard disk module to use, but it can normally be omitted. Else make sure that you specify the proper driver for your motherboard SATA hardware chip. We do not create the initrd file in the boot directory, because we can sometimes not access it at this time (especially with md partitions), but we will simply copy the resulting file to the proper destination afterwards. If you receive an error message saying 'unable to stat /dev/md2: 2', just forget about it, the resulting file should still be there.
5. Make sure that the /etc/modprobe.conf file contains the driver you have added to this line: alias scsi_hostadapter sata_via
6. Now, let's come out of the chroot: exit
7. Then, copy the resulting file to the proper destination: cp /mnt/root/initrd-new.img /boot
8. Finally, we need to add the entry in the /boot/grub/grub.conf file, by keeping the last kernel file, but changing the initrd file to the new one.
9. Make sure that the following files have been properly changed accordingly to your new server setup: /boot/grub/grub.conf /boot/grub/device.map /etc/fstab /etc/modprobe.conf
All should be done now. You can reboot and try the result...
Thanks to all the others who also helped me with this problem.
Kind regards, Daniel
Thanks for posting this. I wanted to do this once or twice in the past, but never bothered to figure it out. I will be trying it soon... I have a Mondo Backup of a server that I want to move to less powerful hardware, and hopefully this will do the trick. Dennis
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of dan1 Sent: Monday, April 09, 2007 11:22 AM To: CentOS mailing list Subject: Re: [CentOS] SOLVED: hard disk move to another server
You can at least try to prepare a new initrd (name it differently and create a different entry in grub.conf) with mkinitrd. mkinitrd has a nice feature called --with=module so you can try to mkinitrd --with=sata_via to include this module even if not 'already' specified in /etc/modprobe.conf (don't forget also to change this after the machine has correctly booted : 'alias scsi_hostadapter=') I've never tested such hdd migration but it should work ...
Hello, Fabian.
Sorry for the very late answer. You are right, this did the trick. However, there was a thing to add to make it work, we need to mount the /proc filesystem on the destination root directory for the mkinitrd to work properly. Else, thank you very much for the help you provided!
The quick fix is to simply copy the /boot/initrd-xx.img file from a working installated drive on the destination server to the old drive partition, and it will work (you must update the grub entry of course). However, if you don't have such a working hard drive, you will need to recompile this initrd file. Therefore I post the complete procedure below to move a hard disk drive with a working CentOS 4 system from one server to another one, not having the same SATA chips, or from a PATA to an SATA or vice/versa. If you don't do this, then you might receive this kind of error:
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!
Here is my procedure for those who would need it:
1. To recreate the initrd file, we will do it by booting from a successful boot partition on the destination server, like the CentOS live CD for example, or any other hard drive a hard drive which has been installed with the CentOS installer on the destination server.
We will mount the destination (failing) boot filesystem to /mnt/boot, and also its associated destination root filesystem, with these commands: mkdir /mnt/boot mkdir /mnt/root mount /dev/sda1 /mnt/boot mount /dev/sda3 /mnt/root
2. We must now change the root directory so that we can have access to the latest kernel sources which is always in /lib/modules. However, we must first create the /proc filesystem on the chrooted partition, else the compilation won't work properly: mount -t proc none /mnt/root/proc
3. Then, we can chroot to that partition like this: chroot /mnt/root
4. We then rebuild an initrd file by typing the following: mkinitrd --with=sata_via /initrd-new.img 2.6.9-42.0.10.EL
To know the proper kernel version to use (last number of the command line), you need to use an existing directory listed in the /lib/modules directory. Normally you should take the last one. the --with=sata_via is to force specifying the right hard disk module to use, but it can normally be omitted. Else make sure that you specify the proper driver for your motherboard SATA hardware chip. We do not create the initrd file in the boot directory, because we can sometimes not access it at this time (especially with md partitions), but we will simply copy the resulting file to the proper destination afterwards. If you receive an error message saying 'unable to stat /dev/md2: 2', just forget about it, the resulting file should still be there.
5. Make sure that the /etc/modprobe.conf file contains the driver you have added to this line: alias scsi_hostadapter sata_via
6. Now, let's come out of the chroot: exit
7. Then, copy the resulting file to the proper destination: cp /mnt/root/initrd-new.img /boot
8. Finally, we need to add the entry in the /boot/grub/grub.conf file, by keeping the last kernel file, but changing the initrd file to the new one.
9. Make sure that the following files have been properly changed accordingly to your new server setup: /boot/grub/grub.conf /boot/grub/device.map /etc/fstab /etc/modprobe.conf
All should be done now. You can reboot and try the result...
Thanks to all the others who also helped me with this problem.
Kind regards, Daniel
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos