fog perform full host registration = no viable mac to use

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