Project

General

Profile

Feature #8471

Support 32-bit UEFI boot

Added by intrigeri over 4 years ago. Updated almost 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Hardware support
Target version:
Start date:
07/07/2015
Due date:
% Done:

100%

Feature Branch:
feature/8471-32-bit-UEFI
Type of work:
Code
Starter:
Affected tool:

Description

In our first iteration (#5739), we've added 64-bit UEFI support only, on the ground that 32-bit UEFI machines were pretty rare (first-generation MacBooks, mostly). However, recent Bay Trail-based laptops and tablets, while 64-bit, have a 32-bit UEFI firmware for obscure reasons.

How complicated would it be to support 32-bit UEFI too?

Steve McIntyre's blog posts on this topic should be helpful (look for "UEFI Debian installer work for Jessie, part $n").


Subtasks

Feature #9703: Update documentation wrt. 32-bit UEFI supportResolved


Related issues

Related to Tails - Feature #5739: Support UEFI boot Resolved 10/03/2013
Related to Tails - Feature #6064: Handheld Tails Confirmed 07/10/2014

Associated revisions

Revision ba2c4f5e (diff)
Added by Tails developers about 4 years ago

Also install the syslinux 32-bit UEFI boot loader.

Note that we install it in BOOT/TAILS32 (while the 64-bit boot loader lives in
the BOOT/EFI fallback directory), since syslinux module files have the same name
regardless of the architecture, so we cannot simply put them all in the
same directory.

The drawback is that some buggy UEFI firmware may pick the wrong bootloader,
that's not made for their architecture. Or, that they present the user with
confusing choice between "EFI" and "TAILS32". We'll see.

Of course, alternatively we could try to rename the 32-bit module files, so we
can put them in BOOT/EFI as well; this would require adjusting the configuration
files accordingly, in order to 1. load the 32-bit modules when the UEFI firmware
is 32-bit; and 2. convince syslinux to load a different configuration file
depending on the UEFI firmware's architecture (not the CPU architecture,
beware!).

Refs: #8471

Revision 11f460d5 (diff)
Added by intrigeri about 4 years ago

Revert "Also install the syslinux 32-bit UEFI boot loader."

This reverts commit 441892f6197efbe014cfb54fc6f9d43ed7e425bb.

The two 32-bit UEFI systems I've tried booting on only support the fallback UEFI
path, that's not an option for us with 32-bit syslinux UEFI, as explained in the
commit we're presently reverting.

I also tried, and failed, to convince GRUB2 installed in the fallback location
(EFI/BOOT/bootia32.efi) to chainload into 32-bit syslinux UEFI.

So I'm giving up with using syslinux for 32-bit UEFI.

Refs: #8471

Revision 821a35a4 (diff)
Added by intrigeri about 4 years ago

Install a 32-bit GRUB EFI boot loader, with an initial hand-made configuration.

Ideally:

  • either this configuration should be generated automatically from
    the syslinux one;
  • or, we should use GRUB's syslinux_configfile command (from the syslinuxcfg
    module) to load and interpret the syslinux configuration;
  • or, worst case, we should have a documented process to update the
    GRUB configuration whenever we change anything that affects
    the syslinux one.

Also, this initial configuration has some drawbacks:

  • it has a security issue, see XXX in grub.cfg;
  • the failsafe mode is incomplete, because I currently need that one
    to debug stuff.

Refs: #8471

Revision 2966e59d (diff)
Added by intrigeri about 4 years ago

Load GRUB2 video modules at runtime, and set linux_gfx_mode.

It's what Debian's default GRUB configuration does. This fixes screen freezing
after the switch to inteldrmfb, at least on the Toshiba Encore 2 WT8-1 tablet.

Refs: #8471

Revision 052a2479 (diff)
Added by intrigeri about 4 years ago

grub.cfg: stop setting terminal_input and terminal_output.

The default is to use the platform's native terminal input and output,
which should be good enough.

Refs: #8471

Revision 7bf83a1e (diff)
Added by intrigeri about 4 years ago

