brugh's Posts

If you hit the 'import pxe files' from the main screen of the EDA it should fix this automatically. EDA uses the bootfiles from the original media and just changed the source path. if that fails for some reason, you can manually change /var/www/tftpboot/boot.cfg but keep in mind that will be overwritten once you hit the import button again.

the errors you see usually means it has an outdated boot.cfg on the webserver, most likely from an other version. did you import PXE files at every dvd change? that's important because it will read the boot.cfg from the CD and rebuild it so the files can come from a webserver instead.

i'm currently having some problems with my internet uplinks. things should be back up again soon. i don't have access at the moment but i'm awaiting a call to let me know things are working again.

actually, you can simply remove that file and reboot the machine. alt-f2 should work to access the console but you can use the 'patch' menu from the eda as well. simply type in the execute box: 'rm /etc/udev/rules.d/70-persistent-net.rules'. it's a known issue in linux vm's where underlying hardwarelevel changes.

you dont have to edit the ks file for that. you can simply put '=remote' in the installdisk option on the bottom left side of the eda interface. you need to have an esx5 cd mounted for the option to show.  be sure to disconnect any data luns (zone them out) or at least have their lun id set to something higher than the lun you want esx to install on.

the solution exchange links have been fixed. we moved sites and were promised the links would automatically be redirected. unfortunately that promise was only half kept. we're working on getting old links back up so references will work again but the https://solutionexchange.vmware.com/store/products/esx-deployment-appliance-eda and http://virtualappliances.eu/?download links are back up!

I'm probably skipping 1.10 The 1.05 version runs 5.5 perfectly so there's no need for it. The two small patches on the ntp and syslog targets I built in my 1.10 aren't big enough to go through the whole process of applianicing a new version

actually, eda should have picked that up. the pxe import reads the boot file from CD and redirects the files on it to the webserver in the eda. the vib builder generates that file and points to the openmanage.v00 which in turn gets redirected by the eda. so building vibs into your image should work. HP and Dell images work fine and they do exactly the same. if it boots from CD, it should boot from eda as well. it's how eda works how exactly did you build the image?

i've had that request a couple of times but because of the way i built it, that would require quite a large rewrite. i usually advice people to use the backup/restore function on the EDA to do basically the same thing with a couple of extra clicks. i could extend the backup/restore option so switching between configs would be a bit easier (=intuitive). would that help?

is that from a default VMware image or from a vendor's build (HP, Dell)? what do you see when you go to the 'patch' menu and type 'ls /var/lib/tftpboot/cd/esx' in the 'exec' box? does that file 'scsi_bnx.v01' exist there? or anything similar?

yeah *cough*, that bug's been in there for a while. if you change line 31/32 in /var/www/eda/ajax.php from:     $a1=current($this->ar);     while (key($this->ar)!=$id) $a1=next($this->ar); to     while ( ($a1=next($this->ar)) && key($this->ar)!=$id ) { } all should be well again.

if you remove the NIC, you may also want to remove the persistent rules files. if you dont you'll end up with eth1, eth2 etc and all EDA scripts are built for eth0. you can go either to alt-F2 and log in with root/root or go to the patch menu in eda and type 'rm /etc/udev/rules.d/*.rules' from the 'exec' box.

the best way to troubleshoot unwilling commands is to remove the reboot from the ks script (perhaps i should make that an option in the interface?). it will log everything to console (press alt-F11 and alt-F12). the script itself is put in a 10-firstboot script in /etc/rc.local.d if you want to rerun it and check for console errors. other logging is put in /var/log

i got the syslog and ntp settings question a couple of times before so i just did a quick test to see if something breaks if i (almost blindly) add them. 5 minutes later the good news is that it works fine. i have an eda v1.06 now that has an ntp and syslog setting on the left. adding a management VLAN should be just as simple (if you know where to add it ). i'm not building that into the eda by default but here's a few hints: edit /var/www/eda/index.php add a line after 87 that says: if ($vlanid=$_POST["vlanid"]) { $cfg["VLANID"]=$vlanid; } add a line after 198 that says: row("vlanid", $cfg["VLANID"]); edit /var/www/ks/ks5.php and at the end, right before the autobackup: <? if ($cfg["VLANID"]) { ?> esxcli network vswitch standard portgroup set -p Management --vlan-id <?=$cfg["VLANID"]; ?> <? } ?> i have a few more things i wanted to add so you could wait for the next eda release that should be out soon. or you can add ntpserver and syslogserver the same way as described above. to add color to input boxes shouldn't be too hard to do. i use a 'row' function to display the various input lines. it takes 2 or 3 parameters where the 3rd optional will display a small hint if you hoover your mouse over the input box. if you change inc.php in /var/www/eda: change line 34 and add '$color' as 4th argument change line 36 after '<input' add ' style='background:$color' then in /var/www/eda/index.php at any line that has a 'row' function you could add a color 'lightblue', 'orange', whatever as 4th argument

not sure why you'd want to change the php code (it's not very reader friendly ). the vmk0 is connected to a portgroup and usually that portgroup gets the vlan tags. that command is in the script builder: esxcfg-vswitch -p "<portgroup name>" -v <VLAN_ID> <virtual switch name> is your setup different? that usually works fine.