@Sebastian-Roth Alright, good to know for the future. Since I didn’t have a clear fix, I blew up the VM and am starting from scratch. There were only two images anyway.

Thank you @george1421 for giving me such a complete answer. My greatest concern was looking as if I had attempted something like a cold boot attack, but if something onboard such as IME is going to show logs then I really wouldn’t bother. It’s not worth finding out if they care to distinguish, so thanks for your advice.

In regards to potentially angering people like yourself, I’m grateful you were still fair to me! I didn’t take any steps that were contrary to IT’s mandate, we are after all a team. Maybe they will approve the request. 🙂

FOG was a means to satisfy a curiosity (NDI) but will prove to be much more useful and fun with my own half-broken Desktops. Have a good one!

@dongtuuyenblackpeony Sounds very strange because the iPXE menu/task execution simply is selected via the MAC address of the client machine. That should be no different whichever state the machine is in. For example, you could even wipe the whole disk or install Linux on the drive and it should still behave same on the PXE boot!

Sorry, don’t want to sound rude but have you used FOG to capture/deploy images before? Just want to make sure you know the process.

I didn’t update kernel. it still working for me.

Thanks,

@pdit So it’s probably something that changed in the Linux kernel that is causing this issue. I’d like to track this down but I don’t think I’ll find the time to do so in the next months.

You should be able to switch between different kernels to see which version first had the issue. Find all the different kernel versions in the FOG web UI or here: https://fogproject.org/kernels/

@Sebastian-Roth
yes, i want to say that i correct it in the post

@CpServiceSPb I would second Sebastian’s recommendation about setting up fog on a disposable VM. Look at the configurations as well as the install logs to see what packages are loaded during the fog installation.

Fog creates its own apache configuration files so it should not step on anything existing. There are some url rewriting rules that you will need to work around.

As for the tftp server, FOG only “requires” one running to server out the pxe boot files. It doesn’t care (in the end) what tftp server is running.

Fog also uses phpfpm with its 1.5.x release to respond to php requests.

I’m not sure of you end goal here, are you attempting to hack fog into doing something other than imaging (which is OK since its opensource)? Or are you trying to install FOG along side these other apps. If its along side, then you might want to consider using a docker container to isolate fog from the other systems. I don’t know about docker but there were some tutorial on this forum on how to setup fog in a docker container.

@Tom-Elliott Thank you.

Yes, it’s fixed now. Thank you.

@AndrewG78 said:

There are several identical broadcast responses.

Can’t explain that without having a full wireshark/tcpdump pcap file. Way too much information is missing to be able to get a glimpse on why this might happen

There is tftpd error - Error code 8: User aborted the transfer

It’s kind of a known thing. Before loading the boot file via TFTP the client requests the file size (via RRQ query command). The server answers the size query and for some weird reason the client sends back a “User aborted the transfer” and then sends a new request to actually download the file.

As time goes, time to time i turn back to my previous things for refreshing memories, getting new ideas, whatever. So it happened to this topic.

I am again thinking about fully offline cases. We here discussed that zstd compression is not compatible with clonezilla so i have to recapture image to use tools like clonezilla which uses same image taking tool. But… as now i have read, clonezilla now capable using zstd compression (er… whatever it means exactly btw).

Let me ask if it is still true or not to use already taken images (by for) deploy from a live clonezilla-like tool without recapturing? Anyone tested maybe?

@Almeida
@Sebastian-Roth

this is a simply example, security is by your side:

#!/bin/bash SERVER=$1 USERNAME=$2 PASSWORD=$3 FILE=$4 USER_TO_LAST=$5 echo "Result from last $USER_TO_LAST" &> $FILE last $USER_TO_LAST &>> $FILE lftp -u $USERNAME,$PASSWORD $SERVER << EOF put $FILE EOF

Configure as on image:
Snapin template is bash.
example.png

Tested on Linux Mint 19.

@george1421 Thank you for the response. The issue was the switch. I put a “dummy” switch in place of my other one and it worked. I ended up enabling fastport on my other switch and success. Appreciate the help!

@MediumToast i thought this might interest you https://forums.fogproject.org/post/123288

Resolve this please.

@loosus456 What OS is your FOG server running?
You will also need to be able to configure your network switch to support LACP (802.3ad) LAG.

No we do not have any requirement. we just want computers to work as normal with our modified image.

Thank you for quick response. Please mark this as answered.

@virtualdxs You can actually give it a try already! Would be great if you’d join in as tester to help us bring it forward.

git clone https://github.com/FOGProject/fogproject/ cd fogproject git checkout working-1.6 cd bin ./installfog.sh

@Sebastian-Roth Hello, yes I have setup 3 servers with fog running and I was successful in capturing the image and deploying it to 18 computers at the same time. I did look at FOG API, but I had questions about it like does is it run on bash or other script but later figure that it runs on bash.

@Sebastian-Roth Thanks!