@RobertD said in PXE boot - HP Elitebook 650 G10 - No configuration methods succeeded ...:

We have been using ipxe.efi for all of our devices for years so I’m afraid to change all our DHCP scopes to use this loader for this one problematic model. Any suggestions?

Its great that you have a path to boot these system via the snp driver.

You didn’t mention if you updated iPXE to the latest release to see if the ipxe.efi boot loader works once again.

Let me (re)clarify in this thread the differences between ipxe.efi and the snpX.efi boot loaders.

ipxe.efi (uefi) and ipxe.kpxe (bios) contain all of the known drivers built into the boot loader, this makes the iPXE boot loader much larger in file size (in 1990 terms of file size) because it has to carry all known drivers onboard the boot loader. For older systems > 6 years those were the preferred boot loaders for iPXE

snp.efi, snponly.efi (uefi) and undionly.kpxe (bios) use the network adapters built in driver through the generic snp or undi interface. This boot loaders are much smaller than the ipxe.* versions since they only need to have one driver onboard (snp or undi). The undi driver (bios) has been around for 30 years and is the preferred and very stable network interface for bios computers and should always be the #1 choice. The uefi firmware has only been around for 12 years or so. The early version were very buggy so the snp driver did not work well. This is the reason why the fog developers recommended the ipxe.efi boot loader for uefi systems. In the last 6 years or so the snp and uefi firmware has matured to a level where the fog developers are recommending snp.efi or snponly.efi for all modern hardware. For bleeding edge hardware you have a better chance to get the snpX.efi bootloaders to work before the ipxe.efi bootloader, because the iPXE kernel developers will need to add the driver to the bootloader. Its just a timing issue.

Now you might ask what is the difference between the snp.efi and snponly.efi drivers. snponly.efi will only initialize a network interface from where it was loaded from. For example lets say you pxe booting a compute with 4 nics, and you pxe bootin from nic2. The iPXE boot loader would only init nic2 using the snponly.efi bootloader. In contract snp.efi would try to init all nic intefaces starting with 1, 2, 3, and then 4. The issue becomes if nic1 takes the boot loader someplace else other than to the FOG server, since the fog server is on nic2.

@dominique said in Database engine MyISAM - upgrade FOG?:

Any idea when 1.6.0 will be general available?

There is no timeline for this yet. Many people use FOG but very few help working on it. So things are going very slow at the moment. We’ll bring out a last 1.5.x release (1.5.10) to finish up that line and then the next will be a first 1.6 release (months down the road).

If you are keen to get InnoDB earlier you can follow the topic Goerge posted. From my point of view this should be possible in 1.5.x setups as well. But we won’t officially support this and don’t want to push out for a major change in the 1.5.x branch anymore.

@george1421
Increasing PHP-fpm memory did the trick.

Thx for the thinking together.

@Quazz I do the following:

click Images multicast image give session name client count (12) timeout (0) choose image Start!

The strange thing is, sometimes it reaches the client count. Sometimes not.

@Dominique From what it reads in the other post the issue seems fixed in the working branch and I have done some minimal multicast test lately.

The FOG dev Team is not very strong at the moment as people have other important things on their private schedule and can’t put as much time into FOG. So I can’t promise you a date for the next release yet. But I think it’s not that far away.

If you use FOG in your company you might think about helping out in the FOG team to make things go a bit faster. One way to help is by answering questions in the forums. Or even get involved in coding and testing.