@quazz You’re right. Must have been a bad spot or something. One thing we all know Windows does is to add a minimum of two partitions on a clean install. Mine had 3 (ms system reserved, empty) partition. Did lots of research, found I don’t need three, just setup GPT with single partition, did base install, and now FOG imaging upload works.
Thanks for pointing me in the right direction.
@Sebastian-Roth Gosh darn it, that worked!!! What ultimately was done was what you suggested. Someone else had suggested the primary disk change, that was removed. But there was also some custominit.xz or something like that listed as well, so I changed that to init.xz. Can’t believe it, but that worked! Now going to try and deploy this same image to exact same hardware on different PC. I’ll let you know how the deploy goes. Sebestian (and team) thanks so much for your hard work and diligence on this. -Jim
Also, digging deeper, it appears as though it is a good GPT image file:
cat /images/EUFI2HDD2025x/d1.partitions
label: gpt
label-id: 90AAA622-0DBD-4BE4-9D85-A54D50340EC6
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 500118158
sector-size: 512
/dev/nvme0n1p1 : start= 2048, size= 204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=8E1F3336-F9E2-4C7F-A832-B8865182DF2D, name=“EFI system partition”, attrs=“GUID:63”
/dev/nvme0n1p2 : start= 206848, size= 32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=BAEB99F3-C8AC-4FAE-8CC7-95C7D412A219, name=“Microsoft reserved partition”, attrs=“GUID:63”
/dev/nvme0n1p3 : start= 239616, size= 498755998, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=B16B4307-0A5C-42AD-B6EA-8A783ABC4C8C, name=“Basic data partition”
/dev/nvme0n1p4 : start= 498997248, size= 1118208, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=DDE992F8-5913-46DB-8E25-B0AD6C84266A, attrs=“RequiredPartition GUID:63”
-Jim
Tom I was able to get everything back up and running with the assistance of ChatGPT - but it only took a little over a week! (And for anyone else reading this, I would highly NOT recommend using ChatGPT for FoG assistance)
However Tom I am stuck with the same issue. FoG will not write to the correct partitions. Once again here is my setup:
32GB RAM
500gb Seagate HDD in SATA0
256gb SSD drive (M.2) in SATA1 (these are not cabled, not changeable)
NOTE: I setup the PC with the SSD drive being the main PRIMARY drive (faster speed, “C” drive) and the Seagate standard HDD as the SECONDARY drive (“D” drive)
The device was imaged as a “Multiple Partition Image - Single Disk (not resizable) - (2)” as the SSD drive has the standard 3 or 4 partitions that Windows setups up by default.
Host was setup using /dev/nvme0n1 as the “Host Primary Disk”. It was captured without error. I verified via diskpart before imaging that each HDD/SDD was GPT partitions. However when I do a file listing of the image, I am seeing a d1.mbr file. Is this correct?
1024 -rwxrwxr-x 1 fogproject fogproject 1048576 Jun 7 16:21 d1.mbr
13268 -rwxrwxr-x 1 fogproject fogproject 13584339 Jun 7 16:21 d1p1.img
4576 -rwxrwxr-x 1 fogproject fogproject 4684567 Jun 7 16:21 d1p2.img
18382576 -rwxrwxr-x 1 fogproject fogproject 18823753628 Jun 7 16:49 d1p3.img
454724 -rwxrwxr-x 1 fogproject fogproject 465637248 Jun 7 16:50 d1p4.img
4 -rwxrwxr-x 1 fogproject fogproject 873 Jun 7 16:21 d1.partitions
When I watch the DEPLOY task, it says it’s writing to the /dev/nvme0n1 disk, but when the deploy is completed, I can verify that it wrote to both drives, but not in order.
Can you help me with this PLEASE?
-Jim
Tom, I am pretty sure this is a kernel issue - but this is beyond my knowledge. Are you available to assist remotely?
-Jim
FoG was running perfectly for years, as you may recall. The only recent changes are that we are no longer using Legacy Bios for the imaging - as we have added a secondary SSD drive (M.2 on SATA1) to the equation. However FoG was only sending the Primary image to SATA0 no matter what I put in FoG. However these same machines with a single standard Seagate 500gb drive in SATA0 was working fine under EUFI, both DEPLOY and CAPTURE. Ai recommended a change in the iPXE file, which started this whole nonsense. So this time we wiped the pxe files from TFTP and did a reinstall of FoG. Getting closer now, but still getting the same errors on the PXE screen.
Pretty much at my wit’s end here. I know were are close…
-J
@Tom-Elliott said in [BUG] iPXE Boot Loop & Menu Failure After FOG 1.5.10.1660 Upgrade:
Seems to me you likely need to check the host or global kernel settings. 64 bit kernel should be defined to bzImage This would show up under global configurations (FOG COnfiguration Page -> FOG Settings) “TFTP_PXE_KERNEL” should be set to bzImage
TFTP_PXE_KERNEL_32 should be set to bzImage32
These are set correctly
-J
@Tom-Elliott said in [BUG] iPXE Boot Loop & Menu Failure After FOG 1.5.10.1660 Upgrade:
Seems to me you likely need to check the host or global kernel settings. 64 bit kernel should be defined to bzImage This would show up under global configurations (FOG COnfiguration Page -> FOG Settings) “TFTP_PXE_KERNEL” should be set to bzImage
TFTP_PXE_KERNEL_32 should be set to bzImage32
Tom, where can I find these settings? I am in Fog Settings, but I only see lot of blue links, none of which refer to Kernel or TFTP?
-J
Now this:
ChatGPT says: “Your system booted in UEFI mode, but bzImage32 is a 32-bit kernel, which cannot boot on most 64-bit UEFI systems.”
Does this help?
-Jim
@Tom-Elliott said in [BUG] iPXE Boot Loop & Menu Failure After FOG 1.5.10.1660 Upgrade:
git reset --hard
git clean -xfd
git checkout stable
cd bin
./installfog.sh -y
Tom, I did this again (16th time now) and I never get prompted to update database or schema. Is this normal?
I still can’t get past the iPXE (v1.21.1+) screen!
@Tom-Elliott
Thanks Tom
However I ran this about 15 times. Post install I was never given an option to update the database or schema.
My initial issue before upgrading was that I was trying to deploy image to Lenovo M625Q tiny with 256gb SSD drive as the PRIMARY drive and the standard Seagate 500gb (SATA0) as the SECONDARY drive. I added the /dev/nvme0n1 as the primary disk, yet FoG wrote to the Seagate drive first every time.
I asked ChatGPT for ideas, and it found a known issue with FoG writing to EUFI SSD drive as Primary drive and stated that I needed to update to the latest iPXE file. Everything been broken ever since. I have spent more than a week trying to get FoG working once again.
I’m updating my Ubuntu server to v20.04 now and I will try the re-install one more time, unless you have any other ideas?
-Jim
192.168.9.10/root/fogproject//var/www/After upgrading to the latest FOG version, my PXE boot environment is broken. What used to work flawlessly is now a disaster. PXE clients either hang, enter a loop, or display autoexec.ipxe not found. Sometimes pressing ESC brings up a green DOS-style login prompt, then fails to chainload. Sometimes they hang on “Booting…” indefinitely.
Could not boot: autoexec.ipxe not foundChainloading failedbzImage, bzImage32) and init files are missingboot.php loads in browser but returns:hosts, hostMAC, and ipxeMenuItems are populated and correctbzImage32, but the file is missing/var/www, not /var/www/html/var/www/autoexec.ipxe, permissions confirmedboot.php but files are goneboot.php returns valid iPXE script, but boot failstasks table/var/www/fog/service/ipxe/ is missing bzImage, init.xz, etc.FOG Configuration → iPXE Menu Configuration are missingmenuaccess=1 in boot.php call to testdisplay_errors in PHP FPM, CLI, and Apache configs/tftpboot/var/www/autoexec.ipxeboot.phpFOG’s original behavior:
- If task is scheduled → auto-execute
- If no task → show PXE boot menu
That logic is now broken post-upgrade. I do not want custom behavior or rewritten logic. Just default.
bzImage32, init.xz)?Thanks in advance — desperate for resolution.
– Jim