@Tom-Elliott looks like i have to update my fog to 1.6 instead of 1.5 as i thought i resolved it by updating fog to the latest 1.5 but the error is still there on 1.5, i thought it went at first as when i made my first image it saved as a folder but on my second capture its saving as a file again

@MichaelPower said in FOG & iPXE Anywhere - issues from boot menu:

Just wondering if a working bzImage I can use that boots under Secure Boot?

The issue is exactly that. bzImage is not signed so the uefi firmware will not boot it. That is the root of the issue. You could self sign ipxe and bzImage but then you will need to update the certificates in each computer to include your self signed certificate. Its possible but it is quite a bit of work to get it all setup.

Ok,

I finally figured this out. I know it’s not the best method, but I prefer this than having the wording “plain text” Here’s what I did in case someone needs to do the same.

I read that API tokens do not go well as a securestring. Here are some references:
https://jamesone111.wordpress.com/2020/04/10/transformers-for-powershell-parameters-which-take-secrets/, and https://github.com/Azure/azure-powershell/issues/25533.

So in order to get past this, I needed to create another variable as show below:

$testapi1 = [pscredential]::new(“token”,$yourtoken)

You’re basically adding the pscredential above like you’re going to setup a username, but you put something like “token” or any wording as a placeholder for the username, then put the token in.

Then after you define the header you do something like this: $testheader.add(fog-user-token’,$testapi1.GetNetworkCredential().password)

Again it’s not the best method, but I also read a way when you do read-host -aseecurestring and save your api there as a variable, you can dispose that variable so it doesn’t stay in memory.

$test.disposeof

If someone has any better ideas, please let me know as I’m always on here learning new things and want to share as well. This basically can be closed out.

@lucancurtismahoney First let me start with the yada-yada-yada. Imaging over wifi is not supported by the developers of FOG. Imaging over wifi has its use cases but also is not advised because wifi is a shared resource and your entire wifi network will suffer if you try to image over wifi. You would be better served to get a supported (by the manufacturer) usb ethernet adapter and pxe boot over that.

With that said it might be possible to image over wifi if FOS is configured in an (unsupported) way. It will require a custom FOS Linux kernel and some tweaks to the virtual hard drive to add in the needed bits to configure wifi.

Below is a FOG USB debug image that contains a modified bzImage and init.xz files. Use rufus to burn to a 1GB usb drive. The image is less than 500MB so don’t waste a large usb on this boot image.

Understand this boot image WILL NOT WORK out of the box. We will use this for debugging your network adapter. Many network adapters need specific drivers to work with a linux kernel. We will find out what that firmware is with this debug usb.

Use rufus to write the image file to the usb drive. Edit the grub.cfg file with notepad++ (not windows notepad) its located in the /boot/grub directory. At the top set the IP address of your fog server, and half way down the variable add in your wifi ssid and password. Remove the curly braces. Save the config file and then take it to your target computer. USB boot this image file on the target computer. You may see some error messages about networking, but that is expected. After a few screens you need to clear by pressing the enter key you will be dropped to a linux command prompt. See if you can see the wifi adapter with this command ip a s If you see something like wlXXXXX then the driver is loaded and you are done. If you only see the loop back (lo) adapter then continue. Key in the following command it will look through the startup messages for anything that mentions firmware. grep -i -e firmw /var/log/messages My bet is there will be a message from the intel wireless (iwlwifixxxxx) saying that it needs a specific firmware to load. Take a clear snapshot of the name of the firmware name with a mobile phone and post it here. I will patch the kernel with the required firmware and upload it with additional instructions.

https://drive.google.com/file/d/1psCrPVzBTvlakLkCMvhdoScAEZp1CKE6/view?usp=drive_link

your right they do support PXE boot i found the option right at the bottom in the bios you can choose between PXE HTTP and iSCSI
i didn’t do enough scrolling down last time i looked.

So I have deleted the entry with no data

DELETE FROM powerManagement WHERE pmMin = '' OR pmHour = '';

The problem is resolved.
I have backed up the table before 😉

This can sometimes happen after you have sysprepped an machine and missed the boot menu prompt, entering the Out-of-box-experience. Trying to shutdown the device will leave the dirty bit resulting in the unclean error.

