32-EFI boot

[LoreBadTime]

Unfortunately (thanks Microsoft and Intel) some tablets come with a 32-efi bootloader,that can't boot any windows 64 edition,even if the processor has 64 bit instructions,this should be signalated on UEFI page,unless Microsoft fixes this thing

[rcmaehl]

Of course Microsoft would do this, why wouldn't they do this after their crazy CPU requirements. 🙃

[micwoj92]

@LoreBadTime what is exactly your issue here? WNW11 already shows both CPU + currently installed OS bits.

[LoreBadTime]

Yeah,but in a perfect world if a CPU supports 64 bits,you should be able to install windows with 64;and this happens on normal PCs,but because of Intel and win11 bullshit (EFI 32 on 64 machine) i will never be able to install it on my tablet,and this i think should be signalated in the program with a red advice.

[micwoj92]

So is there additional things that WNW11 can do in this regard? Now your situation is: 64bit cpu and 32bit os. And wnw should properly show that. As you said, this is not common, so is it worth looking into? Is it even possible to detect 32 vs 64 bit uefi?

[LoreBadTime]

There is a specific list of this processors,all of them are from Intel atom series,you can check from the list and then check the OS version,if the Os is 32 and has those infamous processors,it means that they cannot be upgraded since this 32 EFI bootloader,even if they have a 64 bit processor and respect all the requirements.Lucky that Linux devs found a workaround,so I can run most of the 64 programs with wine

[micwoj92]

Could you give this list? It will be much easier to implement then.

[LoreBadTime]

Anything in the atom series that isn't in this list will probably have this combination(64-processor and 32 bit OS),and it means they will never be able to install any windows 64 bit edition. https://docs.microsoft.com/en-us/windows-hardware/design/minimum/supported/windows-11-supported-intel-processors

[micwoj92]

I've looked a bit at this topic. Most of these devices had soldered 2gb ram anyway so they wouldn't pass the ram requirement. If they had 4GB RAM, then for example Surface 3 had x7-Z8700 which is not on this list, but that device had 64-bit Windows so it is not the problem.

[verdy-p]

If an old tablet had only 2GB internal RAM that was not extensible at all, it made sense to use a 32-bit OS because it uses less memory than a 64-bit OS. The only way get additional performance would have been to use an external faster USB flash drive if the internal storage of the tablet was not already a flash drive/SSD, in order to get faster swap space.

32-bit OSes are now extremely old (even several Linux distributions have also stopped supporting 32-bit installations in recent versions, or will require that user compile all packages from sources; those 32-bit versions of Linux will become for specialists and niche markets, for specific small devices or appliances, but NOT for general purpose graphic environments, or LAMP servers, file servers, media players)

Such devices with 32bit-only OS still supported may be things like SOHO routers, wifi hotspots, firewalls, hardware monitors, simple webcam recorders, iOT devices, all of them not needing any graphics adapter, or keyboard/mouse input for a human interface (except a few buttons or beeps or LEDs) to be almost instantly operational and functional. Most of these devices (including "smart TVs", and routers/boxes provided/supported by their ISP) are running a Linux or BSD kernel (and many people don't even know that, and often don't even have to configure these devices to use them instantly).

[mmeyran]

32-bit OSes are now extremely old (even several Linux distributions have also stopped supporting 32-bit installations in recent versions, or will require that user compile all packages from sources; those 32-bit versions of Linux will become for specialists and niche markets, for specific small devices or appliances, but NOT for general purpose graphic environments, or LAMP servers, file servers, media players)

Careful, don't mix up the EFI boot mode and the OS' boot mode - eventhough it's quite niche, a 64-bit Linux kernel is indeed able to boot off a 32-bit EFI boot loader; using a lean desktop environment (xfce, lxde etc.) and stuff like zram, 2Gb is enough for browsing and light desktop work. It should still show up as incompatible for Windows 11 though - 32-bit UEFI and 64-bit Windows (any version, at the very least from Win10 1703) just don't work well together.

