Bug #12511

The ISO includes lower-case bootx64.efi, should be BOOTX64.EFI

Added by dkg 2017-05-05 02:44:45 . Updated 2017-05-23 09:07:54 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Installation
Target version:
Tails_3.0~rc1
Start date:
2017-05-05
Due date:
% Done:

100%

Feature Branch:
bugfix/12511-bootx64-efi-case
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

I have a thinkpad X220 that normally boots in EFI mode. I made an
intermediate 3.0~beta4 image by dd’ing the iso to one USB stick. Then from that i used
tails-installer to create a new USB stick.

however, the new USB stick wouldn’t boot.

Looking at it, i see that the new USB stick has a gpt partition table, and there is an
EFI/BOOT directory in the first partition (a fat32 filesystem).

however, inside that directory there is a file named “bootx64.efi”. My
x220 doesn’t want to boot from it. I notice that the computer usually
boots from a different volume which has /EFI/BOOT/BOOTX64.EFI (note that the case is different).

from another computer, i mounted the new USB stick’s first filesystem,
and did:

mv /media/usb/EFI/BOOT/bootx64.efi /media/usb/EFI/BOOT/bootz64.efi
mv /media/usb/EFI/BOOT/bootz64.efi /media/usb/EFI/BOOT/BOOTX64.EFI

(i would have done it in one mv, but the linux kernel understands that
the filesystem is case-insensitive and complains about the filenames being the same if you try to do that)

after that change, the USB stick boots on my x220!

so interestingly, it looks like:

* the data stored in the FAT32 filesystem actually does have a case
(note that EFI and BOOT are both rendered as upper-case in linux,
though “bootx64.efi” was rendered in lower-case).

* at least one UEFI implementation expects to see BOOTX64.EFI in
upper-case and can’t find it if it happens to be in lower-case.

* the tails-installer is placing it in the filesystem in lower-case
somehow.

Subtasks

History

#1 Updated by dkg 2017-05-05 02:47:02

  • Subject changed from tails-installer creates lower-case boot64x.efi, should be BOOT64X.EFI to tails-installer creates lower-case bootx64.efi, should be BOOTX64.EFI

#2 Updated by dkg 2017-05-05 02:48:06

Sorry, the text above says “boot64x” where it should say “bootx64”. serves me right for trying to do it from memory.

#3 Updated by segfault 2017-05-06 14:20:53

  • Description updated

> Sorry, the text above says “boot64x” where it should say “bootx64”. serves me right for trying to do it from memory.

I fixed this in the description. You can edit the description by clicking the pencil icon next to the “Description” label when editing an issue (yes, it’s well hidden).

#4 Updated by intrigeri 2017-05-11 09:47:41

  • Category set to Installation
  • Status changed from New to In Progress
  • Assignee set to intrigeri
  • Target version set to Tails_3.0~rc1
  • % Done changed from 0 to 10

Thanks for the analysis! I’ll try to fix that in time for 3.0~rc1. Affected files:

  • config/binary_local-hooks/99-syslinux_uefi
  • wiki/src/contribute/design/UEFI.mdwn
  • wiki/src/support/known_issues.mdwn

#5 Updated by intrigeri 2017-05-17 06:20:03

  • Subject changed from tails-installer creates lower-case bootx64.efi, should be BOOTX64.EFI to The ISO includes lower-case bootx64.efi, should be BOOTX64.EFI

#6 Updated by intrigeri 2017-05-17 06:27:57

  • % Done changed from 10 to 20
  • Feature Branch set to bugfix/12511-bootx64-efi-case

Let’s see what Jenkins thinks of this change.

#7 Updated by intrigeri 2017-05-18 11:23:28

  • Assignee changed from intrigeri to anonym
  • % Done changed from 20 to 50
  • QA Check set to Ready for QA

Actually we’re not running UEFI boot tests on Jenkins (due to Bug #11583) so I’ve run “Scenario: Booting Tails from a USB drive in UEFI mode” locally and it passes.

#8 Updated by anonym 2017-05-18 17:37:42

  • Status changed from In Progress to Fix committed
  • Assignee deleted (anonym)
  • % Done changed from 50 to 100
  • QA Check changed from Ready for QA to Pass

Works on my hardware. Let’s see if we get regressions reported against 3.0~rc1.

#9 Updated by intrigeri 2017-05-23 09:07:54

  • Status changed from Fix committed to Resolved