@george1421 Follwing your suggestion, here’s what I ended up doing with success:
ipxeconfig:

:netboot
chain http://*fogip*/html/default.ipxe || goto netbooterror

:netbooterror
prompt --key s --timeout 10000 DHCP failed, hit 's' for the iPXE shell; reboot in 10 seconds && shell || goto refind

:refind
imgload file:///EFI/Boot/refind.efi
boot

I also placed refind.efi and refind.conf on the EFI partition in EFI/Boot/ along with the custom bootx64.efi. Now I don’t know if refind.efi will automatically read refind.conf or do I have to tell ipxe to load the conf as well.

Now when the connection fails, I get the 10sec prompt (which I will shorten and change the message of), then it goes to the refind menu, which the first option is selected, Windows EFI Boot option, with a 20sec timeout. Boots into Windows!

I just have to clean things up and shorten the timeouts since our end users will see this if their internet goes out. Otherwise our Helpdesk will get flooded with “weird messages on screen when starting up”.

@george1421 I was messing around with a UEFI vm that has windows 10. Normally it boots from EFI/Microsoft/Boot/bootmgfw.efi. I made a vISO with the FOG bootx64.efi and watched as the ipxe process would try to connect to the fog server, failed, then it boot into windows. When I placed the fog bootx64.efi onto the hard drive efi partition, and told the vm to boot to that first, ipxe would fail and drop to a shell instead of booting to the first boot option in the UEFI. I don’t think or know if the ipxe shell can access a gpt partition, or if it can even see the drive. Sanboot 0x80 returns an error device could not be found.

@george1421 Odd thing is that it worked on a VM booting from the USB files inside of a vISO in virtualbox, I had the VM on a local lan that does not have access to the prod network so it couldn’t connect to the fog server and then it booted from the virtual hdd. That could be because the default boot device is the first vhdd, and it is pointing to efi/microsoft/boot/bootmgfw.efi. So I could specify that file somewhere in the ipxeconfig file right? Only thing is how would I know the root path of the efi partition of the windows drive? I’ve seen something like PCI/HDD0/something/something/EFI/ but not sure.

@george1421 said in Boot from hard drive if connection to fog server fails:

http://<fog_server_ip>/fog/service/ipxe/boot.php?mac=00:00:00:00:00:00

You da man sir!
I changed the ipxeconfig to this and it booted to the hdd after failing to connect to the fog server!

:netboot
chain http://fogip/html/default.ipxe ||
imgfetch http://fogip/service/ipxe/refind.conf
chain -ar http://fogip/service/ipxe/refind_x64.efi

I have a setup where I replaced the Windows EFI files with a custom FOG efi file that connects to the fog server first, checks if there are any tasks, then boots to Windows if no tasks are running. If the connection can’t be made to the FOG server, according to the ipxeconfig script, it will fail and either prompt to drop to shell or reboot.

:netboot
chain http://fogip/html/default.ipxe ||
prompt --key s --timeout 10000 Chainloading failed, hit 's' for the iPXE shell; reboot in 10 seconds && shell || reboot

This can be a problem if internet goes down for a remote site, the PCs won’t boot into Windows and the clients can’t work locally at the very least.
How do I tell the script to boot from the hard drive or a specific file instead of rebooting? Windows has multiple EFI files to boot from that work, bootmgrfw.efi and bootx64.efi work the same. So I’m thinking to leave one of those as the stock Windows efi file, then tell the script if it cannot connect to the fog server, boot from a specific file, in this case the Windows efi file.

@george1421 I just tested it out on a PC outside of our IT vlan with success. I hard coded it already, but I have a habit of not disclosing our IP addresses even if they’re private. I get the Press ESC to show the menu option for one second, then it boots to the hard drive. Now I took the modified bootx64.efi from my usb drive and copied it to the Windows EFI partition, replacing the existing one (renamed the old to bootx64.efi.bak), made sure that the UEFI is pointing to the file, and now the PC boots the fog process without USB.

@george1421 I placed a copy of default.ipxe in /var/www/html and verified it is accessible via my web browser. Still having trouble with the ipxescript. What I’d like it to do, and I’m currently researching how to do, is tell ipxe to:

1. Init devices
2. Request an IP via DHCP
3. chainload the default.ipxe file by connecting to the http share.

What I don’t want is the proxy check and all that. I want everything to be specified and explicit.

UPDATE: Found it! Still a bit dirty, but I got it to serve over http only.

#!ipxe
isset ${net0/mac} && ifopen net0 && dhcp net0 || goto dhcperror
echo Received DHCP answer on interface net0 && goto netboot

#:dhcpnet1
#isset ${net1/mac} && ifopen net1 && dhcp net1 || goto dhcpnet2
#echo Received DHCP answer on interface net1

#:dhcpnet2
#isset ${net2/mac} && ifopen net2 && dhcp net2 || goto dhcpall
#echo Received DHCP answer on interface net2

#:dhcpall
#dhcp && goto setserv || goto dhcperror

:dhcperror
prompt --key s --timeout 10000 DHCP failed, hit 's' for the iPXE shell; reboot in 10 seconds && shell || reboot

#:proxycheck
#isset ${proxydhcp/next-server} && set next-server ${proxydhcp/next-server} || goto nextservercheck