[verdy-p]

Careful, don't mix up the EFI boot mode and the OS' boot mode

No confusion. I spoke only about 32-bit OS, not about 32-bit EFI, can can load any OS (32-bit or EFI) but this is very unlikely: if you want to run a 64-bit OS, you need a 64-bit processor, and your machine must have a 64-bit EFI to support it. A 64-bit BIOS (EFI or not) however can still boot a 32-bit or 64-bit OS. provided that the OS has a loader to make the transition, and the 32-bit vs. 64-bit mode of the CPU has not been preconfigured and locked by the EFI BIOS with security settings (this should not occur with legacy BIOS, and EFI BIOS should detect the capability of the OS image to see which mode to set the CPU into if security is required before locking the mode (unlocking requires full machine reset, i.e. rebooting, or special shutdown/resume support code in the OS to set some boot settings in non-volatile memory or non-erased RAM area with signatures and timestamps checked agaisnt the hardware clock to work with hardware watchdogs, otherwise the BIOS will boot in normal mode and will not "resume" from unsafe mode). I've never seen any 32-bit EFI or legacy BIOS capable of running a 64-bit OS. All what exists is a 64-bit BIOS that can keep some parts resident and running in 32-bit mode for supporting a legacy non-PNP-aware 32-bit OS (or 32-bit with PAE extension to support more than 4GB or RAM, by paging in/out some blocks of RAM in a swappable area the 32-bit memory space instead of paging memory to external disk storage, which is much slower: PAE is a great extension for 32-bit OSes to improve their performance by offering them a larger virtual memory space, but that cannot be fully resident, it's very useful notably to support disk caches, large framebuffers or buffers communicating with other processors or coprocessors via partially sharable memory, but generally PAE is made for use by the kernel drivers and not directly for user-mode applications, unless they use OS-specific APIs to manage page switches for memory allocated to the user-space application)

[goosnarrggh]

Careful, don't mix up the EFI boot mode and the OS' boot mode

No confusion. I spoke only about 32-bit OS, not about 32-bit EFI, can can load any OS (32-bit or EFI) but this is very unlikely: if you want to run a 64-bit OS, you need a 64-bit processor, and your machine must have a 64-bit EFI to support it.

This is only part of the truth. ANY UEFI with a CSM, either 64-bit or 32-bit, can use CSM mode to fall back to 16-bit real mode, and to provide 16-bit real-mode BIOS I/O calls with which the second-stage bootloader can use to access the peripherals until the OS has finished loading its own specialized device drivers. From there, a legacy BIOS boot might upgrade itself to either a 32-bit OS (if you have either a 32-bit or 64-bit CPU) or a 64-bit OS (but only if you have a 64-bit CPU).

A 64-bit UEFI, operating in UEFI mode, can ONLY proceed to the next stage in the boot process if that next stage is also 64-bit. It can also ONLY provide runtime services to the OS if that OS is also 64-bit.

A 32-bit UEFI, operating in UEFI mode, can ONLY proceed to the next stage in the boot process if that next stage is also 32-bit. It can also ONLY provide runtime services to the OS if that OS is also 32-bit.

The Windows UEFI second-stage bootloader can only go from 32-bit UEFI to 32-bit kernel, or from 64-bit UEFI to 64-bit kernel. The same is (was) also true of the MacOS X UEFI second-stage bootloader.

The trick which Linux uses to go from 32-bit UEFI (on a 64-bit CPU) to a 64-bit OS, is to insert a specially compiled second-stage bootloader (typically GRUB2), compiled as 32-bit code so that it can be launched from 32-bit UEFI, but which has its own instructions to switch the system up to 64-bit mode prior to jumping into the OS kernel.

I personally own two such machines (32-bit UEFI WITHOUT CSM support; 64-bit Atom CPU; Microsoft Secure Boot enabled) which can only boot into 32-bit Windows 10; however M am able to boot into 64-bit Fedora using the GRUB2 32-to-64 trick.

