@george1421 Thanks.

@tia-clark What is ifogsim?

what do you mean “scheduling algorithm”?

@Lukaz You could try doing a post download script that takes the hostname you set for that fog host and put it in the /etc/hostname file.
I think there may be other locations that hostnamectl sets on newer linux builds, but this could still work.

I haven’t done a linux post download script but you can see some other examples in these posts, mostly windows based, but I’m sure we can apply the idea to linux without too much trouble. Just gotta mount the client disk in FOS (Fog operating system that you boot into over the network for the imaging process) after imaging is done and inject the fog hots hostname variable (not sure what the var name is off the top of my head) into /etc/hostname on the client. It’s a bit of work initially, but once setup should just work from then on.

https://forums.fogproject.org/topic/8889/fog-post-install-script-for-win-driver-injection?_=1682187993801

https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script

@footbolvova Can we get a clear and complete shot of the kernel variables?

We need to know much more to be able to help you. The message says the target computer can’t access the nfs share on the fog server.

Is this a new install of fog or did just this one client have this issue?
Is the client on the same IP subnet as the FOG server?
On the fog server linux console, what is the output of showmount -e 127.0.0.1 ?

@geardog I think I understand what you did. Let me say this with my words. You built a FOG server but did not have the space on the small VM, so you connected via NFS to an external NAS. You mapped the /images over to the remote NFS server wanting to borrow space from that external NAS.

If that is the case, then you can’t do that with NFS. Basically you are trying to reshare a network connected drive. This is akin to taking server A and mounting a directory from server B as the W drive, then trying to share the mapped W: drive to a third computer.

The only way to make the above scenerio to work is via mouting the remote disk as an iscsi LUN on the fog server. map that external iscsi lun over the /images directory. Then install FOG. That will work because the iscsi lun is a block device, and nfs is a file level device.

This was a weird one. I ended up reimaging my FOG server and now it works. I wasn’t able to figure out what happened, but it was some kind of local issue as far as I can figure.

@george1421

Just tested it and it works correctly.
Thank you for your effort.

For other beginners with iPXE like me:
This is the relevant documentation for the flow control.
https://ipxe.org/scripting
With examples at
https://ipxe.org/examples

@marsface Well done finding the solution, the regex expression might need to be updated in the tutorial then. It could have been FOS linux changes since the tutorial was written, or a different way that the dell firmware is reporting the model. Either way well done.

@smazzola Well a question back to you is, what is your dhcp server? What is the manufacturer and model of the dhcp server. If its a linux or windows dhcp server then you are in luck. Here is a tutorial on how to create a dynamic dhcp server that will send the proper boot file based on the pxe booting computer. https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence

@dvorak said in new version e2fsck ?:

Used answer from MarSoft found here (the last comment):
https://github.com/NixOS/nixpkgs/issues/229450

basically run :
tune2fs -O ^orphan_file /dev/mydevice
e2fsck -f /dev/mydevice

and it is successfully capturing

I can confirm that this works as well.
I ran into this issue trying to take an image of an EndeavourOS virtual machine.
On the EndeavourOS virtual machine i had to boot off a USB so that the host OS was unmounted and then ran the following commands from terminal:

tune2fs -O ^orphan_file /dev/sda1 (Yours might be different, use lsblk to check)
e2fsck -f /dev/sda1 (Yours might be different, use lsblk to check)

After doing this i was able to take a system image with FOG 1.5.10.15

@Krautkopf said in Batch-File from Snapin is just partially executed:

I think I’ll give it a try with your suggested solution of injecting the drivers with the post install script

In my tutorial I deliver the drivers during the post deployment scripts so the drivers are already on the the computer when it boots for the first time into windows and then after oobe completes I have the pnputil command run from the setupcomplete.cmd. The setupcomplete.cmd batch file is run as part of windows oobe and is executed as SYSTEM user.

Now in your case you have one snapin copy the files over and a second snapin install them. The fog client executes the snapins and the fog client runs as SYSTEM user. So in theory it should work.

Here are some random thoughts on the issue

One thing I do is use the start /wait "" <some_command> (so in this case the command would be start /wait "" pnputil.exe /add-driver “C:\Drivers\*.inf” /subdirs /install >>c:\drivers.bat hint: the 2 double quotes are needed to work around a quirk in the start program) to start a program and then wait for its execution before going on to the next step in the batch file. I’ve ran into situations where a batch file will spawn an application and then not wait before going to the next line in the batch file.

Its strange that you are not getting “anything” from the pnputil program. If you log into this computer and run this batch file does it work?

Is it possible that the path variable is not being used during a fog client snapin install where you need to provide the full path to the pnputil.exe program for it to be called.

Another check you might do in this batch file is verify a key or specific file exists in the drivers directory to confirm that the drivers are installed before this batch file runs, or at least log that it found the drivers.

Why not combine the driver copy and uncompressing with this script to install the pnputil command. By using the start /wait command you can ensure the execution is sequentially.

@abdel The error message indicates that no pxe boot information is making it to the target computer. Please try to pxe boot with a physical computer. For this test you don’t need to do anything other than get to the fog ipxe menu. Make sure when you pxe boot a physical computer you know if its in bios or uefi mode, because the value entered in dhcp option 67 is specific to the pxe booting computer. For bios computers you need undionly.kpxe in option 67 and for uefi computers you will need ipxe.efi in dhcp option 67.

@Tom-Elliott Thank you for your time. I will look at that. With a backup, I may try it just to see. Current vValue in schemaVersion is 259.

Years back, more than 10 years, ( Yes, long time user, Seems like .26 was my first but definitly by .32 ), I had something similar happen and it was obvious what field was corrupt because when it hit that point in the display of the web page we got garbage.

For this case, I do not have my notes at home but one of the records value when displayed in mysql was about 20 pages of stuff. I recall it was one the the paths and should have been 10 to 15 characters. Most of the rows settingValue in the globalSettings table were empty. I was trying to update the FOG_MEMORY_LIMIT in the Web Gui when I had an issue with the save. After a couple of tries it saved the 384 number but the other values were missing.

What I have done is go through each row and replace it with either the older backup value or what I thought it should be. Tonight, I was just correcting the two rows with the IP addresses because of the wrong value discovered with today’s test.

My old backup had the values for MINIG and the new table did not 🙂

Right now production is a concern and time is short. The web GUI is working again. I will need to test tonight’s changes for the IP address. Today’s test the screen was still red but it had the wrong IP address for the tftp and web server and may need to work on the PXE menu. I have some pxe menu options that were not fully moved over to the newer advanced options that are in settingID=74.

As always lesson learned, consistent backups and get the box updated. This is a xen VM and I have another FOG named newFOG but I did not compare values yet or check what version. In the past I would make a copy and upgrade the copy.

@JJ-Fullmer Okay then, i’ll go for that ! For the moment i’m trying to test my fog server without the nas but when everything will be okay i will setup like you said. Thank you for your help !

In replacing net 0 by net4 in “param mac0 ${net0/mac}” Fog is not bugging.
But I don’t find how to inhibit the linking-up of net0, net1, net2 and net3 to directly link-up to net4…

#!ipxe
cpuid --ext 29 && set arch x86_64 || set arch ${buildarch}
params
param mac0 ${net0/mac}
param arch ${arch}
param platform ${platform}
param product ${product}
param manufacturer ${product}
param ipxever ${version}
param filename ${filename}
param sysuuid ${uuid}
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
:bootme
chain