@george1421 This is correct. It works fine. Thanks,

@kbats183 I haven’t looked at the quick registration bit of code but I did have a hack that updated the fog.auto.reg (full registration) option to begin imaging right after registration without a reboot. This involved taking the FOG supplied script updating it to your requirements and then adding a bit of code onto the end and then finally dynamically patching that script on every boot of the target system. It sounds like a lot of steps and its complicated but not if you know how fog works.

I should be able to point you in a direction so you can get started.

When FOG Linux (the os that gets transferred to the target computer for imaging) boots it runs the master fog script stored in the /bin directory in FOS Linux. The scripts bits of that /bin directory is here: https://github.com/FOGProject/fos/tree/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin The file you are interested in is called fog.auto.reg. If you can understand bash script programming you can modify this file to fit your requirements. Once you have the script the way you need it then you can dynamically patch when FOS linux boots using this tutorial (understand this tutorial is for patching fog.man.reg but the concenpt is the same only the file name changes.

https://forums.fogproject.org/topic/13500/dynamically-patching-fos-using-a-postinit-script

I have tutorials that are targeting the manual registration but the concepts are similar. (hint: this is where I tweak the script to give me a custom calculated host name kind of like the auto naming but better. )
https://forums.fogproject.org/topic/14278/creating-custom-hostname-default-for-fog-man-reg

So that’s the background, how do I make it image right after rebooting?
For the fog.man.reg file you append a bit of code that makes the script think the system rebooted and collects the latest imaging info.
(For the life of me I can’t find that tutorial I created but here is the script that I collected from a recent issue with the code in the script.

sysuuid=$(dmidecode -s system-uuid) sysuuid=${sysuuid,,}switch mac=$(getMACAddresses) 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 '' curl -Lks -o /tmp/hinfo.txt --data "sysuuid=${sysuuid}&mac=$mac" "${web}service/hostinfo.php" -A '' [[ -f /tmp/hinfo.txt ]] && . /tmp/hinfo.txt . /bin/fog.download

In the case of fog.man.reg this code would be added at the very end of the script.

Looking at the fog.auto.reg script I would say it should go at the very end of that script too.

ref: https://forums.fogproject.org/topic/17601/deploy-image-right-after-registration-without-a-reboot/3
ref: https://forums.fogproject.org/topic/16378/start-imaging-right-after-the-full-host-registration-without-reboot-possible

@Cristian Any chance you are sending the image out to new/different machines than before? We have just received some new machines into our fleet (Lenovo neo 50q Gen 4), and we are seeing something similar…we get 14GB/min on the older machines, but these new machines are at about 2GB/min. I started a thread on that here:

https://forums.fogproject.org/topic/17698/fog-very-slow-to-deploy-image-lenovo-neo-50q-gen-4/2

Not sure if yours is for the same or similar reasons, but if it is, it might help to know if they are the same machines as we just got.

Thanks!

@fabritrento I’ll be honest, I have no idea what you’re saying is isn’t happening here?

@Tom-Elliott

Yep, that certainly worked. We were avoiding that just so we did not lose all of the location associations that the hosts already had, but if this solves the issue, we will plow through it.

Thanks for the info! This took care of the issue.

@Bhav In addition to what Tom posted, the server response timeout is suspicious too. IF the target computer is in uefi mode and it downloaded undionly.kpxe the target computer should have responded with something about undionly.kpxe is not the right format. But in this case its getting a server response timeout. This makes me think two things. 1) your dhcp opition 66 is set incorrectly or the name of the file has a capitalization issue. For linux Undionly.kpxe and undionly.kpxe are not the same thing. Either way I would start with your dhcp server and make sure dhcp options 66 and 67 are set correctly for a uefi based computer.

@JJ-Fullmer I would mark this one as solved. I didn’t see a way for me to do it. Thanks, again

@Tom-Elliott Even that’s too much for them. They don’t want that NFS is sharing with nobody but without it, it’s impossible to run it I guess unless perhaps using the Samba protocol. Tried to install the latest version of Fog today but got stuk during install.

@fabritrento yes, you can interchange them though sometimes (not the case here) the biggest concern is schema updates between different versions.

In this case, dev-branch is the basis of stable, so these should be effectively interchangable.

@Tom-Elliott All good with 1.5.10.1629

Thanks

@Tom-Elliott latest pull working correctly again. Thanks for sorting!

/etc/pam.d/vsftpd looks fine

#%PAM-1.0 session optional pam_keyinit.so force revoke auth required pam_listfile.so item=user sense=deny file=/etc/vsftpd/ftpusers onerr=succeed auth required pam_shells.so auth include password-auth account include password-auth session required pam_loginuid.so session include password-auth

ftpusers file:

# Users that are not allowed to login via ftp root bin daemon adm lp sync shutdown halt mail news uucp operator games nobody

Great. bzImage 6.1.89 fixed it. Will test newer ones to see where it breaks.

@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

Hello, some one can help me ? 😞

@Tom-Elliott woo not sure how i managed to miss that but its working as described. Thanks.

I believe I have a viable migration process to get FOG services moved from set of servers to another set. This process takes into account Locations, Storage Groups, existing Hosts, etc. The system I’m migrating has 7 remote sites so that’s 8 locations and 8 servers - one FOG server and 7 FOG Storage Nodes, each at the end of a Static VPN WAN. The initial FOG server is an alias ‘fogserver’ in DNS and DHCP is served out by MS Domain Controllers at each site. Each Storage node serves out all that is needed for each remote location (PXE, initrd, snapins, and images). Each storage node is the master of its own storage group. We do replication manually, so there may be some snapin and image replication issues in this process that I can’t account for.

The process requires being able to harvest the digital identity of the initial FOG server for use on the replacement FOG server, so the replacement server needs the same name and IP address. This is necessary to allow existing hosts to be easily ‘acquired’ by the new system since the Hosts. I pursued a side-by-side migration that worked fine PXE booting->host registration->imaging, but failed for existing Hosts and, for unknown reasons, even new Hosts failed all software distribution steps. The idea of placing FOG required scripts in group policies wasn’t appealing for my purposes since we need the FOGService to work without the machine joining a domain.

I’m currently testing and will have a process “doc” soon. I’m interested in posting this process for FOG Project’s use if the powers that be find it useful.

I’ll post it here when it’s completed.

It seems to me that the need to change Linux distros is an age-old requirement as various Linux OSs have been dropped or usurped. Migration of FOG from CEntOS to any other Debian Linux should be well documented.

More soon.

Jim Graczyk