Thank you all so so much. Right after this emergency planning for corona virus hit and I’d been taken off it.

That’s all wonderful, having skim-read it I’ll be in a better position to take it all apart.

Bless you.

@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

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.

@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!

@george1421

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 #ipxe you 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.

@george1421

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!