Posts made by george1421

@scott-adams Are you still seeing load averages above 2?

Also are you sure you are running ubuntu 10.04??

@hammett131 said in UEFI Initializing devices.:

HP 4300

Is it just with the above model?
Just for confirmation we are talking about this model? https://support.hp.com/us-en/document/c03403843

Have you ensured you have the latest firmware installed on this device?

How many of these devices do you have on your campus?

What version of FOG are you running?

Where its getting hung up is booting the iPXE kernel, its hanging up on initializing the hardware. We have seen this with some crappy uefi firmware implementations. Usually a firmware update fixes the issue.

@scott-adams FWIW: Upgrading to 1.5.0 may undo the php-fpm settings you made.

Also ensure you test the info.php page and confirm the server API function is ‘FPM/FastCGI’. As outlined in step 21.

If php-fpm is running you should only see just a few apache service instances and php-fpm instances running not the 100s of apache2 instances like in your OP.

It looks like you are a bit over committed on the fog server memory (not a bad thing other than consuming more space than necessary). Tell us a bit more about your fog server.

1. Is it virtual or physical.
2. How many (v)CPUs does it have?
3. Tell us about your disk subsystem, is it raid or a single disk?
4. What about your network adapter(s), how many do you have?

@zago123 Understand I can only guess at the cause because I don’t know your network. But again this makes me think its because you have spanning tree enabled on your network switch and you are not using one of the fast spanning tree protocols.

I can explain it this way. When you turn your target computer on, the link light goes on (or may already be on if you have vpro installed). So your computer pxe boots and loads the iPXE kernel from the FOG server. When iPXE kernel starts, it will momentarily turn off the link light and then back on as iPXE now manages the network adapter. This is all normal. The problem is if standard spanning tree is enabled, when iPXE turns off the link light, spanning tree stops the network port from forwarding data for 27 seconds to see if it hears a BPDU packet (i.e. someone plugged another switch into the port. The building switch doesn’t know so it listens before forwarding. This is standard spanning tree design). Well for FOG 27 seconds is a long time and FOG has already given up on booting by the time spanning tree starts forwarding data.

The no configuration methods error means that iPXE could not get a dhcp address from your dhcp server and timed out. If you were to hit the s key at that message to get the iPXE shell, then wait 30 seconds and key in dhcp net0 my idea is that iPXE will pick up an IP address. If it does then it is for sure a spanning tree issue.

Again this is not specifically a fog problem, but a problem with your networking infrastructure. We are here to help you, but we can only do so much since you have not started FOG yet.

@zago123 Your issues to me still appear to be a networking infrastructure issue not a fog issue. The most likely cause is spanning tree shutting off the port when it sees the network link “wink” as iPXE takes over.

Have you confirmed that the mac address displayed c0:4a:08:02:1b:a6 is indeed the mac address of the ethernet adapter?

Did you do what Sebastian suggested by putting and unmanged switch between the pxe target computer and the building switch?

Have you changed the password on the linux account called fog? Understand this isn’t the webgui default administrator called fog, this is the linux service account called fog.

@safari2010 Well I can tell you that fog doesn’t change anything in the target system by default. To do this in FOG you would have to do something outside of the norm, because the FOS engine (the linux OS that moves images from the fog server to the target computer) doesn’t have access to the target image security/logon environment (under normal circumstances).

Since this is abnormal behavior from FOG, lets collect a bit more information. During FOG deployment, have you setup any FOG post install scripts?

Are you using the FOG client on / in the target OS?

Are you deploying any snapins that might alter the user accounts on the target OS?

@george1421 Looking in the inits FOS mounts the fog server with this command
mount -o nolock,proto=tcp,rsize=32768,intr,noatime <fog_ip>:/images /images

From a USB booted FOS image, make the /images directory in FOS and then see if you can mount it using the above command.

The mount command can be found in /bin/fog.mount in the FOS environment.

@culture20 first, FOS/FOG uses nfs v3 not v4. Not sure if there are different ports in play or not.

I would drop iptables as a test to ensure you have not missed a port.

If you usb boot into FOS, I would like to see if you can manually mount fog fog server. I’ll provide the command in a moment.

Something else not related to your nfs issue, but when booted into FOS, if you give root a password (any password like ‘hello’) and get the IP address of FOS, you can connect to it using putty allowing you the chance to remote debug FOS. Without setting root’s password the ssh server won’t allow remote connections.

@safari2010 OK lets get some clarity here. Is the password changing happening on the FOG server when you install fog (on the fog server), or on a target system? If it is the target system, what is the user account name, where the password is being changed?

Are you using fog’s linux service account called fog perchance? That linux user is managed and owned by the FOG application. If you change/reset this account you will have imaging issues.

@arainero It would be interesting to see the output of the following command. Key this into a browser: http://<fog_server_ip>/fog/service/ipxe/boot.php?mac=fc:aa:14:31:0b:5b

That will display the ipxe menu. There is something simply not right with the exit mode here.

@chris-whiteley Why not just put a fog storage node on the other side of the link. Then you wouldn’t run the risk of over committing your WAN. You can define a specific replication bandwidth. That IS something that fog can manage. You could even use an older dual core desktop computer as a FOG storage node. FOG Servers don’t need a lot of resources.

