@1337darkin My initial reaction is don’t use virtual box, my second thought is don’t use virtual box…

The thing is that vb uses iPXE as its own internal boot loader, and the issue is chaining with FOG’s version of iPXE. The screen shot you show is VB’s version of iPXE running trying to call snponly.efi where its failing. This is an issue with VB and not specifically with FOG.

I think there is a fix for this but I can’t seem to find it at the moment, google-fu is weak today.

On a totally abstract note. You can capture a uefi image with FOG in bios mode. And on the flip side you can capture a bios disk image in uefi mode. BUT to be able to boot that image after image/deployment the target computer’s firmware needs to match the disk image.

@professorb24 from 192.168.52.X can you ping devices on 192.168.54.X. If yes then you have network routing setup.

Once you pass full routing, what is your dhcp server for 192.168.52.X and 192.168.54.X?

@EuroEnglish I’m finding it hard to believe that there is a connection of having win11 on the computer that is causing this behavior. When the fog menus are being displayed, we are running iPXE boot loader. This in a way is an OS by itself. The OS on the target computer is not even known about at this point in the booting process.

The only thing I can think is that the format or disk structure is now allowing iPXE to fully initialize correctly.

Could you make this test for us? If you have 2 computers of the same model (make sure that bit locker is disabled on both systems) and secure boot is disabled.). One with win11 and one with win10. Verify they both behave the same way as you mentioned above.
On the win11 computer remove the hard drive/nvme drive. Boot into the FOG iPXE menu. Does it still have the slow speed?
Move the hard drive from the win10 computer to the win11 computer. Does the system act slow or normal?

@MonsterKaos There are 3 issues (well really 4 issues) that is probably impacting your deployment.

