Sorry everyone I haven’t updated on this post, my organization wanted our fog server migrated to our data center on to a vm so my time was reverted to doing that and building an additional one at one of our new hospitals we recently finished construction on. But I plan to get back to working on it this week on my test server I have set up. Once I have it set up I am going to implement it on our production servers, I think I’m very close to implementing this concept and once I have it cracked I will make sure to share this with everyone because I think the option of being able to do this will be valuable to many others. @george1421 @Wayne-Workman

@Sab First I would have to say both fog server and fog storage node have to be on the same version. The fog storage node doesn’t have its own database, it uses the fog server’s database. There could be schema changes in the database between 1.5.10 and 1.5.9.

Unless you change the storage group around, its not possible to capture to a storage node (in the default configuration). Only the master node in a storage group captures the image, then it replicates the captured image to all storage nodes. Both the master node and storage node can deploy images.

If I had to guess, I would think that in the storage group the nas fog server is not defined as the master node. If I think I understand what you did to configure this setup.

On the fog error screen it should print out the kernel parameters sent to the FOS imaging engine. There should be a filed marked storage or storage_ip, that will point to the fog server it will try to get the image from. Make sure that is correct for your configuration.

@Tom-Elliott

Ok thanks

@HorizonG
Solution :
I deleted all my groups and renamed them.
I think there’s still a bug in the DATABASE

Hello again,

After some tests its appears that le pc join the domain if somebody was logged before ( and the dot red became a green windows logo). Is there a solution to do the same thing without a first loging ?

@DBCountMan In the post init or post install scripts the $mac variable contains the mac address of the target computer

To get the ip address this script will work

myip=`ip route get 8.8.8.8 | awk 'NR==1 {print $NF}' | cut -d "." -f1-2`;

Getting the user id of who did it will be a bit harder since they never log into the web ui. The user ID and password they key in during the deploy image stays in ipxe and is not sent onto FOS Linux. I’d like to say that the username field can be trapped from iPXE and then pass that variable as a kernel parameter onto fos linux. Once that is done then the $username variable should exist in your fog scripts. Getting that info into the fog database is another challenge. In the post install script the /ntfs directory is mapped over to the fog servers /images/dev where you could append an echo statement into a text file.

Understand I’m taking in programming pseudo code. But I see an path here and it should work.

@TimBr Did you migrate this from an older server?

The getPrimaryGroup/getStorageGroup’s are the indicator of the problem here.

Basically, you would likely see the same type of problem if you were to goto snapins:

Effectively the issue is the Image (in this instance) is associated to a StorageGroup that simply doesn’t exist or that storage group has no storage nodes associated to it.

Biggest thing I found from this for future searches of answers…

F*CK UEFI. Legacy FTW.

@alexamore90 said in Snapin question:

@Tom-Elliott
yes sure, I would be interested in running a batch file after the fog has restarted because the deployment on the client has finished. I think I can’t use the snapin because of the host registration that we don’t do. but is the postinit done with fog?

You still haven’t answered the question.

I already stated that postinit scripts run in FOS (fog adjacent if you will) but you haven’t answered the question of “where or when” you’re expecting the script to run.

Please provide details of what you’re doing, when you’re expecting things to happen (explicitly as possible) and we can try to give guidance and direction.

Otherwise we’re talking in circles.

@tomierna Glad I could help and glad your issue is fixed.

@george1421 now I see the files, but I’m still getting an exec format error. the file command says the bzi is a linux kernel x86 boot executable bzimage

@sega I don’t know enough to answer your question intelligently.

I can tell you that for multicast imaging FOG uses the linux commands udpsend and udpreceive.

I don’t see any command line switches to pick which igmp mode is being used.
https://users.soe.ucsc.edu/~kent/test/udpcast.html

I can say its rare that there is ever a question on the revision of igmp being used.

@rogalskij so it seems your “ipaddress” is defined as your fqdn either on the IP address for the storage node directly.

I don’t know what your storage node settings look like but should be looked at likely from:

Storage Node-> DefaultMember

HOpefully that will help.

Normally if you can dereference the DNS name all would be fine so I’m just not sure where to help out.

But at least you know what is happening now?

Thank you for letting us know.

Just replying to this with some updated information after my latest upgrade to Ubuntu 20.04 so I don’t forget on the next upgrade. I couldn’t get the fog installer to work without the -X option but figured out what the issue was. I needed to edit the /etc/pam.d/common-password file and change the following line to 10000 instead of 1000.

password [success=3 default=ignore] pam_krb5.so minimum_uid=1000

This was because the fogproject user was more than 1000, so changing it to 10000 let the installer work without needing the -X option and the password was updated properly. I then switched it back to 1000 so kerberos would work with my AD accounts.

@george1421

I installed fully new OS on a PC.

I get a new error message.
20240821_114507.jpg