@eseelke The short answer is, it isn’t going to happen. The WIM files are windows centric. You have to remember that FOG is based on linux, and the engine that writes the image files to disk [i.e. FOS] is linux based. FOG/FOS uses partclone to capture image files, that can be expanded or compress dynamically (to a certain point) based on the size of the target media. I do agree that there would be value in integrating the WIM file format into FOG, but not enough for the developers to spend their time on. FOG has a very fast working solution today.

But, yes, if you want to tweak the golden image you can’t do it from the captured file like you can with a WIM format. The other thing you have to be aware of is that FOG supports more operating systems than just windows. The wim format is (very) windows focused.

[Edit]
Well after the above response I did a little google-fu and found there are linux libraries that support reading and writing wim files. ref: https://wimlib.net/ Briefly looking at the document it appear it is possible. I guess I’ll leave it up to the developers if they are interested, possibly for FOG-too. As for me my initial reaction still stands.

@joe-schmitt said in Web interface/full inventory/etc. extremely slow:

It’d also be worth while switching to php-fpm instead of Apache’s mod_php, as its better suited for more heavy PHP usage

I did some testing on this a bit ago and it helped with my install: https://forums.fogproject.org/topic/10717/can-php-fpm-make-fog-web-gui-fast

Activating php-fpm and memcache did seem to make FOG a bit more responsive. But also did changing the check in time to 15 minutes.

You can review the default isc-dhcp configuration file here: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence#Example_1

@zago123 As sebastian said, plug a dumb (unmanaged) switch between your pxe booting computer and your building switch. Your picture looks like the typical spanning tree issue we see some times. If the unmanaged switch “test” not work then we will have you do the following.

1. Manually register this computer with fog. Create a host record and name the host, and add the mac address.
2. Assign the host to an image. The image doesn’t matter because we will do something special next step.
3. Schedule a deployment to this target computer. Before you press the ok to schedule button, be sure to select the debug check box.
4. pxe boot the target computer. Since you said debug mode the target computer will ask you to press enter a few times then it will leave you at a linux command prompt. on the target computer.
5. Key in ip addr show if the network adapter does not have an IP address wait 30 seconds and key in ip addr show again. Post the results in this thread.

The above test will show us if the network adapter is seen at all by the linux operating system running on the target computer. Once we know where the problem is, we can give you a better answer.

[edit]Network adapter in mobo is Realtek PHY RTL8201EL [/edit]

@ldiorio Interesting the scan delay setting was added intentionally to give the uefi firmware a chance to fully boot up before attempting to exit via refind. We may need to reconsider switching that back if it continues to cause an issue. It was turned on by default to solve a problem, but then it appears to have caused another.

Thank you for all of your fine detective work on this. Without the actual hardware in our hands, it hard to debug issues like this.

@steveo There were a few more questions, I’l start with those

1. Do you need unattended image deployment, or do you require an IT tech to sit in front of the system for image deployment.
2. How do you invision deploying images? (i.e. someone sitting at HQ deploying images globally, or the site IT techs managing the process?)
3. In regards to imaging target computers. Is you plan to have one image for all, or one image per model?

OK, now hold on we are heading into the details.

First let me say I’m a big supporter of FOG. We have it deployed in our organization and it works very well. BUT (IMO) FOG (in its current state) is geared more towards the SMB market than the enterprise (where I would class you based on the size if your projected deployment). Will fog work for you? Yes, as long as you understand the caveats.

Your 128KB links are a concern for me for few reasons.

The first observation is the storage node’s dependency on the database running on the master node. Storage nodes must have 100% access to the database on the master node, or the storage node will not function. We have not tested if there will be any impact on imaging due to communication latency between the Master Node and the Storage Nodes.

In you install the FOG client on the target computers (not mandatory for imaging with FOG). The FOG client checks in with the master node on a set interval, that interval is 5 minutes by default. With a large campus you might want to increase this check in time to 15 minutes to spread the load out a little. This check-in consumes CPU on the master FOG server as well as network bandwidth. With FOG’s distributed imaging (master node, storage node) all files needed for imaging will be delivered locally, but the FOG clients still communicate over the WAN back to the master node.

Multicasting only functions from the Master Node. If you need multicast imaging then storage nodes won’t work for you.

Officially you can only capture images on the Master Node, storage nodes are not intended to capture images. With that said, there is a certain configuration you can use to capture images locally.

FOG’s replication is one way Master Node to Storage Nodes. Images captured at the Storage Node level (with the specific configuration) will not be replicated back to the master node.

FOG currently doesn’t have the ability to create storage nodes in an unattended manner. Plus to install FOG, the master nodes and storage nodes need to have internet access.

I have to hop off and do some other things, I’m not done here. There IS a path forward with FOG. I just want to document the difficulties first then we can work towards a solution.

@steveo Sorry I thought about a few more questions on the commute into the office.

1. Will you deploy software with FOG or some other technology?
2. What is the smallest network link (in bandwidth for a remote site)?
3. Do you need to multicast images at the remote sites?

Stick with me, because they are specific leading questions…