@Roger-Saffle There is nothing you need to do with fog, its your final destination OS that has control of the disk once it is launched.

FOG Image format wise there is no difference between a HDD, SSD, or NVMe drive once fog captures it. Once FOG deploys the image you will not be able to tell the if the source image was from a ssd, hdd, or vmdk file.

As a test deploy the same image to the 3 different disk structures (hdd, ssd, nvme drive). On the hdd you should get 50-90MB/s sequential speed using crystal disk mark. For the ssd you should get 350-520MB/s sequential speeds depending on your sata attached ssd. For the NVMe drive 700-900MB/s sequential transfer rates. All from the same source image.

@george1421 the next time I need to change something in the golden image I will test these scripts. Thank you.

@blainey Replication needs FTP (random ports for the data channel) and HTTP.

After a few days of testing on a local network just using the onboard ethernet port going to a router this is already a heck of a lot easier than the previous imaging solution that I banged my head against for a month. Bare metal is definitely the way to be and I greatly appreciate the insight. I would have torn what remains of my hair out trying to figure out making that work with Virtualbox.

Going from here, trying to get the final set up the way I described in my original post, it sounds like I need to look into the DHCP configuration to move the imaging to the two additional ethernet ports and off eno1, is that correct? Right now I have eno1, enp2s0f0, and enp2s0f1. eno1 will be supplying internet and I presume the other two will be on different gateways reaching out to the switch where the target PC’s will be connected to. Would this be something I can achieve using the built in tools?

@drumnj said in Deploying BIOS Boot Order to multiple computers (booting to network 1st):

You said you return yours to “normal” boot (I take it hd 1st)

What I was referring to here is with Dell and CCTK you can set a flag in the bios that basically says on the next reboot boot to the network. On reboot+1 boot what ever the default boot device is.

So if you wanted to do an unattended imaging but your normal boot device was the hard drive you could push out a FOG snapin that called cctk on next boot-boot to the LAN, then schedule a fog deployment. If the fog client is installed it will reboot the target computer and then start imaging right away.

@Qweeqweg the change from using an account named “fog” to an account named “fogproject” is recent. in spite of directions, people kept creating and using an account named “fog” as their user account when setting up the server.

@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