@sebastian-roth Again, I can’t check right now, but I’m pretty sure secure boot is disabled. I will look further into what you suggest when I get another chance to work on this project. Thank you.
I don’t think I did say yes to having my FOG server handle DHCP, but I don’t remember.
Can those iPXE binaries be changed in the webgui?
@george1421 Yes. I edited my previous post. I had posted that before you sent the rest of the chat messages. I had only seen the link.
Thanks again for the help, mate.
@george1421 Thanks. Would I still be able to deploy the image by creating a task in the FOG webgui?
EDIT: I see your second message. I can do everything by scheduling in the FOG webgui. That works. I will play around with this another day when I have time to do so again.
Thanks for the help.
@george1421 How do I boot USB? And what capabilities of FOG would I not have access to?
@george1421 I guess it hangs starting iPXE. It detects media, downloads the boot file and then begins to initialize devices before it freezes. It never makes it to any menus after I instruct it to boot via the IPv4 NIC.
As for whether the motherboard is in BIOS or UEFI mode, That’s a great question. I don’t quite remember and I can’t check right now but I’m pretty sure it’s in UEFI mode.
@george1421 If by “the latest firmware on the HTPC” you mean the newest available BIOS for my motherboard, it does indeed have the newest BIOS. It’s an MSI H61M-P21 with BIOS 19.2 which is the latest listed on their website.
Is it that simple? A BIOS incompatibility? I guess my newer rig works because the BIOS is not conflicting with iPXE. If that’s the case, it’s very disappointing.
EDIT: On closer examination, that link does indicate that I have a Realtek NIC. It’s weird that inxi in Mint reports a Qualcomm NIC. Maybe that’s why it’s having issues.
@bristow-0 I’m running FOG 1.5.9 in a Buster 10 VM on Proxmox 6.1-3 and it’s mostly working fine. I imagine a significantly newer version of Proxmox wouldn’t have any issues. I was able to register and capture an imagine from a Ryzen 7 3700X machine. I’m just having issues booting my HTPC from ipxe for some reason I can’t figure out.
Hi guys.
This seems to be a common enough problem, but all the threads I am able to find about it are either really old or not quite specific enough to my issue. I’m using FOG 1.5.9 on a headless Debian 10 Buster server which is running in a Proxmox VM. I have it all set up, I believe, correctly. I was able to properly register and capture an image from my much newer (Ryzen 7 3700X) gaming machine but when I try to boot my HTPC (i5 3470) it hangs on initializing devices. I’m not sure which machine would be at fault here. My server (LGA 771 era dual Xeon machine) but it works for the gaming machine so I’m at a loss. I think it has to be the fault of the HTPC but I don’t even know where to begin. I’ve read that realtek NICs can cause this problem, but the NIC in my HTPC is a Qualcomm and the VM is using a virtual intel NIC, probably passed through from the Supermicro motherboard.
Any constructive input appreciated. Thanks.
EDIT: After a little more research, I’ve been able to determine one possibility. Could it maybe be a host boot kernel issue? I’m apparently running kernel 4.19.0-11, but that kernel isn’t even listed when I go into Kernel Update in FOG. Would it be worth upgrading the kernel? I don’t want to make it stop booting my gaming rig.
EDIT AGAIN: Now that I think about it, the kernel that FOG is running doesn’t have to be the same one that it boots hosts on. Where do I find which kernel it is using to boot hosts? My other question still stands though, if I can upgrade the kernel, is that something worth trying?
EDIT #3: Corrections.
@Sebastian-Roth Here’s a strange new development that I happened upon today. I’m not 100% sure if this actually has anything to do with the issue, but at my primary location there is a particular rig with the troublesome MSI motherboard that was no having any issues booting past the iPXE menu…until I tried to update the nVidia graphics card driver. Once I updated the driver, then it started having the same boot-looping issue the rigs at the secondary location were having. The rigs at the secondary location all have newer drivers than some of the ones at the primary, since I made sure the image I took down there was up to date. I wouldn’t think the graphics card driver would have anything to do with it, but there it is. It’s really…weird.
EDIT: Confirmed. This particular rig, at least, will not boot past the iPXE menu when the newest driver I have downloaded (456.71) is installed. Despite a BSoD and hard crash during installation, the driver seemed to have installed correctly and the machine was mining and the manager was reporting the correct driver, it would not boot past the iPXE menu and into Windows. When I uninstalled that driver and reinstalled an older one (452.06) it has no problem booting past iPXE and into Windows. To confirm further, I reinstalled both drivers a couple of times just to make sure. The result was the same. I dunno.
@Sebastian-Roth Updating BIOS did not solve the problem. I don’t know what’s going on but I do know that I, personally, will never buy an MSI product for this and several other reasons.
@Sebastian-Roth It does certainly seem like buggy BIOS/EUFI, doesn’t it? It seems that some random rigs at the primary location have also started having this problem now with the exception that where resetting and reconfiguring BIOS at the secondary location does not solve the problem, it does seem to help at the primary.
This is so totally effed up I can feel my hair turning gray. I’m going to see if there is a newer BIOS for these boards and if there is maybe that will fix this? I don’t know. At this point I’m almost ready to just burn both buildings down.
@JJ-Fullmer The site is definitely not worth the work of setting up a local copy of ipxe.efi, but I guess I can try other efi files from the /tftpboot directory.
What’s happening is not always consistent. There are certain things it does most of the time, but occasionally it seems to decide it wants to switch things up a bit.
When I first registered (not imaged) the hosts on the FOG server, they booted into Windows just fine. And if that’s all I do, they continue to seem to boot into Windows just fine. However, as soon as I either image them or capture an image from one of them, they will no longer boot to Windows. What @george1421 was calling the ipxe menu (which I could have sworn was more closely FOG related) would time out and then the circling Windows loading indicator would appear briefly before the screen would go black and then shortly the whole thing would reboot and do that all over again. Sometimes, the screen would just go black and the monitor would either go to sleep or not (that just seemed to completely random) and it would hang that way until I rebooted it.
Resetting BIOS to defaults and then reconfiguring allowed it to boot past the ipxe menu and into Windows, but only once. After rebooting the machine, it would begin to boot loop again.
@JJ-Fullmer Yeah there is nothing like that in the BIOS of these MSI gaming boards. I assume it might have something to do with the LAN Option ROM, but other than enabling or disabling that I can’t do anything with that either. I have no idea how to configure it and the mobo manual is no help at all.
I’ve asked the guys on the MSI_Gaming subreddit about it but to be honest I’m not expecting much.
I think this whole endeavor is pretty much a wash.
@JJ-Fullmer So I have confirmed that I am able to shut down the machines and have them wake on lan when I schedule a task in FOG, but I can’t make them boot from network if they have received a magic packet WOL request. They just boot into Windows and the task is not executed. I’m not sure how to change that. I know it would be in BIOS but I can’t seem to find anything related to that in the BIOS.
@george1421 Well, I don’t know. I’m also out of ideas. I’m pretty certain that any hardware moved from the secondary location to the primary location will not suffer this issue because, again, I’ve moved motherboards from the secondary to the primary before and they’ve worked. That’s not to say it’s 100% guaranteed to work but I’d say it’s 99.99% certain to work. The ipxe.efi file and all the refind files have not made any difference at all. As much as I would like to get this FOG server working properly at the secondary location, it’s not a priority compared to other stuff I need to do so I’m inclined to just call this a defeat. I generally shouldn’t need to image the secondary rigs that often anyway so, as inconvenient as it is, I think I will just have to physically go to the secondary site to do any imaging.
Thanks for all the help mate, but this site just keeps having strange issues that take too much time to solve. If you do come up with any other ideas, I’m happy to give them a try but I really don’t think moving any hardware is going to solve anything at the site. It’s just a lot of work that I don’t think will be worth doing, especially since the site is slowly being decommissioned anyway.
@george1421 Yeah, I didn’t think it would make a difference at all. I just figured it might be worth noting. I’ve managed to get the ipxe.efi file transferred to the secondary location without leaving the primary. I’m about to reboot one of the problematic rigs now to see if it will boot properly. Cross your fingers.
EDIT: Well, upon a simple reboot it managed to make it into Windows. However, it was one that I had not previously imaged with FOG. Once I had deployed the image to the rig, it will no longer boot into Windows. This is bizarre.
@george1421 A new discovery today: Apparently FOG at the primary location is running in a Proxmox VM. I was not aware of that. I don’t think it should make much of a difference, but there it is. The FOG server at the secondary location is running on bare metal.
@george1421 I can almost guarantee that the problem would not move with the hardware. I have moved rigs from the secondary location to the primary before, as we are slowly downsizing this secondary site and moving stuff to the primary as we sell off video cards. I’ve used motherboard from here to replace boards at the primary location without any problems. I do have an empty rack at the primary location where I can move a couple of the rigs from secondary though and make sure it will work. I will have to do that at some point next week. I can’t have a rig dismantled over the weekend.
@george1421 Unfortunately, I cannot access the primary FOG server from the secondary location and that particular step will have to wait until I’m back at the primary location next week. Then I will likely have to put it on a flash drive and manually drive it down here.
I just made a backup of the 1.5.9 ipxe.efi file though, so that’s already done.
If that’s all that can be done for now, I guess I might as well head home. There is nothing else I can do here.
@george1421 Okay, I just replaced the refind.conf file with the original.
The hardware at the main office is the same. MSI Z170A Gaming M7 motherboard with the same version of BIOS. The only differences between some of these rigs with the same motherboards (or even the ones with Biostar boards, for that matter) is that some are running Pentium G4400s and some are running Pentium G4650s. They’re all running a bunch of GTX 1070 or GTX 1070 Ti cards or a combination of the two.