[BUG] iPXE Boot Loop & Menu Failure After FOG 1.5.10.1660 Upgrade
-
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, I am pretty sure this is a kernel issue - but this is beyond my knowledge. Are you available to assist remotely?
-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:
- Lenovo ThinkCentre M615Q tiny;
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.partitionsWhen 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
- Lenovo ThinkCentre M615Q tiny;
-
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
-
@Jim-Holcomb So unfortunately i’m not readily available for a remote assist due to work requirements and duties so I apologize.
@Jim-Holcomb said in [BUG] iPXE Boot Loop & Menu Failure After FOG 1.5.10.1660 Upgrade:
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.
So this “autoexec.ipxe not found” always shows. This is not an issue. It’s simply saying there’s no file called autoexec.ipxe on your /tftpboot folder. It’s NOT whatever was causing ipxe boot issues. I’m guessing this PXE boot environment was broken due to whatever was changed?
As to the selective hard drive. I’m not sure I understand what is wrong here. YOu watched it write ONLY to the /dev/nvme drive but somehow it wrote to both the sda and the nvme? Something doesn’t sound right there. Single Disk resizable and Multiple Partition Single disk shoudl only write to a single drive and be done. Do you have video of this process writing to both? I only ask because seeing this in action will help me understand where the code is flawed. To my knowledge, however, it seems more likely that at some point before you wrote to the NVME it had accidentally written to the SDA drive, then you try to figure out how to have it write to the NVME. Then, finally, it was able to write to the NVME, but now it LOOKS like it wrote to both because the SDA drive was never cleared out?
And yes, d1.mbr is absolutely correct. That’s how it initializes the disk.
-
@Jim-Holcomb @Tom-Elliott Did you get anywhere with this? We’re having a similar issue that started today. Only affecting older machines, UEFI boot.
See attached for Pcap, PC hangs at “iPXE initialising devices… autoexec.ipxe not found”
Doesn’t matter if I set snp.efi, snponly.efi or ipxe.efi. PC hangs for exactly five minutes then reboots.
We’re on working-1.6, latest update. I’ve done a git clean as suggested above.
-
@sideone THis issue seems completely different from the context of this. I understand, or at least believe the reason this was asked here is because of the “Boot Loop”? portion?
In either case:
If you want to see what I mean, just create an empty file in /tftpboot called
autoexec.ipxe(sudo touch /tftpboot/autoexec.ipxe) and the error of “autoexec.ipxe” will disappear. It will not fix the issue you’re seeing, but this message is not, itself, an error. Just the last thing that happens, if I 'm reading the clues correctly.Do you know what type of NIC the machine that sticks for 5 minutes is using? If it’s realtek or intel, you could try the realtek.efi or intel.efi tftpboot file?
-
@Tom-Elliott Hi Tom, sorry that I’ve misposted. Your suggestion of trying a realtek.efi didn’t work but it prompted me to try using undionly.kpxe instead. This worked, so maybe its a UEFI / legacy hybrid BIOS? Not sure how its working, but it is.
Thanks, and sorry to crash OP’s post.
-
@sideone No worries. That just let’s us know in your specific case at least, it’s not booting in UEFI mode at least for NIC devices, so thank you!
-
@sideone said in [BUG] iPXE Boot Loop & Menu Failure After FOG 1.5.10.1660 Upgrade:
Your suggestion of trying a realtek.efi didn’t work
At running the risk of polluting this thread just a tad more. If undionly.kpxe worked in bios mode then snp.efi should work in uefi mode.
Also knowing the exact realtek nic model could be important if its a 8168 (1GbE) or 8125 (2.5GbE) the default drivers in the linux kernel wont work well. You can try to use the experimental kernel that has the official realtek drivers built in https://github.com/rluzuriaga/fos/releases/tag/EXPERIMENTAL_REALTEK_DRIVERS Understand this will only help once you get past the FOG iPXE menu. This would be after undionly/snp has displayed the FOG Menu.
-
@george1421 said in [BUG] iPXE Boot Loop & Menu Failure After FOG 1.5.10.1660 Upgrade:
If undionly.kpxe worked in bios mode then snp.efi should work in uefi mode
Hi George, the BIOS claims its in UEFI mode but when booting it looks suspiciously like legacy (larger text etc). Its an old Viglin with a second generation i3 which is being retired this October so its not too much of a deal now I have a workaround.
