Image Type X64 Is Not Supported By This Ia32 Shell
Munir Junker
Here I document my trial-and-error methods for booting the Windows OS install when the BIOS boot order was getting ignored. Another alternative title might be How I managed to install Windows when I could not boot from any USB devices. (Tested USB DVD, USB Flash Drives).
This was a new device, freshly unpacked and booted up. I experienced issues starting Windows for the first time. "OS goes to "Just a moment" for a very long time. Then the sysprep cmd window launches, then nothing happens." This issue is identical to this reddit post and has been posted a few times on the LattePanda forum already.
I followed the LattePanda documentation on reinstalling Windows to create the bootable USB stick. I set the boot order in BIOS, but it still just kicked me back to the pre-installed windows.
So I tried a different USB stick (sometimes they can be fussy) but the results were the same.
It just refused to boot to USB! Always defaulting back to the pre-installed Windows.
Next I grabbed a windows 10 home DVD and plugged in my trusty USB 2.0 DVD burner. It has it's own power source, so I was sure there wouldn't be any power draw issues. I accessed the BIOS and set my boot order. To my dismay, the system still refused to boot to USB (Just loaded the pre-installed Windows again.)
Next I used Microsoft's media creation tool and created a Windows 10 32-bit bootable USB stick. (32-bit because I am working on the 2G/32G version of the LattePanda, I shouldn't need the 64-bit version... or so I thought. read on!)
While it was downloading I did other stuff to shake my frustrations. Once finished, I connected the newly imaged USB stick to a different, working PC. It booted to the windows setup as expected.
I plug the USB stick into the 'Panda, change bios boot order settings... and it goes right back to the pre-installed windows. Won't boot from the USB stick or the USB DVD.
Ok, so that won't work. I get into the Windows troubleshooting start menu and I select the option to restore my PC, don't keep any settings. I start this process.
Around 49%, I get hit with a brief power outage. Hmm... at least it wasn't firmware, right? I wait for a bit to make sure the power is stable again, then I start it up. That's when I am greeted by a not-so-nice message:
"The computer restarted unexpectedly or encountered an unexpected error. Windows installation cannot proceed. To install Windows, click 'OK' to restart the computer, and then restart the installation.".
Picture:
I got this same mesage no matter how many times I tried to F8 or otherwise access any windows safe mode.
Great. So now my pre-installed image is shot and I can't get this thing to boot from any USB device.
I really didn't feel up to installing and configuring a PXE server just for a single Windows 10 install. So I kept on tinkering.. and while tinkering, I noticed an entry on the BIOS exit screen labeled "Launch EFI Shell from filesystem device".
I ran this and after a moment I was provided a command line to the EFI shell. Cool. Reading the screen I notice the mount points and read to figure out which is my USB device. In this case, fs1:
I mounted my USB device by typing fs1:
then I typed cd efi
then I typed cd boot
then I typed in bootia32.efi
I was immediately notified that the Image type IA32 is not supported by this x64 shell. so, Microsoft used the Itanium efi on the x86 version of Windows 10 home? That just doesn't make sense.
So, once again I used Microsoft's media creation tool and created a Windows 10 64-bit bootable USB stick.
Once the stick was ready, I launched EFI Shell from the BIOS. Ran these commands (again):
fs1:
cd efi
cd boot
bootx64.efi
Success! The shell launched the Windows setup program from the USB device.
Because of the problems I was having, I decided to delete the hard disk partitions and reinstall windows on a clean 'unallocated space' emmc disk.
Afterwards, on another computer I downloaded the drivers from the LattePanda GITHub repository and transferred via the same USB stick. Then I proceeded to install drivers for all the unknown devices in the device manager. (it was a pretty long list.)
I had neglected to remove the USB stick from the LattePanda when I rebooted to finish installing the first of the device drivers. To my surprise, the 'Panda booted from the USB stick. So after the clean OS install my LattePanda began properly booting from the USB devices.
I removed the USB stick, rebooted into Windows and continued with device driver installation. I've since then updated Windows and have let the device 'burn in' for a day. It seems to be working perfectly now.
I hope you find this post informative and helpful. Use these instructions at your own discretion.
I'm in the unlucky situation that I need to use a CPU feature that the BIOS hasn't enabled in the ia32 feature control MSR register. The BIOS does set the lock bit so I can't set the bit myself. The BIOS (Asus UEFI BIOS) has no option to change the behavior. Question is, is there any way I can set this bit? I'm thinking if it is possible to write an UEFI extension or some program I could execute from the UEFI shell. But I'm not sure if the register is locked before this would be execute (I know very little about UEFI and its programming environment). Alternatively, is it possible to patch the BIOS update image or modify it using standard tools? Anyone who heard of success stores in this area?
Update May 22th: I just updated the Asus Z170-K to the newly released BIOS 1803 (released 20th of May). It was a big jump in version number so I was hopeful. Sadly, SGX support still isn't there. I've now filed a new request with Asus and this time I plan not to be just brushed off. I think it is outright amateurish this is not supported from the beginning - it is part and parcel of supporting a Skylake CPU so I think all customers requiring this should try and pursue a refund (I know I'm gonna do that).
Probably not feasible without modding the BIOS ROM and re-flashing it. The CPU initialization is one of the earliest parts of of boot. The lock bit would get set in either SEC or PEI phase. Any extension you write will be for the DXE phase, which occurs later.
SGX support will require much more than just setting a bit in MSR. UEFI must reserve a special memory block (Enclave Page Cache) for SGX to work properly, so if ASUS haven't supported SGX from UEFI side, you either need to implement it yourself (which will be hard even with enough experience in UEFI programming, because of required firmware binary modifications) or wait for ASUS to catch up.
A beta BIOS version 3107 has now been released on the Asus web site. This version is the first to enable SGX (it introduces a new SGX option in the BIOS menu). I have not verified it is actually working, but at least this is progress. It seems other motherborads in the Z170-series are getting BIOS upgrades that start with "3" so that might add SGX for those as well.
Looks like ASUS Z170-A does not support Intel SGX. Processor is Intel Core i7 6700K.I tryed to install Intel SGX PSW, but it says that platform does not support Intel SGX. I searched for Intel SGX settings in BIOS settings and did not find such an option. Then I made BIOS update, the actual version is 1602 by this moment.. it still does not support Intel SGX. That's a great pity, that Intel does not publish a list of motherboards which support SGX.
Some x86 systems ship with a 64 bit CPU, but 32 bit UEFI firmware. It is possible to use a 32 bit UEFI grub build to boot a 64 bit kernel and distribution on these systems. So far this setup has not been supported in Fedora. This feature is about adding support for installing and booting Fedora on this hardware.
Fedora ships with grub2-efi-ia32.x86_64 and shim-ia32.x86_64 which is supposed to work with 32bit UEFI. The kernel will always be 64 bit. It is likely this is not very well tested as the developers may not have the hardware to test on.
For those using the custom title bar (the default on Windows, macOS, and the web), you may have noticed that we are introducing more interactive content to the title bar. While there are already settings to hide each of these elements individually, you can now right-click the title bar to access a context menu that toggles the menu bar (not shown on macOS desktop), Command Center, and layout controls.
For Windows users expecting the system context menu, the menu can still be triggered by right-clicking the VS Code icon in the top left corner of the window or by pressing Alt+Space. Mouse position is used to determine the behavior when triggering with Alt+Space, so the custom menu will appear if it sits on top of the title bar.
With the addition of the Command Center, we tried shrinking the menu bar to a hamburger menu to make space. After hearing user feedback, we switched back to the old menu bar folding behavior until most of the menu is collapsed, and only then switch to the hamburger menu.
Also as part of improving the Command Center experience, when interactive components are present in the title bar on macOS, the title bar will now zoom with the rest of the UI for increased accessibility.
VS Code now keeps folded ranges, even if the folding range is no longer part of the ranges computed by a folding provider. A typical example is when the user comments out the file, starts a string literal, or creates a syntax error that makes it impossible to create all the ranges. Such folded ranges become 'recovered' ranges. They are removed once the folding provider comes back with ranges at the same location or by using the command Remove Manual Folding Ranges.
The folding controls in the gutter can now be hidden with the setting "editor.showFoldingControls": "never". Folding ranges can still be expanded and collapsed using the folding commands and shortcuts.
e59dfda104