Quick Host Registration not working on FOG 1.5.3

[Tom Elliott]

So i just tested and got the same error, which I can fix. (About the MSDM) but that didn’t impact the ability to quick register. Is it possible the machine NICs are not during quick reg causing it not to actually send the host information?

I’m not having any issues fully registering, or quick registering machines. I see the same error. The “parse error” I’m seeing is a little concerning, but I believe it due to the NIC as I suggested earlier. Are these USB nics?

[fry_p]

@tom-elliott Full Reg is throwing a “No Viable MAC found” (not the exact error) after registration for me on 1.5.3. I just updated this morning and the problem started then. I can try to get the exact error if needed, but I am doing this on an integrated NIC for an Optiplex 790, a model we’ve successfully imaged many times before. Thanks in advance for your help

[Erik Rafael]

@fry_p @tom-elliott
I too receive that error, nic is integrated, my model is Dell Precision M4700

[tedlwsn]

I’m having the same issue. I have tried quick register/full register, also tried different client devices. Even wiped and reinstalled FOG 1.5.3 on Ubuntu 18.04 LTS instead of CentOS 7. Still having the same issue.

I recorded the process I did when trying to register the host here:
https://drive.google.com/file/d/136YeecO8ysLPGmc2kF-btCifNj4Rqbzy/view?usp=sharing

[fry_p]

I tried manually adding the host through the web interface and was able to get to deploy image. However, it hung on “Erasing MBR/GPT”.

[tmcg0727]

I am also getting the “No Viable MACS to use” error. Also getting an error creating epoll and also the parse error. Let me see if I can get more information on the errors.

[Tom Elliott]

Please run:

rm /path/to/fogprojectinstaller/binaries1.5.3.zip

Please rerun the installer then. I’ve reverted the init’s to 1.5.2 inits. It will essentially replace all the binaries needed, inits, kernels, client (nothing changed from 1.5.2 to 1.5.3 for the client) to that from 1.5.2.

I’m not able to replicate the problem, but there seems to be enough people having the issues that it’s warranting this quick change.

[candidom]

@tom-elliott

I’m also having the same issue except with a HP ProBook 650. I’m on the same version of Ubuntu as OP and FOG as well.

I ran the suggested command and then ran the installer again but I’m still having the same issue. Any suggestions?

[george1421]

If reverting the inits doesn’t resolve the issue lets do this to collect a bit more information.

1. Manually register one host by going into host management and entering the details for that test host.
2. Schedule a deployment (doesn’t mater what since we will never get that far) but before you schedule the task make sure you check the debug check box then submit the task.
3. PXE boot the target computer. You may get warning messages along the way about IP addresses and such. After a few enter key presses you should be dropped to a linux command prompt on the target computer.
4. When you are at the FOS linux command prompt key in
   ip addr show
5. We need to see if eth0 is listed and it has a mac address. If eth0 is not there are there entries like ensXXX where XXX is a number?
6. If there are no ethernet adapter listed then lets key in this command
   lspci -nn | grep thern
7. This should return the name of the network adapters detected in the system. As an example, this is what is returned on my laptop.

00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit Network Connection [8086:1502] (rev 04)

8. Post the results back to this thread so we can understand what FOS is seeing on your hardware.

[jdeverse]

Hello, we are having the same problem, just popped up today. Hosts have to be registered prior to deployment, we are unable to perform a full or quick registration. The same message is shown “No Viable MAC found”

This is happening on Dell desktops, however, I’ve pulled the requested information from a virtual guest. I have two screen-shots attached.

I would like to add that one change we made in the last 24 hrs besides the move to the most recent version was to fix DNS so the fog server could resolve the host names of hosts added to the system.

[george1421]

@jdeverse Excellent this tells us that the kernel is OK since it is showing us eth0. This will allow the developers to focus on the inits (virtual hard drive) & scripts and not spend time debugging the kernel.

[Tom Elliott]

From the debug can you run the command uname -rm

Maybe I can do a remote session with somebody having the issue as well to try to determine what’s going on.

[jdeverse]

Happy to offer our resources here at the Nye County School District. Below is the output of uname -rm

[Tom Elliott]

@jdeverse This is before or after removing the installers binaries1.5.3.zip file?

[Tom Elliott]

Mod note: I’ve moved to bug reports as this is getting way too many hits to be considered less than such, though I don’t know where the issue is at quite yet.

[jdeverse]

Hello, I’ve got the main server and some storage nodes. We were working through some other issues so I think we used GIT to install the latest yesterday. After your recommendation today, I grabbed the Fog tar installer directly and re-installed.

Brings up a question, the procedure you outlined, was this for an existing install directory, or was it to be performed as a matter of fact, even on a freshly download file?

Thanks.

[Tom Elliott]

@jdeverse If it was a 100% clean install, and you ran the installer AFTER I requested the removal of the binaries1.5.3.zip file, you shouldn’t have anything to worry about.

[jdeverse]

Hello Tom, In this case it was an attempt to fix our production server, so while the install file was clean, I did reinstall over an existing system. I can create a separate 100% clean install to test with.

[Tom Elliott]

@jdeverse No need. Mind seeing the chat bubble? I can chat more realtime with you.

[Tom Elliott]

Thanks @jdeverse for the remote session and letting me figure out the issue on your systems.

I can say I’ve corrected the problem and the fix is pretty simple for everybody, due to me making a mistake, originally in pushing up 1.5.3. I forgot to add an argument to my script that makes it look for the binary release files. What’s good about that, is it means all you should have to do to fix the issue, now, is re-run the installer. I was able to find the problem. This was related to the lshw having a bug that is still, to my knowledge, not fixed.

When using lshw -json it creates a non-well formed json string when used with the lshw class statement. (My command is lshw -c network -json).

I was able to fix this by removing all spaces in the output string, and remove the trailing , (hence the , messages seen on screen.) It also fixes the MSDM issue.

1.5.4 will have the proper binaries laid out and should be released pretty soon as it fixes the CentOS 6 php-fpm usage issues.