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 ?

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

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

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

Update to fog 1.6 fixed problem

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

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

@Tom-Elliott

No worries, all the help is appriciated!

199cd3f7-9311-4f08-80df-dd932845af2d-image.png

a6b999ce-4c5b-4462-9181-3746b2972f8a-image.png
a900cb0f-9abb-41fa-84b8-cef64c317cc6-image.png

6d685e25-ca2f-4c18-8a27-add58d1470e0-image.png

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

@45lightrain said in Issues with capturing an image with a raid0 array.:

Also is fog able to capture both the OS SSD data and raid array data on the NVMe drives?

FOG captures disks in block mode. It doesn’t care about partitions (mostly). Also make sure that md0 is the true device for these drives. When you are in the FOS linux shell you can / should create a mount point and then mount /dev/mdX partition to see if you can read the content. I have seen where sometimes md0 is created but the real raid array is /dev/md126.

Also FOG calls a script before imaging starts. Sometimes its needed to assemble the array in this postinit script. Or do other things to prep the system for imaging. So the postinit script (found in the /images directory on the fog server) is a the place to put that code.

Also when you start in debug mode (when debugging the imaging process) you can actually start the imaging process from the command line by keying in fog. The imaging will stop at each debugPause; command in the imaging code as a breakpoint. If you notice something wrong, you can hit ctrl-C to exit back to the command prompt. To restart the imaging process again just rekey in fog.

While it doesn’t exactly apply here I wrote an article 8 years ago about imaging using the intel rst adapter that may contain a nugget of help: https://forums.fogproject.org/topic/7882/capture-deploy-to-target-computers-using-intel-rapid-storage-onboard-raid

@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

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

F*CK UEFI. Legacy FTW.

@kalmarteve How did you delete the old FOG? It looks like the web server folder still exists and the database probably still exists.

This wiki article outlines a method for fully removing FOG if you’re looking for a fresh install.

https://wiki.fogproject.org/wiki/index.php/Uninstall_FOG

If you have a backup you can restore too, you should also be able to just do an in-place upgrade.

@george1421

I installed fully new OS on a PC.

I get a new error message.
20240821_114507.jpg

@kalmarteve so you’re running 1.5.9

the “master” branch is on 1.5.10

While the 2 files may not have been changed, you should really install the latest version if you’re going to try to implant files from newer version on your fog server.

That said, since it doesn’t seem broken (from a usability) standpoint, i’m not sure what question you’re asking.

I don’t know how to fix the problem if you haven’t tried the suggestions.

For example “This number of slots available” is based on the Storage node.

This is configured from the UI.

I don’t know what you did or didn’t do and can’t really provide much more direction than make sure the node that is in use (since you’re not providing IPs I cannot really give any more information).

@berenyia

What switch, and what network card? I’ve been seeing a similar issue, I’m working on a theory as to what is happening. I’m not currently at work so I can’t be sure yet on my replies to those questions but I’ll let you know

@Tom-Elliott me neither!

I have run a search on the server (Debian 11) and it appears I do not have one at all?

@AUTH-IT-Center Should be addressed in the latest.

I found a couple of other posts saying to upgrade to the latest version. I have done that and it’s solved.