@chris178 There is a right way to do this and an easy way.
Easy route.
Download both .sh files to your FOG server.
Then make both executable. by running this command chmod 755 *.sh
Install the script by running ./install.sh
Done.
That was it.
I changed it, because indeed there was the old interface in there. Now the dhcpd works fine.
I also found, that in /tftpboot/default.ipxe was the old IP-Address.
To create a menu in the advanced one, you must fill it in under iPXE General Configuration -> Advanced Menu Settings > Advanced Menu Commands
example:
:urls
set msdart-url http://192.168.1.155/2-MSDART
:MENU
menu
colour --rgb 0xff0000 0 ||
cpair --foreground 1 1 ||
cpair --foreground 0 3 ||
cpair --foreground 4 4 ||
item --gap -- -------------------------------------
item fog.local Boot from hard disk
item msdart6x86 Microsoft DaRT for Windows Vista 32bit
item msdart6x64 Microsoft DaRT for Windows Vista 64bit
item msdart7x86 Microsoft DaRT for Windows 7 32bit
item msdart7x64 Microsoft DaRT for Windows 7 64bit
item msdart81x86 Microsoft DaRT for Windows 8.1 32bit
item msdart81x64 Microsoft DaRT for Windows 8.1 64bit
item fog.return Return to previous menu
choose --default fog.local --timeout 5000000 target && goto ${target}
:fog.local
sanboot --no-describe --drive 0x80 || goto MENU
:msdart6x86
initrd ${msdart-url}/MSDaRT60x86.iso
chain memdisk iso raw
:msdart6x64
initrd ${msdart-url}/MSDaRT60x64.iso
chain memdisk iso raw
:msdart7x86
initrd ${msdart-url}/MSDaRT70x86.iso
chain memdisk iso raw
:msdart7x64
initrd ${msdart-url}/MSDaRT70x64.iso
chain memdisk iso raw
:msdart81x86
initrd ${msdart-url}/MSDaRT8.1x86.iso
chain memdisk iso raw
:msdart81x64
initrd ${msdart-url}/MSDaRT8.1x64.iso
chain memdisk iso raw
:fog.return
chain http://${fog-ip}/${fog-webroot}/service/ipxe/boot.php?mac=${net0/mac} ||
prompt
goto MENU
@sebastian-roth Thanks for the suggestion, those commands are handy. I ran --recreate-CA alone & with --recreate-keys and just got a newer version of that same strange cert. I’m looking into it now but I believe someone may have customized the openssl.cnf file on our template, and something with that may be causing this behavior.
DELETE FROM `fog`.`snapinAssoc` WHERE `saHostID` NOT IN (SELECT `hostID` FROM `fog`.`hosts`) OR `sSnapinID` NOT IN (SELECT `saSnapinID` FROM `fog`.`sID`);
Don’t know why this ext3 thing is coming to my mind all the time when people have FTP errors on deleting stuff. Never mind. See the code on why you get those errors. It first tries normal deletes before it does a recursive delete on the files. As the directory is not empty it fails at first. So it’s all fine!
@fractal13 Hey, long time no hear, hope all is well.
Wondering if you (being the original writer and all) wouldn’t mind reviewing my latest procsfdisk.awk script? Had a few issues in 1.3.x days that kind of required a rewrite of it all, which went fairly well. Last night (early this morning) I hope to have solved the mystery of extended partitions though I’m sure it’s not perfect. I can’t see the “flow” nicely. So a good review could be very very useful. (Others are welcome to it as well.)
Thank for your answers. Due to the nature of our work and why we use this FOG server it’s unfortunately air-gapped from the internet so updates have been hard to come by regularly. The only thing that makes sense on root-cause here was one severely borked imaging operation. Even then I’m grasping at straws for a good answer on what triggered the error.
However, I pushed through our ITsec group and got the server updated to current stable release 1.4.4 this morning which did resolve this error and it’s deploying images normally again.
Thanks for the info guys feel free to revoke my nerd card for it being resolved with a standard update.
Something JLE said is the first thing I thought about (ip helper-addresses). If you can get access to login to the switch, find the relevant documentation online for your switch and verify if the VLAN has an ip helper-address configured.
On our ProCurves, we could check like this:
show ip helper-address
or we could configure like this:
config
vlan <vlan_number>
ip helper-address <IP_of_your_DHCP_server>
write mem
end
@SmartyParts I am marking this solved but I’d highly recommend looking into UEFI boot (ipxe.efi, snp.efi, snponly.efi, …) as more and more devices and operating systems are heading for this.
Thank you for the quick response. I normally create my images using a virtual pc. This time I did not do that and forgot to check the bios settings. I did not even think about checking that. Thanks again.