Bugzilla – Full Text Bug Listing
|Summary:||[META] Support for 64-bit processors on motherboards with 32-bit UEFI (mixed-mode support)|
|Product:||[openSUSE] openSUSE Tumbleweed||Reporter:||Jens Krieger-Juhnke <jens>|
|Component:||Basesystem||Assignee:||Bootloader Maintainers <bootloader-maintainers>|
|Status:||NEW ---||QA Contact:||E-mail List <qa-bugs>|
|Priority:||P5 - None||CC:||afsalrahman51, glin, jcheung, jens, jlee, jslaby, mbenes, mchang, nwr10cst-oslnx, saahriktu, tiwai|
|Found By:||---||Services Priority:|
|Marketing QA Status:||---||IT Deployment:||---|
|Bug Depends on:||1178338, 1178340|
Description Jens Krieger-Juhnke 2020-05-29 16:48:39 UTC
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:76.0) Gecko/20100101 Firefox/76.0 Build Identifier: On some devices (In my case a Lenovo Ideapad 100s-11iby) have 64 bit processors, but a 32-bit UEFI, so the 64-bit installation mediums are not recognized by it. Reproducible: Always Steps to Reproduce: 1. Grab a device with a 64-bit processor and a 32-bit UEFI 2. Try to boot from a 64-bit installation medium Actual Results: The installation medium is not listed in the boot menu. Expected Results: The installation medium is listed correctly, just like on a machine with a 64-bit UEFI. I did a bit of research, and found out the following: Fedora has natively supported 32-bit UEFI for 64 bit installs since Fedora 27. There seems to be a a workaround, but this is not very practical for new users, which adds a file from Github (https://github.com/hirotakaster/baytail-bootia32.efi) to the installation medium.
Comment 1 Michal Filka 2020-06-01 07:00:21 UTC
Nothing for yast. Kernel team might help with that (?)
Comment 2 Gary Ching-Pang Lin 2020-06-04 07:42:37 UTC
It's so called UEFI Mixed mode, and it would need support both from bootloader and kernel. CONFIG_EFI_MIXED is already enabled in kernel, so the question would be how to detect mixed mode and install the proper UEFI bootloader.
Comment 3 Miroslav Beneš 2020-10-27 15:03:23 UTC
Gary, anything new here? Is anyone working on it? Anyway, it sounds like a feature request and not a bug to me.
Comment 4 Gary Ching-Pang Lin 2020-10-28 02:00:57 UTC
(In reply to Miroslav Beneš from comment #3) > Gary, anything new here? Is anyone working on it? Anyway, it sounds like a > feature request and not a bug to me. (Cc Michael Chang for grub2.) Yeah, it's a feature, and it would need some changes in shim, grub2, and even yast.
Comment 5 Jiri Slaby 2020-11-02 07:54:40 UTC
(In reply to Gary Ching-Pang Lin from comment #4) > Yeah, it's a feature, and it would need some changes in shim, grub2, and > even yast. And installation-media, of course ;). FWIW installation step is quite easy: grub from grub2-i386-efi works just fine, it can load already present grub.cfg just fine (I tested this on a mixed-mode machine some time ago). So it only needs to be placed on the media (as bootia32.efi). Then yast needs to install grub2-i386-efi if it detects mixed-mode during the installation. That can be done by reading /sys/firmware/efi/fw_platform_size. I haven't tested secure boot, we do not provide shim32 for x86_64, AFAIK.
Comment 6 Neil Rickert 2020-11-03 02:02:41 UTC
I'll note that I have been experimenting with this since 2018. My experiments are in a KVM virtual machine with ovmf firmware. I described some of my attempts here: https://nwrickert2.wordpress.com/2018/11/28/opensuse-leap-15-0-and-32-bit-efi/ I currently have both Tumbleweed and Leap 15.2 running this way. If you want help for installing, then open a new topic at forums.opensuse.org and I will assist. My current install method would easier than in that earlier blog post, but does require some linux command line steps. With regard to possibly providing install support, I can probably help there too with testing and with perhaps using my experience. With current install media, my method would be: 1: Use the DVD installer, and copy that to a USB flash drive; 2: Create a new larger EFI partition on that flash drive, and change the original partition type to FAT16 (so that there is only 1 EFI partition). 3: Copy the original EFI partition to the new one (file/directory tree copy, not binary copy. This is so that 64-bit EFI installs can still be done. 4: Modify that EFI partition by installing support for grub2-i386-efi booting. Obviously that's missing detail. After those changes, you can install. But to boot the newly installed system, you would need to install grub2-i386-efi, and manually run grub2-install to set it up.
Comment 7 Afsal Mc 2020-12-08 15:47:19 UTC
I'm using Opensuse in a Baytrail z3735f (64 bit) laptop with a 32 bit uefi since 5 months approx . I did the installation by accessing the installation media through Ubuntu grub command line (by manually grubconf to grub.cfg of opensuse installtion media ). yh so , Ubuntu and grub was already present in my system and i just installed opensuse through Ubuntu's Grub . The installation media was created using dd (Etcher works fine) . HERE , You don't have to copy bootia32.efi to installation media as the booting is done by Ubuntu's already installed 32 bit Grub . During installation use the existing /boot partition to install opensuse and don't create a new one !!!!!
Comment 8 Lubos Kocman 2021-02-22 12:37:09 UTC
*** Bug 1177937 has been marked as a duplicate of this bug. ***
Comment 9 Miroslav Beneš 2022-02-18 11:24:58 UTC
I wonder what the current status is. Has there been any development since back then? As stated in comments 6 and 7 there are ways to make it work.
Comment 10 Neil Rickert 2022-02-19 02:48:57 UTC
The good news is that Leap 15.4 Alpha runs very well on 32-bit UEFI. The bad news is that there is still no installer support (for Leap or for Tumbleweed).
Comment 11 Miroslav Beneš 2022-02-21 09:25:46 UTC
Ok, thanks for the feedback. Let me reassign to Basesystem component then, so that the remaining pieces can be solved.
Comment 12 Jiri Slaby 2022-02-21 10:53:31 UTC
(In reply to Miroslav Beneš from comment #11) > Ok, thanks for the feedback. Let me reassign to Basesystem component then, > so that the remaining pieces can be solved. Note this is a META bug. installation-images are handled in bug 1178338.