Posts made by george1421

@PatrickL You might want to review this post: https://forums.fogproject.org/topic/17648/massive-cpu-usage-from-a-service

That .sysvd is suspicious and very similar to the thread above.

@jfernandz said in BitLocker compatibility:

The TPM point is a good one, but … almost all machines we work with have an “easily” accessible/replaceable TPM hardware module, could just we restore some disk image in a new machine with the TPM of the old one? Would this work?

-Or- just decrypt your golden/mother image before image capture, then either have the unattend.xml or gpo policy encrypt the drive when it hits the target computer hardware? Don’t make it harder on yourself than needed. I’m sure your users are willing to do that to you for free.

@Eliseu What I see here is that ipxe is booting, but this isn’t FOG’s version of iPXE. Are you running this pxe booting computer in virtual box?

@stokehall Just a quick oracular review and it will eventually ship with linux kernel 6.11, and it kind of works with the latest ARM processors. But we are getting close and kernel 6.11 is probably a good place to start. We might want to start with the default config for the qualcom processors and then add in the bits that FOG needs. Linux kernel 6.11 was released on 15-Sep.

@jfernandz Actually bitlocker fde (full disk encryption) was developed to prevent what you are trying to do. I don’t remember if the developers put a stop point in the code if fde is detected but technically FOG will copy a bitlocker protected disk, but it will do it in raw mode. The issue you will have if fog cloned the disk image is that bitlocker encrypts the disk with a key that is held in the TPM chip. So even if FOG cloned the disk, the data would not be able to be used because the TPM keys would not match. This prevents cloning or accessing data on protected media.
For the data to be cloned and usable afterwards you must decrypt the drive before cloning.

@fairoozfarhan You didn’t mention what you are trying to do with the swiss army knife called dnsmasq. If you are trying to configure a proxy dhcp server the configuration listed in this tutorial will get you started: https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server If you want to use that dnsmasq server for a dhcp and or dns server you need a bit more data in your configuration.

Usually when dnsmasq fails to start there is a service already using a port it needs to start. Like DNS or DHCP. There may be a log file in /var/log

@Eazis said in Multicast stuck:

[09-18-24 9:36:35 am] Interface not ready, waiting for it to come up: 10.54.68.101
[09-18-24 9:36:45 am] Interface not ready, waiting for it to come up: 10.54.68.101
[09-18-24 9:36:55 am] Interface not ready, waiting for it to come up: 10.54.68.101

I think this is the most interesting bit of info. Why would udpsend wait for an interface to come up that is clearly up. In the global configuration make sure the proper interface is defined for the imaging interface. Also there may be an interface section in the multicast section of the configs. I don’t have a fog server near me at the moment but it should be under fog ui->fog configuration->fog settings. Hit the expand all button then search for multi

Also when you schedule the multicast deployment from the fog server console run ps aux|grep udpsend and save the output. I think part of the udpsend command parameters will also list the interface udpsend is using.

@Eazis So you went from physical servers to VMs on the same subnet?

These are VMs running under VMWare? If yes is your vSwitch configured for promiscuous mode?

There isn’t a lot of useful info here. We need a bit more detail about your environment. What else changed other than physical to virtual?

Does the fog server master node have more than 1 network interface in it?

FWIW only the master node will send out multicast images, so the storage node shouldn’t be in the picture here.

@anube If this is a new model make sure the firmware is updated. If ipxe never completes initialization then something in the firmware is hanging it up.

We may also consider having you recompile iPXE into the latest version depending on how old of a FOG install you have.

@stokehall said in Windows on ARM:

is this the kernel that is downloaded and installed inside the fog web interface?

yes. but the file bzImage does go into /tftpboot it goes into /var/www/fog/service/ipxe directory.

You can also manually download the kernels from here: https://github.com/FOGProject/fos/releases and then place them in the path.

@stokehall said in Windows on ARM:

UBUNTU server 24.04.1 LTS ARM64 and that gives me the same error as MarkG,

Please keep testing, but I’m going to suspect the current class of linux kernels will need to be updated to 6.11 to support these new processors. Its the linux kernel devs that need to have one of these devices in their hands to debug. We’ll see mainstream linux support soon on this. This isn’t really a fog problem, but a linux kernel issue. We’ll get there when one of the fog developers have one of these systems soon too.

@stokehall said in Windows on ARM:

UBUNTU to 24.04 LTS and will then install Kernel 6.11

Just be aware the needed kernel is for fos linux and not the fog server’s host OS.

@45lightrain ok so lets start with some basics.

a 1GbE link (under theoretical conditions) is 1 Giga bits per second or 128MB/sec or 7.5GB/min raw data. Understand that there is ethernet overhead and you will never achieve 7.5GB/min.

So how is it possible to see speeds above 7.5GB/min on a 1GbE link? Simply data compression. So what you are seeing in the part clone screen is a composite speed including fog server speed sending the data to the network, network transfer time, the client receiving the image, expanding in it memory, and then writing it to disk.

