We’ve begun seeing that certain workstations (Lenovo Thinkcenter M72e, HP Elitebook 8530p) will PXE boot fine, load up the FOG kernel and do whatever FOG needs, but they won’t fall through to the HDD. Instead we get the blinking cursor on the top-right of the screen.

Our workaround is to change the BIOS boot order to boot off the HDD, and hit an F-key during boot to choose PXE booting when we need to do FOG stuff, but this kills remote imaging (something we’ve come to depend on).

Has anyone else seen similar behaviour? Any fixes?

We never figured out how to get a FOG server and client up and running in VirtualBox. I’m sure I initially tested FOG under VirtualBox successfully, but that was more than three years ago. I think it was just a case of choosing the right virtual network hardware and/or chipset.

And I never got time to look at it myself, which happens at this time of year.

We ended up setting up FOG on an old workstation (this is just to get the summer student acquainted with FOG) and tried imaging some new Acer desktops. It works, but there BIOS is a little funny. You can PXE boot or HDD boot, but you can’t PXE boot and then fall through to the HDD. So we have to change the boot settings in BIOS, image, then change the boot settings back. We won’t be buying any more of this model of computer.

[quote=“Jaymes Driver, post: 12372, member: 3582”]If you are still having issues I recommend using a custom built kernel, I had to do so to use VMWare, and I take back what I said before about VMWare, Stay on Virtual box, it’s a much easier program to use!!![/quote]

Our summer student has kept pushing on this, and looked into an alternative to pxelinux. I think I’ll set up a FOG test environment myself in a VBox test network sometime soon…but I’m on vacation at the moment. It will have to wait at least until Tuesday.

We ran into this [URL=‘http://www.fogproject.org/wiki/index.php/Boot_looping_and_Chainloading’]link[/URL] on chain-loading in the FOG documentation. We’re looking into this now.

We’ve looked into this a bit more, trying physical machines and… We get the same problem. This is really strange as we’re just using a standard FOG .32 install followed by upgraded to the newest kernel, but any machine PXE booting from FOG won’t then be able to fall through to boot off its local hard drive.

I really want to repeat what the summer student has done to confirm it for myself, but I can’t really see how one could mung things up in a way that would have this affect.

I have a summer student working with FOG and he’s using VMs to get his feet wet. Using VirtualBox, he’s set up a FOG server guest and a Windows 7 guest. The Windows 7 guest will PXE boot, register, and upload an image (raw at the moment).

The issue we’re running into is that PXE booting into FOG then on to the OS on the local disk doesn’t work. Instead it just hangs with a message ‘Booting to local disk…’.

The same guest will boot Windows 7 fine if we turn off network booting in the guest’s VirtualBox settings.

This seems like a VirtualBox related problem to us. Any ideas?

VirtualBox 4.2.10 on Linux (Ubuntu 13.04). FOG 0.32.

That bit about little submitted code is really worrying. From surfing the forums I got the impression that Chuck and Jian were still quite active but I guess getting down to coding, or at least submitting code, hasn’t been happening much.

I’m also really surprised that the donations are so minimal. Then again, we haven’t donated anything. But still, with the value that FOG brings, I assumed that the donations would be flying in. Hmmm… Maybe some crowd-funding is needed.

Thanks for some transparency on this Bryce. We’ll be in touch.

In no way is this meant as anything but constructive. It seems like most of this would have been discussed at some point, but I’m not finding it in the forum.

Like many others, we’ve come to depend on FOG. We’ve been starting to feel a fair bit of pain when it comes to imaging (U)EFI machines and have been hoping 0.33 would help with that. We’ve been waiting a long time, but I’m beginning to think we should stop waiting and should start helping out.

I’d like to better understand the issues that have delayed 0.33. I’m betting that a couple of key people moving into new jobs may have been a primary factor but maybe there was a major change in direction that ended up causing more pain than was expected. (I’ve been on the wrong end of that a few times myself.)

I’m also curious about the donations. Are they significant or so small as to just be a pain to manage?

We’re lucky enough to have two programmers on staff and will be adding a third in about four months. FOG is important enough to us that we want to begin donating some time. Any advice on how to get involved on that end would be appreciated. We were going to just download .33 and begin banging away in a test environment.

Basically, I’d like to see a discussion of how the community can help out, really help out.

Andy, I wish I could help you, but I have no idea what could be causing your issue other than a problem with redirecting directories in profiles. If you are using an old Windows Server or Samba file-server, it may be unable to authenticate and the profile can’t be transferred. But that is just a wild-ass guess.

As for my annoying Network Location issue, I used Kyle Wadman’s unattend.xml (available [URL=‘http://blog.ibuddy.info/index.php/2011/05/fog-29-my-windows-7-guide-3264-bit-docv1/’]here[/URL]) and it went away.

Of course, now I’m noticing that Microsoft Security Essentials loses it’s configuration (and malware database) after a Sysprep.

Kirksec, I’m not sure of the default behaviour of Sysprep, but I know that you can set an option to copy the Administrator profile to the DefaultUser profile in unattend.xml. I’ve just confirmed that it works. (As I’m sure many others have before me.)