Posts made by dugjones

[quote=“Nate Baker, post: 24539, member: 23116”]I know this thread is old, but wondering if anyone else has had success with this?

Doug, your method sounds like it would work great, but I’m wondering if that would work with critical drivers such as storage and network? Or do you need to have the storage and network drivers in the image already, and install the rest of the drivers using that method? It seems like since that oobeSystem pass is the last pass, it would need the storage and network drivers by that point.

Thanks,
Nate[/quote]

Sorry for the late reply. You are correct, Nate. I inject mass storage and LAN drivers into my base image for all the models of computers we deal with here before sysprep.

I wanted to update my post in case others where having the same issue. I have not figured out the problem with capturing/deploying a resizeable image on Win7 but I did get a decent work around in place. Basically I used Stephen Perkins [URL=‘http://fogproject.org/forum/threads/resizing-partition-with-windows-7-image.250/#post-1332’]post[/URL] idea of just adding a command to my unattend.xml to extend the OS partition during sysprep since I was able to capture and deploy a non-resizeable image with no problem.

Thanks Stephen, I just used your technique and it worked great. I had tried scripting it but the scripts apparently wouldn’t work probably due to permissions.

Great! Glad you got it working.

That is interesting. I find this strange as I have created over the past couple of months single partition resize-able images as well as dual partition resize-able images (for windows 7) and all has worked flawlessly. Now all of a sudden I am having problems both capturing and deploying them. I have not changed anything on my FOG server and have been using it to image XP machines for the past 2 years. Although others have posted having similar problems I have seen no real viable solutions to speak of. I don’t understand how the scripts can appear to be changed/wrong as I have not updated my FOG server so why the errors?

What happens if you do a deploy-debug and then manually dd the d1.mbr to the hdd? Does that work okay?

Thanks for the reply Bobfrid. I am using an Autounattend.xml to create the single or double partition setup. I am using FOG .29 running on Ubuntu 10.04 server. I have been using this setup for awhile now with windows xp with no issues. I have created the image on physical machines (several types) but am currently working in a VirtualBox virtual machine running on Linux Mint 12.

Playing around this afternoon I was able to manually capture the image by using the commands in the /bin/fog script (partimage save …) but when I deployed it it wouldn’t boot. I’ll continue playing around next week…

I am developing my Windows 7 image and am having a couple of problems. I posted in a separate post but this sounds like similar issues and seems to be an active post.

1. When I try to capture a Windows 7 Enterprise image with 1 partition it immediately fails when starting the partimage (blue screen).

2. I have successfully captured an image with 2 partitions (Includes the 100mb part) but when I try to deploy it I get a BOOTMGR is missing error.

As it is I cannot seem to either create or deploy a Windows 7 image in FOG. I have tried this on various hardware as well as in a virtual machine all with the same result. Others have commented in my post to having the same issue. Any ideas??

Sorry, Tim, I should have mentioned that I am running on .29 so I am not sure if the script changed at all but it certainly sounds like the same problem. If you are getting the same error about the backup path doesn’t exist (right after the blue screen goes by - you have to scroll up to see the message) then I assume it is the same issue. What do you mean by swapping out the older version of the script?

Hi Tim,

I am having the same issue and mention it under my BOOTMGR is missing post (I should have created a new post). I don’t have a resolution but I have noticed that there seems to be an error in the FOG script ( /bin/fog ) If you scroll up using the <shift> key and the <page up> key after the blue screen flashes by in debug mode you should see an error. There appears to be an error on line 624 that causes this. I fixed that error in the script, however, now I am having a problem regarding partimage not being able to determine the file system type. I haven’t gone further yet to see if I can fix that. Any help is greatly appreciated!

I have imaged both Windows and Linux systems with FOG and they both work fine but have never tried a dual boot system. FOG does backup and replace the MBR but I believe it determines the type based on which OS you told FOG you are imaging. You probably would want to tell your image that it is a linux image in FOG due to the fact that you are using grub boot mgr.

I always used the debug options when trying to troubleshoot imaging but I am unsure of whether there are logs created that would be helpful.

I have more info on this. I was able to hold down <shift> and <page up> to scroll up in the buffer to see what the error message was when it bombs on the “blue” imaging screen. There are two messages, actually, here they are in order:

Warning: Unable to open /dev/sr0 read-write (Read-only file system). /dev/sr0 has been opened read-only.

chmod: cannot access `/images//images/080027d6bb31’: No such file or directory

It sounds to me like there might be a problem in the fog imaging script but I am not sure where to look…

EDIT: Whoop! This is the message when I try to capture a single partition image. I was trying to recapture the image using 1 partition instead of two.

EDIT2: Upon further testing I found that the first warning was caused by an .iso file I still had mounted in the virtual cdrom and didn’t appear to be causing any problem really. I did find that by poking around in the fog script that line 624 appeared to have an extra /images/ in front of $tmpBackupPath so modifying it got rid of the second error. Now I appear to be getting an error from partimage that is indicating that the file system type is listed as -unknown- and is therefore not supported.

Awesome! Glad you got it working!:)

Not sure if this will help you but I have seen our server do this when the loaded kernel doesn’t contain the proper NIC driver for the computer. You can change it easily by clicking on the “i” icon (lower case “i” in blue circle) in the Fog console then select “Kernel Updates” on the left hand menu. Now, scroll down the Published kernels to install a new one.

We have noticed that some of our newest machines require a new kernel (ie. kernel 2.6.39.1) but our older machines require us to load an older kernel (ie. kernel 2.6.35.7 KS). Unfortunately, I don’t think there is any way to know which is currently loaded but you can load different kernels and retry the imaging process fairly quickly.

Hi All,

I am having a problem deploying a Windows 7 Enterprise resize-able image. The image captures fine both using the 100mb double partition and as a single partition configuration using the resize-able and non-resize-able options.

I can deploy the image fine if I use the non-resize-able option but if I try to deploy the captured resize-able image i get the “BOOTMGR is missing” error. I can boot into a PE environment and run “bcdboot d:\Windows” to fix it which works fine but that is obviously a work around for now. I don’t understand why this is happening.

I have searched the forums and the only advice I saw was to be sure to chkdsk and defrag the image prior to capture which I do. I also use the /generalize option when sysprepping the image but I also tried running the Fogprep.exe just in case.

Any ideas what I am doing wrong?

I have not had success with getting drivers to install using the DriverPaths option in the unattend.xml. Admittedly, though, I have not spent a lot of time trying to get it to work. I do have my fog installation modified to copy the specific drivers for the computer build down to a folder on the drive after imaging but before booting. It wasn’t a simple thing to configure so unless you are already skilled at writing bash scripts or are very determined to learn you may want to find another way to get the drivers on the pc.

The way I am currently handling driver installation is that I put a Windows-Shell-Setup / LogonCommands entry in the oobeSystem to launch an AutoItv3 executable which launches the dpinst.exe (which points to the folder previously mentioned). There is probably a better way to do it but I had my Windows XP installs doing something similar so I just modified it slightly. I have only tried it with a couple of different builds so far but it works well. One nice thing about dpinst.exe is that it has a force option (/F) which forces your specified drivers to install even if they are not considered “better” by Windows.

Dpinst.exe is part of the Microsoft Windows Driver Kit (WDK) and it does include 32bit and 64bit versions. Below is a link to a technet article that should get you started.

[url]http://blogs.technet.com/b/svengruenitz/archive/2008/07/02/driver-installation-and-updating-made-easy-dpinst-exe.aspx[/url]

Doug