I am attempting to install Redhat 5.4 onan ESXi3.5 host. The full OS install from the media I'm using can be done successfully on bare metal on the same machine (this is my first OS install on a vm). The install proceeds a bit and then halts with these last messages:
RAMDISK: Compressed image found at block 0
VFS: Cannot open root device "<NULL>" or unknown-block(8,3)
Please append a correct "root=" boot option
Kernal panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,3)
Does anyone have any solution?
This message is displayed while the installer boots? Or during the first boot stage of the installed system?
In case of installer, what kind of media do you use to boot? Image, physical media (where connected)?
See my response to your post on this thread to make sure the server is on the HCL:
Hope that helps
I have 8GB of ram on the host with 5 of it allocated to the vm. That's overkill, but I wanted to eliminate a shortage as any cause of the problem. I have 32 bit hardware. My proposed guest OS is Red Hat Enterprise Linux (32-bit).
The message is displayed when the installer boots. I get the splash screen. I reply with "linux text" at the "boot:" prompt and then 20 seconds and around 60 lines of messages are diplayed ending in the error message I reported earlier. I am using an ISO image stored in the datastore.
Update on this issue:
It seems that there may be corruption on the ISO copy I have in the datastore on the host. The datastore copy is not the exact physical copy that I used for the successful bare-metal install (though it should a binary equivalent). The datastore copy was uploaded with the VI Client. The md5sum on the client checks out. Does anyone know how to check the media once it is on the host? As a workaround check I decided to download the ISO from the host back to the client via the VI Client and do another md5sum check. They were different. The file size was the same and I received no error messages in the upload or download. Does anyone have any ideas about this?
I've used the VI client more than once with the same results. What's disconcerting about that was that I received no error messages. A failed OS install because of the ISO getting corrupted is usually pretty obvious. What if I was using this copy method for other data transfers and the error remained hidden? Yikes!
Anyway I am pursuing your suggestion to use Veeam FastSCP. Seems like a nice tool. I've tried to use it and my copy attempt errors off. I have opened a support ticket with Veaam.
I've tried to use Veeam FastSCP and WinSCP and they both give me messages pertaining to aborted connections on the hos. Under Configuration/Security profile I see only 2 services. I started the NTP Daemon and I'm not using VirtualCenter so it seems the other service is irrelevant. If I'm reading the documentaion for ESXi correctly no further servicescan be added. Does anyone know what's going on here?
What is the build number of the ESX host? If it is not 153875 or higher then RHEL5.4 is not supported as a guest OS until Update4 or higher.
The ESXi host is a IBM xSeries 365 with 4 CPUs 8GB memory. The HBA on this machine is a Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet. There is no load on the network or the host. The client is an IBM Intellistation ZPro running Windows XP SP3. I am able to connect to the host via the VMI Client. I can upload data with the VMI Client though the results were corrupted. Does this information help some?
The x365 is not on the HCL for ESXi 3.5 (or any 3.5 version). Not sure if that is the cause of the problem or not but curious if any other OS's can install and if you use ESX 3.0 does it work?
What kind of datastore (local harddisk, RAID? SAN?).
As it is an IBM server, I (strongly) assume, that there is ECC RAM used!
Could it be, that there is a BIOS upgrade for your hardware/network card?
My datastore is on local harddisk. The memory is ECC and I recently ran an exhaustive memory check that was successful. I'll have to check, but there is probably a BIOS update I could do. Tonight I tried another VI Client upload to the datastore. It was error free (at least no error message). I copied over an MD5sum executable from an other Linux server and ran the check. The sums of the source and target ISO copies were different. At least now I know which leg of the journey first had a problem (previously I downloaded it back to run the check).