none
How to force use of x86 boot image? 32-bit VMware guests use x64 image on 64-bit host, then blue screen upon boot

    Question

  • I created custom boot images based off build 7600 and they both work for x86 & x64.  The problem I'm having is that if I have a VMware guest running on a 64-bit ESX/ESXi host, and specify the OS to be 32-bit, it tries to boot the x64 image and blue screens.

    I tried removing the x64 image to force it to only boot the 32-bit image, but I just get that pesky "connecting ....." and it never boots.

    Any ideas?


    ~Luke
    Monday, July 12, 2010 10:21 AM

Answers

  • Cougar - try switching all of the 64-bit sequences to use the 32-bit image, then see what happens. Restart the Windows Deployment Services service every time you make changes, too.
    • Marked as answer by cougar694u Tuesday, July 13, 2010 6:52 PM
    Tuesday, July 13, 2010 2:16 AM

All replies

  • When you configure your TS, you can choose which boot image you want it to use.

    I Install Windows 2003X86 on ESX X64 with no problem.  

     

    Monday, July 12, 2010 11:06 AM
  • Correct, but this is the initial PXE boot image I'm referencing.  It seems random, but uses the 64-bit boot image the majority of the time, downloads it, then starts to boot and blue screens because ESX is limiting the guest to 32-bit.  Every once in a while it will pull the 32-bit image and boot fine.

    I never get to the option to choose which TS for the 32-bit TS with associated 32-bit boot image.


    ~Luke
    Monday, July 12, 2010 11:33 AM
  • Do you refer to the wdsnbp.com file when you talking about the first image ?

    Have you pre-stage your computer with its mac adress wich allow you to choose a specific TS ?

    Monday, July 12, 2010 2:16 PM
  • No.  I'm referencing the boot.wim file it downloads in order to PXE boot.

    I'm on 2007r2 sp2, supporting unknown computers, no pre-staging necessary.


    ~Luke
    Monday, July 12, 2010 2:23 PM
  • Do you have two task sequences advertised to all unknown computers, one with x86 as the boot image and one as x64? Been a while since I played with PXE, but try disabling the x64 advertisement/sequence. If that fails, I heard it chooses which boot image initially based on "last updated" - so maybe try updating the x86 image.

    If possible, I'd remove the x64, because you can deploy x64 via an x86 image just fine.

    Monday, July 12, 2010 5:32 PM
  • The PXE process makes an autodetect of your architecture. If the processor is X64 capable, it will boot on the X64 boot image, unless you prestage your computer.

    With WDS it was possible to skip the autodetect and require the user to choose an image. I am not sure it's possible with SCCM but I tkink you must search in this way.

     

     

    Monday, July 12, 2010 6:26 PM
  • True there is an auto detect but SCCM overrides this if there are advertisements for TS's that only have x86 PE images assigned to them.  If there is an advertisement for a x64 TS then it will default to the x64 image.  This is how it worked for me since the beginning and I was using exactly the same method for PXE (option 66/67).
    Scott Gill
    SCCM Consultant
    Monday, July 12, 2010 6:56 PM
  • Hi Luke,

    I am not sure about your issue as you havent specified that where exactly the blue screen comes and the message on the blue screen ( hex code). During the PXE deployment process it downloads image twice.

    Consider your VM has a Physical Computer. (VMware guest running on a 64-bit ESX/ESXi host, then take it as 64 bit physical machine). We can install either 32 bit or 64 bit image on it (You have custom image).

    First time we boot a machine, depending upon the architecture it downloads the boot image ( in our case 64 bit image). We will find 64 bit image booting for the first time while doing a PXE boot. As far as I know that we can not force it to boot from 32 bit image unless we donot put 64 bit image on the distribution point.

    Second time it downloads the image depending upon the TS we have advertised. It can be 32 bit or 64 bit.

    Now when you get a blue screen, you need to be clear when exactly are we getting and what is the STOP code does it display? Generally we get these bluescreen during the boot time if we donot have appropriate drivers in the boot image. Those drivers are either Network driver or Mass storage driver. Therefore I recommend you update you boot images with appropriate drivers. (Needless to say, 64 bit boot image should have 64 bit VMware network and mass storage driver , 32bit boot image should have 32bit vmware network and mass storage drivers) If the issue does not resolve then I will request you paste the exact point of process where we are getting the blue screen and the hex code.

    Harpreet Rana


    Harpreet Rana
    Monday, July 12, 2010 7:04 PM
  • @mike.gaal - Yes, I have both advertised, and tried removing the x64 as you stated, but it doesn't boot at all.  It just says contacting server ...... and never actually boots.  I tried the 'last updated' method as well, but it still seems to randomly choose the bit level (perhaps not random, but appears that way to me).

    @Scott Gill - I have TS's that use both (I set the 32-bit deployments to use the 32-bit boot image, and the 64-bit deployments to use the 64-bit boot image), so there's a mix, but it's 4:2 ratio of 64:32.

    @Harpreet -  blue screens with 0x0000005D immediately after downloading the boot.wim file during PXE (it says downloading the file with the advertisement ID of the x64 boot image, then BSoD immediately after), I never get to the point where I could select the TS because it tries to boot a 64-bit boot.wim on a 32-bit machine.

    I can mitigate this by setting my VM to 64-bit initially and lay down the 32-bit OS, but the problem is having to power off the VM to go back and change that (and not everyone will remember to do that).

    I did try only having the 32-bit boot image on the DP, but it wouldn't PXE at all.


    ~Luke
    Tuesday, July 13, 2010 12:54 AM
  • Cougar - try switching all of the 64-bit sequences to use the 32-bit image, then see what happens. Restart the Windows Deployment Services service every time you make changes, too.
    • Marked as answer by cougar694u Tuesday, July 13, 2010 6:52 PM
    Tuesday, July 13, 2010 2:16 AM
  • Hey Luke,

    I see it as:

    STOP: 0x0000005D (parameter, parameter, parameter, parameter) UNSUPPORTED_PROCESSOR
    The BSOD indicates that there is a processor present that is not supported.

    To me if nothing is helping us then we should first need to make sure that our hardware combination is correct. I suggest try installing the same OS from the CD. Just to make sure we donot have any hardware incompatibilities. As per my experience we need to fiddle with our hardware combination to make it boot.

    ~ Harpreet


    Harpreet Rana
    Tuesday, July 13, 2010 11:18 AM
  • STOP: 0x0000005D (parameter, parameter, parameter, parameter) UNSUPPORTED_PROCESSOR

    The BSOD indicates that there is a processor present that is not supported.

    That's exactly my point.  You cannot run a 64-bit OS (ie, the 64-bit boot.wim) on a 32-bit processor, hence UNSUPPORTED_PROCESSOR.

    @mike.gaal - I'll test that theory to see if it works.  I guess in theory, you could use the 32-bit pxe image to lay down the OS image, then it should boot the 64-bit OS image after.  Of course, this is just a guess.


    ~Luke
    Tuesday, July 13, 2010 12:42 PM
  • Not just a theory sir, it works great. In fact, it has been my preferred deployment method for a long time. Some utilities don't work in the x64 PE environment. I deploy 2003 x64 and 2008 R2 x64 via an x86 boot image.
    Tuesday, July 13, 2010 12:56 PM
  • I've also used 32bit PE to deploy 64 bit OS.  It's also the ONLY way you can ever deploy both a 32 bit and 64 bit OS in a single TS (which is what I was doing).
    Scott Gill
    SCCM Consultant
    Tuesday, July 13, 2010 3:13 PM
  • Luke,

    I think we have a disconnect here.

    - In the Question you mentioned you have a 64 bit host

    - In your previous post you mentioned: "That's exactly my point.  You cannot run a 64-bit OS (ie, the 64-bit boot.wim) on a 32-bit processor, hence UNSUPPORTED_PROCESSOR."

    - You also stated that you will try to use "...the 32-bit pxe image to lay down the OS image, then it should boot the 64-bit OS image after.  Of course, this is just a guess."

    If you have a 32 bit processor, understand that it is not at all possible to deploy an 64 bit image using even with 32-bit boot image.

    I 100% agree with Mike and Scott that it is possible to deploy 64 bit OS image using 32 bit boot image but only on 64 bit architecture.

    You need to make sure what architecture of machine you have.

    Harpreet


    Harpreet Rana
    Tuesday, July 13, 2010 4:03 PM
  • Cougar - try switching all of the 64-bit sequences to use the 32-bit image, then see what happens. Restart the Windows Deployment Services service every time you make changes, too.
    I set all TS's to use the x86 boot image and everything works fine.  I had to change some stuff because some of the tasks were proprietary for 64-bit, but were trying to run under the 32-bit WinPE.  I deployed 2008r2 without issue like this, thanks for the advice!

    ~Luke
    Tuesday, July 13, 2010 6:53 PM
  • Luke,

    I think we have a disconnect here.

    - In the Question you mentioned you have a 64 bit host

    - In your previous post you mentioned: "That's exactly my point.  You cannot run a 64-bit OS (ie, the 64-bit boot.wim) on a 32-bit processor , hence UNSUPPORTED_PROCESSOR."

    - You also stated that you will try to use "...the 32-bit pxe image to lay down the OS image, then it should boot the 64-bit OS image after.  Of course, this is just a guess."

    If you have a 32 bit processor, understand that it is not at all possible to deploy an 64 bit image using even with 32-bit boot image.

    I 100% agree with Mike and Scott that it is possible to deploy 64 bit OS image using 32 bit boot image but only on 64 bit architecture.

    You need to make sure what architecture of machine you have.

     

    You completely misunderstood my point where you quoted me.  I was saying you could deploy a 64-bit os (obviously on 64-bit hardware) via a 32-bit boot image.  I was not talking about deploying a 64-bit OS on 32-bit hardware.

    The back end hardware is indeed 64-bit, but when building a VM Guest and selecting a 32-bit guest OS, VMware essentially limits it (the guest hardware) to 32-bit.  So, when booting up, the cpu detected by SCCM upon PXE boot is that of the back end hardware (64-bit).  That is why when it tries to boot a 64-bit boot.wim (or any 64-bit image) it blue screens.


    ~Luke
    • Edited by cougar694u Wednesday, July 14, 2010 12:46 PM grammar
    • Proposed as answer by RonMen Wednesday, November 16, 2011 5:06 PM
    Tuesday, July 13, 2010 9:12 PM
  • I think it was my bad :(

    But m happy that your issue got resolved. Cheers (Y)

    Best Regards,


    Harpreet Rana
    Wednesday, July 14, 2010 11:10 AM
  • SCCM OSD uses the PXE boot image of the last task sequence advertised. Just make sure that your last one is one that uses a x86 PXE boot image. Just had that issue after I was testing a W2K08 R2 build and couldn't build and 32bit systems which had worked the day before. Advertised one of the 32bit TS and now all is OK again. When you select a 32bit OS when building a VMware client it only likes 32bit images.
    Thursday, March 17, 2011 5:01 AM