@sideone Please run an update, I just released what I believe should fix this problem.

The reason you’re seeing that in the browser is the url is expecting a mac address being sent in. #!im == “Invalid MAC”

@Robert Can you post examples of the errors you’re seeing?

ftp is one thing, which uses the fogproject user, though this was migrated from a user named “fog” in the past. So I think this is what you’re referencing but there’s also password syncing that may need to happen, but to try to provide more direct and helpful information, examples would be awesome.

Thanks!

@Greg-Plamondon I forget what version of fog you’re running but I suspect (and had just forgotten initially, apologies) that you need to get the token:

Process for that is as such:
Would be to change:

curl -A "" -Lkso /tmp/hinfo.sh "${web}/service/hostinfo.php?mac=$mac"

To:

    base64mac=$(echo $mac | base64)
    token=$(curl -Lks --data "mac=$base64mac" "${web}status/hostgetkey.php")
    curl -A "" -Lkso /tmp/hinfo.sh --data "sysuuid=${sysuuid}&mac=$mac&hosttoken=${token}" "${web}service/hostinfo.php"

Hopefully this helps?

@Robert FOG 1.5.10 was not written when Debian 13 was built. Stable branch hasn’t updated for the month of September but this fix is in the dev-branch.

Please, for now, switch to the dev-branch and install where this should be resolved.

@Greg-Plamondon Are you sure the machien that’s loading has an other1 tag defined to it?

Looking at the php that returns the export variables, other1 maps to $othertag and other2 maps to $othertag1

@Greg-Plamondon Are you willing to run a debug mode and echo what’s coming out of $othertag? just to ensure that’s being set accordingly? This won’t fix the issue, but will let us know that it’s being pulled in correctly.

@plegrand I’m not sure i understand what you’re saying here.

If you installed Stable branch and it completed successfully you should be on 1.5.10.1673, not 1.5.10

Did it complete successfully?

@plegrand Something on your network is not allowing the file to download.

Can you try the curl you see it erroring out and see what you see?

@plegrand

It seems like maybe you’re behind a proxy? or something, I don’t know. If this were broken in general, i’m certain we’d have known about it by now.

@plegrand IT seems to me you manually edited yoru lib/common/functions.sh

So you need to stash the changes or revert those changes.

This can be done in many different ways, usually the simplest method being:
git checkout lib/common/functions.sh but this would only fix this one file, if you’ve any others you changed manually, then you may need to do any/all of those files.

The stash method is another simple way to move all custom changes out of the way:

git stash then the steps.

I don’t know what changes you were making so this is entirely up to you on what steps you’re willing to part with. Have a backup handy of your installation directory just in case.

@plegrand

cd /path/to/fog-project/installer/folder
git checkout stable
git pull
cd bin
./installfog.sh

That should be all that’s necessary. The stable can then be changed to master for 1.5.10 official release, and dev-branch for whatever the bleeding edge of FOG is based on the 1.5.10 branches. and working-1.6 to see the beta version.

@plegrand 1.5.10 is very old, run on stable branch or working-1.6 you will be fine.

@AngryITGuy The iPXE file likely needs the boot shim or whatever to allow things to work correctly and with upgrades this isnt’ really feasible as every newly built ipxe file (snp.efi, snponly.efi, etc…) would need that shim configured and installed in place.

It’s possible there was a step in the original installer from your collegue that may have moved the ipxe files from a backup where these were shimmed appropriately?

I don’t know exactly just spitballing.

Ultimately, yes, I’m glad you got this working by disabling secure boot.

Technically, it’s possible to do this with secure boot, but not in an easily scalable way that we can include as part of the install script. Nor, in reality, do I think we want to do such a thing. While it’d be nice to do it as an installer, I am hoping we can get a document that more clearly details what steps to do. This is mainly due to the constantly changing nature of fog, so if we have an easily repeatable knowledgebase on what steps to do in a well documented sort of way, it’d be a lot better than trying to have us maintain some installer that could easily have some issue on a new iteration and continually have to maintain yet more blocks of potentially os dependent code.

@darbizzle The /images/dev/<mac> is the image, so as long as you are certain that’s the one it should be, you can move it from /images/dev to /images as the image path name as defined, likely /images/PDMDTRuggedWIN11DB9-2-25

I think that’s a good starting point, I was just pointing out (due to having not seen the ‘image store error message in plain print - if i’m being a slight bit honest’, but the update to 1.5.9.114 vs 1.5.10.1673 is odd to me. 1.5.9 is very very old. Updating to the latest may not have fixed the problem, but it’s always better to at least be up to date so what we’re seeing is all in line.

@darbizzle Why did you update to 1.5.9.114? We’re at 1.5.10.1673 on the stable branch

That said, I don’t think this is that, as it’s failing to actually prepare the partition.

I suspect its because the init you’re using is MUCH newer than the version of FOG you’re using. So maybe variables and tests are missing.

@dejv 1.5.10 is quite old, though is the master I suppose.

We have bene doing stable branch releases more autonomously with likely newer versions of the kernel.

With that said, however, this appears to be kernel related.

Of course first question just to ensure all is right:

UEFI Secure boot is temporarily disabled correct?

Please attempt to update your kernel to a newer version.

You can do this in the UI from FOG Configuration Page -> Kernel Updater

Find the latest version and try that, and work back if necessary for older versions. I suspect one of these will work better for your needs.

@chunter2 This domain does not exist or dcouldn’t be contacted seems to be indicative of the problem. Simply put, from the message you show, it seems the DNS isnt’ able to reach the domain controller.

I highly doubt this is due to the version of FOG based on this, but my perspective is obviously very limited at this point.

@Fog_Newb I don’t know how to replicate the problem you had unfortunately, but I believe I made a fix for the issue you were having. The function is expecting the parameter to be a string, and we were sending a null. I’m now going to have it send in an empty string instead which should prevent that problem moving forward.

Thank you.

I still wish I could get you to look at 1.6 but I understand the hesitation

@Fog_Newb Can you provide your http/php error logs?

See my signature for locations (or very similarly close to)

@plegrand

I don’t know if it will work or not.

We had one person try it, and I just got around to adding what they suggested as found here:
https://github.com/FOGProject/fogproject/pull/733

I think it will work just fine, but we won’t know for sure until someone tries. What works for one may or may not work for another, so your mileage may vary.