Posts made by RuralIT

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

Yes. We join workstations to the domain using FOG after imaging has finished. This works great for us.

Thanks Matt. Ya, I’ve read through that blog. And it was helpful. I should have included it in my list above.

However, I do have the network set to “Work” in unattend.xml. That’s what really irks me. That and the fact that it is the one remaining problem that makes my unattended install need an attendant.

I’ve been working at creating Windows 7 images for the first time and have been having a lot of…fun. Since others have been down the same road, I’m betting they can save me, and anybody else who reads this thread, a bit of frustration.

I’ve been using Windows 7 Enterprise but have ran into a problem where it asks which network location to use (ie. Home, Work, or Public). So I’m trying Windows 7 Professional SP1 instead. Hopefully, the problem doesn’t exist with 7 Pro. Anyone care to confirm?

The following links have been really useful as I try to wrap my head around Sysprep in a Windows 7 world. In order of decreasing value:

[url]http://blog.ibuddy.info/index.php/2011/05/fog-29-my-windows-7-guide-3264-bit-docv1/[/url]
[url]http://www.fogproject.org/wiki/index.php?title=Create_a_windows_7_image_for_many_different_hardware[/url]
[url]http://community.spiceworks.com/how_to/show/2224[/url]

Also, I can’t stress how important it is to use some sort of virtualization environment, and one that supports snapshots. This is a huge time-saver and also a way of avoiding a silly arbitrary limit to the number of times you can run Sysprep on a workstation.

As I write this, I’ve figured out the basics of Sysprep and configuring Windows 7 similarly to how we’ve been using Windows XP. Still have a way to go, but progress is occurring.

That is almost exactly how I’ve imaged our Windows XP machines since we started using fog about 18 months ago. I’ve had no problems.

I’m not sure about the “pre-activated” part. In Setup Manager, we use “fully automated set-up” and choose a workgroup (we [I]do not[/I] join it to a domain). When running Sysprep, we use the mini-setup option and choose reseal. The warning about SIDs can be ignored.

We’ve noticed no issues using the above.

Thanks pbhound. We’re actually not using Windows Server 2008. We’re using Samba. So no Group Policies for us (at least until Samba 4 is released and stabilises). For Windows XP we were able to use Windows NT-style System Policies, which worked. However, I was beginning to lean away from them anyway. Local policies and registry hacking work and FOG makes it simple enough to deploy them to groups of machines.

So we have a bunch of carts with 20 or so netbooks/notebooks. The idea being that a teacher wheels the cart into the room and the kids go to town. They sort of work, but having a bunch of kids log in near-simultaneously is a real strain on wireless. (If anybody has some hint on how to best configure Windows 7 to minimise log-in time yet still allow domain logins, I’m all ears.)

I’m not going to ask if we can use FOG to do wireless PXE booting and imaging. That wouldn’t work. What I am wondering is what strategies folk who use FOG in this kind of environment do. The best I can come up with is just to do all my imaging via the wired network. Then disable PXE booting. I don’t really see an alternative, but maybe someone else has come up with something more clever.

Hmmm… I thought I would have more bites. This seems like it would affect just about everyone. So there must be something about this somewhere. I’ve searched the forum for “Default User” and “DefaultUser” and come up empty. I did manage to confirm that Windows 7 [I]can[/I] create the DefaultUser profile from the Administrator user’s when using Sysprep. A setting has to be set in unattend.xml (which I’ve never used). Details are [URL=‘http://support.microsoft.com/kb/973289’]here[/URL].

Looks like I get to get my hands dirty with the new tools.

We don’t use AD Group Policies. We used System Policies with Windows XP, but now that we are moving to Windows 7, that doesn’t seem to work. (For whatever reason, the System Policy, that works fine on XP, doesn’t apply to Win7 machines.) So we’re left trying to get the Default User set up properly, the main issue being Folder Redirection.

So how does one make a Default User profile in Win7? Or do you even have to? Does it just get copied from the Administrator user? The FOG User Guide alludes to that, but I haven’t seen anything concrete.

It worked. In a nutshell, my procedure for moving FOG to a new server was as follows:
[LIST=1]
[]Install Ubuntu 10.04 LTS (server) on the new hardware, using whatever IP address DHCP offers.
[]Install FOG on the new hardware, making sure to configure FOG with the IP address that will get used. In my case, this was the IP of the old FOG server.
[]Copy images from the old server to the new.
[]Backup the database on the old server, restore it on the new.
[]Shutdown the old server or move it to a different IP address.
[]Move the new server to the old server’s IP address.
[]Set the password for the fog user to whatever FOG_TFTP_FTP_PASSWORD is on the new FOG server’s web interface.
[]Confirm that everything works as expected.
[/LIST]

Cool. And as luck would have it, I’m in the position to try this out today. Fingers crossed.