From the updated I/O sheet this is what's mentioned on supported SATA controllers....
Supported SAS/SATA Dual Controllers
ESX Server 3.5 supports selected SATA devices connected to dual SAS/SATA controllers. This support is limited to ESX Server 3.5. It is not included with ESX Server 3.0.x.
The supported dual SAS/SATA controllers are:
mptscsi_2xx (PCIE) ‐ LSI1078*
mptscsi_pcie ‐ LSI1068E (LSISAS3442E)*
mptscsi_pcix ‐ LSI1068 (SAS 5)*
aacraid_esx30 ‐ IBM serveraid 8k SAS controller*
cciss ‐ Smart Array P400/256 controller*
So what is the best PCIE card for me to put into my S5000PAL server that will use the above driver, if only someone could make a list :smileygrin:
I know I have run that utility before and that it runs as part of the script that fixes it inside ubuntu, but are you saying that it should be run as a service on startup or everytime before you reboot to keep your current configuration?
if you have "repaired" your ESX with a boot cd you have do do a
further step when you first start the ESX server afterwards.
This is why?
you are patching the initrd-image and then you can boot.
But when the ESX server shuttsdown/reboots it recreated a new initrd image.
With the next reboot all changes tok place for an working startup.
the parameter for esxcfg-pciid is invalid!
When you want to create the initrd file in a script you should use
Hello, thanks for the response. Just so I am understanding you correctly, are you saying in your last post that all that needs to be done is modify the entry in your script so that each line as the -r added to it?
I am assuming this is the section of your script that I need to modify:
echo "#!/bin/bash" >> /mnt/eroot/etc/init.d/rp-esxcfg-pciid-boot echo "esxcfg-pciid" >> /mnt/eroot/etc/init.d/rp-esxcfg-pciid-boot echo "sleep 5" >> /mnt/eroot/etc/init.d/rp-esxcfg-pciid-boot echo "rm /etc/rc3.d/S99rp-esxcfg-pciid-boot" >> /mnt/eroot/etc/init.d/rp-esxcfg-pciid-boot chmod a+x /mnt/eroot/etc/init.d/rp-esxcfg-pciid-boot cd /mnt/eroot/etc/rc3.d/ ln -s ../init.d/rp-esxcfg-pciid-boot S99rp-esxcfg-pciid-boot
i wrote a second mail,
sorry for the "-r" error on my side.
The snipplet below creates a script which is being started on startup.
>Hello, thanks for the response. Just so I am understanding you
>correctly, are you saying in your last post that all that needs to
>be done is modify the entry in your script so that each line as the
>-r added to it?
>I am assuming this is the section of your script that I need to modify:
echo "#!/bin/bash" >> /mnt/eroot/etc/init.d/rp-esxcfg-pciid-boot >echo "esxcfg-pciid" >> /mnt/eroot/etc/init.d/rp-esxcfg-pciid-boot >echo "sleep 5" >> /mnt/eroot/etc/init.d/rp-esxcfg-pciid-boot >echo "rm /etc/rc3.d/S99rp-esxcfg-pciid-boot" >> >/mnt/eroot/etc/init.d/rp-esxcfg-pciid-boot >chmod a+x /mnt/eroot/etc/init.d/rp-esxcfg-pciid-boot >cd /mnt/eroot/etc/rc3.d/ >ln -s ../init.d/rp-esxcfg-pciid-boot >S99rp-esxcfg-pciid-boot
I'm running an ML115 with the internal SATA drives, with the nvidia RAID enabled (2 x 500GB SATA drives in a RAID-1 setup) using ESXi 3.5 and it works fine. I had issues with ESX 3.5 and it didn't like it. So, use ESXi 3.5 if you can
Ok, no problem. I will add the -r to everything and give it another try.
nice work on the script by the way, it definitely helps.......If it was not for the script, i would have been looking at buying something that would work with ESX out of the box.
EXTREMELY URGENT PROBLEM WITH ESX/ESXi 3.5 Update 2 – UPDATE
Dear VMware Customers,
find the latest update about the product expiration issue. From this
point on, we’ll provide an update every two hours. Thanks.
issue has been discovered by many VMware customers and partners with
ESX/ESXi 3.5 Update 2 where Virtual Machines fail to power on or
VMotion successfully. This problem began to occur on August 12, 2008
for customers that had upgraded to ESX 3.5 Update 2. The problem is
caused by a build timeout that was mistakenly left enabled for the
VMware ESX 3.5 Update 2 & ESXi 3.5 Update 2
Reports of problems with ESX 3.5 U1 with the following 3.5 Update 2 patch applied.
No other VMware products are affected.
What has been done?
and Web teams pulled the ESX 3.5 Update 2 bits from the download pages
last night so no more customers will be able to download the broken
VMware Engineering teams have isolated the cause of the problem and are
working around the clock to deliver updated builds and patches for
A Knowledgebase article has been published (http://kb.vmware.com/kb/1006716), but traffic to the knowledgebase is causing time outs. A new static page has been published at http://www.vmware.com/support/esx35u2_supportalert.html that customers and partners will be able to view.
The phone system has been updated to advise customers of the problem
Vmware partners have been notified of the issue.
Do not install ESX 3.5 U2 if it has been downloaded from VMware’s website or elsewhere prior to August 12, 2008.
Set the host time to a date prior to August 12, 2008. This workaround
has a number of very serious side affects that could impact product
environments. Any Virtual Machines that sync time with the ESX host and
serve time sensitive applications would be broken. These include, but
are not limited to database servers, mail servers, & domain
VMware to notify customers who have downloaded this version and provide
an update every two hours.
Engineering has isolated the root cause and is working to produce an
express patch for impacted customers today. The target timeframe is
6pm, August 12, 2008 PST.
What would this express patch do?
More information will be provided in subsequent communication updates.
Will VMware still reissue the upgrade media and patch bundles in the timeframe that has been communicated?
Yes. We still plan to reissue upgrade media by 6pm, August 13 PST
(instead of noon, August 13 PST) and all update patch bundles later in
the week. We will provide an ETA for the update patch bundles
subsequently. NOTE: the "patch bundles" referred to here are for the
patches listed above under "Affected Products" and the other bundles
released at GA. They are not the same as the express patch which is
targeted for 6pm, August 12, 2008 PST as stated above.
Why does VMware plan to reissue the upgrade media before the patch bundles? That is a wrong priority call!
This is not a matter of priority. Since we can get done building and
testing the upgrade media before the patch bundles, we want to make
that available to customers first instead of reissuing all the binaries
later in the week.
Can VMware issue a patch that opens the licensing backdoor in the next hour as a critical measure?
There is no licensing backdoor in our code.
Does this issue affect VC 2.5 Update 2?
What is VMware doing to make sure that the problem won’t happen again?
We are making improvements on all fronts. The product team had
endeavored to deliver a release with support customers deem important.
But we fell short and we are deeply sorry about all the disruption and
inconveniences we have caused. We have identified where the holes are
and they will be addressed to restore customers’ confidence.
Never trust any update
This post is for rpartmann,
I tried to modify the script as you suggested but I must be doing something wrong as it did not work.
I changed all the entries to look like this:
echo "#!/bin/bash" >> /mnt/eroot/etc/init.d/rp-esxcfg-pciid-boot-r
echo "esxcfg-pciid" >> /mnt/eroot/etc/init.d/rp-esxcfg-pciid-boot-r
echo "sleep 5" >> /mnt/eroot/etc/init.d/rp-esxcfg-pciid-boot-r
echo "rm /etc/rc3.d/S99rp-esxcfg-pciid-boot-r" >> /mnt/eroot/etc/init.d/rp-esxcfg-pciid-boot-r
chmod a+x /mnt/eroot/etc/init.d/rp-esxcfg-pciid-boot-r
ln -s ../init.d/rp-esxcfg-pciid-boot-r S99rp-esxcfg-pciid-boot-r
Have I done something incorrectly?
the "-r" is a parameter for a command.
i thought incorrectly to an other command where "-r" is ok, but
esxcfg-pciid does not need any parameter.
what errors-messages exactly/how far - do you get?
I tried to modify the script as you suggested but I must be doing
something wrong as it did not work.
I changed all the entries to look like this:
>echo "#!/bin/bash" >> /mnt/eroot/etc/init.d/rp-esxcfg-pciid-boot-r
>echo "esxcfg-pciid" >> /mnt/eroot/etc/init.d/rp-esxcfg-pciid-boot-r
>echo "sleep 5" >> /mnt/eroot/etc/init.d/rp-esxcfg-pciid-boot-r
>echo "rm /etc/rc3.d/S99rp-esxcfg-pciid-boot-r" >>
>chmod a+x /mnt/eroot/etc/init.d/rp-esxcfg-pciid-boot-r
>ln -s ../init.d/rp-esxcfg-pciid-boot-r S99rp-esxcfg-pciid-boot-r
>Have I done something incorrectly?
yes, sorry for that
After I run the script to fix the initrd image and reboot, I am able to load vmware and configure it, etc. Then once I reboot, it is right back to the "cannot mount root" error and I am stuck at the sh prompt.
would it help if after I fix it and boot into console for the first time, if I ran the esxcfg-pciid once, would that fix it?
check the xml files after your first boot.
if the correct pci id`s of your SATAcontroller (lspci -vnn) are
within the correct file then run esxcfg-pciid
then it should boot always.
now I'm totally confused....:-(
I reinstall my ESX completely new with version 3.5 without any updates.
Then i tried to execute both gosata versions (0.61 and 0.62).
The effect was that both scripts fail although at least version 0.61 goes perfect some weeks before.
I attached what the console gived out.....very strange...so probably a failure on myside
when you said in your last post to check the xml files, do you mean to check each and every xml file in the etc/vmware/pciid folder? I did run the lspci -vnn command, and a lot of stuff came back. I did record all the numbers, not sure which ones exactly I need but I am assuming it is the id number. I checked the sata_nv.xml file and the correct numbers were in there, I think. The main number I need I believe is 037f, which is always there no matter what after I run the script to fix the initrd image file. It is strange though why this does not work for me, according the the website that lists working whitebox systems with ESX, my mother board is on there "Asus M2N-Sli Deluxe" and all the guy said he had to do was edit the sata_nv.xml file and add the number 037f.
So, after checking the sata_nv.xml file I ran the esxcfg-pciid and rebooted, still the same problem "cannot mount root". So I ran the fix script again and I am now waiting to try the next idea..........
I should note that when I booted up after fixing it once again, I paid close attention to the boot up and I noticed that the command that runs from the fix script "rp-esxcfg-pciid-boot" fails. I am wondering if that is the problem??
If I try to run that from the command line after I am booted in, it says it is an invalid command and the only one that works is the esxcfg-pciid.......
Any more ideas, or what files I could look at to determine what the problem is?
i have applied the new fixed Update2 patches on my ESX.
The only problem is that i cannot execute the gosata script to get working my nvidia mcp sata onboard controller.
But I have told this problem and the failure messages to Reinhard.
sorry was busy and we had a public holiday.
1.) no console output.
2.) installed 3.5u2 in my ML115G1 (dont worry, onboard hdd will be
detected as hdaX)
3.) boot 3 option -> Serviceconsole only
4.) cd /etc/vmware/pciid
5.) vi sata_nv.xml
changed the last entry from 037e to 037f (this might be a different value
depends on your system..
use lspci and lspci
-vnn, to resolve)
Have you tried running vms on it? I managed to get update 2 working on mine but had issues with the host crashing once vms running on it. Would be interested to know if u have vms working on it with a load.