@JonesDK Sorry for the delay. You can try it out now (as described below).

@Greg-Plamondon Is this still an issue or did you find what was causing this?

@george1421 built-in nic can upload/download image just fine. I’m not sure of how to get MAC address from firmware bios on a Mac.

@falko Bump…

@Single Did the logs help you any further?

@george1421 i’m thinking we could have an “unregistered host” host and have it auto-register and auto-remove when the tasking was created/finished. that would also allow us to have a task to track in the gui.

@Greg-Plamondon Any news on this topic? While I am still not exactly sure how this could happen I still haven’t found anything in the fog-client code that would convince me it’s something we can fix. I have worked a lot on that code in the last two weeks.

@sgoodman Bump…

@sgoodman While this is a good point and I like the idea of a cleanup it’s not as easy as removing those options I am afraid. There is quite some code logic in the background that I would argue needs a cleanup together with this as well. Not sure if we should consider removing it all in a rush now. Sure we can just remove the UI part of it quickly. But all the rest would then stay in the code for way longer I suppose.

@Sebastian-Roth This is more by design. Typically snapins are one time run. If needed to rerun a while later, you can run it individually to the host needed, or you could task the host to run all snapins associated. Maybe something we can limit in the future, but I guess I need better understanding. Snapins run in queue. For example, if a host has 25 Snapins to install, it installs 1, 2, 3, etc… It will not install 25 at once. Now, based on the information, I believe the question here is about number of machines running snapins at once. Lets say you have 25 Machines to install Snapin 1, you want this to be limited? Right now the code doesn’t take into consideration the number of snapin tasks as a queued process. Hopefully this all makes sense. Thank you,

@markbam I started to implement that but need to push this further down the list. We need to focus on bugs of the core FOG code before that. Note to myself: I have saved a diff of the current work in my workspace.

@pa_fog_man I think we have a bit of confusion here (and the 390 is not helping with clarification). First let me say that the Dell’s will let you dynamically boot in the other mode without changing the firmware (where it gets its default value). You can do this dynamic switching from the F12 boot menu. The other issue with the 390s (I can’t speak for personal experience with the 390s, but we have 790s in our fleet) the 790s were the first generation to support UEFI mode. But as far as I know, the 790s don’t support pxe booting in uefi mode. The 7010s was the first generation to support pxe booting in uefi mode. To pxe boot on the 7010s you would have to enable the uefi network stack on the network adapter settings in the bios. Otherwise you would not get ipv4 and ipv6 entries under uefi on the F12 boot menu. Back on point. You MUST select the proper boot kernel for the target system bios mode (legacy/bios or UEFI). If you sent the wrong boot file to the system you will not see the FOG iPXE boot menu. for bios mode you can use ipxe.pxe or undionly.kpxe for uefi mode you can use ipxe.efi or snponly.efi The bold text above are the typical kernels to set for dhcp option 67. You can not mix the boot kernels. This isn’t a FOG issue, but rather a firmware one.

Couple of things to check: Is the original machine in BIOS or UEFI mode? Is the target machine in BIOS or UEFI mode? If both are in UEFI mode, you may have to manually add the boot option in the UEFI of the target machine.

@p4cm4n also, tried cmd and batch from sfx archives, specifically 7zip sfx maker which threw an error trying to run on my own machine and winrar sfx maker. Rar is crappier compression but oh well. One of those worked can’t remember which…but things like wifi configs using it didnt.

well, what i needed was the french keyboard for the registration/capture/deploy. I followed Quazz advice (General settings / keymap : azerty) and all is good now ! thanks

@reese I am having the same issue. How did you safely downgrade back to 1.4.4. I had no issues there but can’t image an entire lab anymore. Just locks up. Hints on the downgrade process would be appreciated!

@jmg74 said in dell optiplex 3050 avec windows 10 UEFI: @verdierr : have you tried different options in your host config in Fog website, about “Host Bios/EFI Exit Type” ? [FR : As-tu tenté différentes options, pour ton hôte (via le site web de FOG), concernant “Host Bios/EFI Exit Type” ?] we tried every possible combination but none worked. for option 60, we have legacy computers and to try the uefi, we saw on the web that you have to activate option 60?

Has there been any progress with this issue. I am having the issue where the “_” flashes but goes no further and I have been searching for a solution for the past 3 days. In my case, I am attempting to boot a WinPE Environment to run a 3rd party application. I tried both clean boot.wim files from Win7 and Win10, both fail. But when booted from a USB Drive or CD the application boots. Everything worked perfectly when I was running 1.5.0 but no longer in 1.5.4. Dell PowerEdge 910 Windows Server 2016 DHCP ** Option 66 - IP of CentOS 7 Server Running Fog ** Option 67 - undionly.kpxe DNS Hyper-V ** CentOS 7 ** Fog 1.5.4 ** 16 Cores ** 128GB Ram It will sit here forever.

One other possible solution is Veeam Backup Agent (free). This will do a full system backup with bare metal restore. You can back up to a NAS, Veeam B&R Server ($$), or other network storage device. If you have a system failure, you boot from the linux boot cdrom, connect to your storage device and then restore your system. This is one way to protect your fog server. There may be native (Ubuntu) options like Bacula too.