@george1421 …having made my decision though, I have seen the REFIND option available in the Boot Exit Settings. I’ll drop back in if that fixes the universe in the more “legacy” approach to all this.
EDIT - it did not I got a snowstorm of odd characters marching across the screen. Quite pretty but not successful. All fine though, have my route to making this work now.
@george1421 As always thanks George for the help. Yes indeed DHCP policies will be the way to go to get it all playing nice, but I think also on my end I could commit workstation-side to either/or. And probably of the two UEFI-style will be it.
I’ll more than likely shelve this then and towards the summer update FOG and take advantage of the new features. Ultimately it’d be nice to always have workstations “primed” and I will eventually, but as it stands now (where we only PXE boot when there’s imaging to do) will a - make the boot times a little swifter and b - still be better than WDS!
Cheers. 
…and just to add in, where ipxe.efi is set (and CSM is off in the BIOS to support old-ness) we’re fine and it boots through. Albeit a bit lethargic though, and just on the verge of not really being ok to leave “out in the wild” as is (people will moan and gripe.)
For some context, in a new environment and their imaging here was a little neglected. FOG seemed the best thing to put in to get a smooth, slick imaging solution (as it’s always been tbh) and at the same time cure a little Linux-phobia.
We have though a mix of old BIOS-ey PCs and new UEFI-ish ones. Previously to working here I’d taken newer machines and beaten the BIOS settings into whatever legacy options I needed to force down their throats to get them happy and usually undionly.kpxe working. However here and now I’d like to work more with the UEFI side of things.
So, long story short, I can live with sending techs out around the network and just PXE boot things we want to image but of course I’d much prefer knowing PCs will PXE boot and be ready and willing to image remotely.
Again and help or indeed any thinking or experiments to do would be super. Thanks all!
Morning folks.
Had a read around on this but not quite sure my exact problem has come up. Got FOG running nice on one VLAN, excitedly wanted to roll it out around the network but hitting a snag.
When clients boot and try to pass over to the local disk I get the following:
Booting from SAN device 0x80
Boot from SAN device 0x80 failed: Operation canceled (http://ipxe.org./0b8080a0)
Could not boot: Operation canceled (http://ipxe.org./0b8080a0)
Could not boot: Operation canceled (http://ipxe.org./0b8080a0)
Chainloading failed, hit ‘s’ for the iPXE shell; reboot in 10 seconds
Any magical DHCP 067 file that sorts this? Is it/could it even be that? Just for all the world looks like it’s not paying attention to the message to then pass to the local disk to boot.
Bit stuck and appreciate any and all thoughts and assistance. Thanks folks!
@junkhacker Ok smashing, thanks.
So to confirm the password is encrypted where it’s stored, but can’t be obfuscated in the web gui, that right?
Hi all, hopefully an easy one!
Following along in the old wiki I’m looking at the stage that says “Navigate to the FOGCrypt\etc directory from the FOG download package.”
Must admit I have no idea where this is.
Tried to have a go on the old fogcrypt client from the client downloader in the web gui, to scary messages about not using it.
How do we run fogcrypt these days?
Thanks all!
Best post I’ve found in troubleshooting this thanks much for that George! Tracked down another pesty, ancient server that “answered” and I will chop it momentarily.
I’ve had some excellent and patient help from you over the years thanks muchly for what you do mate.
Hi all,
Had a read around on this one but not sure how to proceed.
I have been “auditioning” all the available files in the /tftpboot folder to try and find one that will work with both Oracle VMs and with “real” PCs. I think this domain previously had a WDS sever on it but no longer does. At least it certainly doesn’t on this VLAN and scope where FOG, the DHCP and DNS servers, and the test client/s reside for now.
Options 66 and 67 seem to be fine, and entering the IP of the FOG server dutifully boots it, but I can’t get it to just “get on with it” without typing that IP in.
Anyone ever solve this one? If so or if anyone has any ideas let me know where to look?
Thanks all.
@george1421 said in Securing FOG Boot Options?:
@jra Now that I’ve had my second cup of coffee this morning I can explain it a bit more.
What the advanced menu and advanced.php does is insert a menu you create when advanced.php is called. You have to hand code the advanced menu and insert the text into a field in FOG Configuration->FOG Settings PXE Advanced Menu field. That field is then inserted after the
#ipxeyou saw when you called advanced.php directly (like I had you do).I don’t have the skills to do this, but it would be great if you could construct the advanced menu like you do the standard iPXE menus by just changing the Menu Show with field, to “Show on Advanced menu”. Then you could move standard menu item behind the advanced menu right from the gui. That sounds like a logical feature to have, but right now the FOG Project doesn’t have the developer time to add that feature.
Right right - ok I’m with you. Have the workaround though and for now even the non-splash menu is functional, in the sense that curious students here can’t amuse themselves doing goofy imaging.
I am appreciative of the help so thanks much there.
Thanks much for all that George. Ok I’ll knock that into shape at some stage.
…just confirming paste that text you put up into /var/www/fog/service/ipxe/advanced.php, that right? Sorry I need a coffee!
@george1421 said in Securing FOG Boot Options?:
@jra said in Securing FOG Boot Options?:
Especially as it has persisted across two versions of Ubuntu and two versions of FOG also
My intent isn’t to be snarky here but stating fact. You are also persistent between the installs and menu fails. I’ve had this issue with other things in the past too. We can’t rule out that the web ui is letting you do something that causes the advanced menu to fail. I’ll see if I can duplicate this on my dev box later tonight. I have not needed the advanced menu so I don’t have any experience with it.
No not feeling you were snarky at all, didn’t read it as such either. However, limited in the mischief I can potentially cause when all I’m doing are basic installs and accessing menu options, plus having had FOG work perfectly before in two production environments, I can’t understand why it isn’t now, especially as I persisted across those also. Genuinely genuinely also not being snarky back, I am grateful for the help.
I can live with the pre-splash hidden options for now and we can suck it up. It’s at least functional there which is what matters.
If you get any insights do let me know as and when.
Thanks again George.
Ok very strange then. Especially as it has persisted across two versions of Ubuntu and two versions of FOG also. I’ve never seen it before either, FOG’s just always been kinda “ok” to set up.
How do I proceed though? I’m a bit stuck on what to do.
@george1421 said in Securing FOG Boot Options?:
http://<fog_server_ip>/fog/service/ipxe/advanced.php?mac=00:00:00:00:00:00
Hehe, think we crossed edits there!
From the first edit url I only have:
#!ipxe
From the second edit url I have:
#!ipxe
set fog-ip 10.134.60.60
set fog-webroot fog
set boot-url http://${fog-ip}/${fog-webroot}
chain -ar http://10.134.60.60/fog/service/ipxe/advanced.php
cpuid --ext 29 && set arch x86_64 || set arch i386
goto get_console
:console_set
colour --rgb 0x00567a 1 ||
colour --rgb 0x00567a 2 ||
colour --rgb 0x00567a 4 ||
cpair --foreground 7 --background 2 2 ||
goto MENU
:alt_console
cpair --background 0 1 ||
cpair --background 1 2 ||
goto MENU
:get_console
console --picture http://10.134.60.60/fog/service/ipxe/bg.png --left 100 --right 80 && goto console_set || goto alt_console
:MENU
menu
colour --rgb 0xff0000 0 ||
cpair --foreground 1 1 ||
cpair --foreground 0 3 ||
cpair --foreground 4 4 ||
item --gap Host is NOT registered!
item --gap – -------------------------------------
item fog.local Boot from hard disk
item fog.multijoin Join Multicast Session
item fog.advancedlogin Advanced Menu fog.advancedlogin
choose --default fog.local --timeout 5000 target && goto ${target}
:fog.local
sanboot --no-describe --drive 0x80 || goto MENU
:fog.multijoin
login
params
param mac0 ${net0/mac}
param arch ${arch}
param username ${username}
param password ${password}
param sessionJoin 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
param sysuuid ${uuid}
:fog.advancedlogin
login
params
param mac0 ${net0/mac}
param arch ${arch}
param username ${username}
param password ${password}
param advLog 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
param sysuuid ${uuid}
:bootme
chain -ar http://10.134.60.60/fog/service/ipxe/boot.php##params ||
goto MENU
autoboot
@george1421 Thanks much there.
Not sure if it’s because of the rendering of it specifically, but confirming I do only see that using the advanced menu options. If there were some way to obfuscate all the options students here would find “interesting” I’d certainly take it.
Ok, so the message is as follows. I enter the username and password to access the advanced options and get this:
And the text from the URL is:
*#!ipxe
set fog-ip 10.134.60.60
set fog-webroot fog
set boot-url http://${fog-ip}/${fog-webroot}
cpuid --ext 29 && set arch x86_64 || set arch i386
goto get_console
:console_set
colour --rgb 0x00567a 1 ||
colour --rgb 0x00567a 2 ||
colour --rgb 0x00567a 4 ||
cpair --foreground 7 --background 2 2 ||
goto MENU
:alt_console
cpair --background 0 1 ||
cpair --background 1 2 ||
goto MENU
:get_console
console --picture http://10.134.60.60/fog/service/ipxe/bg.png --left 100 --right 80 && goto console_set || goto alt_console
:MENU
menu
colour --rgb 0xff0000 0 ||
cpair --foreground 1 1 ||
cpair --foreground 0 3 ||
cpair --foreground 4 4 ||
item --gap Host is NOT registered!
item --gap -- -------------------------------------
item fog.local Boot from hard disk
item fog.multijoin Join Multicast Session
item fog.advancedlogin Advanced Menu fog.advancedlogin
choose --default fog.local --timeout 5000 target && goto ${target}
:fog.local
sanboot --no-describe --drive 0x80 || goto MENU
:fog.multijoin
login
params
param mac0 ${net0/mac}
param arch ${arch}
param username ${username}
param password ${password}
param sessionJoin 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
param sysuuid ${uuid}
:fog.advancedlogin
login
params
param mac0 ${net0/mac}
param arch ${arch}
param username ${username}
param password ${password}
param advLog 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
param sysuuid ${uuid}
:bootme
chain -ar http://10.134.60.60/fog/service/ipxe/boot.php##params ||
goto MENU
autoboot*
Any clues in all that?
Cheers again for the help.
Also DHCP server is a HyperV VM on server 2012R2.
@george1421 I’m hiding the option to image etc PCs behind the Advanced login options (this is a school so kids will delight themselves imaging or b0rking PCs all day if it’s not locked down a bit.)
Logging in to the advanced options from the PXE/background image splash screen menu options bring the chainloading message up. Across now two versions of FOG and Ubuntu server.
Never seen it before on any network.
undionly.kpxe is in DHCP as ipxe.pxe just sits at a prompt for a tftp server (?) - however entering the IP of the FOG server and continuing I get the same chainloading message. If that’s even a hint.
Thanks much for the reply there.
Previously had FOG working on 18.04 on a former network so reinstalled the server from scratch.
That ran 1.5.7 so I installed that version of FOG also.
I am now proficient enough (sorta) to hide the menu options behind the Advanced login by setting the options in the iPXE Menu Customization page in the web gui.
What is KILLING me though is I still get the same stupid thing; “Chainloading failed, hit ‘s’ for the iPXE shell”
Has anyone got even the first idea where to start with this?
Thanks hugely if you can help me out. It’s not been an awesome day.
Ok getting a little further with it, but think on the other hand it’s getting ever more broken.
I can hide the PXE menu (although I really do want my nice little splash screen background image back to be honest) but setting a key (eg F9) to bring up the PXE options, logging in to the prompt which appears I get a chainloading error and it boots to first disk.
Is there any way to fix this and to hide all the menu options behind a single login option on the splash screen instead?
Thanks all.
Morning all,
Have an issue in FOG 1.5.9 where, no matter what I change in the web GUI I can’t seem to “lock down” the options in the boot menu (eg restrict normal users getting access to perform full host registration or inventory.)
Any good places to fiddle around on that?
Ideally I’d like the whole menu options hidden until a key is pressed, can that be done also?
Thanks much any and everyone.
@george1421 Hi folks - so sorry huge influx of users back today, had to get on with other bits.
All three of your points correct though George yes. Although I’d add in on point 2 that it won’t WoL until power is unplugged for about 20 secs and also, following that, the PC is then booted to BIOS for a few seconds or paused at the polling for DHCP part of POST, and then shut down again. That will “prime it” for WoL and WoL will work thereafter until Windows is booted, then it won’t until you repeat the above “priming” process.
Thanks again everyone.
At this stage it’s not looking like a FOG problem strictly, so if you’re getting sick of it it’d be fair to say it’s outside you folks’ remit but I do appreciate the help muchly.
@george1421 You are a gentleman thank you for staying with me on this. I’ll give it a go and let you know…