Posts made by george1421

@lperoma said in PXE Boot Error - "Kernel Panic" Issue "XZ decompressor ran out of memory":

Any other idea? Can some one identify any issue with my dnsmasq ?

Its not a dnsmasq issue. dnsmasq only instructs to pickup ipxe.efi or undionly.kpxe once that boot loader is running dnsmasq has done its job. For some reason ipxe is misidentifying the processor as 32 bit only. Will you collect the exact processor model in these AIO?

I just saw in your previous message ipxe.kkpxe is being sent. Update your dnsmasq to send undionly.kpxe instead. That shouldn’t matter because ipxe.kkpxe uses the internal network adapters and undionly.kpxe uses the generic UNDI driver. But for consistency sake, lets make sure its not an ipxe issue.

@lperoma I don’t feel this is a pxe booting issue. There is only two flavors of iPXE. One for bios and one for uefi. Is this computer in bios or uefi mode?

The only way I can see this messing up because of dhcp is that the computer is in uefi mode, and you had something wrong with dnsmasq, where its loading the 32bit version of iPXE. That might falsely miss identify the processor as a 32 bit causing bzImage32 to be called.

The other thing I can think in the fog configuration -> fog settings. If you hit the expand all button then search for bzImage. If by chance someone changed the 64 bit fields to load bzImage32 and the 32 bit initrd. But that’s really unlikely.

Do all other computers work correctly except for this one?

@lperoma Looking at your screen shot a few things jump out at me.

Why is iPXE loading the 32 bit version of FOS Linux?

What hardware are you running here? What is the CPU? Is this super old hardware, like from the Pentium era?

I translate this error to the kernel (bzImage32) doesn’t have enough RAM memory to expand the FOS linux virtual hard drive (init_32.xz) into memory. If this IS a 32 bit system I still can’t understand why there is not enough ram for this kernel expansion. 32 bit arch is limited to 2GB of RAM. The FOS linux kernel and initrd compressed is < 400MB. Something is not adding up.

@cros I’m kind of spit balling here but your imgargs line especially around nfsroot doesn’t really follow what I expect.

FWIW here is what I have in my guide for debian 11. (I really don’t keep up with current distros anymore)

kernel tftp://${fog-ip}/os/debian/Server11.3/linux
initrd tftp://${fog-ip}/os/debian/Server11.3/initrd.gz
imgargs linux initrd=initrd.gz root=/dev/nfs boot=casper netboot=nfs nfsroot=${fog-ip}:/images/os/debian/Server11.3/ locale=en_US.UTF-8 keyboard-configuration/layoutcode=us quiet splash ip=dhcp rw
boot || goto MENU

For me your imgargs line stands out as is your 192.168.7.5 server your fog server or a different server? If its your fog server you can make the line a bit more portable by using ${fog-ip} which will be replaced by the IP address of the fog server by iPXE. Secondly did you create an /nfs share on your fog server because that is not one of FOGs standard nfs shares. On the fog server you should be able to run the command showmount -e 127.0.0.1 to see the list of nfs shares on the fog server. In my imgarg command you can see I’m using /images/os which is in the path of /images on the fog server and /images is an NFS share.

ref: https://forums.fogproject.org/post/150256

@jcarr ok that is an x86 system. I see its strange that the kernel doesn’t try to boot at all. That’s not a new system (8th Gen) there shouldn’t be an issue with FOS Linux starting up. I understand that all actions from the ipxe menu doesn’t boot they all rely on FOS Linux kernel starting up. Have you tested an older kernel, maybe either in the 5.x or 4.x (last choice) range?

Is the issue with just this computer or all computers you try to pxe boot?

If its just this computer, is the firmware up to date?

I have to shot gun this, because it should boot.

@jcarr Just for clarity this target system is x86 based?

Also in the fog configuration ->fog settings panel of the ui set the logging level to 7. It may be either 4 or 1 by default. This should print more information on the boot screen. What its showing so far is that its working.

@rodluz Good going. I also saw the issues with the lenovo’s ARM notebooks. I think we may need to wait until 6.12 is released. Yeah, without networking or keyboard you are kind of stuck. I was thinking that we could just ssh into the fos engine to bypass the keyboard issue, but then no network and no way to set root’s password. That would have to be done using buildroot to assign a default password to root. Not worth the effort until you get keyboard access. I just has a flash of an idea of a serial console, but that system probably doesn’t have a real serial port either.

@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.