@plyons7890 The error message about an unclean file system is typically related to the source computer not being powered off correctly and files are still marked open.

If the source computer is a ms windows computer I can understand this error. You must not use the standard “shutdown” command because it is not really a shutdown/power off command but more of an advanced sleep command, leaving files open.

You can/should do the following

Let sysprep power off the computer before cloning with FOG. Turn off fast startup in windows, this will switch shutdown into its traditional shutdown mode. Use the windows shutdown command shutdown -s -t 0 command to power off the computer before cloning.

@george1421 Okay, then to make it easier, I’ll just use UEFI boot to avoid any problems. Thanks!

@george1421 NBP is almost always the “label” of UEFI, but you’re describing PXEv4 MAC?

Similarly, hte 0.0.0.0 seems to indicate that there’s no IP address on the machine in question. Maybe there’s no DHCP server.

Without an image or more detail, we’re not sure how to help as @george1421 as suggested.

@switch_apoc You’re not an idiot. And yes, simply rerunning the installer would have been my first suggestion so glad you got it all working 🙂

@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.

Found it in the client, settings.json, changed https = 1. Did not correct the issue, but it did cause the client to look at https://…

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.

@rodluz After disabling VT and X2APIC Intel x2APIC Mode disabling these settings and the system properly deploying an image what setting in the kernel would need to change to allow for the system to deploy properly without having to modify the BIOS settings? I think this may be easier said then done but want to start looking at it.

@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