#:nextservercheck
#isset ${next-server} || set next-server fogip && goto netboot || goto setserv

#:setserv
#set fogserver fogip && goto netboot || goto setserv

:netboot
chain http://fogip/html/default.ipxe ||
prompt --key s --timeout 10000 Chainloading failed, hit 's' for the iPXE shell; reboot in 10 seconds && shell || reboot

@george1421

/root/fogproject-1.5.9/src/ipxe/src/ipxescript

#!ipxe
isset ${net0/mac} && ifopen net0 && dhcp net0 || goto dhcpnet1
echo Received DHCP answer on interface net0 && goto proxycheck

:dhcpnet1
isset ${net1/mac} && ifopen net1 && dhcp net1 || goto dhcpnet2
echo Received DHCP answer on interface net1 && goto proxycheck

:dhcpnet2
isset ${net2/mac} && ifopen net2 && dhcp net2 || goto dhcpall
echo Received DHCP answer on interface net2 && goto proxycheck

:dhcpall
dhcp && goto proxycheck || goto dhcperror

:dhcperror
prompt --key s --timeout 10000 DHCP failed, hit 's' for the iPXE shell; reboot in 10 seconds && shell || reboot

:proxycheck
isset ${proxydhcp/next-server} && set next-server ${proxydhcp/next-server} || goto nextservercheck

:nextservercheck
isset ${next-server} && goto netboot || goto setserv

:setserv
echo -n Please enter tftp server: && read next-server && goto netboot || goto setserv

:netboot
chain tftp://${next-server}/default.ipxe ||
prompt --key s --timeout 10000 Chainloading failed, hit 's' for the iPXE shell; reboot in 10 seconds && shell || reboot

The ipxe.efi was compiled on the same server that the USB boot method is connecting to. It seems like default.ipxe is being served via tftp AFTER ipxe init. So that file is what I want to be served via http. I guess I’d have to make the ipxe.efi do this via script of config file before compiling it.

I’ve been experimenting with the USB boot method for a bit now. I’m wondering if it is possible to serve all boot files via http instead of tftp using the USB boot method.

@sebastian-roth 1.5.9. What is also strange about how FOG behaves across subnets is the USB boot method. I’ve explained in another post about how booting from USB on the same subnet and/or same switch stack on my floor will not prompt me to enter the tftp server but booting from a completely different vlan or subnet physically outside of our own network will prompt for it. See this line in the ipxescript:

:setserv
echo -n Please enter tftp server: && read next-server && goto netboot || goto setserv

I tried changing it to and this time it configures net0 then does nothing and the PC returned to it’s own (Dell) boot menu:

:setserv
set next-server 10.x.x.x && goto netboot || goto serserv

I know this is off OP but it seems related to different subnet behavior in FOG.

@sebastian-roth Yes. What I ended up doing is logging into the FOG Web UI from a workstation set up near the server itself, used for setting up sessions and images, which is on the 10.0.0.0 network, and I was able to delete the image. Not sure why it didn’t work from the prod network side maybe I never checked “Delete files” while deleting an image.

@sebastian-roth I never use fogproject during the ipxe fog menu login, always use fog/pw. I followed all the steps in your link, same result.

I know this is probably a dumb thing I don’t see but I’m getting an error when trying to delete an image while also checking delete files, after entering the credentials. I tried the fog/pw web ui creds, and I also tried the fogproject/longpw creds from the FOG Settings>TFTP menu (that told me invalid login).

@sebastian-roth I could always do a mysqldump export and import from the primary fog server to the secondary right?

Let me start by saying that we do NOT have pxe set up on our prod network, because reasons out of my control.

My plan is to have two identical servers running FOG, the only difference would be that the primary FOG server would be offline and serving DHCP/PXE on a local switch, while the secondary will be just an NFS server, on the prod network, that I use to image remotely, without PXE, but starting the ipxe chain using the custom FOG efi boot image on the hdd0 of the client workstations.

I will also find a way to sync the two servers so the images and hosts will be the same. But I believe if the secondary is a Storage node, I wouldn’t have to sync them. So can a Storage Node still serve tftp files so that I could boot off of it remotely?

@sebastian-roth Ah ok thanks for clarifying. So I should only download from github what I already have instead of all of the inits right? Also I don’t know why those two bzimage files are in the group “fogproject” instead of www-data, but other than the resizing issue, my FOG server works fine.

@george1421 There wasn’t any doubt on my end…but I can imagine you read that and said to yourself “of course it did…”.

@sebastian-roth The last thing I remember reading was that modifying the partition file was a fix. I also remember being told that Microsoft made their recovery partitions non-resizable. I’m on 1.5.9 and unless we image a drive that is the same size as the source drive, the process will fail saying one of the partitions could not fit or was too big. I remember in earlier versions of fog that we could always create an image from a 500gb drive and deploy it to a 250gb drive, even with the windows recovery partitions. Acronis can do the same thing. But now we can’t.

@george1421 BOOM! That worked! Thanks!

@george1421
So I got it working. The only thing I’d like to omit from the script is the site code function. I only need the serial number to be read from bios and set as hostname. Which parts of the script can I comment out to skip that step?