fog.postinit not executing fog.reg.man.fix

[lucycle]

@Tom-Elliott Yes. Out of frustration I even copied over the init.xz files from the old server to the new one. I didn’t expect it to work and it didn’t.

The only thing I can think of is the two fog users don’t have matching passwords (this was an issue for other hiccups along the way as I migrated) and the fog user ownership of fog.postinit only looks correct because it came from a system with an identically named user but is actually wrong because the old server’s fog account had a different password?

BTW, after database and image migration the old server’s fog password hash needed to be copypasted into .fogdefaults and installer re-ran for everything else to run smoothly.

This is why my thoughts went to permissions and/or mismatched users in the first place.

I might just be misunderstanding how it all works in regards to fog.postinit however.

BTW, have not had a chance to try chowning the file to the new fog user as I am not able to test it tonight.

[Tom Elliott]

@lucycle The password for the linux fog users is not what’s preventing the fog.postinit file to run.

An option that may work better, then, would be to run a task in debug mode.

As this issue is happening on registration (fog.man.reg.fix I’m guessing), you’ll want to add:

isdebug=1 to the FOG_KERNEL_ARGS found in FOG Configuration->FOG Settings.

Then try to register a host.

This will drop your machine (or any that will be booted after this is defined) to startup in debug mode.

Press Enter key twice and you will be at a shell where you can type commands. From here, type the command fog and press Enter. As fog.postinit is one of the first things to run, I imagine we’ll see an error here. Can you get a picture of the error? Or at the least, what you see during this phase?

[lucycle]

@Tom-Elliott Ok these are images from debug mode on a host:

and

It’s not very descriptive but I’m searching through the forums now to see if something similar has been posted about already.

[Tom Elliott]

@lucycle now 10.1.10.2 is your new server up address?

The error is expected at the end there.

[lucycle]

@Tom-Elliott yes 10.1.10.2 is the new server’s ip.

I’ve also tried moving the contents of fog.postinit to a dedicated patch.reg script, set to 755, and called from fog.postinit as mentioned in another post detailing this and the fog.postinit instructions themselves with no success:

#!/bin/bash
 . ${postinitpath}patch.reg

Updated the kernel too. No joy.

Also , while in debug mode on the client , I attempted to echo ${postinitpath} and it returned a blank line.

[Sebastian Roth]

@lucycle I’ll stick to this thread as we have all the information here.

To me it files like there is some typo somewhere in the scripts or calls that prevents this from happening. But I am not sure yet. Have you double checked all the file names, permissions and so on?

[lucycle]

Yes all permissions and files are identical. They were copied over from the functioning instance of the deployment server. The “new” server is just different in RAM size and storage capacity. Other than that both are identical.

contents of /images/dev/postinitscripts on server where fog.reg.man.fix works

-rwxr-xr-x 1 deploy deploy 10480 Apr  7 16:06 fog.man.reg.cust
-rwxrwxrwx 1 fog    root     379 Apr  2 17:49 fog.postinit

contents of /images/dev/postinitscripts on server where fog.reg.man.fix does not work

-rwxr-xr-x 1 deploy deploy 10480 Jul  1 19:21 fog.man.reg.cust
-rwxrwxrwx 1 fog    root     379 Jul  1 19:21 fog.postinit

The “fog.man.reg.fix” naming convention has obviously been changed on my side but it seems inconsequential as to what i name it if I call it properly from fog.postinit and the fact that it works on one server and not the other.

Thanks

[Tom Elliott]

If the file is now called fog.man.reg.cust, and the postinit script is looking to copy over fog.man.reg.fix, it would seem it really is a typo. As we still haven’t seen the contents of the new servers postinit script, I’m still having to lean towards a typo just as much as Sebastian is.

[lucycle]

My mistake for not posting it:
Old server fog.postinit:

#!/bin/bash
## This file serves as a starting point to call your custom pre-imaging/post init loading scripts.
## <SCRIPTNAME> should be changed to the script you're planning to use.
## Syntax of post init scripts are
#. ${postinitpath}<SCRIPTNAME>
echo "Installing Patch"
debugPause

cp -f ${postinitpath}fog.man.reg.cust /bin/fog.man.reg

echo "Done Patching stuff"
debugPause

New Server fog.postinit:

#!/bin/bash
## This file serves as a starting point to call your custom pre-imaging/post init loading scripts.
## <SCRIPTNAME> should be changed to the script you're planning to use.
## Syntax of post init scripts are
#. ${postinitpath}<SCRIPTNAME>
echo "Installing Patch"
debugPause

cp -f ${postinitpath}fog.man.reg.cust /bin/fog.man.reg

echo "Done Patching stuff"
debugPause

I have been known to typo in the past and wish it was a typo at this point!

Also, excuse the naming inconsistencies of files between posts. It’s due to me trying anything and everything I could.

[george1421]

@lucycle There is a few comments I can make here.

1. The thing we don’t know is if ${postinitpath} ends in a / or not. If it doesn’t then the path and file name will be in error. You might want to insert a / in the cp path to make cp -f ${postinitpath}/fog.man.reg.cust /bin/fog.man.reg
2. The next thing you can try is schedule a deploy/capture I don’t care, but select the debug checkbox before scheduling the task. Then pxe boot the target computer. If you are dropped to a linux command prompt key in fog at the linux command prompt and press enter. When you see the text “Installing Patch”, hit Ctrl-C. This will drop you back to the linux command prompt but with the exact environment where the copy command needs to execute. First start with this linux command set |grep postinitpath That should point to the location where the fog.man.reg.cust exists. Confirm that file exists in the noted directory. Also check to see if /bin/fog/man.reg exists. Then finally execute the entire command as it appears in the postinit script. cp -f ${postinitpath}fog.man.reg.cust /bin/fog.man.reg

Somewhere in test #2 the commands should fail. If you never see the “Installing Patch” text then your postinit script is never executing, then we should focus there.

[lucycle]

@george1421 thanks for the reply!

After following your instructions I noticed that there is no “Installing Patch” text on the new server that is not behaving.
Also, /bin/fog.man.reg exists on both servers.

So I decided to follow the rest of your instructions on the old server that behaves as it should just to see what kind of results I should be getting. The results from following your post on the OLD server were as follows:

After getting to the command prompt I keyed in fog and hit Ctrl+C once i saw “* Running post init scripts … Installing Patch”. However, when I was returned to the command prompt and keyed in set |grep postinitpath nothing was returned and I was returned to the command prompt. I did grep for other words/variables that appear after keying in set by itself, just to make sure everything was functional, and set |grep type returned type=down as expected.

As for the NEW server, “Installing Patch” did not appear at all, just “* Running post init scripts … Done” . I did press Ctrl+C after this to see what set |grep postinitpath would return and it too output nothing and returned me to the command prompt. Keying in set |grep type for testing purposes returned type=down.

I also executed the fog command multiple times so that i could stopping the procedure at different debug steps to check set |grep postinitpath on both the OLD and NEW server and it never returned the location of the fog.man.reg.cust file.

Please let me know what you think.