To avoid having to sysprep again, allow the device to enter OOBE again and hit shift+F10 and enter “oobe\bypassnro” at the resulting command prompt. Once you hit enter, the system will perform a clean reboot, clearing the dirty bit and allowing Fog to capture the filesystem correctly.

Hopes this helps someone else as some Dell machines are notorious for failing to get an IP from IPV4 PXE boot.

are they all in a clean shutdown state before starting?
do they already have an OS?

Just came across the same issue, did you fix it?

@tian I’ve got exactly the same problem. The initial 10 queue items complete, but the next batch won’t start. I have to click the lightning bolt icon in the task list to force it to start. Am running up to date FOG software on a fully patched Ubuntu server.

Finally , @Tom-Elliott

Reinstallation of fog solved the problem . I think the issue was linked to the fogproject account. This issue can be closed.

@infotech_22 Generally speaking, if you do setupcomplete.com, you should completely disable the FOGService as re-enable it as the final step of the setupcomplete.com script.

The reason:

FOGService will attempt to start up and perform its actions alongside anything else that’s occurring. Generally, when the system is setup and running just fine, things are okay because there’s no interactions, but when you pair it with the OOBE configuration stuff, where it could be changing ini’s and Registry thigns, then the FOG Client is saying “Hey restart to change the name and join the domain” or “Hey restart because I completed installing this Snapin” or whatever else may be going on, it can leave your machine in an unknown and cause issues.

This isn’t something we’re able to fix in a codified manner unfortunately and we have given instructions many times to allow FOG Client while in OOBE state.

https://wiki.fogproject.org/wiki/index.php/FOG_Client#:~:text=If you plan to use,the image deployment is complete.

I don’t know if this is in the more modern Documentation, but it is in the original documentation as well.

@Mr_____T Well, I have discovered a work around. According to our consultant, the legacy wrapper message in the 1st or 2nd image was kinda the key. the X360 has no wired nic port and the usb nic adabter is recognized as a legacy booting device. But the unit only boots efi. I followed this link for starters:

Kernel runtime parameter:

Next I added the MAC addresses from each usb dongle I have available. Then, from the fog web interface:

list all hosts
Select the host
Basic Tasks tab
Deploy tab
Task (I first checked debug and followed the bread crumbs no issues)
Imaging commenced.

This is quite a bit more work than I was hoping to do just to image one machine. I was hoping someone out there could come out of the fog (pun intended) and provide some feedback.

So this is not solved. But a work around that does. If you got this far Tx

Not sure why I did not just start with trying a pre 6.xx.xx kernel…

Downloaded the the last 5.15.xx Linux kernel slapped it in /var/www/fog/service/ipxe/bzimage-5.15.98 updated the host kernel to bzimage-5.15.98 and BOOM 20GB/min.

Still willing to do some testing if there is anything you need from me to see if this can be fixed in 6.xx.xx.

Hello again, I conducted additional tests. In debug mode on the client, I ran network tests between the client and the fog server using the iperf server. The results do not indicate any network issues:

iperf -c 192.168.25.11 ------------------------------------------------------------ Client connecting to 192.168.25.11, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 1] local 192.168.25.49 port 35204 connected with 192.168.25.11 port 5001 (icwnd/mss/irtt= 14/1448/924) [ ID] Interval Transfer Bandwidth [ 1] 0.00-10.02 sec 1.09 GBytes 938 Mbits/sec

I also conducted disk write tests, and they also do not indicate any issues with the disk:

bash dd if=/dev/zero of=/tmp/testfile bs=1M count=1000 status=progress 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB, 1000 MiB) copied, 0.17635 s, 5.9 GB/s

I also created an uncompressed image, and it also restored slowly, with transfer speeds below 1GB/s, rather around 500-600 MB/s, which results in even lower speeds.

I changed the PXE environment boot file, set it to realtek.efi, and then changed it to snp.efi.The snp.efi visibly improved the FOS loading process, but the image restoration is still slow. Can the FOS system use a different driver during restoration than it does when operating in debug mode?

@JJ-Fullmer We are using FOG 1.5.9 I have tried turning on the Mac passthough. I have tried all of the .efi bootfiles i have. We did get a machine back from Lenovo where they rolled back the biois and that one machine is working fine