grub.cfg: add some "echo" statements to ease debugging.

Refs: #8471

Revision d6a709b1 (diff)
Added by intrigeri about 4 years ago

grub.cfg: factorize the calls to load_video.

All our menu entries run it, so we can as well do it before displaying the menu.

Refs: #8471

Revision 23f4396b (diff)
Added by intrigeri about 4 years ago

grub.cfg: add two menu entries that respectively load liveamd64.cfg and syslinux.cfg.

This allows starting to test and work on 32-bit GRUB2 EFI reading the syslinux
configuration at runtime. Note that the syslinux.cfg one is not expected to work
at this time, since support for vesamenu.c32 (that was implemented upstream
recently) didn't make it in Debian's GRUB2 package yet.

Refs: #8471

Revision f932630e
Added by anonym almost 4 years ago

Merge remote-tracking branch 'origin/feature/8471-32-bit-UEFI' into devel

Fix-committed: #8471

History

#1 Updated by intrigeri over 4 years ago

#2 Updated by intrigeri over 4 years ago

We can't simply copy the 32-bit version of syslinux.efi and its modules to BOOT/EFI, as the modules are called the same as the 64-bit ones.

#4 Updated by intrigeri over 4 years ago

#5 Updated by intrigeri over 4 years ago

Next step: try installing syslinux 32-bit UEFI in e.g. EFI/Tails.

#6 Updated by intrigeri over 4 years ago

One of us tried copying bootia32.efi from that http://cdimage.debian.org/cdimage/unofficial/efi-development/jessie-upload3/debian-jessie-UEFI-testing-netinst-i386-amd64-build3.iso into EFI/BOOT/, and then it was enough to boot Tails (installed with Tails Installer) in UEFI mode on a MacBook Air 1,1 (32-bit UEFI, never managed to boot Tails in UEFI mode before).

#7 Updated by intrigeri over 4 years ago

  • Description updated (diff)

#8 Updated by intrigeri over 4 years ago

  • Blueprint set to https://tails.boum.org/blueprint/UEFI/32-bit/

#9 Updated by intrigeri over 4 years ago

  • Feature Branch set to feature/8471-32-bit-UEFI

intrigeri wrote:

Next step: try installing syslinux 32-bit UEFI in e.g. EFI/Tails.