If you are getting 5.5-6.1GB/min in partclone on a pure 1GbE network your fog environment is well designed and network well managed.

I wrote an article a few years ago that has some benchmark tools you can use to see where you can get additional speed out of your setup. https://forums.fogproject.org/topic/10459/can-you-make-fog-imaging-go-fast

So the executive summary is that if you want to go fast.

1. Install at least (1) 10GbE network link. (If you have many computers running the fog clients, run (2) 10GbE links in lag configuration.
2. If you have many clients hitting your fog server while you are trying to image use a ssd disk or nvme drives on your fog server (I would look at spending here the last, typically its not the disk that is slow, unless you have just a single spindle hdd driving your fog server).
3. Try to get the 10GbE network as close to the target computers as you can.
4. If you are trying to image multiple target computers at the same time look into fog casting your image to the target computers.
5. When capturing your image use the zstd compression tool over gzip. Set zstd at compression 11 to start. If your target computers have a lot of horsepower, 16GB of ram, and fast nvme disks you can get more data through your network by compressing the data more. This will put a heavier load on the target computer expanding the image and writing it to disk.

Think if your imaging as 3 factor triangle. You have server speed to get the image to the network adapter, the speed at which your network can move the image to the target computer, and finally the time it takes for the target computer to intake the image, expand it in memory and write to disk. In the imaging process the fog server typically has the least impact on imaging of the three.

@45lightrain Firstly, let me say I have no experience with increasing hte MTU with FOG or any benefits. Where its failing is in iPXE. For some reason iPXE can’t take the larger MTU. The second challenge is with the FOS Engine (bzImage), you will need to set the mtu in there too. The FOS Linux engine is where the rubber really meets the road with MTU changes.

You could create a USB boot drive and boot directly into FOS (that would reduce the number of other things you need to address, just to see if changing the MTU would help.

I think you will be opening a lot of nuance issues in your network by upping the MTU, regardless if it helps with imaging or not. I would think it should help but unsure to what degree.

You say you are doing this to help with imaging performance. What numbers are you seeing during the partclone part of imaging? On a well managed 1GbE network you should be seeing 5.7 to 6.1 GB/Min. If you have 10GbE in your network core, and the fog server running on a healthy VM host server, with 1GbE to the desktop you should see in the area of 12-15GB/min range.

What numbers are you seeing and under what conditions?

@ccatcc Is this a new fog install or has it been in service for a while?

Will you verify that in this path on the fog server bzImage file exists? /var/www/html/fog/service/ipxe make sure bzImage is in that location.

@rodluz On that laptop, what is the processor model? From what I’m gathering (I’m a bit ignorant on arm systems) but snapdragon is akin to the word pentium. There are a few models that fit behind that banner. Is your system the x elite or one of the older processors like the 850?

FWIW It looks like snapdragon support will first be available in linux kernel 6.11

https://www.phoronix.com/news/Qualcomm-Adreno-X1-85-GPU-Linux

additional linux support docs
https://docs.qualcomm.com/bundle/publicresource/topics/80-70014-3/features.html

@MarkG said in Windows on ARM:

class “UEFI-ARM64” {
match if substring(option vendor-class-identifier, 0, 20) = “PXEClient:Arch:00011”;
filename “arm64-efi/snponly.efi”;
}

Well done working out the hard bits. It sounds like there needs to be some fog ui updates and we need to get that FOS kernel to boot cleanly. In the FOG Global configuration settings. There should be a field for log level, set that to 7 to see if there are any additional log entries that gets displayed. The default value of 0 or 4 masks most of the kernel messages. The level 7 is only used for debugging.

@stokehall said in Windows on ARM:

How do I go about this step? “Get that file name and key it into the dhcp server/s option 67 value”

The question back to you is what is your dhcp server for the imaging network? That is where you would set the value for the boot loader. BUT the OP of this thread has already done that and has proven how to get into the FOG iPXE menu, so the inits work. He has already figured out the arch type (11) for the dhcp server (what i needed the tcpdump/wireshark pcap for). Right now we have an issue with the fos linux (engine that clones disks) starting up. If I remember right the person that developed the FOG arm kernel was building it for a cortex CPU. It might not have all of the bits in it needed to boot the dell/lenovo. This is nothing unsolvable, we just need to find out about the processors in your system(s) and look at the kernel configs. This hardware is so new there aren’t a lot of info out there about it.

It would be interesting to see if you could find a live linux OS for the arm cpus and get that to boot. We could then reverse engineer the kernel settings for that live boot OS. (just thinking out loud)

@Tom-Elliott said in Windows on ARM:

So that leaves me with a few notes already:

Tom, I did some testing back in 2021 trying to get a rpi to pxe boot. I never did but here is what I found with FOG and a few changes that needed to happen: https://forums.fogproject.org/topic/14959/raspberry-pi-4-unable-to-pxe-boot

I’m only adding this here for reference.