@lmioperations As @quazz stated, the only thing the “updater script” does different from the installfog.sh from a repository is download the data, extract it, cd into it, and run the installfog.sh

FOG automatically updates itself if it’s already been installed. Nothing will be “blown away”

Let’s go the simplest method.

Edit one of your batch scripts.

At the start have it do something like:

echo "Snapin BLAH BLAH beginning installation" > %systemdrive%\fog_snapin_install_snapinname.log

At the end, also have it run:

echo "Snapin BLAH BLAH ending installation" > %systemdrive%\fog_snapin_install_snapinname.log

Try deploying the snapin that fails. When it shows as complete, look on that system to see if the log file was generated and has what you expect.

This is already known and fixed in working branch.

Imma going to guess the problem is mroe difficult than just error logs. Imma going to guess you installed Capone AFTER installing capone after getting up to 1.4.4? Please try:

wget -O /var/www/fog/lib/fog/plugin.class.php https://raw.githubusercontent.com/FOGProject/fogproject/6717f382177e714c1bd22eb11627133cfd4e0ebe/packages/web/lib/fog/plugin.class.php

Uninstall capone and reinstall it. Your database should exist and you should be able to make the proper associations finally.

Logged in and remoted.

Found the problem was the mysql password had changed. Set the password properly and configured so future upgrade shouldn’t have any issues.

I don’t know what the script looks like, but it’s fully possible there’s another problem causing the script not to write to the file as you’re intending, for example it doesn’t make it to the point where you have the log file being written?

Typically I like to do a script in lines of:

1. Define the variables.
2. Write to log stating we’re about to start the work.
3. Do the work, redirecting output from the running command to go into the log (both errors and standard)
4. Write to log state we’re complete with doing the work.
5. End the script as needed.

I’d have to see the script to help you a little more, but I don’t think FOG is failing to run the script (as this isn’t what we typically see when people post such threads.) Rather the script IS running, but the expected actions aren’t done in the manner that the Client expects them to be done, such as something waiting for user interaction.

So the problem you’re seeing is due to how Ubuntu deals with named virtual hosts. I’m going on a limb and guessing you’re accessing the fog server via dnsname of the fog server? What if you change the dnsname to ip? The fog config for Apache doesn’t add in named hosts by dns name, by default. It does it based on the ip. Because the servername element of the config is the ip, that config isn’t running for the dns called name. The default site is the trying to route it, which is not configured to rewrite the request to the API.

@Sebastian-Roth should already be allowed again in rc 4

@Frode-Woldsund Or you could set a mysql password and just use it… This particular issue only occurs on DB’s that have no password defined. I don’t like that ubuntu keeps forcing the code after the user has defined it, but this should not be the case if the password is already set.

Can you try:

UPDATE `users` SET `uPass` = MD5('password') WHERE `uName` = 'fog';

I know you’re using 1.3 or higher, but the MD5 mechanism should work as well.

WOuld you mind looking over: https://wiki.fogproject.org/wiki/index.php?title=ProxyDHCP_with_dnsmasq? The article you referenced is for legacy FOG, which with the right changes can still work. This article is newer and more applicable to more modern versions of fog.

Update, we’re up to 1.4.4. I think, however, the plugin issue was addressed in the RC’s (maybe? I forget now).

@crbarahona Is the OS configured as a Legacy (MBR) style image or is it configured as a UEFI style image? It, at least seems, to me to be Legacy style windows image as you are using the SANBOOT/GRUB_FIRST_HDD to work on both 1604 and 1703, but it almost sounds like 1703 is forcing some form of UEFI stack to the disk. (Maybe 1703 is changing the disk to a “dynamic” disk changing how the disk is partitioned without losing the data.) – (Doubt it as changing to GRUB works okay – then again GRUB is a proper bootloader and might not be hitting the constraints the bios is handing out as iPXE could be).

I really don’t want to think this is an iPXE issue considering the iPXE code did not change one bit. If it were an iPXE specific issue, the problem should be present on the same system regardless of what OS you deploy/use on it. The only variable that’s changed here is the OS on the client machine so it must be something that OS is doing.

The next question is more direct, I think.

If you deploy the 1604 image to a machine, boot into Windows, then deploy the 1703 image to the machine is this issue immediate? (When the machine reboots after the post deploy does it boot into windows or is it immediately broken?)

If it boots into windows 1703 and then fails on any subsequent reboots I would think there’s something Windows is doing regarding firmware which could be causing the problem. (It could even be something like the firmware to the NIC changing how iPXE is passing to SANBOOT, meaning iPXE might be able to do something to check and fix this.)

If it doesn’t boot immediately following deployment, then I believe the issue is how the disk is “laid” out.

I know there’s a lot of information here, just trying to get a full picture.

Now that I understand the full scope of the problem, I more clearly was able to take and fix this issue. Login should’ve worked for any page but it was loading page specific js code even when no user was logged in. I have since corrected this in working branch.

Is this “new vm in hyper-v” setup as Generation 2? Is it defined to boot in UEFI mode?

Have you tried rEFInd?

@andrewg78 I don’t think you need the --data '{"taskTypeID": 8}' though it shouldn’t really matter. Is there any return output from the command losing teh --silent component should show you what’s going on more directly.

Something like:

curl -vvv -H 'Content-Type: application/json' -H 'fog-api-token: <my_token>' -H 'fog-user-token: <my_token>' http://<IP>/fog/group/3/task -X POST --data '{"taskTypeID": 8}'

@andrewg78 Why don’t you try what I suggested?

curl -vvv -H 'Content-Type: application/json' -H 'fog-api-token: <my_token>' -H 'fog-user-token: <my_token>' http://<IP>/fog/group/3/task -X POST --data '{"taskTypeID": 8}'

Your posting here:
http:////fog//maintenance/backup_db.php: Invalid host name.

Notice how there’s no hostname?

You should have an ipaddress in your /opt/fog/.fogsettings file. Is this defined for your machine?

x23 remoted in and helped fix a couple minor things in regards to menu.

Talked with OP and found that the 7050 giving issues was not the case for ALL 7050’s. He pulled a different out and all seemed to work fine.