Tails

#1 Updated by BitingBird 2015-03-02 22:38:43

• Category set to Installation

#2 Updated by intrigeri 2015-03-03 10:42:38

• Assignee set to goupille
• QA Check set to Info Needed

Which version(s) of UUI?

#7 Updated by intrigeri 2015-06-18 09:54:29

• Status changed from New to Rejected

> the user didn’t answered so, no news about that…

OK, thanks. We’re now four months after requesting additional info that might allow someone to reproduce and debug this problem => closing.

#10 Updated by intrigeri 2017-11-11 14:37:56

• related to Bug #14959: Test UEFI boot with a Tails installed with UUI added

#12 Updated by intrigeri 2017-11-11 16:12:05

• Subject changed from "no configuration file found" when booting a UUI made Tails device to "no configuration file found" when booting Tails installed with UUI in UEFI mode
• Status changed from Rejected to In Progress
• Assignee changed from goupille to intrigeri
• Priority changed from Normal to Elevated
• Target version set to Tails_3.3
• % Done changed from 0 to 10
• QA Check deleted (Info Needed)
• Type of work changed from Research to Code

I’ve finally managed to get a hold on a Windows system and then it was easy to reproduce this problem (Bug #14959#note-7). On both test systems (ThinkPad T460 and MacBook Pro 8,1), having a look at the GRUB config on the USB stick was enough to identify the culprit: efi/boot/grub/grub.cfg says syslinux_configfile /efi/boot/syslinux.cfg, but we ship no such file, hence the “no configuration file found”. copy boot/efi/isolinux.cfg to boot/efi/syslinux.cfg. This seems too good to be true but I think the fix will be a one liner in our Git repo… to be continued :)

I’m not quite sure why the GRUB chainloading is involved on the ThinkPad T460 (normally we only use GRUB for 32-bit UEFI), and I can’t investigate easily as its screen is broken. I guess it’s due to some weirdness Whatever.

I don’t understand how we (Installation Assistant developers, Foundations Team members, Help Desk) have not managed to do Bug #14959 in 2 years. I think a blame-free postmortem process would be in order. I suspect it’s another instance of too vague scope of responsibilities, which leads us to not go through the extra mile needed to test it (e.g. me to get access to a Windows system, or sajolida to get access to a UEFI computer, or getting a picture of the screen which would have allowed me to understand it was a GRUB problem).

#13 Updated by intrigeri 2017-11-11 16:12:19

• blocks Feature #13244: Core work 2017Q4: Foundations Team added

#14 Updated by intrigeri 2017-11-11 16:24:52

• Feature Branch set to bugfix/8992-uui-vs-uefi

#15 Updated by intrigeri 2017-11-11 16:39:46

• Subject changed from "no configuration file found" when booting Tails installed with UUI in UEFI mode to USB sticks installed with UUI fail to boot in UEFI mode: "no configuration file found"

#16 Updated by intrigeri 2017-11-11 18:03:13

• % Done changed from 10 to 20

A USB stick installed with UUI with an ISO built from this branch boots fine (up to the Greeter):

• in UEFI mode: on a ThinkPad T460 and a MacBook Pro 8,1
• in legacy mode: on a ThinkPad X200

Same for a USB stick installed with dd on the ThinkPad T460 (that fallbacks to legacy boot) and X200 (legacy boot), but the MacBook Pro 8,1 won’t boot, which is kind of expected.

I’ve started a full test suite run locally to ensure this doesn’t break other supported use cases. I have great hopes this can make it into Tails 3.3.

#17 Updated by intrigeri 2017-11-11 20:47:03

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

Crap, I see a kernel panic in the first “When I shutdown Tails and wait for the computer to power off” step during the “Writing a Tails isohybrid to a USB drive and booting it, then installing Tails on top of it using Tails Installer, and it still boots”. But, I’ve tested the important part (“installing Tails on top of it using Tails Installer, and it still boots”) by hand and it still works. The only supported installation scenarios that go through the failing step are:

• Linux expert: no big deal, these people will manage to turn off the machine by hand;
• Mac: they won’t be affected as the intermediary isohybrid stick can’t currently boot on their hardware in the first place, i.e. this installation scenario is uterly broken anyway, so they won’t even go far enough to see this problem; let’s pretend it’s good news in this context…

=> IMO repairing a major installation scenario, as done by this branch, is totally worth introducing this regression… which is probably unrelated to this branch anyway: I don’t see how a UEFI bootloader config file being renamed can affect the behaviour of a device booted in legacy mode. If you agree I’ll file a ticket about it and will take a closer look later.

Other than that, these features pass flawlessly on 1st try on my local Jenkins:

• features/usb_install.feature
• features/usb_upgrade.feature
• features/persistence.feature

(I have a full test suite running but given this change should only affect UEFI boot, it doesn’t feel worth waiting for it to complete before I send this to QA. I prefer to give you more time to review and raise any concern you may have.)

#20 Updated by anonym 2017-11-12 16:29:09

• % Done changed from 50 to 90
• QA Check changed from Ready for QA to Pass

intrigeri wrote:
> Crap, I see a kernel panic in the first “When I shutdown Tails and wait for the computer to power off” step during the “Writing a Tails isohybrid to a USB drive and booting it, then installing Tails on top of it using Tails Installer, and it still boots”.

I cannot reproduce this (5 tries) and neither can Jenkins (2 tries) so I think it was unrelated. But…

> But, I’ve tested the important part (“installing Tails on top of it using Tails Installer, and it still boots”) by hand and it still works. The only supported installation scenarios that go through the failing step are:
>
> * Linux expert: no big deal, these people will manage to turn off the machine by hand;
> * Mac: they won’t be affected as the intermediary isohybrid stick can’t currently boot on their hardware in the first place, i.e. this installation scenario is uterly broken anyway, so they won’t even go far enough to see this problem; let’s pretend it’s good news in this context…
>
> => IMO repairing a major installation scenario, as done by this branch, is totally worth introducing this regression… which is probably unrelated to this branch anyway: I don’t see how a UEFI bootloader config file being renamed can affect the behaviour of a device booted in legacy mode. If you agree I’ll file a ticket about it and will take a closer look later.

If it turns out the kernel panic is related: I agree with your reasoning.

> Other than that, these features pass flawlessly on 1st try on my local Jenkins:
>
> * features/usb_install.feature
> * features/usb_upgrade.feature
> * features/persistence.feature

Passed on my system too!

> (I have a full test suite running but given this change should only affect UEFI boot, it doesn’t feel worth waiting for it to complete before I send this to QA. I prefer to give you more time to review and raise any concern you may have.)

Ok. I’m ready to merge this branch and I’ll do so in time for 3.3 unless you report that this test suite run failed for related reasons.

#22 Updated by anonym 2017-11-13 11:07:59

• Status changed from In Progress to Fix committed
• Assignee deleted (anonym)
• % Done changed from 90 to 100

#23 Updated by anonym 2017-11-15 11:34:10

• Status changed from Fix committed to Resolved