Both of them are low-end convertible Windows 10 tablets, one "Acer One 10" (4 GB soldered RAM), and a really cheap Walmart special "RCA" tablet (2 GB soldered RAM) without any distinctive model name stamped on it.

edit: Interestingly, the Acer One 10 (4GB RAM) also has TPM hardware. While I was converting it over to Linux, I noticed that Windows even automatically enabled Bitkeeper encryption by default. So it is just the sort of machine that might be interesting for this feature request. (Well, not mine specifically, because it'll never run Windows again. But someone else who owns the same model.)

[Bepulsoft]

Careful, don't mix up the EFI boot mode and the OS' boot mode No confusion. I spoke only about 32-bit OS, not about 32-bit EFI, can can load any OS (32-bit or EFI) but this is very unlikely: if you want to run a 64-bit OS, you need a 64-bit processor, and your machine must have a 64-bit EFI to support it.

This is only part of the truth. ANY UEFI with a CSM, either 64-bit or 32-bit, can use CSM mode to fall back to 16-bit real mode, and to provide 16-bit real-mode BIOS I/O calls with which the second-stage bootloader can use to access the peripherals until the OS has finished loading its own specialized device drivers. From there, a legacy BIOS boot might upgrade itself to either a 32-bit OS (if you have either a 32-bit or 64-bit CPU) or a 64-bit OS (but only if you have a 64-bit CPU).

A 64-bit UEFI, operating in UEFI mode, can ONLY proceed to the next stage in the boot process if that next stage is also 64-bit. It can also ONLY provide runtime services to the OS if that OS is also 64-bit.

A 32-bit UEFI, operating in UEFI mode, can ONLY proceed to the next stage in the boot process if that next stage is also 32-bit. It can also ONLY provide runtime services to the OS if that OS is also 32-bit.

The Windows UEFI second-stage bootloader can only go from 32-bit UEFI to 32-bit kernel, or from 64-bit UEFI to 64-bit kernel. The same is (was) also true of the MacOS X UEFI second-stage bootloader.

The trick which Linux uses to go from 32-bit UEFI (on a 64-bit CPU) to a 64-bit OS, is to insert a specially compiled second-stage bootloader (typically GRUB2), compiled as 32-bit code so that it can be launched from 32-bit UEFI, but which has its own instructions to switch the system up to 64-bit mode prior to jumping into the OS kernel.

I personally own two such machines (32-bit UEFI WITHOUT CSM support; 64-bit Atom CPU; Microsoft Secure Boot enabled) which can only boot into 32-bit Windows 10; however M am able to boot into 64-bit Fedora using the GRUB2 32-to-64 trick.

Both of them are low-end convertible Windows 10 tablets, one "Acer One 10" (4 GB soldered RAM), and a really cheap Walmart special "RCA" tablet (2 GB soldered RAM) without any distinctive model name stamped on it.

edit: Interestingly, the Acer One 10 (4GB RAM) also has TPM hardware. While I was converting it over to Linux, I noticed that Windows even automatically enabled Bitkeeper encryption by default. So it is just the sort of machine that might be interesting for this feature request. (Well, not mine specifically, because it'll never run Windows again. But someone else who owns the same model.)

Hello, can you help me? I need to install windows 10 x64 but bootloader only 32 bit uefi. Have you an instruction? Please send me if you're have.

[verdy-p]

The trick which Linux uses to go from 32-bit UEFI (on a 64-bit CPU) to a 64-bit OS, is to insert a specially compiled second-stage bootloader (typically GRUB2), compiled as 32-bit code so that it can be launched from 32-bit UEFI, but which has its own instructions to switch the system up to 64-bit mode prior to jumping into the OS kernel. I personally own two such machines (32-bit UEFI WITHOUT CSM support; 64-bit Atom CPU; Microsoft Secure Boot enabled) which can only boot into 32-bit Windows 10; however M am able to boot into 64-bit Fedora using the GRUB2 32-to-64 trick. Both of them are low-end convertible Windows 10 tablets, one "Acer One 10" (4 GB soldered RAM), and a really cheap Walmart special "RCA" tablet (2 GB soldered RAM) without any distinctive model name stamped on it. edit: Interestingly, the Acer One 10 (4GB RAM) also has TPM hardware. While I was converting it over to Linux, I noticed that Windows even automatically enabled Bitkeeper encryption by default. So it is just the sort of machine that might be interesting for this feature request. (Well, not mine specifically, because it'll never run Windows again. But someone else who owns the same model.)

Hello, can you help me? I need to install windows 10 x64 but bootloader only 32 bit uefi. Have you an instruction? Please send me if you're have.

May be youd could boot a good 64-bit Linux hypervisor (using the GRUB2 trick described above), e.g. an opensource "KVM"-based hypervisor (not "VMware" which has severe hardware/device limitations in its support, and is costly and full of tricks, really supporting only installations on modern servers but failing on many PCs), to run Windows in a VM.

Microsoft supports running Windows in various VMs (including on Linux-based hypervisors, not necessarily on Hyper-V which requires much more ressources on the system and wastes lot of memory): Microsoft does that for running virtual Windows installations on Azure (Microsoft uses there a special build of the Linux kernel with some Microsoft-specific drivers for Linux, and various restrictions applied for the security, that you may need to integrate in your Linux build used to run the KVM hypervisor).

If you want performance for your VM, you'd need a minimal "core" installation of the Linux build (without the full UI and desktop environment). Several Linux hypervisors provide this setup (and allow you to control the hypervisor via a local network service, either via a web browser to the local host machine, or just via SSH for maximum performance and minimal footprint of the host OS+hypervisor). In the hypervisor settings, it is possible to delegate some devices (e.g. the graphics adapter and the sound device) to the VM running the guest OS (your hosted Windows will then use its own drivers); this is not needed for most devices (network, storage, memory, CPU...).

[This is not tested. I have never run Windows on a local Linux-based hypervisor which may be tricky to configure and secure correctly.]

The other solution would be to install an UEFI OS (featuring a trick simular to GRUB2.efi to pass from 32-bit mode to 64-bit mode, and still offer a 64-bit UEFI interface that Windows will accept to boo on). However I don't know if such UEFI OS version exists. I did not know that GRUB2 was able to do that for booting 64-bit Linux on a 32-bit-only EFI (because I've never used any machine with such 32-bit-only UEFI).

The final solution is to check the vendor of your machine (if it's still supported!) to see if they have an update of their UEFI/BIOS.

If all this does not work, you won't be able to use any 64-bit version of Windows on your machine. There are tons of 64-bit recycled machines at very low cost (or sometimes given for free) that you can use if you lack money. You can still use you old 32/64-bit machine to run 64-bit Linux as a secondary device on your local area, or as something you'll still be able to run and use to get support from the Internet, when your modern Windows fails and needs some fixes (this happens frequently with various broken Windows Updates: with Windows, you always need a working secondary system).

[Bepulsoft]

Thank you so much for your response, I really appreciated it. But I can't load iso. Which folders should I show for it to load? In Linux the folder is kernel, but in Windows I don’t know. Didn't find instructions. Please tell me how to install Windows via Grub2.

On Thu, Mar 28, 2024, 23:06 Philippe Verdy @.***> wrote:

The trick which Linux uses to go from 32-bit UEFI (on a 64-bit CPU) to a 64-bit OS, is to insert a specially compiled second-stage bootloader (typically GRUB2), compiled as 32-bit code so that it can be launched from 32-bit UEFI, but which has its own instructions to switch the system up to 64-bit mode prior to jumping into the OS kernel. I personally own two such machines (32-bit UEFI WITHOUT CSM support; 64-bit Atom CPU; Microsoft Secure Boot enabled) which can only boot into 32-bit Windows 10; however M am able to boot into 64-bit Fedora using the GRUB2 32-to-64 trick. Both of them are low-end convertible Windows 10 tablets, one "Acer One 10" (4 GB soldered RAM), and a really cheap Walmart special "RCA" tablet (2 GB soldered RAM) without any distinctive model name stamped on it. edit: Interestingly, the Acer One 10 (4GB RAM) also has TPM hardware. While I was converting it over to Linux, I noticed that Windows even automatically enabled Bitkeeper encryption by default. So it is just the sort of machine that might be interesting for this feature request. (Well, not mine specifically, because it'll never run Windows again. But someone else who owns the same model.)

Hello, can you help me? I need to install windows 10 x64 but bootloader only 32 bit uefi. Have you an instruction? Please send me if you're have.

May be youd could boot a good 64-bit Linux hypervisor (using the GRUB2 trick described above), e.g. an opensource "KVM"-based hypervisor (not "VMware" which has severe hardware/device limitations in its support, and is costly and full of tricks, really supporting only installations on modern servers but failing on many PCs), to run Windows in a VM.

Microsoft supports running Windows in various VMs (including on Linux-based hypervisors, not necessarily on Hyper-V which requires much more ressources on the system and wastes lot of memory): Microsoft does that for running virtual Windows installations on Azure (Microsoft uses there a special build of the Linux kernel with some Microsoft-specific drivers for Linux, and various restrictions applied for the security, that you may need to integrate in your Linux build used to run the KVM hypervisor).

If you want performance for your VM, you'd need a minimal "core" installation of the Linux build (without the full UI and desktop environment). Several Linux hypervisors provide this setup (and allow you to control the hypervisor via a local network service, either via a web browser to the local host machine, or just via SSH for maximum performance and minimal footprint of the host OS+hypervisor). In the hypervisor settings, it is possible to delegate some devices (e.g. the graphics adapter and the sound device) to the VM running the guest OS (your hosted Windows will then use its own drivers); this is not needed for most devices (network, storage, memory, CPU...).

[This is not tested. I have never run Windows on a local Linux-based hypervisor which may be tricky to configure and secure correctly.]

The other solution would be to install an UEFI OS (featuring a trick simular to GRUB2.efi to pass from 32-bit mode to 64-bit mode, and still offer a 64-bit UEFI interface that Windows will accept to boo on). However I don't know if such UEFI OS version exists. I did not know that GRUB2 was able to do that for booting 64-bit Linux on a 32-bit-only EFI (because I've never used any machine with such 32-bit-only UEFI).

The final solution is to check the vendor of your machine (if it's still supported!) to see if they have an update of their UEFI/BIOS.

If all this does not work, you won't be able to use any 64-bit version of Windows on your machine. There are tons of 64-bit recycled machines at very low cost (or sometimes given for free) that you can use if you lack money. You can still use you old 32/64-bit machine to run 64-bit Linux as a secondary device on your local area, or as something you'll still be able to run and use to get support from the Internet, when your modern Windows fails and needs some fixes (this happens frequently with various broken Windows Updates: with Windows, you always need a working secondary system).

— Reply to this email directly, view it on GitHub https://github.com/rcmaehl/WhyNotWin11/issues/77#issuecomment-2025817023, or unsubscribe https://github.com/notifications/unsubscribe-auth/BHGUC2M23XNKAWUKTO65BX3Y2RE2BAVCNFSM47MRTOH2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBSGU4DCNZQGIZQ . You are receiving this because you commented.Message ID: @.***>

[verdy-p]

I did not say to load Windows via GRUB2.

But to try using GRUB2 to load a Linux kernel to run a Linux-based hypervisor (there are dedicated distribs that can install a PC with a GRUB2 bootloader, a preconfigured kernel, and the hypervisor itself and its configuration tools to manage VMs and their resources).

Then use that Linux-based hypervisor to start a Windows VM.

You'll configure the VM to use the Windows ISO in a virtual SATA or SCSI DVD drive. Don't forget to configure the VM with secure boot enabled, and a virtual TPM2.0 device (managed inside the hypervisor, this works even if your PC does not have such hardware TPM2.0: instead you can still use another possible hardware TPM1.2 device for use in a secure boot for the core GRUB2 bootloader and Linux kernel used to start the hypervisor).

The hypervisor will create/emulate everything needed for Windows: the virtual UEFI environment, the virtual TPM, the virtual storage devices, the virtual memory, ... and will eventually allow you to dedicate some hardware devices of the host machine to on of your VM.

[ E.g. the graphics and audio adapters may be dedicated from the core hypervisor/Linux to the VM, or some USB devices like a webcam or some hardware USB ports. Such dedication, which will bypass some hardware vendor_id/device_id from the ACPI configuration of your host (and its needed hardware resources like memory/ports/IRQ/DMA) is not needed for other devices (like network adapters, mouse, keyboard) that should remain virtualized and protected by the hypervisor. Just dedicate the very few devices that Linux and the hypervisor does not need at all for itself. Such "bypassing" may accelerate your audio/video performances, but may also cause possible troubles/conflicts in the core hypervisor, that won't be able supervise the hardware interactions made by the hosted VM, so this "devirtualization" of devices from the core host to one of the guest VMs should be minimalist, and by default the VM configuration in hypervisor should first use the default options. ]

So the first thing to do is to first find a good, fast, secure and maintained 64-bit Linux kernel that can boot on your machine. You may try some stable Ubuntu version (with a minimalist graphic environment), this generally works well and can be used to test several types of KVM/QEMU hypervisors to evaluate the performance of Windows. You'll see which devices may benefit from a devirtualization.

Then replace the desktop version of your Linux distrib by a native Linux-based core hypervisor with similar settings. You'll have to choose which Linux-based hypervisor you want (there are a dozen of them; some like VMware or Citrix are commercial and costly, and not suited for your small machine but for high-end professional servers; others like VMware Free ESXi are commercial and free of cost but very poor in performance and have limited hardware support, not working well on old PCs or notebooks; Virtual Box works and is free of cost, but its performances are very low and require a whole host environment that will compete with the hosted VM, notably for the memory/CPU footprint; I would probably use an opensource hypervisor based on KVM/QEMU with a modern Linux kernel, on your low-end machine, to get the best performances and stability).

[verdy-p]

Microsoft documents what Windows 8+ needs for the machine: See https://learn.microsoft.com/en-us/windows-hardware/test/hlk/testref/trusted-execution-environment-acpi-profile (this technical article lists many requirements on ACPI and TPM configuration that either the UEFI/BIOS native machine, or the hypervisor, must implement).

It is already expected that Windows 12 (expected as a beta in 2025 and to be released in 2026) will include new hardware requirements on the CPU (notably the support of some advanced SSE4a/SSE4.1 instructions like "POPCNT" for counting bits which are set in some integer value, and "MPCD" features, which would not only make some CPUS not eligible but would also completely block the installation, even with "Labs" settings, barring the route for Intel Core 2 Duo and early AMD Athlon 64 CPUs made up to year 2008, Microsoft wants to remove also the "Labs" installation settings to block devices without at least TPM1.2; all this will depend on the results of tests being performed with some Windows Insiders and and on responses from a few very large companies).

IMHO, blocking the absence of "POPCNT" is stupid for Windows 12, because it is very easy to emulate with very few instructions even if it takes a few more CPU cycles (but I bet that Microsoft wants it for performance of its IA, integrated now everywhere, when running the IA engine only on the CPU without an alternative GPU support, but Microsoft is probably commercially motivated by Intel and AMD that want to sell new chips, and by PC manufacturers: maybe they are paying Microsoft to extend the requirements, just like what they did to restrict the eligibility with Windows 7/8/8.1/10 and then Windows 11). But this is a strategic error: many users are just going to go with Linux or to Android and iOS and are abandoning the PC platform on Windows: Microsoft, Intel, AMD and nVidia are losing in all cases, but Google, Apple and ARM foundries are winning a lot !