NFS based automated installs of ESX 4

Just something I noticed today while testing an automated install from NFS. The arguments I pass to the installer are:

initrd=initrd.img mem=512m ksdevice=vmnic1 ip= netmask= gateway= ks=nfs:// quiet

Let’s focus on the part that’s incorrect, with ESX 3 the following bit(part of the bootstrap above) would work:


As of ESX 4 this doesn’t work anymore, and when I do an “alt-f2” and go to /var/log and check the esx-installer.log file it shows the following error:

mount: failed, reason given by server: Permission denied

After checking the permissions on my NFS share 4 times I was pretty certain that this could not cause this issue. After trying some various combinations I noticed that the format of the string for “ks” has changed. As of ESX 4 you can’t use the second colon(:) anymore. So the correct format is:


I still receive a warning but the installer does continue. If anyone knows why the following message is displayed please speak up:

No COS NICs have been added by the user
Be Sociable, Share!


    1. Jon Kohler says

      You have to specify the network adapter information Linux style (eht0 not vmnic0) in that text string at the installer splash screen or I won’t load the source. Don’t have it in front of me now because I am traveling, I will look up my notes on this pater if you Havey got it by then. Love your blog Duncan! — jon k

    2. Jon Kohler says

      Fat fingered the post while getting off the plane and cross referenced with erics post. It’s vmnic0 not eth0

    3. Jon Kohler says

      I am guessing you have more than one nic? Did you try setting device=(macAddressOfCosNIC) instead of vmnic0? If not give it a quick shot and see of it clears that sass up

    4. Jon Kohler says

      And that should be ksdevice=(macAddr) in the preinstall string, not in the ks cfg file, that’s what I was thinking about previously when I said eth0. (traveling across country to a wedding is wearing on me!) kscfg would still be device=vmnic0 I believe

    5. says

      Jon is on the right track I believe. I don’t have my notes or access to my scripts currently but I tackled this recently. From memory I think the important piece is the following:

      install url nfs:// (referenced in the kickstart file you are calling if you are using the automated syslinux method)

      I also edit my isolinux.cfg file to add the following entry:

      kernel vmlinuz
      append initrd=initrd.img mem=512M quiet ksdevice=vmnic0 ip= netmask= gateway= nameserver= ks=nfs://

      (ksdevice=vmnic0 is the magic here for what i believe you are after)

      If I remember correctly the syntax for kickstart in VMware has changed from VI3 to vSphere.

      EX: I know I used to use something similar to:
      esx ks=nfs:

      Now in vSphere I have to use:
      ks=nfs:// (notice the slight syntax differences with added // and missing trailing colon)

      Some of this info was shamelessly harvested from page 48 of as far as the kickstart syntax changing. Hint copius use of F1 virtual console was used for debugging my initial network based automated and unattended scripted installs.

      Take it easy Duncan, your blog is amazing and is always my number one source for the beat on the virtualization street 😀

    6. says

      Sorry but maybe I explained it wrong. Neither “vmnic0” or “vmnic1” or “eth0” resolve this issue, and of course I have multiple NICs in my Host. (who hasn’t?) Using a MAC Address is not an option as manually specifying MAC addresses for 150 hosts can’t be the way to go.

      So again to be clear, it is the Bootstrap (the part where you pass arguments to the installer) where this string is used.

    7. says

      My mistake, I see what you referencing now. I just ran a nested ESX scripted install to validate and get the exact same text ‘No COS NICs have been added by the user’ as well. I had actually forgotten about this arcane message as I have done so many of these now that I have the automatic notion to disregard it when I see it on the console. The scripted installations seem to always successfully proceeds as long as the network repo is alive and kicking.

    8. says

      Duncan, I was going to suggest that perhaps it’s an IP configuration issue, where you might need to specify everything at boot time:

      ks=nfs:// ip= netmask= gateway= dns=

      at boot-time, like a RHEL network kickstart. However, I’m not clear if this is just a warning or if it’s preventing an install. If it’s just a warning then perhaps it isn’t a big deal, and it’s just some component complaining that a COS NIC isn’t set up right when it was expecting one to be.

    9. Jonathan Somers says

      I went through this exact same process and could never get it to work. I ended up using USB ks files and point to an http source for the install.

    10. says

      That’s what I did Bob, I only did not include the complete string in the post. Maybe I should have.

      It’s just a warning by the way. Hmmm maybe I should edit my article to make it crystal clear.

    11. cjomcs says


      had the same problem with a kickstart installation. In this case there was no dhcp server in the network. The base problem is that the python installer script inside the esx install routine creates a new virtual interface for the console (COS).

      This interface has a mac-address wich is new and always generated. So the only solution to get an ip-adress for the cos interface is to have dhcp in the network enabled. I´ve tried all options to define the interface before the COS interface is build (vc installation guide) and nothing works if there is no dhcp server.

      Hope this helps.

      Best regards

    12. says

      I think I’ve found something but I don’t have the opportunity to test it right away:

      The IPAPPEND PXE configuration option specifies that the same network adapter the machine boots from is also used for connecting to the network. See “IPAPPEND,” on page 38.

      Page 38 in


      For scripted installations, the IPAPPEND option specifies that the same network adapter the machine boots from
      is also used for connecting to the network. When you include the IPAPPEND option in the PXE configuration
      file, omit the –device option to the installation script network command. The IPAPPEND option has no impact
      on interactive installations. The following snippet shows how to include the IPAPPEND option in the PXE
      configuration file:
      label Installer
      menu default
      kernel http:///vmlinuz
      append initrd=http:///initrd.img mem=512M vmkopts=debugLogToSerial:1 ks=nfs://
      IPAPPEND 2
      For the IPAPPEND flag_val, use IPAPPEND 2. IPAPPEND 1 is not required.
      If you omit the network –device option from the installation script, the IPAPPEND option from the PXE configuration

    13. Adam Savage says


      I had the same error when i was setting up the UDA with ESX 4 Update 1.. No error messages at all. I changed the install media to be the original ESX 4.0 Media and found that there was an error in my install script.. it still gave the error “No COS NICs have been added by the user” but then gave some more info on what part of the script it wouldn’t pass.


    14. Adam Savage says

      BTW – you may be able to hit alt-f4 when it prompts you to reboot – and get to the console to check out the /var/log/

    15. RussellCorey says

      We’ve pretty much seen that you can ignore the error message. If you’re staring at it when the kickstart finishes then there is probably something else wrong in your kickstart config.

      I’d check the weasel.log (swap to another console) for syntax errors that caused Weasel to exit. As near as I can tell if you have things set up right you’ll still see that message for a split second and then it launches the installer.

      If you’re going strictly by VMware’s install docs, they’re incorrect in a couple spots (specifically on the syntax for selecting what disk to use.)

      In short, if you’re stuck on ‘No COS nics defined by the user.’ that isn’t the fatal error.

    16. says

      I do have DHCP in my network… that’s not it. It’s just a warning, not a fatal error as the installation completes but I just wonder where it is coming from.

      Log files don’t give you more info than the warning unfortunately.

    17. says

      Ah, okay then — warnings aren’t so bad if they’re not critical. Sorry for misunderstanding what you’d tried!

      It might be possible to take the installer code and recursively grep it to find out what component has that string in it. That might provide a clue. I don’t have access to my dev environment right now but I can try it on Monday.

    18. cjomcs says

      I think it´s only the old routine :-) from the time when it was a physical nic for the integrated cos and not a vnic for the virtual cos machine…

    19. bitsorbytes says

      “No COS NICs have been added by the user” I received this error when using UDA 2.0 (beta). Installed works without issues, I assumed its some ‘installer’ bug!

    20. Matthew Anderson says

      I have vlans on my network. How would that work?
      initrd=initrd.img mem=512m ksdevice=vmnic1 ip= netmask= -vlanid=40 gateway= ks=nfs:// quiet