Image can only boot through FOG Menu
-
Hello out there,
I am running FOG server version 1.5.9-RC2 on Ubuntu 18.04. All machines I am imaging are running Ubuntu 16/18 on an Intel NUC. I’ve run this server from both a virtual machine server instance and a Desktop instance and see this happening on both. I am running into this issue where when I pull an image from the linux NUC, and then push that image to a different NUC, the only way I can get the image to boot is to go through the FOG server menu through network boot. From that point if I choose “Boot from image” it has no problem. If I don’t go through network boot, or I try and view the boot options, the NUC acts as if the there is nothing on the drive to boot. Interestingly enough, I mainly see this when I pull from an image with a different type of hard drive than the one I am pushing to.
For example, pulling from: Inland Premium 256GB 3D NAND TLC M.2 2280 PCIe NVMe 3.0 x4 SSD and pushing to: ADATA SU800 256GB M.2 2280 SATA 3D NAND SSD, or vice versa, causes this issue to happen.
When I make an image, I leave storage group as default, I select Linux for the OS, I do “single disk - Resizeable” for image type, “everything” for partition, leave compression on the default value of 6, and use default “Partclone Zstd” for image manager. I’ve played around with these options but it still always behaves the same way.
-
This is interesting where the iPXE menu can find the boot sector/file and the firmware itself does not.
The problem may be in your golden image and not fog or the target computer.
So let me ask you is your image bios or uefi based?
If its uefi based does the first partition on the disk contain the EFI boot loader? If it does then the firmware in uefi mode should find it. FOG doesn’t adjust the uefi boot manager when it images so if you have a efi partition that moves around on the disk that may be the issue.
-
The Image is uefi based. Secure boot disabled. I’ll have to figure out the EFI boot loader being present/missing, but I have pushed this same image to multiple targets without issue which would lead me to believe the boot loader is there. The catch is, the brand/style of drive on the targets was the same as the machine the image was captured from. Now that I am trying to push to a different brand/style drive, this is happening.
-
@dennis-porter said in Image can only boot through FOG Menu:
Now that I am trying to push to a different brand/style drive, this is happening.
So using this logic, can you take a drive from a system that deploys correctly and swap it with a drive from a failing system. The goal is to see if the problem moves with the drive (divide and concur approach). A full drive exchange approach is the best to see if the problem really moves
-
I did have two systems (1 working, 1 failing) and was able to swap the drives. The problem stayed on the original failing system machine even with the new hard drive. Because of that I tried another machine, to try and prove that maybe it was just that machine causing problems, where the only difference between the target and source was the drive. But this one also cannot boot on it’s own.
-
@dennis-porter FOG does not capture/deploy UEFI boot entries because almost all UEFI firmware out there is able to boot without explicit creation of boot entries and some firmware even has trouble when FOG would so this. So for now I don’t see why we’d add this to FOG.
Though in your case the firmware seems to not be able to find the boot partition and loader and won’t boot from it. In this case you can use Post deploy scripting to add the entry using
efibootmgrLinux command included in the FOS inits.
