fog perform full host registration = no viable mac to use

[george1421]

@buercky said in fog perform full host registration = no viable mac to use:

Im also getting this error. I have installed twice after deleting the .fogsettings file. Running on Ubuntu 16.04 on VMware.

Surprisingly I am able to choose image device from the fog menu and it works for an existing device, but quick or full registration gives me the jq error and no viable mac to use.

Three points here.

1. Deleting the .fogsettings file only removes the options you selected the last time you installed fog. All this does is ask the questions over again and really doesn’t reset anything from the previous install. If you were to delete the .fogsettings and then remove /var/www/html/fog directory THEN you would reset almost everything. Understand this is destructive, but you will not kill any images or your FOG database, only the fog programming code.

2. Make sure you remove the .zip file from the root of the fog repo you downloaded with git before you rerun the fog installer. That zip file contains the suspected broken inits that are causing registration errors. The fog installer should download the latest zip file when it runs.

3. If you manually register the target system with FOG, will it image?

I’ll spin up a new FOG server in my dev environment to see if I can duplicate this error. I’m going to suspect that yes I can.

[kafluke]

@george1421 Yes manually registering through the gui works fine. I also completely deleted the whole directory where I temp stored the FOG install files forcing FOG to re-download everything fresh. Still didn’t work.

[buercky]

@george1421 do you know the path to the .zip file once i get to the root of the repo i downloaded. I had deleted the download yesterday and re-downloaded and installed again yesterday with the same results.

If i manually register the client Yes it will image but i still get the:

jq: error (at <stdin>:0): Cannot index string with string “logicalname”
jq: error (at <stdin>:0): Cannot index string with string “serial”

Thanks for the help and sorry to hijack this thread

[george1421]

@buercky It should have been in the root of the repo. In my case its /opt/fogproject others root /root/fogproject

[buercky]

@george1421 this is mine none listed

[Tom Elliott]

1.5.3 didn’t have the binaries being downloaded. I missed an argument when I initially pushed up the release. (That was my bad). What this does mean, however, is you don’t need to do anything other than rerun the installer to get the new inits. I’m currently rebuilding them with the 1.5.2 getMACAddresses function as there’s a problem with the lshw -c network -json command. The idea was to use json data to parse and get our information.

I was able to get this to work, but it appears to only fix single mac machines. So the “next” fix would be to detect the number of nics first, then parse the information differently in the case of multiple nics found on the machine. This seems a bit strange and counterintuitive to me, so I’m reverting this function to the one that worked in 1.5.2. It’ll just be a few before they’re ready.

I’ll post here to say, just rerun the installer, and you’ll be all set hopefully with this issue.

[george1421]

@buercky One of the developers just ping’d me and he is working on the issue right now. He should have it resolved and pushed up in a few hours.

You have the right directory, those .zip files are only downloaded when the installer runs. So if you have a new git pull those files shouldn’t be there.

[Tom Elliott]

Please rerun the installer. I’ve updated the init’s. They now use the older version of the getMACAddress method, that used to work near flawlessly. It is newly built so it’s using Buildroot 2018.02.2 rather than 2017.11.2, but things appear to be working as expected.

[buercky]

@tom-elliott YES!! thank you very much works great!

[kafluke]

@tom-elliott Thanks Tom it now works again

[george1421]

@tom-elliott said in fog perform full host registration = no viable mac to use:

Buildroot 2018.02.2

Interesting… I wonder if some of the utilities will work better with a fresh build of buildroot(thinking ntfs-3g)

[Tom Elliott]

@george1421 the problem with mbr erasing is related to the kernel apparently. Using 4.15.2 appears to work properly, while 4.16.6 is broken, though I suppose it’s also likely I missed a patch on the kernel that fixed something like this a while ago. I haven’t needed to do it in a while so maybe there’s a regression in the kernel code base?

[george1421]

@tom-elliott So you rolled back bzImage to 4.15.2 in the 1.5.4 release? (just for my knowledge)

[Tom Elliott]

@george1421 nope I haven’t because I don’t know that it slows everybody down, and even if it is slow, it’s not broken.