1. You have really new hardware, but you are running an old version of FOG.
2. Your version of iPXE (the boot loader that provides the FOG Menu is old (this is probably causing the no connection methods.
3. Your version of the FOS Linux kernel (you haven’t got this far yet) is probably too old.
4. You are missing some of the enhancements to the FOS Linux OS that interface with NVMe drives. Just be aware if you have issues deploying to nvme drives you should probably upgrade to FOG version 1.5.10 and then upgrade to the branch version of 1.5.10. This is not a mandatory upgrade unless you have issues deploying your image.

For issues 2, I have instructions on how to compile the latest version of iPXE here: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe Your fog server will need to have internet access to get the latest source code for iPXE. This should address the no configuration methods.

For issue 3, in the fog ui go to fog configuration-> kernel update. Download the latest kernel 6.x series to get support for the newest hardware.

Lets see where that works for you with deploying images.

@maximefog said in Deploy Image:

it is mandatory to register the workstation

This is not a requirement under certain conditions. There is a method I call “load and go”. It is a process that system builders use where once they load the OS on the target computer they never see the computer again. In this method you can not use the FOG Client for any of its function. The install process must be self contained or use a FOG post install script to make the install time adjustments to the target computer. Using this method you do not need to register the computer with FOG. Once the image is deployed to the target computer FOG forgets it ever saw this target computer. Once you have the master image setup as needed you deploy the image from the FOG iPXE menu “Deploy Image” menu. You never have to touch the FOG web ui for image deployment.

@bmick10 said in Fog stops at init.xz...18% and other percentages:

So it will load to Fog stops at init.xz…and different % each time.

This sounds like an iPXE issue, where its not loading FOS Linux’s virtual hard drive completely for some reason. Lets start out by having you rebuild/compile the latest version if iPXE using these instructions: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe Lets see if there is an update to iPXE that solves this issue.

@Tom-Elliott Thank you for the update. I should have looked at the code.

So the OP needs to update the current curl call with this ?

    base64mac=$(echo $mac | base64)
    token=$(curl -Lks --data "mac=$base64mac" "${web}status/hostgetkey.php")
    curl -Lks -o /tmp/hinfo.txt --data "sysuuid=${sysuuid}&mac=$mac&hosttoken=${token}" "${web}service/hostinfo.php" -A ''

To make it work now?

@JamiesonCA092 I can’t really give you a solid solution because fog isn’t designed to work the way you want it with unregistered target computers.

But I know how FOG works. There are 2 “hook” scripts. One is before imaging starts and one after the image push is complete. The bash script that is called before imaging starts is the postinit script. When this script runs all of the kernel parameters have been expanded to variables, including storageip value. This value as well as most others could be reset by this postinit script.

I have a tutorial on a postinstall script that uses the IP address of the target computer to decide what OU the target computer will connect to. That mechanics of the bash script could be the basis to update the storage IP variable. I don’t know if it works, but if you are that deep into modifying the ipxe script, creating your own bash script shouldn’t be to complicated.

Edit: Post on point. https://forums.fogproject.org/post/69725

@JamiesonCA092 ok it shows you have some debugging skills, so I’ll add a few new tools into your toolbox.

1. on the fos linux (target computer) when you schedule a task and tick the debug checkbox, when you pxe boot the target computer you will be dropped to the fos linux command prompt.
2. You can start the imaging process in single step mode by simply keying in fog at the command prompt.
3. The script will run until it hits a debugPause; command in the script. You can add that command in your custom script with echo statements to understand how your script is running. Pressing the enter key will cause the script to run again until the next debugPause command.
4. At the fos linux command prompt if you get the ip address of the fos linux (target computer) with ip a s and then give root a password with the passwd command (make it simple like hello, it will be reset at the next reboot). Once you have those 2 bits of into you can use putty or ssh from a second computer to the fos linux computer for debugging. Using this method you don’t have to sit in front of the target computer plus you can copy and paste using the putty/ssh session.
5. If you need to stop the fog script during hit ctrl-c to skip out of the script. At this point you can verify the environment, check the available variables, etc. When you are done looking around, then you can enter fog again to begin the imaging process once again. No reboot needed.
6. In the fog script the kernel parameters sent to fos linux are converted to bash script variables in the functs.sh script between lines 9 and 13 https://github.com/FOGProject/fos/blob/0efdd68f1783a06f3214607fc313db50747fbc43/Buildroot/board/FOG/FOS/rootfs_overlay/usr/share/fog/lib/funcs.sh#L9

I’m pretty sure Wayne is right that the varialbles in the postinit script are local and will be erased when the script terminates. But I would test to be sure.

One last hack I can think of is that you can hack the fog.mount script https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.mount Put the logic to decide the target’s IP address into that script. The concept of dynamically patching the fog.mount script can be found in this tutorial (which addressing the fog.man.reg script) https://forums.fogproject.org/topic/14278/creating-custom-hostname-default-for-fog-man-reg but the concept and actions are the same.

@DBCountMan In the post init or post install scripts the $mac variable contains the mac address of the target computer

To get the ip address this script will work

myip=`ip route get 8.8.8.8 | awk 'NR==1 {print $NF}' | cut -d "." -f1-2`;

Getting the user id of who did it will be a bit harder since they never log into the web ui. The user ID and password they key in during the deploy image stays in ipxe and is not sent onto FOS Linux. I’d like to say that the username field can be trapped from iPXE and then pass that variable as a kernel parameter onto fos linux. Once that is done then the $username variable should exist in your fog scripts. Getting that info into the fog database is another challenge. In the post install script the /ntfs directory is mapped over to the fog servers /images/dev where you could append an echo statement into a text file.

Understand I’m taking in programming pseudo code. But I see an path here and it should work.

@cros I’m kind of spit balling here but your imgargs line especially around nfsroot doesn’t really follow what I expect.

FWIW here is what I have in my guide for debian 11. (I really don’t keep up with current distros anymore)

kernel tftp://${fog-ip}/os/debian/Server11.3/linux
initrd tftp://${fog-ip}/os/debian/Server11.3/initrd.gz
imgargs linux initrd=initrd.gz root=/dev/nfs boot=casper netboot=nfs nfsroot=${fog-ip}:/images/os/debian/Server11.3/ locale=en_US.UTF-8 keyboard-configuration/layoutcode=us quiet splash ip=dhcp rw
boot || goto MENU

For me your imgargs line stands out as is your 192.168.7.5 server your fog server or a different server? If its your fog server you can make the line a bit more portable by using ${fog-ip} which will be replaced by the IP address of the fog server by iPXE. Secondly did you create an /nfs share on your fog server because that is not one of FOGs standard nfs shares. On the fog server you should be able to run the command showmount -e 127.0.0.1 to see the list of nfs shares on the fog server. In my imgarg command you can see I’m using /images/os which is in the path of /images on the fog server and /images is an NFS share.

ref: https://forums.fogproject.org/post/150256

@Quintin-Giesbrecht said in FOG Very Slow to Deploy Image - Lenovo Neo 50Q Gen 4:

Lenovo Neo 50Q Gen 4

I’m with Tom here, I would go with the latest FOS Linux kernel with this new hardware. You didn’t happen to mention what version of the FOS Linux kernel you are using (FOG UI -> FOG Configuration -> Kernel Update). I would go with the latest 6.6.x or later kernel. This is the easiest and quickest way to see if it solves the problem. It would be useful to know what version is your current kernel too so if we see this issue again we can help the next guy.

@jmeyer said in Error PXE-E18 - Lenovo ThinkPad E16:

It’s now loading but terribly slow (average 6 Mb/s on a Gb link).

What is loading slow iPXE or the image via partclone? I haven’t been following closely the issue but I think I saw that someone tried an earlier version of the FOS kernel, like in the 6.1 range and imaging on these current lenovos went at normal speeds. I don’t know what the linux developers did between 6.1 and 6.6 to cause this slowness. Have we identified what nic adapter is installed in these computers? We would need the hardware ID of the nic to research it.

@robertkwild Yes right now pxe booting issue is between uefi firmware and network adapter. Typically the hardware vendor will have a recommended usb adapter (typically hardware vendor branded $$) that supports pxe booting, where the driver for the usb adapter is built into uefi.

I the imaging process once bzImage is loaded (FOS kernel) and you have a network issue then the issue with with the “FOG kernel”. You are not there yet in the booting process.

@Jias94 Where I’ve seen this before is in a custom fog menu. The menu id has a minus sign in it and ipxe is thinking its a command not an id. Somewhere around the choose command its getting hung up.

So how do you find this? Using a web browser and access the ipxe menu at http://<fog_server_ip>/fog/service/boot.php You need to replace <fog_server_ip> with the correct ip address. Since you are messing with https, you may need to change that so. You should end up with a screen full of text that makes up the ipxe menu. Looks for things you have entered that have a minus sign. If you can’t find it post the entire content of the ipxe menu here and we will take a look for you. But I would focus your attention around the choose command, one of its entries as a dash where it thinks is an internal command to the menu

@rodluz said in FOG Very Slow to Deploy Image - Lenovo Neo 50Q Gen 4:

That is exactly what I did, I disabled the 8169 driver from the kernel config too.

Good going. That 8125 driver was originally in the linux kernel individually but then the driver was merged into the 8169 unified driver which has not kept up with the realtek hardware changes. I was getting lost trying to integrate a third party driver into the linux kernel. I could compile it as a module and add it to the init.xz but that is not a sustainable solution. If you have it integrated into the kernel for the 8169 (1GbE) and 8125 (2.5GbE) that should cover most of the common network adapters today from realtek (outside of the 10GbE stuff, but those haven’t hit the desktops yet).
Well done!

@mbghost said in UEFI Boot - Kernel panic: Unable to mount root fs on /dev/ram0:

I disabled Snooping

If that was dhcp snooping I can see where it might be causing a problem. If that’s igmp snooping then for multicasting you want that enabled.

@mbghost said in UEFI Boot - Kernel panic: Unable to mount root fs on /dev/ram0:

But when I try to create an image from the FOG web console and capture image, it breaks everything. I get the same error on all device

Mind including the error you are seeing? It would be helpful to include a screen shot or picture of the error so we can see the context of the error too.

@mbghost If the network test doesn’t work then lets focus in on that toshiba all in one. Lets identify the hardware components since it seems to be the focus of the problem. First do the easy stuff.

@mbghost I’m still leaning towards init.xz corruption. Its very strange that on a fresh fog sever it works on day one and then the next its no good.

Just for clarification its all and every Toshiba all in ones but other models work just fine? Its only this specific model.

What I’m thinking at the moment is that bzImage transfers fine and its around 8MB in size. The kernel also boots fine because its getting to the point where it attempts to connect to the root file system.

init.xz is a zstd compressed image. Its compressed size is around 350MB. Both images are very small in size. Something is happening to the init.xz image to where bzImage is not able to mount it and the kernel panics.

This image persists across multiple deployments and multiple installs of FOG server. It also crosses different init.xz and bzImage kernels.

FOS linux does boot 1 out of 12 attempts.

So where could the problem hide?

1. The FOG server hardware if that was a consistent deployment throughout the server rebuilds. (test try building fog server on a desktop/laptop computer to rule out fog server infrastructure)
2. Something with the network between the fog server and the target computer. (move target computer as physically close to fog server as possible and test deployments eliminating all of the existing networking between fog server and target computer)
3. Something with the target computer. (if you have been testing with the same computer throughout these tests use a different computer. Its possible there is a ram issue with this computer)

Right now there isn’t a clear picture on the cause. I can say this IS unique and I’ve haven’t seen this before with FOG.

Something else you might do is in the fog settings, set the log level to 7. I think the default is 4. 7 is verbose and the kernel might spit out more information to why its not happy with the init.xz file. Like decompression failed.

@mbghost This error message baffles me. If its happening where I think its happening its not a pxe boot issue. This error happens after you pick an iPXE menu item or if you tell a computer to image.

So you can probably rule out ipxe.efi/snp.efi here.

This error message is generated with FOS linux is booting. The kernel has booted and when it goes to connect to init.xz the format of init.xz is corrupt for some reason.

What version of FOG are you running
What version of “the kernel” are you running?
What version of init.xz are you running (get this from a bios computer that boots. the version of the init will be under the fog logo)

What computer is this happening on (make and model)?
Is it all uefi systems or only from one manufacture?
How much ram does this computer have?
Are you seeing both bzImage and init.xz get transferred completely to the target machine. This will be visible just after you pick an item on the FOG iPXE menu.

To me this error is telling me something is wrong with init.xz or for some reason bzImage is not the right kernel for init.xz