The boot images are not updated between version releases, so the 0.29 boot image was the same from release until 0.30 which received an new boot image, and so on.

Which version of the boot image are you using? The wiki says that the Z400’s work with 0.29, but there were some significant changes between 0.29 and 0.30 which have been problematic for a number of people.

Could you please describe the process of what happens step by step, to try to pin down where it’s failing.

What happens when you try to register them from the boot menu?

Unfortunately I’m not a kernel expert. I would think that a newer KS kernel would be more likely to support your newer motherboard. It seems like you need a module that’s not compiled into the 2.6.36.1 Core.

Duffney, what is your TIMEOUT set to? TIMEOUT is counted in tenths of a second, so TIMEOUT 50 is 5 seconds. I’m not a 100% sure on this, but I think without a TIMEOUT set it will just go straight to the DEFAULT option.

I’ve looked into this in the past, it happens a lot with 960’s, and it appears to be related to the way the kernel goes through the shutdown process. [url]http://linux.koolsolutions.com/2009/08/04/howto-fix-linux-hangfreeze-during-reboots-and-restarts/[/url] seems to be related, though I haven’t had a consistent set of results on the same model of optiplex, so I stopped trying to figure it out for now.

Peter, have you tried updating the kernel? Not all kernels are built the same. Unfortunately there is no great listing (that I’m aware of anyway) that correlates kernel to compatible hardware sets other than on the FOG [URL=‘http://www.fogproject.org/wiki/index.php?title=WorkingDevices’]wiki[/URL], which is far from a complete listing. I’d suggest trying different kernels to see which ones work for your hardware.

FOG Web Console->Hosts->%pick-a-host%->General->Host Kernel.

First guess would be that you either have some severe network congestion, which would be very noticeable in other areas, or the FOG server is running on faulty hardware. You might want to try the steps listed on the wiki for a [URL=‘http://fogproject.org/wiki/index.php?title=Tftp_timeout…’]TFTP timeout[/URL].

[FONT=Tahoma][COLOR=#141414]My apologies to anyone trying to read this thread without having seen it first on the [URL=‘http://sourceforge.net/projects/freeghost/forums/forum/716418/topic/4719993’][COLOR=#555555]sourceforge forum[/COLOR][/URL], I was not aware how much the formatting was messed up.[/COLOR][/FONT]
[FONT=Tahoma][COLOR=#141414] [/COLOR][/FONT]
[FONT=Tahoma][COLOR=#141414]My first thought was something like “Great! Deeper AD integration will remove the hassle of setting everything up the first time, and might even be able to maintain things in an orderly fashion!” but I have a hard time believing anything like that would be easy to implement or work as smoothly as I would like.[/COLOR][/FONT]
[FONT=Tahoma][COLOR=#141414] [/COLOR][/FONT]
[FONT=Tahoma][COLOR=#141414]Some initial questions for this approach:[/COLOR][/FONT]
[LIST]
[]Would FOG do a scheduled pull from AD or would a manual import be simpler to maintain?
[]Would these groups be locked down in some way, or would users be able to add or remove hosts from a group built by AD?
[*]How would this play out in a host swap scenario since the new host wouldn’t be in the correct OU until it’s finished imaging?
[/LIST]

[URL=‘http://www.fogproject.org/wiki/index.php?title=FIX:_Chainloading_alternate_SYSLINUX_to_force_boot_from_first_hard_drive’]Chainloading[/URL] is what you’re looking for.

Another option would be to try adding “acpi=off” to Host Kernel Arguments on the web console.

Is this a standard installation of Windows 7 from the DVD or a preinstalled OEM installation? Single Partition is the preferred image type for standard Windows installations as it allows you to deploy to HDDs with different geometries. With deploying a non-resizable image to a different model of HDD can potentially cause problems.

The problem you’re describing sounds like a “corrupt” MBR that doesn’t match the disk geometry.

The BIOS errors are obnoxious, but for the most part harmless, at least they generally don’t prevent imaging from occurring.

The fogproject wiki link I posted describes how to setup chainloading in FOG, but it is rather light on details explaining what chainloading is… the [URL=‘http://en.wikipedia.org/wiki/Chain_loading’]wikipedia article on chainloading[/URL] is slightly more descriptive but is not very thorough…

Chainloading, in this context, could be described as linking from one boot device to the next. In theory, when a computer network boots to FOG it pulls down PXELINUX, which includes the FOG boot menu, unless a task is assigned to that host, and when no task is assigned and no action is taken the boot menu attempts to return to the BIOS for the next boot device. For some reason, and there are some opinionated explanations of this around the internet, certain BIOS/chipsets (generally seen with newer Dell Optiplex models) don’t accept the return to BIOS for the next boot device and promptly reboot. Chainloading bypasses the return to BIOS and statically calls the first disk drive on that system. This method has it’s drawbacks, and is not ideal, but so far I’ve been unable to find an alternative.

[URL=‘http://www.fogproject.org/wiki/index.php?title=FIX:_Chainloading_alternate_SYSLINUX_to_force_boot_from_first_hard_drive’]Chainloading[/URL] can fix the boot looping issue. I’ve never encountered the DVI issue, and while FOG likes to complain about BIOS not being supported it generally works anyway. If it refuses to work with the BIOS you might want to try using a different kernel, in the FOG console under About->Kernel Updates.

[URL=‘http://www.fogproject.org/wiki/index.php?title=FIX:_Chainloading_alternate_SYSLINUX_to_force_boot_from_first_hard_drive’]Chainloading[/URL] might help with this.

I can’t go into all the details for setting it up, because I only worked on it from the FOG side, but a while back we were able to “bypass” the FOG authentication system and “replace” it with a [URL=‘http://shibboleth.internet2.edu/’]Shibboleth[/URL] installation. This gave us pseudo centralized logins. Quick overview: the Shibb team added FOG as a service provider and we modified the /management/includes/loginform.include.php to use a static random character password that all accounts were set to in FOG, and set the username to $_SERVER[‘REMOTE_USER’].

Hitting the URL forces you to the Shibb login page and you can’t get past that without a Shibb user account, and then it fails if your username doesn’t exist in FOG.

It’s rather hacked together, although it works pretty well, but I’m wondering if there is going to be a better method of external authentication with 0.33.

I’ve been running that way for almost a year without a problem.

The bootloader issue is tied to the Windows 7 OS setting on the host in FOG. When you select Single Partition as the image type and upload an image FOG ignores the hosts MBR, so the actual MBR never gets uploaded. When deploying that image to a host FOG checks what the OS type is set to and applies a “generic” MBR. FOG’s Windows 7 generic MBR expects the 100MB partition to be there, which is why you’re having problems booting after imaging.

My first guess about the errors during upload would be that the HDD has problems, possibly a bad sector or failing controller board.