Posts made by Bobfrid

Well, flipping the BIOS to IDE is quick and worth at least a try. I can’t imagine it’ll fix it, but I’d try it anyway. Maybe a BIOS update if one is available could help.

I checked this: [URL=‘http://www.fogproject.org/wiki/index.php?title=WorkingDevices’]http://www.fogproject.org/wiki/index.php?title=WorkingDevices [/URL]and it looked like somebody was only able to get the HP 6005 Pro Business Desktop to work with a Multiple Partition Image - Single Disk. I don’t know how that does or doesn’t translate to your 6000, but it might be related. There are also mentions of some notebooks having problems with AHCI mode, so maybe creating the image in IDE mode might produce a working image. It’d at least be possible to switch to AHCI post deployment with a registry change or two.

Also mentioned were some forced kernel options on some HP models. I’ve not tried any of that, perhaps someone who has can advise?

I’m trying to think of anything else that’d help nail this down, but drawing a blank. Anybody else with some good ideas?

From here, my suggestions are apt to start entering the realm of insanity: Like try putting the drive in one of the working machines and see you get something more than the blinking cursor. If it got to the Win7 splash and then bailed, that’d be interesting.

Or, vice versa, take an imaged drive from one of the other working computers and try to boot the 6000 with it and see if that gets stuck at the blinking cursor.

I’ll keep thinking on this and if I think of anything that seems half reasonable, I’ll let you know.

One thing I’d try is putting a Windows 7 disk in the imaged computer and see if it can fix whatever is wrong with the boot partition. If it does, you might try capturing that image, redeploying, and see if bootmgr is missing again.

I looked around the forums for more missing bootmgr stuff, I’m not sure if the workaround and the end of this thread is useful:

[url]http://fogproject.org/forum/threads/bootmgr-is-missing.233/[/url]

You indicated this was only happening on one type of machine…

Can you create a new, plain Win7 image for troubleshooting? Wipe a disk, load Win7, sysprep, upload, deploy, see if it works? If that fails, then I have to be thinking a setting on the bios needs changing or something.

When multicasting, you’d need to add hosts that you wanted imaged added to a group. Then you’d go over to task management, list all groups, and click on the multicast symbol next to your group name. At least, that’s what I do on version .32

If you are going to host management, clicking on an individual host, clicking on Basic Task, and then clicking Deploy, you’re unicasting. Even if you set up several tasks at once in this fashion, it still unicasts to the individual hosts.

It seems really odd that the XP image deploys fine, but Win7 has problems. Is there a significant difference in size between the two images?

Could there be an active task still running for that machine? You might have to kill it before anything else happens.

If I’m understanding correctly, the target machine is starting the PXE boot, but isn’t getting to the list of options for inventory/memtest/etc. ?

Hi Tangerine,

I’ve not played with dual boot, but the success you had capturing and deploying the image to the original machine leads me to believe you’ve got all of that set right.

Off the top of my head, I’d guess the two 40GB disks aren’t the exact same size. You can boot both into debug mode and check with “fdisk -l /dev/sda” to verify. However, doing just the Win7 + data partition (I’m assuming multiple partition - single disk image) and having that deploy correctly makes me think that isn’t the case. Do you have a larger capacity drive you can try deploying to, say a 60 or 80gb drive? If that also failed, that might give somebody more experienced than I an idea on what could be wrong.

Another guess would be the sata controller mode, could the “other” machine be set to something different in the bios?

If I come up with anything else, I’ll post.

Which OS and version of Fog are you using? I’ve only used 0.32, but if you’re on an older version, somebody who’s had experience on that version may be able to offer some advice.

Oh, if you have specs on your Fog installation, flavor of linux, model(s) trying to image, etc, that might help in case there’s a specific issue with some combination of hardware/software.

Hi Dug,

I found this mentioned from this Fog guide: [URL=‘http://blog.ibuddy.info/index.php/2011/05/fog-29-my-windows-7-guide-3264-bit-docv1/’]http://blog.ibuddy.info/index.php/2011/05/fog-29-my-windows-7-guide-3264-bit-docv1/ [/URL]
[QUOTE]
[LIST=1]
[][LIST]
[]Scott S
[]June 14th, 2011
[/LIST]
[LIST]
[]REPLY
[*]QUOTE
[/LIST]
Kyle,
Just wanted to mention that building your W7 master image with VMWare Workstation works as well. I followed your guide and everything appears to be working just fine
Just one note of caution! If you are using VMWare, make sure you do not let VMWare Workstation do an “easy install” of your Windows 7 installation. If you do, the additional 100mb partition will not be created. Not allowing this partition to be created will cause issues when you try to upload your master image. Fog looks for that 100mb partition when you upload a W7 host. If it doesn’t exist, the upload will fail (blue upload screen flashes and restarts the system). Several hours of frustration until we figured that out!
[/LIST]
[/QUOTE]
When you’re doing the single partition/single disk upload, by 1 partition, do you mean that it’s just the primary partition without the 100mb partition? This might be the issue, but it’s odd. Blackout has said that he removes the 100mb partition and it works.

I’ll keep thinking on it and see if I come up with anything better, but if anybody else has solved this or a similar issue, please post and help Dugjones out!

Never tried a T3500, but can you do the deploy w/ debugging? I’d be curious to see if from the command line you’re able to see /DEV/SDA or whatever else. This might help point to where the problem might be.

Could there be any other devices that are plugged in that might be recognized as some type of storage and throwing off FOG? Or maybe the controller mode (RAID, SATA, AHCI)?

A workaround I’ve been able to do is just move the drive into another model of computer you’ve been able to upload from and capture the image from there, since FOG is only grabbing the image and doesn’t care what the actual computer is (as I understand it, anyway). Well, unless it’s a T3500 I guess. This would at least allow you to get the image onto the server.

My guess is that deploying said image to the T3500 would be a problem as well.

I, for one, can’t see any way that PXE or FOG could cause this situation.

Was the NIC actually working in the 2K box prior to capturing the image? Not knowing how it is used, I could imagine a situation where the NIC had been down for some time, you image it, someone notices the NIC isn’t working, and since you touched it, you own it (in their mind), even though there isn’t a way FOG or PXE couldn’t have changed things.

I might check the network cable, especially if a different cable was used for capturing the image. Or the pins on the NIC, wall jack, hub/switch/whatever else it’s connected to. I’ve seen pins pop out, get crossed, and other strangeness.

You could also try a safe-mode boot and see if that gets you anywhere as far as being able to log on. Or even an Ubuntu LiveCD. If you’re getting network connectivity there with the same cables, etc., I’d guess it is a driver issue.

Only other possibility I can think of (and this is pure speculation) is there might be a damaged bit of the hard disk where the NIC driver (or other files) live and aren’t able to be read. Perhaps the activity on the disk pushed it over the edge, but it would have failed sometime soon anyway in that case. Short of being able to log onto the 2K installation, I don’t see how you’d be able to troubleshoot this one.

You’ve demonstrated the NIC still functions, FOG doesn’t change anything on your computer when capturing an image (as I understand it), and you had no way of logging onto the computer to change anything.

I believe so. I’ve not done any work using FOG and VMs, but I’d think a virtual Win7 image with a single partition (excluding the aforementioned system partition) ought to image in the same fashion. Maybe somebody’s who’s done this with VMs can reply and verify or offer tips.

As far as using the resizable single disk Win7 image for conventional machines, it works great! I’ve been deploying a roughly 20GB image to all sorts of different drive sizes and it’s done very well.

Well, if it’s deploying RAW and you get a bootable image and want to use it… I guess I’d deploy it, verify the hidden 100mb partition was restored by Windows, sysprep it, then upload the image again as Single Partition/Single Drive, and it should be able to resize it as intended and save you a lot of space and deploy time.

Unless I’m missing something or not understanding something else, I think that might work.

If you wanted to be sure, I’d just start with a new image of a fresh Win7 install that had the 100mb partition and verify your fog setup is accepting the Single Partition/Single Drive upload before attempting anything else. It’ll save a lot of time down the road, in my opinion. Once you’ve verified that part is working as intended, it’ll be easier to find any other issues that might occur.

The single disk/single partition does work for windows 7 as long as you don’t have a recovery partition in the mix also. I just uploaded a Win7 image this morning with the 100mb partition and the regular partition and have been deploying the image successfully.

I agree, it does seem logical to pick the Multiple Part/Single disk, but Single/Single accounts for the 100mb partition and has worked for me.

Try uploading it, worst case is that it won’t upload, but barring some other problem, it should.

I think BryceZ is correct with suspecting a HDD problem.

From my experience “Buffer I/O Error’, ‘on device sda1’, ‘DRDY Error’, ‘ata1.00’, ‘logical block error’” is among a number of error messages that occur when a drive can’t be read at a certain point. Since you’re getting the same error using FOG and chkdsk, I would tend to think there’s hardware issue.

First thing I’d do is reseat any connections to the HDD and/or motherboard and make sure you don’t have a loose cable (I suspect not, but it doesn’t hurt to be sure).

You can try moving the drive to another computer and upload the image from there. If that worked, I’d suspect the hard ware in the original machine as being the problem.

If you got the same error, then I’d believe there’s a problem with the hard drive. At that point, I’d try another very basic image from a different hard drive and see if you can upload an image then.

Also wanted to say thanks to everyone involved in developing FOG. It’s a terrific tool and I’ve had great success using stand-alone servers for imaging. I’m hoping to take advantage of the more advanced features soon.

Even though we’re a “Microsoft shop”, I don’t think I’ll have trouble convincing the powers that be to make the switch, considering I was able to deploy 30 new laptops by myself in less than 3.5 hours using FOG, 2 5port-100Mbit switches, and minimal cursing.

Again, thanks all!