I’ve seen something like this before in the forums, it was related to a proxy server and ssl.

Does your web connection go through a proxy? Do you have a caching server like squid?

Here’s related issues, they all seem to have the same answer:
http://askubuntu.com/questions/186847/error-gnutls-handshake-failed-when-connecting-to-https-servers
http://unix.stackexchange.com/questions/302839/gnutls-handshake-failed
http://devopscube.com/gnutls-handshake-failed-aws-codecommit/

@Tom-Elliott said in dmraid and mdadm?:

@rbaldwin while we await your suggestions/ideas/etc… Anyway we could have you try the --metadata flag during auto assembly? While I will likely add the postinitload feature anyway, I’d still be interested in seeing if we can get automated detection working.

Since mdadm --examine --scan shows the metadata for the array as metadata=imsm, I used that in my attempt.

madadm --assemble --scan --metadata=imsm

Same results as before, the array isn’t found.

In addition to the below answer posted by George, this wiki article will help future readers as well:
https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP

How do I mark this topic as solved? can’t seem to find the button for it…

@Wayne-Workman Will do. It’s been going relatively smoothly so far though so hopefully I won’t have to bug anyone. Thanks again!

HI,

The issue was with using winscp to transfer the tar file from my windows box to the linux server. It caused a corruption in the file(s). I tested this by browsing the icons prior to the scp, and testing afterwards. I used bitvise ssh client to transfer and reinstalled and all is fine now…

Thanks for all who replied.

Rgds

Ubuntu 12 is old. I’d recommend a migration to a new (built from scratch) Ubuntu 16.04 server.

I searched the forums a bit for some older threads, I know there are many more than what I found - probably due to the titles of the threads not being appropriate. But here are some, and some related wiki articles for migrating a broke box to a new one:

https://forums.fogproject.org/topic/9200/problem-trying-to-update-from-1-2-0-to-1-3-0/7
https://forums.fogproject.org/topic/8905/procedure-for-migration-from-1-2-0-to-1-3-0-rc/4
https://wiki.fogproject.org/wiki/index.php?title=Migrate_images_manually
https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_MySQL#Manually_export_.2F_import_Fog_database

#wiki worthy we need some official migration documentation. I can probably have an article put together in a couple of days.

@Joe-Schmitt Yep I had bat for some reason…No idea how because I used to have.cmd

@Wayne-Workman Thanks! That cleared it up.

@Tom-Elliott Updated correctly now - not sure why it wasn’t working the other day. Thanks for the help once again!

The client have IP 172.17.20.165

Here comes log

Client have IP 172.16.20.165
2017-01-10 13:50 FOG::PrinterManager Failed to connect to fog server!
2017-01-10 13:50 FOG::PrinterManager This is typically caused by a network error!

0_1484052941963_error.log

@rstrofton what version of fog are you using? Maybe you could update to the more current release or even the RC series? This thread was over a year old so bringing it back from the dead is a strange site lol. This is also why I ask for version. I am pretty sure current fog is less restrictive in this (not that the issue couldn’t still exist but still.)

@Wayne-Workman I will. I did not pay much attention to it because I assumed that I installed 1.3… but during our Q&A, i slowly realized that there might be an issue with my initial install, especially when I noticed that the FOG client that loaded was 1.2, not 1.3 (but that skips so darn fast that I noticed only after 3 reboots…)

ok, thanks

@Shadow00Caster Figured I’d add to here so others can follow.

We found that the system was in a really weird state. This state broke the root user password and it was not allowing services to be started properly. Worked together and reset the root user password. The installer still failed and we found the issue was due to how the OS was booting and starting services. It was using init as the service starter, but the command systemctl exists on the system. The service was failing with dbus messages because the systemd side was not what was used to load services on the system.

I’ve added a few checks just to ensure all will be well for the next release cycle.

Essentially I’m now checking three things.

Does the systemctl command exist? (command -v systemctl) Is the system booted to use systemd? (ps -p 1 -o comm= | grep systemd) Is the systemctl variable already set?

@george1421 While I know some of SCCM, I can say, I think this method is probably much more accurate than trying to do it in reverse. SCCM, as I understand it, is meant to be used on request. Meaning, when you need to image a device, you tell the device to network boot. From there, it will get its information from the SCCM server and perform the boot to perform the tasking requested.

In our modified scenario, we’re enabling systems to be on network boot mode consistently. All we’re doing is adding a new menu option that allows the user at the system to choose to boot up to disk or if they need to, they can select the SCCM menu option to perform the task sequences as needed.

Hopefully this fits the bill with the requirements, and it allows the users to have a dual type of system for setting up imaging. Essentially you can maintain your ‘light touch’ model if that’s how you’re using SCCM and have a golden base on the FOG Server. (That’s my thoughts, your mileage may vary.)

@Ric41 Thank you for posting the cause/results.

@Ric41 Once the time is updated, the services have no clue until they are restarted.

service FOGMulticastManager restart service FOGScheduler restart service FOGImageReplicator restart

@laintimes I was short with my response, I do apologize. But you described that your problem is hosts are waiting in the queue for imaging (in line for 5, in line for 10, … ). This only happens when there are no more available slots. Which is why I asked you to look into Web Interface -> Task Management and see if there are any tasks in there that may be stuck.

@Steuve68
Follow Tom and George’s advice, they will lead you down the right path.