@george1421 said in Cannot boot hard drive from PXE menu:

@blankzapper booting you can hit F12 to pick the boot device?

No. Also there is no option to “Enable F12 Boot Menu”.

Something else to check, make sure that mobo is running the latest bios version. They might have corrected that behavior in a later firmware update.

It’s latest BIOS released 2014. Nothing newer. I am seeing if it possible to hack this AMI BIOS. I updated RealTek option ROM, to 2016 release, but it didn’t fix anything. I think UEFI network boot option must be added. I don’t know if this can be done without big changes (and likely bricked motherboard!)

@plegrand Which Linux OS and version do you use? Which FOG version do you run right now?

@david201 You might be better off getting this out of Docker. Here are steps on how to migrate FOG. If you have the right switches enabled in the hosting OS, you should be able to mount NFS inside of the container. Otherwise, there are other ways to get the images & things out.
https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

Cool! I didn’t know that option was there. Thanks.

@Hope1983 From the fog.log:

25.11.2020 16:31 Middleware::Response Invalid security token

That means the tokens used to encrypt the connection are not ok anymore. This happens over time or when changing hostnames for example. Go to the FOG web UI -> edit the settings of the host you got this log file from and click the big orange button named “Reset Encryption Data”. If you want to do this for several hosts in one fo you can create a group, put them all in and then go to the group settings and click “Reset Encryption Data” there.

For the database you want to take a look at the credentials stored in /var/www/html/fog/lib/fog/config.class.php. Though I would imagine it’s user “root” with an empty password which was still used in FOG 1.5.5.

Ok, after lots of digging in the code and @JJ-Fullmer database we seem to have found out what happend. Turned out some of his PowerShell code messed things up by deleting the primary MAC address of some hosts and the fog-client did its share to kind of reset some of the hosts’ information and make them pending.

The PowerShell code is fixed already and I will work on adding some checks to hopefully not mess as much up with the fog-client as we did here.

Initially we thought the snapin hash problems were at fault but the evidence collected points to this being a coincidence.

@sebastian-roth IT WORKS !!!

I had to put right for “service local” and “system” on share access AND on security files.
share.png Folder.png

Thank you very much ! And sorry for my bad english 🙂
Thank you again !!!

@gfrancesco84 Any news on this?

@cicero Yes I agree

@sebastian-roth Hi, I didn’t made other tests since end of October but I was able to deploy image to 80 PC at this moment so for me it’s ok 😉

@nerdstburns Just want to add a question to what George already said. Are both your disks NVMe drives by any chance? Just asking because they are special and need different parameters.

Which version of FOG do you use?

@darkxeno Ok you need to ensure that kernel support uefi computers. The could not boot exec format could indicate the kernel doesn’t support uefi.

As for the top post with the iso, that would use memdisk and memdisk only supports bios based computer. I uefi system will throw an error if you try to use memdisk on uefi.

Also try the alternate ipxe syntax I provided.

Lastly on the iso image you have see if there are the uefi directories on that media. /EFI and or /boot

@rogalskij While I can understand that your techs want to get it imaged as fast as possible I would still suggest they take on small hurdle at the beginning and save a lot of time later on.

See if you can tell them to PXE boot and choose “Perform Full Host Registration and Inventory” instead of direct deploy. This will ask for the hostname to be used within FOG (and als set in Windows!) as well as image ID and even set all the information for automatic AD joining. At the end of registration you can tell it to schedule a deploy so it does one reboot and deploys without any further interaction.

If you set things up correctly your techs would take maybe 2-3 minutes for the full registration but after that they can walk away and it does the deploy, rename, join domain (fog-client) without any further action required.

Beside that you won’t have additional MAC flooding that single host…

@lcshelite said in Dell Latitude 5510 Won't Boot from Hard Drive After Imagine through UEFI:

WDS for so long I didn’t even think of that!

Yes that is really the difference between WDS/MDT and FOG. Where MDT does (dynamic) file based cloning and FOG does block layer cloning. MDT takes about 1.5 hours to image a single computer and FOG takes about 4 minutes to image a computer. There is no better technology over the other, it all depends on what the right fit is for the company.

If you are trying to image as many computers as fast as you can then use FOG. If you need a dynamically built image (i.e. able to change the image structure based on external variables) use MDS/WDS.

@george1421 tested with Hyper V 2. everything you said is correct and that is exactly whats happening.

We are assuming this is limitations on the host. Going to try to test with a physical machine.

@wertor I know it’s been a long time but have not found enough time to work on this earlier. We now have a first version of init.xz capable of capturing and deploying a Windows 10 2004 UEFI/GPT install with recovery partition at the end. Would you give that a try.

Please be aware this is still in kind of a pre-release phase. Make sure you have a backup of your original image as well as the machine you pull the master from, just in case!!

@scosta I know it’s been a long time but have not found enough time to work on this earlier. We now have a first version of init.xz capable of capturing and deploying a Windows 10 2004 UEFI/GPT install with recovery partition at the end. Would you give that a try.

Please be aware this is still in kind of a pre-release phase. Make sure you have a backup of your original image as well as the machine you pull the master from, just in case!!

@sebastian-roth I would be happy to give you a feedback if I have the opportunity to test your new init (I am an intern so opportunities do not arise all the time :))

@smoblikat If you get something worked out that might help others, please do tell.

Secondly for the apple computers that use the T2 chip I have a one off kernel that will boot on them so you can access the hard drives behind the T2 chip. Let me know and I will send you a link.

@infrapeya The quickest way is via the linux command prompt on the master FOG server.

If you are using a rhel based linux distribution then.

scp /var/www/html/fog/service/ipxe/bzImage* root@SN_IP:/var/www/html/fog/service/ipxe

i.e. scp /var/www/html/fog/service/ipxe/bzImage* root@192.168.20.40:/var/www/html/fog/service/ipxe

The debian/ubuntu versions are a bit more difficult.
Remote connect to the storage node using ssh (or putty from windows)

On the linux command prompt key in the following.

sudo su - scp <linux_user_on_master_fog>@<master_fog_ip>:/var/www/html/fog/service/ipxe/bzImage* /var/www/html/fog/service/ipxe

i.e. scp daffy@192.168.11.53:/var/www/html/fog/service/ipxe/bzImage* /var/www/html/fog/service/ipxe