Thank you

I’m already using these settings. so I should search elsewhere. As my fog has been rebuilt from scratch and I dit that a while ago, I probably did something nasty.

I have to mention I managed to run FOG 0.32 in a container, with a userspace NFS server. I did that again, maybe there is something wrong with the container.

I’ll rebuild a new FOG server in a fully virtualized environment and see what happens.

I think I should lookup more closely how Junkhacker did to use a VirtualBox VM.

I’m using the same NIC from the beginning, so I guess there is something else to tweak. I guess changing the ROM is overkill if someone manages to avoid that.

I did that at first, but it does not give a clue about what’s going wrong in my case. Even the links to the source code.

EDIT : I’vread your answer too quickly. I’ll try to tweak my VM, but I’ll need some time. As I’m already able to chainload iPXE, maybe my issue is not longer in PXE itself but in my setup in dhcpd.conf.

Is it still necessary to use “next-server” to specify the source of boot.php ?

I’m actually using the Intel Pro/1000 MT Desktop NIC, I must also tell I’m using a already existing dhcp server (debian 8).

I managed to chainload iPXE with the following dhcpd configuration :

  if exists user-class and option user-class = "iPXE" {
    if exists ipxe.multiboot {
     # multiboot is a feature not available in VirtualBox, and available in the iPXE provided by FOG.
      filename "http://192.168.0.21/fog/service/ipxe/boot.php";
    } else {
      option bootfile-name "tftp://192.168.0.21/undionly.kpxe";
    }
  } else {
      filename "undionly.kpxe";
  }

I did not test the last case, for computers without iPXE, because I’m focusing on my VM.

After a boot of my VM, iPXE loads, chains with iPXE from py FOG server. I see a second execution of iPXE with more built in features. Then it fails with the following obscure message :

“Could not start download : Operation not supported (http://ipxe.org/3c092003)”

Hi all

I want to upgrade my good old FOG 0.32 to the latest release.

I noticed FOG its PXE remote boot feature from syslinux to iPXE. Great, it appears to run with “real hardware”. However, a virtual machine powered by QEMU/KVM or Virtualbox uses iPXE instead of a conventional PXE implementation.

I’m not used to iPXE and I’m lacking knowledge to chain iPXE from the BIOS of these virtual machines to iPXE provided by FOG. This appears to be necessary because iPXE in these BIOS is not enouth featureful.

I did not find a backed way to solve this problem, and I really need this to build my master images. Is there someone having success with these virtual machines ?

For Tom Eliott : sorry to make you so much trouble with the 63rd sector a while ago .

… already asked earlier

Hi

I’m working in several colleges and I wish to permit teachers to deploy computers if they need to do themselves.

It would be great to let people belonging to a specific AD group to deploy computers using their login / password stored in the AD.

Here is a small tutorial explaining how to test a valid username and password. This blog show this is quite easy; the (not sooo) hard work woud be managing permissions with an AD group.

[url]http://www.davidschultz.org/blog/2008/4/10/how-to-authenticate-against-active-directory-using-php.html[/url]

That would be a great alternative to managing accounts in the webinterface.

Hi

I created this page some time ago

[url]http://www.fogproject.org/wiki/index.php?title=Working_device_drivers_snapins[/url]

I’m used to deploy device drivers as snapins. most device drivers have a installer able to run silently. However, some drivers need to run when a user is logged on. Some of them (sometimes realtek hdaudio or ac97 depending on the computer, or some ATI video drivers) are a bit ugly and don’t run well silently.

Have a look, that’s quite nice

Now I’m using .cmd files as snapins, and they start my device driver from a SMB share. This is easier to maintain and troubleshoot. No more need to create a sfx with 7z

Hi

You may have a devective RAM chip on your target computer. Y should test it with memtest (from the PXE menu). If your RAM is OK, you mayu also test your drive with a hard drive test tool (MHDD, vivard, or the one from your drive’s manufacturer). I don’t know how a defective SSD behaves, since I never encounteered this case.

Hope that helps