From: Yuri Csapo <ycsapo@mines.edu>
To: linux-admin <linux-admin@vger.kernel.org>
Subject: Re: converted RedHat virtual - SOLVED
Date: Tue, 24 Mar 2009 08:20:35 -0600 [thread overview]
Message-ID: <49C8EC33.8000002@mines.edu> (raw)
In-Reply-To: <49C7FDCC.9040105@mines.edu>
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@mines.edu
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
prev parent reply other threads:[~2009-03-24 14:20 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-23 21:23 converted RedHat virtual Yuri Csapo
2009-03-24 14:20 ` Yuri Csapo [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49C8EC33.8000002@mines.edu \
--to=ycsapo@mines.edu \
--cc=linux-admin@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).