@george1421 said in FOG `Kernel panic - not syncing' error after entering quick host registration:

Plus when you ask for FOG support it will confuse the person helping you because they are not suspecting this non-standard setup.

Going to quote you on that 😉

@andyroo54 Thanks for noting! I just added this to the wiki: https://wiki.fogproject.org/wiki/index.php?title=Installation#VMWare_ESXi

I am still not sure to tell teh truth. I am doing it a different way and right now got pushed back onto another project so I haven’t gotten back to it yet. But that being said using MDT seems to make life better.

We need more details. What is the FOG server’s IP? What is the DHCP server’s IP? What is options 066 and 067 set to? Can you give a photo of the errors your seeing?

And I do believe that fog SVN version 5196 is the latest FOG Trunk version as of April 5th, 2016!

@george1421 Is this what you are looking for?

https://wiki.fogproject.org/wiki/index.php?title=WorkingDevices

@danilopinotti So that worked?

@Tom-Elliott Ok, we fixed it… we looked at the pcap dump here and found it was one of my colleagues and his sonicwall pulling a sarah palin and went rogue. Issue resolved.

Again my hats off to you guys and the community thank you so much!

@Pascal-Gazaille Is this with an external DHCP server? Just for the fun of it, would you want to try UEFI as well? Change from legacy BIOS to UEFI on your DELL Latitude and from undionly.kpxe to ipxe.efi on the DHCP server…

More and more UEFI is coming and it’s good for us to know how well we handle this already.

@Tom-Elliott

Cheers Tom it worked!

With any luck, I hope to have found a potential partial cause of the load. Again, this only appears to happen on Ubuntu based systems, but why I couldn’t tell you.

By moving the servicemodule-active.php file I can limit the load, but I think it’s not a suitable test because it essentially keeps the FOG Clients from doing anything related to the work the modules are expected to do.

This seems, to me, to be two part. First the servicemodule-active was calling at least 12 separate calls to the database per system. I’ve now limited this to a single call to the database to return all the values. The second part that I have no good way to test is the php versioning.

While most are running 5.6.20 (or very close to it), the values should be operating in normal ranges. However, the output of Fedora 23 system running PHP 7 (sorry I don’t feel like downgrading to php 5 for now).

PHP 7.0.5 (cli) (built: Mar 30 2016 09:13:39) ( NTS ) Copyright (c) 1997-2016 The PHP Group Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies

The output of PHP 7 on Ubuntu 15.10

PHP 7.0.5-2+deb.sury.org~wily+1 (cli) ( NTS ) Copyright (c) 1997-2016 The PHP Group Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies

Notice the “extra line” of “With Zend OPcache v7.0.6-dev, Copyright” stuff.

I don’t know if that’s actually supposed to do that. Meaning, I believe the Zend OPcache value should match the php version as php is written by Zend (or so I thought). In either case, it’s intriguing to say the least.

Thank you for your feedback. This is all good information for the Devs. I noticed you didn’t mention the version of FOG you installed. Did you install 1.2.0 stable, or a trunk build of 1.2.0 (i.e. 1.3.0 beta). I see that you stated you installed the dev branch (which is not a term we used). Could you reply with the numbers that are listed on the cloud from the management interface gui?

I can’t speak to issue 1 of yours.

As for 2, I’ve experienced this my self where the second time you run the script the OS password for the fog user gets updated but the information stored in the database is not, creating an inconsistent (i.e. broken) install.

For 3, I wrote a kb article [ https://forums.fogproject.org/topic/6642/moving-fog-s-images-files-off-the-root-partition ] on how to create a similar setup as you have. The issue I see is that the /images and /opt/fog/snapins folder could potentially grow out of control unless you are managing the disk space properly.

Thank you for taking the time to give the dev members great feedback and for taking the time to work with and use FOG. Its a great solution.

Thanks @george1421 and @Sebastian-Roth for your help. For now I did what Sebastain mentioned and moved the images and that worked. George, when I get more time I will review your documentation and see if that is something that I would want to do in the future.

Once again thanks!

Updating seemed to fix the issue.

@Wayne-Workman said:

I really doubt it’s the unmanaged switches fault, and I’m willing to lay 99% odds it’s a cable.

While I totally agree on what you said and fully trust in your network knowledge (I mean that!) this is not a cable issue from my point of view - not this time at least:
http://www.viktorious.nl/2013/11/05/cisco-sg200-08-nfs/
https://supportforums.cisco.com/discussion/11755791/sg200-08-firmware-issue

Other than that I found this as well: http://serverfault.com/questions/367107/cant-mount-nfs-share-over-tcp

Turns out there was a “security” feature enabled on our PowerConnect switch that took offense to NFS SYN packets with source ports < 1024 (dos-control tcpflag). Suffice it to say, disabling the feature solved the issue.

Reading this again I think this is actually the case here. Why? Because I made Miguel try telnet <fog-server-ip> 56557 (the actual NFS data port) and it worked - as telnet is not using a high source port I suppose.

@Sebastian
My HERO !!! 🙂

Tanks a lot it works

@admin
You can solve this post

@FlowLive I guess the only question I am seeing is that you are asking how to determine if the machine is a laptop or desktop. The easiest way to accomplish this is to use a script as the snap in that will check if it is a laptop and if so run the installer from a share some where. If it is a desktop then no installer is run.

Natively there is no way to have FOG determine if the machine is a laptop. But if you know what machines are laptops as you add them, you can have machines belong to multiple groups, add all laptops to a Laptop group and apply only those 3 snapins with no other setting in that particular group. Not automatic, but does work.

I quite often use scripts instead of actual files for snap ins, mostly due to old limitations of snapins back in the .32 days, so I guess it is just an old habit.

@wdmartin said:

It may not like having been put on a VirtualBox when it was originally built against an Optiplex 990.

For sure! Windows is very picky when it comes to IDE controller drivers… Not easy to get a system from bare metal to VM if you don’t adjust the drivers before capturing the image!

I got the 58 GB figure from the FOG imaging screen while it was building the second partition.

Ok, this meants the data within your second partition is 58 GB (28 GB compressed!) but does not tell you anything about the source partition/disk. It’s not an issue to put 58 GB to a 200 GB disk but a problem if the original file system used to reside on a larger disk - no matter how much free space there is!

@Ignacio Sí, trato de traducir. Explicar su problema, por favor.

@FlowLive So far the persistent groups as I laid out in the kb and link previously is working in my environment. A formal solution (authored by the devs) would be better. But if there is no plan to support persistent groups in fog 1.3 (as of today) then this solution should work for you too. You will just need to create your host consistent templates and then setup your host groups as outlined in the KB.

The issue, for others who may stumble across.

If you’re getting Private key not found but all the data seems to point that you do have a Private key file. Make sure the node (ip address or whatever) is actually a node within the system.

In @raumin’s case fog-server was not the node he was working with. The node he had defined was a NAS. NAS’s suck (plain and short) but have their own uses. (No offense to anybody using one, just they’re a bit of a pain to play with to get working with fog).

So the clients were looking at the thing @raumin is using as the GUI access point for private key. This was not a defined node (and I will try to come up with a better approach).

The fix, for now, is to always have a node for the GUI as well. You do not need to have the node enabled for things to work, and I would highly recommend against using in such a setup (NAS->Central GUI) trying to make the GUI node a “master” of the group it’s working with, unless you want it setup in such a way.

For our fix. We created a definition for the node and gave it the proper ip address. All started working immediately.