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
