• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Yellow Bricks

by Duncan Epping

  • Home
  • Unexplored Territory Podcast
  • HA Deepdive
  • ESXTOP
  • Stickers/Shirts
  • Privacy Policy
  • About
  • Show Search
Hide Search

NFS based automated installs of ESX 4

Duncan Epping · Mar 26, 2010 ·

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=192.168.1.123 netmask=255.255.255.0 gateway=192.168.1.1 ks=nfs://192.168.1.10:/nfs/install/ks.cfg quiet

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

ks=nfs://192.168.1.10:/nfs/install/ks.cfg

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: 192.168.1.10::nfs/install 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:

ks=nfs://192.168.1.10/nfs/install/ks.cfg

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

Related

Server ESX, Scripting, scripts, troubleshooting, vSphere

Reader Interactions

Comments

  1. Eric Sloof says

    26 March, 2010 at 18:36

    I’ve experienced the same problem and finally ended up in this tread http://communities.vmware.com/thread/213363 Maybe it can be of any help. It didn’t work for me though.

  2. Jon Kohler says

    26 March, 2010 at 19:31

    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

  3. Jon Kohler says

    26 March, 2010 at 19:47

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

  4. Duncan Epping says

    26 March, 2010 at 20:20

    That’s what I thought as well, doesn’t make a difference. You can specify it as vmnic0 with ESX 4.

  5. Jon Kohler says

    26 March, 2010 at 20:58

    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

  6. Jon Kohler says

    26 March, 2010 at 21:35

    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

  7. Kevin Brooksby says

    26 March, 2010 at 21:49

    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://192.168.2.109/esx/ (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:

    label esx3.virtguru.com
    kernel vmlinuz
    append initrd=initrd.img mem=512M quiet ksdevice=vmnic0 ip=192.168.2.30 netmask=255.255.255.0 gateway=192.168.2.254 nameserver=192.168.2.53 ks=nfs://192.168.2.109/esx/esx3.virtguru.com.cfg

    (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:10.64.3.85:/mnt/kicks/esx35u1.cfg

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

    Some of this info was shamelessly harvested from page 48 of http://www.vmware.com/pdf/vsphere4/r40/vsp_40_esx_vc_installation_guide.pdf 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 😀

  8. Duncan Epping says

    27 March, 2010 at 00:27

    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.

  9. Kevin Brooksby says

    27 March, 2010 at 01:18

    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.

  10. Bob Plankers says

    27 March, 2010 at 04:55

    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://192.168.1.10/nfs/install/ks.cfg ip=192.168.10.50 netmask=255.255.255.0 gateway=192.168.10.1 dns=192.168.254.254

    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.

  11. Jonathan Somers says

    27 March, 2010 at 07:22

    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.

  12. duncan says

    27 March, 2010 at 08:38

    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.

  13. cjomcs says

    27 March, 2010 at 10:55

    Hi,

    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
    Christian

  14. esloof says

    27 March, 2010 at 15:51

    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 http://www.vmware.com/pdf/vsphere4/r40_u1/vsp_40_u1_esx_vc_installation_guide.pdf

    IPAPPEND

    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://
    10.20.118.55/ks.cfg
    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

  15. Adam Savage says

    27 March, 2010 at 16:21

    Duncan,

    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.

    -Adam

  16. Adam Savage says

    27 March, 2010 at 16:40

    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/

  17. RussellCorey says

    27 March, 2010 at 18:14

    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.

  18. duncan says

    27 March, 2010 at 22:04

    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.

  19. Bob Plankers says

    27 March, 2010 at 23:00

    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.

  20. cjomcs says

    28 March, 2010 at 15:06

    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…

  21. bitsorbytes says

    30 March, 2010 at 04:14

    “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!

  22. Stephen says

    31 March, 2010 at 01:24

    Based on this:
    http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Installation_Guide-en-US/s1-kickstart2-startinginstall.html

    Your URL is not formed correctly try this:
    ks=nfs::/

  23. Stephen says

    31 March, 2010 at 01:26

    Based on this:
    http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Installation_Guide-en-US/s1-kickstart2-startinginstall.html

    the URL for the above post didn’t work. refer to ks=nfs section of RHEL5 doc.

  24. Stephen says

    31 March, 2010 at 01:28

    try this:
    ks=nfs:192.168.1.10:/nfs/install/ks.cfg

  25. duncan says

    31 March, 2010 at 10:46

    Please read the post again Steve,

    ks=nfs://192.168.1.10/nfs/install/ks.cfg

    that’s the correct format.

  26. Matthew Anderson says

    31 March, 2010 at 18:44

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

    Thanks
    Matt

  27. Vinayak Kamble says

    26 June, 2010 at 20:46

    No Cos nics problem is resolved by using Build 14 from http://www.rtfm-ed.co.uk/vmware-content/ultimate-da/

Primary Sidebar

About the Author

Duncan Epping is a Chief Technologist and Distinguished Engineering Architect at Broadcom. Besides writing on Yellow-Bricks, Duncan is the co-author of the vSAN Deep Dive and the vSphere Clustering Deep Dive book series. Duncan is also the host of the Unexplored Territory Podcast.

Follow Us

  • X
  • Spotify
  • RSS Feed
  • LinkedIn

Recommended Book(s)

Also visit!

For the Dutch-speaking audience, make sure to visit RunNerd.nl to follow my running adventure, read shoe/gear/race reviews, and more!

Do you like Hardcore-Punk music? Follow my Spotify Playlist!

Do you like 80s music? I got you covered!

Copyright Yellow-Bricks.com © 2026 · Log in