Posts made by george1421

@fernando-gietz You have told us about your physical host, but on the virtual machine itself how many vCPUs are dedicated to it as well as how much ram?

How many clients are hitting this FOG server too? What is their update frequency?

@fernando-gietz [Moderator’s note] Yes I want you to have your own thread on this. Your conditions may be different than the OPs. I’m going to fork this thread into a new one. To avoid polluting this thread with off-point discussions

Thread forked to here: https://forums.fogproject.org/topic/10890/fog-server-cpu-usage-100

I have worked with this area of pxe booting on some pretty tough problems. So I have a few things I can tell you.

First for your dnsmasq if you can install / or have installed dnsmasq 2.76 or 2.77 your configuration will be a bit easier. I would first focus on getting on this release. I have not personally done this with Debian but I have a tutorial on how to compile dnsmasq 2.76 and I know it works on Ubuntu. https://forums.fogproject.org/topic/8725/compiling-dnsmasq-2-76-if-you-need-uefi-support

Before you go through all of that open a command window on your fog server (or dnsmasq server) and key in the following command dnsmasq -v to get the dnsmasq version. If its less than 2.76 then consider compiling an update using my instructions.

If you are on 2.76 or later consider using my ltsp.conf from this end of this post [ https://forums.fogproject.org/topic/8725/compiling-dnsmasq-2-76-if-you-need-uefi-support/6 ]. I can say for absolute this configuration works perfectly. Make sure you change the <fog_server_IP> to the IP address of your fog server. Don’t forget to restart dnsmasq after you make a change to the config file. Also ensure that when you reboot your fog server that dnsmasq restarts too.

I have seen what Sebastian said about home routers. They do send their IP address as the next server but no boot file. That isn’t very helpful if you want to pxe boot at home. So far I’ve been able to use dnsmasq to over ride home dhcp setups of all kinds. In my home right now my home router does exactly what we are talking about, sends itself as the next server with no boot file name. I’m running FOG and dnsmasq on a Raspberry Pi3 server and I can pxe boot both uefi and bios systems no problem. If we take my config file and make a small tweak to it, we should be able to override even a valid dhcp server sending out a proper next server and boot file.

The other thing that Sebastian mentioned was to capture the network traffic using wireshark or tcpdump. Since the pxe booting process needs dhcp and dhcp is communicated via broadcast messages we can have any computer on the same subnet eavesdrop at least on the dhcp process to understand what is going on. There is no need for a mirror port. If you use tcpdump running on the FOG server you can view the entire pxe booting process, even after the target computer switches over to unicast communication since it is talking directly to the fog server at that point. I do have a tutorial on that too: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

@taspharel I guess you need to go back to your service provider and see if you can get a trending over time. What are they considering high cpu load?

The numbers you posted below are pretty low cpu usage. I understand that was only for a max 15 minute time from when you collected the data. You need to see if you can correlate the high cpu usage time the are saying to a specific action. For 200 nodes, it shouldn’t cause high CPU usage even during imaging.

There are two bits of information we probably should have for completeness.

1. How many vCPUs are allocated to the fog server VM
2. What version of FOG are you running. There WAS issues in the 1.3.x range of heavy CPU loading that was addressed in subsequent version of FOG.

@cheisler8504 said in FOG 1.5.0 RC9 - How to have a computer boot stright to multicase session?:

I did not know it would be that easy to create a menu item that easily.

There is a little bit more that is required, but if you go into the fog configuration and then into the ipxe menu configuration you can create new iPXE boot menu entries. The one I provided should be pretty close to what you needed.

@cheisler8504 There is a bit of a misunderstanding in your plan.

With multicasting the whole lot moves at the speed of the slowest system. So if you are imaging 6 i5 quad core computers with ssd disks and 1 Pentium 4 with a slow disk the whole lot will run at the speed of the Pentium 4. The heavy lifting (the most work done) is by the target computers to decompress and move the image to the local hard drive. Since there is only one data stream the 5 faster systems will pause until the slow ones catch up.

How many systems do you envision you need to image per day? With my production environment I can push a single 25GB image to a target computer is about 4.5 minutes. By using a 2 port network LAG and a SSD drive in the FOG server I can image 4 systems in about 5 minutes with 4 unicast streams. If I would increase the LAG to 4 ports I can do 8 in about 5 minutes. Understand my production environment is all virtualized but I did physical server testing a while ago. I can saturate a single 1GbE link imaging 2 systems using unicast at the same time. After the second system the overall throughput dropped dramatically.

While I went off topic a bit I would start with your goal, how many systems do you need to image per 8 hr shift to see if it really warrants using multicasting over unicast image deployment. Now if you needed to image an entire class room of 30 computers between classes, I would say yes muticasting is the way to go.

@jflanagin You can support all other hardware except the 7480 (or the 8th generation devices? The reason why I ask is the latest generation is the new Kaby Lake chip sets, where the older (i.e. Circa 2016) is the Sky Lake design. The Kaby Lake chips may be too new to have proper linux support. I am speaking totally off the top without a foundation yet.

But we have someone else on the forums with a 7050 that uses Kaby Lake chips that is seeing random freezes during registration and imaging.

We may need to get the @Developers involved with some custom debug FOS kernels to help debug exactly where its hanging.

Something you can do is ensure you are on the latest release of the firmware for the 7480 and watch the dell site to see if newer releases are offered. I suspect we are going to see quite a bit of churn with firmware updates like we saw with the 7470/7270 generation.

@jflanagin Can we get a bit more information on this?

1. You say you have a 7480, is that device in bios (legacy) or uefi mode?
2. If in uefi mode, is secure boot disabled?
3. What precisely do you have configured for dhcp option 66 {next-server} and dhcp option 67 {boot-file}?
4. Is it accurate to say you ARE running FOG 1.4.4?

@jackiejack No one will get angry. We all were “new” at one time. You are learning what you can and can’t do. FOG is a really complex system with several other open source systems under the hood. Its not something you can pick up and run with on day one. The developers have done a great job of hiding the complexities inside fog with the nice web ui.

@jackiejack Sorry I meant to include that in my last page of text. Yes dhcp is a requirement for PXE booting. Because the pxe boot client doesn’t know anything. It needs dhcp to supply it with the information it needs to boot. Without dhcp pxe booting isn’t really possible (it technically IS possible to do but it means creating your own boot roms which isn’t practical in most cases).

@jackiejack I’m not sure I understand your request.

Your overbosses say you can not alter dhcp server to support pxe booting. You also had constraints (if I remember correctly) they didn’t want accidental imaging to occur.

If they are willing to allow network booting for imaging but still do no want to change dhcp server then you have an option to have FOG supply pxe booting information as long as the target computer is on the same IP subnet as the FOG server. You would do this by using dnsmasq service on the FOG server. Again you don’t change master dhcp server only supply what is missing needed for PXE booting.

We went with the USB booting method to satisfy the original constrains of 1. not changing dhcp server. 2. no unintentional imaging of target computers. With the USB booting you can’t accidentally image a machine because you have to physically go to that machine and insert the USB boot drive.

If I’ve missed something let me know and we can change design. Right now only USB booting is possible because of your constraints.

@george1421 If you are getting errors, please take a clear picture of the error with a mobile phone and post it here so we can see the context of the error to better understand it.

@jackiejack Correct the USB is providing what you would get through PXE. Once the computer is registered then you go into fog web ui and configure the system, assign to an image and then schedule a capture or deploy task in web ui. Once the task has been scheduled then you usb boot the target computer and pick option 1 to capture/deploy.

Without PXE booting you loose the tight integration between target computer booting and imaging, but as long as you follow the sequence above then its all right.

@jackiejack See this is where I’m getting confused. If you are booting from usb boot drive, at no time do you use pxe or any pxe information. The “PXE - No boot filename received” is typically seen when booting from the network.

@jackiejack Ok (toooooo many thread, so little brain cells that remain functional), then you need to find out why your dhcp server isn’t providing a boot file name (dhcp option 67) while pxe booting.

So if I remember correctly, your main dhcp server can’t be altered. So you setup dnsmasq to supply the dhcp information to your pxe booting clients. The error message seems to indicate that your dnsmasq service is not running on your FOG server. You might want to check into why that service is not responding to the dhcp request.

How many clients do you have in your FOG domain (i.e. devices that connect to your fog server)?

@psycholiquid This is a bit off topic, but I see in your snapshot of “Here is a screenshot of my setup” you are using the ipxe7156.efi. I just saw a pull request on git hub that the “7156” flavor of kernels were being removed from the FOG distribution because the latest ipxe.efi version (in 1.5.0 branch) is now working with the surface pros.

1. Just be aware that this kernel is being removed from the package and you will need to update your dhcp setup.
2. You probabaly should confirm that the latest version of ipxe.efi (pulled from the working branch) does what YOU need it to because ipxe7156.efi was left in the distribution to address an issue with the surface pros and not VMWare.

I’m not saying its a problem. I’m only trying to raise awareness that there was a change and based on your configuration you may have issues.

@x23piracy Its been a while, and my memory is fuzzy and old…

The idea was to create a table of keys and then to assign fog group to an entry in the table. If I remember correctly, if the key is blank the value from the keys table is copied to the host. If the hostkey exists then the host is skipped. The logic was if someone had manually entered a key, that was by design and the developers didn’t want an automated process to overwrite the key to crush the decision of the person who put the key there.

I didn’t code the plugin so the developers may have taken a different approach in the code. But the discussion at the time was to only update blank fields.

@quazz So should that be added to a KB somewhere? i.e. if you have a surface pro, before you sysprep run these commands to remove bit locker so it can be cloned by FOG? Like in the FOG Client section similar to the requirements we have for the FOG Client Service? It is a prep step that is required to be successfully cloned by fog.

General question: Is this “condition” isolated to only MS Surface or is it any OEM installed Win10?

(I have no clue on this since I haven’t been exposed to bit locker as of now) The other part of me wonders if FOG copies that volume as RAW and since it is encrypted with Bit Locker, is that unused space even usable on the cloned system? The TPM chip key would be different so I would assume the encrypted bits would be inaccessible on the new system.