@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:
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
/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?
@george1421 ok so I have created two files fog.man.reg and fog.customhostname containing their respective code as per your tutorial. I see this step “we need to copy the fixed fog.man.reg and (fog.auto.reg) file(s)”. Do I need to worry about the fog.auto.reg file or is the fog.man.reg file enough?
@george1421 These are scripts that run during registration right?
Wondering if there is a way for FOG to detect a Windows recovery partition and have it not try to resize it so that the deployment process can continue.