archinstall
archinstall copied to clipboard
archlinux
Add support for 32-bit UEFI
This PR adds support for devices with a 32-bit UEFI (and a 64-bit CPU), which include many Bay-Trail-powered devices.
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....
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: https://github.com/rhboot/efivar/issues/137
I just noticed a new efivar version is finally out, I'll test this again as soon as I can 👀
I just noticed a new efivar version is finally out, I'll test this again as soon as I can eyes
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.
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
@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).
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, GRUB probably. Right after that life distracted me with a hospital visit and later I no longer had access to my friends device.
It's nice that using the systemd-boot bootloader may have resolved this, personally I prefer it over GRUB. But I still hope this PR can be fixed, tested, and merged so that GRUB can also be used, as many people are familiar with it over systemd-boot. There is still many of these old devices floating around that are perfectly capable of running arch and prolonging their usefulness before they becoming ewaste.
Here is a minimal solution to get this working for GRUB: https://github.com/codefiles/archinstall/commit/b6721635319c17b1d1715f10dfa19437dd4a2638
@Spunkie
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.
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.
It's nice that using the
systemd-bootbootloader may have resolved this, personally I prefer it overGRUB. But I still hope this PR can be fixed, tested, and merged so thatGRUBcan also be used, as many people are familiar with it oversystemd-boot. There is still many of these old devices floating around that are perfectly capable of running arch and prolonging their usefulness before they becoming ewaste.
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.
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).
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 ~~with the first one~~ and lost some code. This resulted in your pull request not having the logic needed for what you intended and so it was not ready for a merge.
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 with the first one and lost some code. This resulted in your pull request not having the logic needed for what you intended and so it was not ready for a merge.
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: https://github.com/archlinux/archinstall/commit/be87a222c623972c8af4fa077795ba5485c0851f#diff-283d51110d004467e254215ad93e4dfcf0188beb22d9f878bb7088c12076dd2eR748-R751
I don't know why my PR wasn't reviewed and/or merged a long time ago.
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.
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).
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 :stuck_out_tongue:
The PR is welcome however, and considering the official support upstream for 32bit (?) configs I am ready to review it.
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. ~~Before I fix up this PR, though, do you mind patching the bug I mentioned before? Just so I don't have to deal with it during the installation.~~ Fixed, thanks!
Relevant: https://gitlab.archlinux.org/archlinux/packaging/packages/grub/-/issues/5
Relevant: https://gitlab.archlinux.org/archlinux/packaging/packages/grub/-/issues/5
There's always something, isn't there :roll_eyes:
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 BOOTIA32.EFI from an older ISO, before this issue.
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?
There's always something, isn't there 🙄
Yep.
I just tried to boot from a live USB and encountered the error described in that issue.
Oh, the ISO uses GRUB so it will have that issue too. Yikes.
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?
By the time this gets merged it will probably be fixed. :laughing:
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 systemd-boot and EFISTUB entries, so I knew something was wrong. I initially blamed my tablet, which notably has a buggy EFI (or just hates efibootmgr), but it turns out the installer sets the --removable flag on grub-install, which, apart from changing the destination EFI file to the standard path, also doesn't add a UEFI entry!
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.