@Fog_Newb Oh those are random, I thought you were talking about the /images/dev/{mac} that is used when capturing.

So /images and /images/dev are 2 nfs shares on your FOG server. You’ll see this defined in /etc/exports

If you aren’t able to manually move the file on the FOG server from /images/dev to /images then there’s some other weird permissions issue on the server.

When you are capturing an image though, the host boots to FOS, and part of the capture process is mounting the 2 NFS shares from the FOG server, /images and /images/dev. The capture process has partclone writing the captured image files to /images/dev/{mac}/*
Once complete, it moves them over to /images (technically it deletes the old version if any in /images and then moves the new version into its place).
I don’t recall if in the stable/dev branch if we are using sftp yet, so it may be doing ftp (1.6 for sure uses sftp). Point being it does technically remote into the server to do the move operation because the /images nfs share is a read only share.
When you have nfs shares mounted in the same folder that are actually on different disks, I’ve seen weirdness like you’re experiencing is what I’m saying.

So all of that is to say

Try moving/copying a file from /images/dev to /images on the server directly, confirm that works. Try booting into a debug capture session, capture the image (use the command fog and hit enter to step through. Capture any errors.

Technically if you’ve captured the image, you can manually move it on the server to the /images/{imageName} folder and you should be able to deploy as a workaround while we figure this out.

You could also try installing 1.6-beta.

@ccatcc Is this a new fog install or has it been in service for a while?

Will you verify that in this path on the fog server bzImage file exists? /var/www/html/fog/service/ipxe make sure bzImage is in that location.

@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

@shatchett0 So it is working now on the new install?

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 ?

@JamiesonCA092 typo in this column the command was storage=fogstorage01.gmh.org/images

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