I don't know if anyone is interested but here it goes:
For some reason the VMware stand-alone converter changed the virtual
machine's SCSI controller during conversion from LSI Logic to BusLogic.
It would probably have been possible to recover by compiling the correct
driver and using some live CD distro to insert it into place;
fortunately just changing the controller in the VM's setting worked.
Thing2 is now up and running.
Yuri Csapo wrote:
This is one for someone with more RedHat expertize (and tolerance) than
I can muster:
Moths ago a colleague was running 3 virtual RedHat boxen (thing1 is
Enterprise Linux AS release 3, thing2 is release 4, thing3 is release 5
- I know, I know, but it's what the application requires). As far as I
can tell, he built thing1 from scratch, copied the files which made it
up to /thing2 and /thing3 and applied enough upgrades on 2 and 3 to get
them to the points he wanted. His original machines were created and ran
on VMware Server on a RedHat (I don't know the version) machine.
Then he made a backup of each (or thought he had made backups) by
copying all those files to a separate location.
We are currently moving to a VWware infrastructure environment so a
different colleague installed ESXi on the hardware that was originally
running all this, thinking the first guy's backups was all he was going
to need; so he wiped the only working copies of those virtual machines.
For some reason it is now my job to recover the boxes. I have thing2
running under Fusion -- not without some troubles; apparently, when guy
#1 originally copied thing1 to make 2 and 3 some strange things have
happened and links seem to have been established between vitual disk
(vmdk) and snapshot files for all three boxes. Anyway, after much
toiling, I was able to import thing2 and it is now running happily under
VMware Fusion on my Mac.
Next step is to convert it to ESXi. So I used VMware stand-alone
Converter running on a Vista box (actually a virtual Vista under
Fusion). Converter seems to have been able to import the virtual machine
and export/transfer it to the ESXi host.
When I boot the newly created thing2, now living on the ESX host, the
kernel loads but soon I get this:
====
(lots of similar lines)
/lib/mptscsih.o: unresolved symbol ioc_list_Rsmp_dd805159
(lots of similar lines)
ERROR: /bin/insmod exited abnormally!
Loading jbd.o module
Journalled Block Device driver loaded
Loading ext2.o module
Creating block devices
VFS: Cannot open root device "LABEL=/" or 00:00
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on 00:00
====
I'm thinking somehow the vmdk conversions have wiped the LABELs from the
partitions; and the advice to provide a correct "root=" seems to make
sense, so I do that (by rebooting and editing the kernel line on the
GRUB menu to make it "root=/dev/sda6"; I know this is the right
partition because I have a running copy of thing2 on Fusion). The result
is this:
====
(lots of similar lines)
/lib/mptscsih.o: unresolved symbol ioc_list_Rsmp_dd805159
(lots of similar lines)
ERROR: /bin/insmod exited abnormally!
Loading jbd.o module
Journalled Block Device driver loaded
Loading ext2.o module
Creating block devices
kmod: failed to exec /sbin/modprobe -s -k block-major-8, errno = 2
VFS: Cannot open root device "sda6" or 08:06
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on 08:06
====
I notice the device numbers change (from 00:00) to (08:06), which hints
that my suspicion that the labels have been wiped is probably right. It
now looks like it can't find many things on the filesystem, including
several modules and /sbin/modprobe itself. So I reboot from a CD image
to a saner environment (Ubuntu server) and fix all filesystems in
/etc/fstab to refer to the proper /dev devices as opposed to the LABELS.
Then I edited /boot/grup/menu.lst and fix the kernel lines so I don't
reference LABELs anywhere. Reboot. No joy, same error.
Any ideas?
--
Yuri Csapo
Academic Computing & Networking
Colorado School of Mines
CT-256
Phone: (303) 273-3503
Fax: (303) 273-3475
Email: ycsapo@xxxxxxxxx
Please use the following link to open a service request:
http://helpdesk.mines.edu
===========================================
With a PC, I always felt limited
by the software available.
On Unix, I am limited only by my knowledge.
--Peter J. Schoenster
--
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
