Feature #8471

Support 32-bit UEFI boot

Added by intrigeri 2014-12-21 20:10:42 . Updated 2015-08-11 10:46:28 .

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

100%

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

Description

In our first iteration (Feature #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 support Resolved

100


Related issues

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

History

#1 Updated by intrigeri 2014-12-21 20:11:38

#2 Updated by intrigeri 2014-12-21 20:20:49

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 2015-01-21 09:11:40

#5 Updated by intrigeri 2015-01-21 09:14:22

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

#6 Updated by intrigeri 2015-02-10 16:27:00

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 2015-02-10 17:15:24

  • Description updated

#8 Updated by intrigeri 2015-02-14 00:51:16

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

#9 Updated by intrigeri 2015-03-30 18:18:36

  • 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 2015-03-30 18:35:34

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 2015-03-30 18:39:15

  • 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 2015-05-06 19:34:08

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 2015-05-15 13:12:46

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 2015-05-30 19:55:29

  • 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 2015-07-02 04:27:30

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 2015-07-03 00:47:17

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 2015-07-07 15:57:46

> 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 commit:5180274.

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

Done in commit: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 2015-07-07 16:22:45

  • 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 2015-07-29 00:42:38

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

Been waiting for feedback on Feature #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 Feature #9703 is that such doc updates will be very minimal anyway.

#20 Updated by anonym 2015-08-03 10:08:53

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 2015-08-03 10:17:43

> 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 2015-08-03 15:23:41

  • 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 2015-08-05 10:20:26

  • Status changed from In Progress to Fix committed

Applied in changeset commit:f932630ea46434ae9427c382eca09e63fd5c685a.

#24 Updated by anonym 2015-08-05 10:34:01

  • 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 2015-08-11 10:46:28

  • Status changed from Fix committed to Resolved