/build/static/layout/Breadcrumb_cap_w.png

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?


3 Comments   [ + ] Show comments
  • Are you deploying a syspreped image? - RandomITPro 10 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 10 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)

Posted by: SMal.tmcc 10 years ago
Red Belt
0

The only thing I have different I format the drive prior to MBR.

Posted by: RandomITPro 10 years ago
4th Degree Black Belt
0

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.

 

Posted by: mpace 10 years ago
Red Belt
0

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:
Posted by: toddhobdey 10 years ago
Yellow Belt
0

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!

Posted by: nheyne 10 years ago
Red Belt
-1

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 10 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 10 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 10 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 10 years ago

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