Done, not enough to boot on a MacBook Air A1237 (original, 1.8 GHz, that's supposed to have a 64-bit CPU and 32-bit EFI): even if I rename EFI/Tails to EFI/BOOT, it's not listed in the Apple boot menu... while the 64-bit version is (unmodified Tails 1.3.1), but fails to go further than the Apple boot menu.

#10 Updated by intrigeri over 4 years ago

intrigeri wrote:

One of us tried copying bootia32.efi from that http://cdimage.debian.org/cdimage/unofficial/efi-development/jessie-upload3/debian-jessie-UEFI-testing-netinst-i386-amd64-build3.iso into EFI/BOOT/, and then it was enough to boot Tails (installed with Tails Installer) in UEFI mode on a MacBook Air 1,1 (32-bit UEFI, never managed to boot Tails in UEFI mode before).

I was not able to reproduce this on the same machine, and I fail to see how GRUB could possibly work with a syslinux, so I'll have to guess that my team-mate did some mistake when testing or reporting his findings.

#11 Updated by intrigeri over 4 years ago

  • Status changed from Confirmed to In Progress
  • Target version changed from Tails_1.4 to Tails_1.4.1
  • % Done changed from 0 to 10

intrigeri wrote:

intrigeri wrote:

Next step: try installing syslinux 32-bit UEFI in e.g. EFI/Tails.

Done, not enough to boot on a MacBook Air A1237 (original, 1.8 GHz, that's supposed to have a 64-bit CPU and 32-bit EFI): [...]

I'm giving up on this machine, since I've no idea if I'm facing Apple oddities, or doing mistakes myself. I should get my hands on some more current hardware with 32-bit UEFI in a month or so, so postponing the initial research to 1.4.1. Not sure when we can ship something ready for production, most likely not before 1.5, and probably later. It might be that switching to GRUB is the best option in the end, we'll see.

#12 Updated by intrigeri about 4 years ago

Next step is to try installing:

  • syslinux 32-bit UEFI in e.g. EFI/Tails
  • GRUB 32-bit UEFI in EFI/BOOT/bootia32.efi, configured to run the 32-bit syslinux with something like chainloader ($root)/EFI/Tails/bootia32.efi.

#13 Updated by intrigeri about 4 years ago

Got something working with GRUB2 (including commits cherry-picked from upstream), but it would be better to do without it => next step is to try what was suggested to me on the syslinux ML.

#14 Updated by intrigeri about 4 years ago

  • Target version changed from Tails_1.4.1 to Tails_1.5

Initial research is done, will try to implement in time for 1.5. No promise whatsoever, though.

#15 Updated by intrigeri about 4 years ago

intrigeri wrote:

[...] next step is to try what was suggested to me on the syslinux ML.

Sadly, this won't work without the user manually choosing between 32-bit and 64-bit, unless a patch is applied to syslinux, as Knoppix does. These patches look simple enough, but until they make their way upstream, I'd rather stick to the GRUB2-based PoC I have.

#16 Updated by intrigeri about 4 years ago

Next steps:

  1. test the latest ISO on a machine with 32-bit UEFI
  2. polish the syslinux to GRUB config conversion as needed
  3. drop all GRUB menu entries except the one that loads syslinux config, and then probably just hide the menu and directly load syslinux config
  4. sum up what the UX is on such machines and discuss with sajolida whether we need a doc update, and if yes, which kind of

#17 Updated by intrigeri about 4 years ago

test the latest ISO on a machine with 32-bit UEFI

Boots fine.

polish the syslinux to GRUB config conversion as needed

Not needed, this does the job (presumably including the 32-bit/64-bit kernel automatic selection):

insmod syslinuxcfg
insmod cpuid
syslinux_configfile /efi/boot/syslinux.cfg

drop all GRUB menu entries except the one that loads syslinux config

Done in 5180274.

and then probably just hide the menu and directly load syslinux config

Done in 7c38f9f.

sum up what the UX is on such machines and discuss with sajolida whether we need a doc update, and if yes, which kind of

That's indeed the next thing to do.

#18 Updated by intrigeri about 4 years ago

  • Subject changed from Reconsider supporting 32-bit UEFI to Support 32-bit UEFI boot
  • Type of work changed from Research to Code

(It makes no sense to consider this as a research ticket anymore, now that most of the work has been done.)

#19 Updated by intrigeri almost 4 years ago

  • Assignee deleted (intrigeri)
  • QA Check set to Ready for QA

Been waiting for feedback on #9703 for 3 weeks, and now the freeze is in two days => please review'n'merge, and any needed doc update can be addressed post-freeze. My theory on #9703 is that such doc updates will be very minimal anyway.

#20 Updated by anonym almost 4 years ago

Given that I do not have access to any 32-bit UEFI devices, at best I can test that this doesn't introduce any regressions on my various hardware.

#21 Updated by intrigeri almost 4 years ago

Given that I do not have access to any 32-bit UEFI devices, at best I can test that this doesn't introduce any regressions on my various hardware.

I don't think that anyone else among us is in a better position wrt. this branch.

#22 Updated by anonym almost 4 years ago

  • Assignee set to anonym

I trust your testing, so I'll only test for regressions on other hardware and merge if all is ok. I'll try both DVD and USB boot (not SD card though) on all my hardware.

#23 Updated by anonym almost 4 years ago

  • Status changed from In Progress to Fix committed

#24 Updated by anonym almost 4 years ago

  • Assignee deleted (anonym)
  • QA Check changed from Ready for QA to Pass

I did the testing I could (only on 64-bit UEFI and non-UEFI hardware => no regressions) and the reviewing I could (no expertise in this UEFI buseiness, but stuff made sense). Merged!

#25 Updated by BitingBird almost 4 years ago

  • Status changed from Fix committed to Resolved

Also available in: Atom PDF