Got it working! This worked for me after making sure the drive was changed to GPT and I also labeled the efi parition as “EFI”:
menuentry “Windows” {
insmod chain
insmod ntfs
insmod part_gpt
set root=(hd1,gpt2)
chainloader (hd1,gpt2)/efi/microsoft/boot/bootmgfw.efi
}

Just realized that the set root part is redundant. I am partitoning the drive now to copy the files from the FOG USB key then tell the UEFI on the PC to boot from this new GRUB partition first. Looking good!

@sebastian-roth I didn’t start messing with things until they stopped working, not the other way around. You suggested this path “/var/www/html/fog/lib/fog/” (and I have also seen this path elsewhere in other posts on this forum) when in fact the system seemed to be using “/var/www/fog/lib/fog/” so something must have changed during the upgrade from 1.5.6 to 1.5.7RC2 erroneously. I think it is the ownership of that path that caused the issue. Not sure how that happened, again, before I changed anything to troubleshoot. I read through that post and it does clear things up thanks. I will bookmark it.

@sebastian-roth said in Quick question about the tftp/ftp credentials:

grep FTP_USERNAME /var/www/html/fog/lib/fog/config.class.php

define(‘TFTP_FTP_USERNAME’, “fogproject”);
define(‘STORAGE_FTP_USERNAME’, “fogproject”)

I just updated FOG to 1.5.9.45 and it changed the username back to fogproject. I went in and changed the user name to just “fog” again because that was what worked earlier today. Should I change it back to fogproject?

Also noticed that the kernel version rolled back to bzImage Version: 4.19.143. I need the latest kernel 5.6.18 because we have new laptops from Dell that need the latest kernel to get passed the FOG boot menu. As I tried to update the kernel I received this error:
Type: 2, File: /var/www/fog/lib/fog/fogftp.class.php, Line: 709, Message: ftp_put(): Could not create file., Host: 10.0.0.10, Username: fog

Let me put the username back to fogproject and see what happens. What prompted me to change the username to “fog” was the end up an image capture, it was trying to login as fogproject and kept failing.
FOG Settings>TFTP Server setting shows this under TFTP PXE KERNEL DIR: /var/www/fog/service/ipxe. Should it be /var/www/html/fog/service/ipxe?

running “sudo chown -R fog:www-data /var/www/fog/” fixed the kernel update error. Going to try an image capture/deploy to make sure everything else still works and will report.

I’m looking for a way to create a standard, non-admin user for the fog webui. This user will be able to manage images, tasks, but nothing else. I basically want to prevent this user from changing storage settings and be completely locked out from the FOG Settings menu. Is this possible?

My fog server is on 1.5.9-RC2 (I will update to 1.5.9 soon) and according to the Web UI>FOG Config>FOG Settings>TFTP Settings, the user name was set to “fogproject” and a long hash password. When I tried to update a kernel, it threw the wrong credentials error. So after some internet digging, I found that I had to change or make sure the owner of /var/www/fog/service/ipxe/ was fogproject:www-data. After doing that using “chown -R fogproject:www-data /var/www/fog/service/ipxe/”, still got the same error. I then checked what password was in the TFTP settings menu and compared it to the Storage setting menu, and they were different. Set the Storage password to the one in TFTP settings, still failed, wrong credentials. So I changed “fogproject” to just “fog” and left the password the same. Changed the owner of that ipxe folder to “fog:www-data”, tried the kernel update and it succeeded. I never changed the credentials so I am wondering if it is possible they change during an update? I am not ruling out the possibility that one of my colleagues might have changed them accidentally. I will lock down the GUI just in case. I am up and running now. I think there was a power outage this weekend and noticed that the isc-dhcp-server service was not running. I had to use “sudo systemctl enable isc-dhcp-server.service” again as I did that a few weeks ago because of the same issue. I know that is more of an Ubuntu problem than a FOG problem but figured I’d mention it in case someone has some insight.

@sebastian-roth Is it possible that running apt upgrade might have broken something? On my home server (Ubuntu Server 20.04) upgrading packages broke the qbittorent-nox service and I had to recreate the .service file and re-enable it.

Of course I didn’t run that command ever! I thought I had run something like that but I guess I didn’t. Thanks!

I am using Ubuntu Server 18.04.5 LTS. The dhcp server doesnt seem to start whenever I reboot the server. I have to run “sudo /etc/init.d/isc-dhcp-server restart” manually to get it back. I know this isn’t a FOG specific problem, but hopefully someone can help me out.

I copied all the files with the folder structure to the partition I created. Set the part type to EFI System, filesystem to FAT32, told the BIOS/UEFI to boot from bootx64.efi in /BOOT/EFI and landed at a grub rescue prompt. After playing out the process in my head I realize that full automation won’t work because the way the menu is set up to autoboot into Windows after 5 seconds will prevent a deploy or capture task from ever starting. I’d have to be at the PC to select the Deploy/Capture option on the FOG Menu. The USB option still works though so all is not lost.

Got it working! This worked for me after making sure the drive was changed to GPT and I also labeled the efi parition as “EFI”:
menuentry “Windows” {
insmod chain
insmod ntfs
insmod part_gpt
set root=(hd1,gpt2)
chainloader (hd1,gpt2)/efi/microsoft/boot/bootmgfw.efi
}

Just realized that the set root part is redundant. I am partitoning the drive now to copy the files from the FOG USB key then tell the UEFI on the PC to boot from this new GRUB partition first. Looking good!

that didnt work for me. said ntldr and drivemap not a command.