K2000: BOOTMGR missing on 64-bit images
Our K2100 is on version 3.5.80613. We've been successfully deploying 32-bit images for a long time, but I went to do a 64-bit one for Win7 Ent SP1 and when the system reboots after deployment I get "BOOTMGR missing". I can use the original Microsoft disk to do a repair and it says "boot manager missing or corrupt" and it does its thing and it's all fine.
I'm using a 64-bit KBE created with the "latest" version of the AIK and the A08 driver pack. My deployment looks like this, which is identical to my 32-bit deployment except where noted:
PREINSTALLATION
UPLOAD HARDWARE INVENTORY
Y:\hta\rpc_upload_inventory.hta
PARTITION DELL DISK
select disk 0
clean
create partition primary size=10000
format quick fs=ntfs label="Recovery"
create partition primary
format quick fs=ntfs label="Windows"
active
assign
INSTALL VISTA/2008/7/8/2012 MBR
bootsect.exe /NT60 c:
MID-LEVEL
DRIVER COPY
Y:\hta\copy_drivers.vbs
POSTINSTALLATION
INSTALL KACE 5.4 AGENT
INSTALL TREND WFBS-A 64-BIT
As mentioned above, that's all the same process and the same steps I use for the 32-bit deploys which work just fine. Is there something specific to 64-bit that I'm missing?
-
Are you deploying a syspreped image? - RandomITPro 11 years ago
-
Yes. I think I've figured it out and am currently testing that theory. When I built my original image, I wasn't paying any particular attention to the partitions on that disk. Going back and looking at it, it has four partitions and we normally deploy with just 2. I'm thinking it's possible that BOOTMGR is on a different partition on that source installation. Stand by. - toddhobdey 11 years ago
-
Yep that would do it - RandomITPro 11 years ago
-
I am having the same problem as the original poster. I only captured drive c:\ so am not dealing with the recovery partition. I have successfully deploy this image before so I don't know what might have changed. - jfrasier 10 years ago
Answers (5)
I remember KACE releasing a kb article involving the windows 7 recovery partition. I followed it back when I wanted to keep the recovery partition. I have since changed my mind but Lets see....
http://www.kace.com/en/support/resources/kb/article/deploy-a-windows-7-image-containing-the-100-mb-system-partition?&p=1
Pay close attention to post install task that is created. The issue is most liekly as nheyne suggests the WinPE is improperlly assigning letters to your drive.
You need to specifiy partition letters (recovery will be C) and which partition Windows is on by using a midlevel bat script. The recovery partition is recognized as C: in KBE, and is also where the bcd is stored. As an aside, if possible I would strongly recommend scrapping the recovery partition and going with a single partition as it cuts out this sort of confusion and the KBE command line has all of the functionality of the Windows recovery tools.
bcdedit /store C:\boot\bcd /set {bootmgr} device partition=C:
bcdedit /store C:\boot\bcd /set {default} device partition=D:
bcdedit /store C:\boot\bcd /set {default} OSdevice partition=D:
Turns out, at least in my situation, the problem wasn't with the deployment side - it was with the image capture side. As shown above, normally we deploy with two partitions, the recovery (unneeded, but nonetheless present) and the OS. When I was building my image source system, I just grabbed whatever disk was laying around and replaced the existing Windows install with my new install. THAT disk turned out to have four partitions on it. Why, I don't know, because we don't ever do any dual-boot or anything like that. At any rate, the BOOTMGR must have been on another partition and therefore not included in the image I captured. My solution (more of a workaround, I suppose) was to deploy the image to a "properly" partitioned disk, then use the OEM Windows disk to do a repair, and then capture a new image from THAT disk. I now have a functioning image. Thanks to all for their suggestions!
It's probably because you're not assigning letters to the two drives you're partitioning. Diskpart is probably assigning the letter C to your Recovery partition so you're installing the boot record to that partition instead of the one containing your image. Run your diskpart commands in a command prompt and then see what letters are assigned to which partitions.
Of course that doesn't explain why it would work in 32-bit, but it really seems like this is the issue.
Comments:
-
Just curious, why are you installing a recovery partition? - nheyne 11 years ago
-
Honestly? I don't have a good answer for that. We started out trying to replicate the partitioning and diagnostics, etc, that Dell ships on new systems. And ideally we were trying to figure out a way to have the base image stored in a partition so that a machine could be recovered at one of our remote sites instead of being sent back to corporate for reimaging. But that whole thing was something we never had the time to finish up, and we removed the "OEM" partition from our imaging plan and never really finished doing anything else with that part of it. - toddhobdey 11 years ago
-
If you're using WIM imaging, that is probably as fast if not faster than using a recovery solution in my experience. And it makes partitioning simpler. Well, of course if you don't count relocating the physical machine to image. - nheyne 11 years ago
-
I knew that a recovery partition wasn't really worth the hassle to deal with, but I did like an OEM partition because it included the DELL diagnostics that my techs were required to run. I ended up writing a script that utilized diskpart to detect OEM partitions if present and install, partition accordingly. I could share if you'd like. - RandomITPro 11 years ago