Add support for 32-bit UEFI #829
Conversation
|
If your still running a Bay-Trail device you must have too much time on your hands! Complete waste of time trying to support CPU's that were current 9 years ago and discontinued. Just another piece of code that will make archinstall bloated or cause problems.... |
@Col433 What makes you say that? Just because these devices have older CPUs does not mean that they don't have potential and should be ignored. I still find my ASUS T100TAM, which has a Bay Trail CPU and a 32-bit UEFI, to be very useful as a portable Linux device despite its lower specs. Besides, work is being done to support 32-bit UEFIs on the official Arch Linux ISO anyway. It only makes sense that archinstall should be ready to support these devices too. P.S. This PR only changes around 8 lines of code across 4 files, to enforce GRUB as a bootloader for 32-bit UEFI devices and configure it to work on a 32-bit UEFI. Not really sure how this makes archinstall more "bloated," or causes problems for non-32-bit-UEFI devices since the code I added doesn't affect them at all. |
|
David has also poked the efivar project asking when we can expect a new release: rhboot/efivar#137 |
|
I just noticed a new efivar version is finally out, I'll test this again as soon as I can 👀 |
Yepp! They announced it two days ago and david packaged it yesterday ^^ |
|
It looks like the archiso issue linked by @HTV04 was finally merged a couple of months ago. Any chance this PR can be resurrected, rebased, and merged? Much to my own surprise I've had multiple friends pop up this year with old asus transformers and ask me to install linux on them because "the windows it shipped with finally stopped updating and is now too slow and broken". So there are def still people out there trying to get meaningful use out of the hardware this PR would support. It would be nice if arch was the easy answer to give to those people. |
Sure, I can try rebasing it! Gimme a sec |
HTV04
force-pushed
the
uefi-32
branch
2 times, most recently
from
be87a22
to
4b6a6c0
Compare
|
@Spunkie Should be good to go! Let me know if there are any issues, I can't test this on my own device right now (but I can if you need me to later). |
| # systemd-boot doesn't support 32-bit UEFIs, so it must use GRUB. | ||
| # This was already fixed upstream, but hasn't been added to systemd-stable! |
There was a problem hiding this comment.
Support for systemd-boot with 32-bit UEFI firmware is now in the latest version of systemd on Arch Linux. [1][2]
The following is from the release notes for systemd v252:
Changes in sd-boot, bootctl, and the Boot Loader Specification:
... * Booting in EFI mixed mode (a 64-bit kernel over 32-bit UEFI firmware) is now supported by sd-boot.
[1] https://archlinux.org/packages/core/x86_64/systemd/
[2] https://github.com/systemd/systemd/releases/tag/v252
There was a problem hiding this comment.
Well, with that, is this PR even necessary anymore? It was intended to use GRUB as a fallback in case of a 32-bit UEFI, but now that systemd-boot works the process should be identical to a 64-bit UEFI.
I forget if I made any other changes for compatibility (other than the 32-bit UEFI debug info), it's been so long!
There was a problem hiding this comment.
Well, with that, is this PR even necessary anymore?
Yes.
The ArchWiki Installation guide has been updated with the following: [1][2]
... 32-bit IA32 UEFI; while this is supported, it will limit the boot loader choice to GRUB.
From ArchWiki admin nl6720 on the Installation guide talk page: [3]
Yes, systemd-boot supports it, but the systemd package does not build and package IA32 EFI binaries.
[1] https://wiki.archlinux.org/title/Installation_guide#Verify_the_boot_mode
[2] https://wiki.archlinux.org/index.php?title=Installation_guide&diff=prev&oldid=782855
[3] https://wiki.archlinux.org/title/Talk:Installation_guide#Use_/sys/firmware/efi/fw_platform_size_to_verify_the_boot_mode
|
I should note I did try to install this PR on my(friends) only 32-bit UEFI device back in Aug 2022 but it potentially bricked the device. Boot didn't work and the internal flash no longer showed up for me to be able to reinstall anything else. At the time I remember doing some research and coming to the conclusion there was still some upstream PRs that needed to be merged, It's nice that using the |
|
Here is a minimal solution to get this working for GRUB: codefiles@b672163 |
That sounds pretty extreme, maybe there was something wrong with the internal flash? I don't believe there's anything in my PR that would do any damage to the internal hardware.
Honestly, I don't know why my PR wasn't reviewed and/or merged a long time ago. I didn't see anything wrong with it (iirc it worked fine when I tested it initially, although I wasn't able to test it after that rebase commit I made, that may have screwed something up). In any case, there's been no input from the archinstall team for a while, which again lead to my commits being outdated and requiring yet another rebase. Thankfully @codefiles made a partial reimplementation of my changes, but personally I don't really want to work on this PR again until I'm sure it will be upstreamed after being reviewed. Don't get me wrong, I love archinstall and I appreciate all the work the developers have put into it. However, I'd just like some more input from the team on this. Even recently, I reported on the Discord server that the EFI partition size was still 1 MiB short (a long-standing bug leaving unallocated space), but nobody from the dev team responded to it. At least that can be remedied manually by editing the partition size during setup, but still, at least a little input on the subject, whether that would have lead to fixing the bug or not, would have been helpful. |
To me it does not look like your pull request was ever ready to be merged. It was initially a draft and you marked it ready for review after you did the two rebases. Examining the rebases, I see that you messed up |
Did I really forget to mark it for review? I could've sworn I marked it after testing before the rebases, but looking at the PR history it doesn't seem like this is the case, so I apologize. However, after I did mark it ready for review, there were no updates on this PR for around a year until @Spunkie reported that it didn't work properly. What code was missing after the rebases? If I can be sure this will be upstreamed after testing and review, I'd be happy to fix up this PR one last time. |
|
Here is code you lost when you force-pushed from be87a22 to 4b6a6c0: |
The main reason is time. 32bit stuff has historically been dropped in 2017 so I had to prioritize other things to review. Most of my focus has been on bugs (both finding and fixing though the community). The PR is welcome however, and considering the official support upstream for 32bit (?) configs I am ready to review it. I can only apologize for the delay on my part, I am however only human and limited in capacity. |
I understand completely; no need to apologize. I must admit that my annoyance came from the fact that I was worried I would have to update my PR again in order to keep it compatible with the codebase (without it being merged), not that I had to wait. I'm trying to make a PR, not maintain a fork 😛
I have two 32-bit EFI devices I can test on, I'd be more than happy to give them a fresh Arch install in the process. |
Co-authored-by: codefiles <11915375+codefiles@users.noreply.github.com>
There's always something, isn't there 🙄 I just tried to boot from a live USB and encountered the error described in that issue. I saw it on the Arch Wiki a while back, but given how old it is, I thought it would have been fixed by now. Guess not. I'll try grabbing a If, in my testing, I also find that GRUB doesn't work after an install, should I make it so that the GRUB option is hidden from the menu for a 32-bit UEFI? |
Yep.
Oh, the ISO uses GRUB so it will have that issue too. Yikes.
By the time this gets merged it will probably be fixed. 😆 I like the patch and it has my support for a merge if that means anything. |
|
So, some interesting findings... I decided to use the ISO generated as part of this PR for convenience, and it turns out GRUB has actually been fixed since the December 1st ISO, so the Arch Wiki is outdated and the corresponding issue needs to be closed. On a worse note, looks like systemd-boot still has issues with EFI mixed mode. The bootloader itself appears to run fine, but selecting either Arch Linux entry leads to a black screen. Just when I thought systemd-boot had the upper hand! I think I might change the default bootloader for 32-bit UEFI PCs to GRUB, because it tends to have way less issues with mixed mode than systemd-boot. Finally, I found out that GRUB is configured in archinstall to not create a boot entry. When I initially installed GRUB via archinstall, I noticed that there was no UEFI entry, just an EFI file copied to my ESP. This does not align with the behavior of the There's also the issue of the aforementioned EFI bugginess, which requires most bootloader installers to run twice before installing properly. So today I decided to make another PR that addresses this issue, the GRUB issue, and a few others, like the lack of a boot entry for Limine: #2312. That PR has some 64-bit-UEFI-specific code, so it's probably better if it gets merged first so I can rebase this PR on top of it. |
This PR adds support for devices with a 32-bit UEFI (and a 64-bit CPU), which include many Bay-Trail-powered devices.