Bug #12146

Tails installed using dd is not seen as a bootable device on MacBook Pro

Added by intrigeri 2017-01-15 17:49:03 . Updated 2019-03-06 11:35:26 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Hardware support
Target version:
Hole in the Roof
Start date:
2017-12-08
Due date:
% Done:

100%

Feature Branch:
Type of work:
Research
Blueprint:

Starter:
Affected tool:
Installation Assistant
Deliverable for:

Description

I’ve tried starting Tails installed with dd with all combinations of:

  • Tails 2.9.1 and 2.4
  • MacBook Pro 6,2 and MacBook Pro 8,1
  • Lexar USB 3.0 and Kingston DataTraveler G3 USB sticks
  • Mac boot loader (on both laptops) and rEFInd (only on the MBP 6,2)

The Mac boot loader has never showed me any of these USB sticks. rEFInd does show me the USB stick, but once I press enter it starts a Windows installation that’s on the internal hard drive of the (dual-boot) laptop.

It was reported (Bug #15021) that MacBookPro 13,2 and MacBookPro 14,3 exposed similar issues.

Subtasks

Bug #15025: Document that Tails installed using dd is not seen as a bootable device on some MacBook Pro Resolved

0
Feature #15325: Test if a DVD works on a Mac where a dd Tails is not recognized Resolved

50

Related issues

Related to Tails - Bug #7462: isohybrid command returns warnings on Tails 1.1 Resolved 2014-07-31
Related to Tails - Feature #5691: Consider upgrading to current live-build Confirmed
Related to Tails - Feature #14448: Consider documenting Rufus as a workaround in case UUI doesn't work Rejected 2017-08-24

History

#1 Updated by intrigeri 2017-01-15 17:49:36

  • Assignee set to intrigeri

Next steps:

  • test with Tails 1.x (I’ll do it)
  • dear help desk, did you get any similar bug report?

#2 Updated by mercedes508 2017-01-21 14:56:27

  • Type of work changed from Test to Research

I just tested with an intermediate Tails 1.8.1 on a MBP 9.2 (without rEFInd) and it is recognized as a bootable device.

And we got at least one similar report, but without details about Tails USB being intermediate or not, and no email

#3 Updated by intrigeri 2017-02-07 01:54:31

  • Assignee changed from intrigeri to mercedes508
  • QA Check set to Info Needed

mercedes508 wrote:
> I just tested with an intermediate Tails 1.8.1 on a MBP 9.2 (without rEFInd) and it is recognized as a bootable device.

What about Tails 2.10 on the same computer?

#4 Updated by mercedes508 2017-02-14 16:58:55

On the same computer, Tails 2.10 installed using dd (from Linux) is recognized as a bootable device, starts booting but apparently get stuck forever with a bliking cursor. Which as far as I remember was what I got from the 1.8.1 intermediate Tails. I do’t remember if I installed it using dd from Linux or OSX. I can later reproduce from OSX dd only.

#5 Updated by intrigeri 2017-02-15 10:01:06

> […] starts booting but apparently get stuck forever with a bliking cursor.

Can you please report a separate bug about this?

#6 Updated by mercedes508 2017-02-16 11:32:56

created Bug #12244

#7 Updated by intrigeri 2017-03-03 17:54:26

  • Assignee changed from mercedes508 to intrigeri
  • QA Check deleted (Info Needed)

Reproduced on MacBook Pro 8,1 with Tails 1.8.2 (that was current when the Installation Assistant was released, so I was kinda hopeful it would work).

Interestingly, when we got back to isohybrid 2 years ago (Feature #8510), we tested DVD on Mac twice, but didn’t test dd’ing a hybrid ISO to USB and booting it on a Mac. I’ll now try:

  • building from stable and using different isohybrid options
  • some even older, non-hybrid Tails ISO, that I’ll hybrid by hand

#8 Updated by intrigeri 2017-03-03 17:55:25

  • Target version set to Tails_2.12

(Mostly to keep it on my radar: I don’t realistically aim to fix it in 2.12.)

#9 Updated by intrigeri 2017-03-03 19:29:01

  • 2.10, AMNESIA_ISOHYBRID_OPTS="": fails
  • 1.1.2, isohybrid’ed by hand (sid’s syslinux) with no option: fails

#10 Updated by intrigeri 2017-04-03 08:00:28

  • Description updated

#11 Updated by intrigeri 2017-04-03 08:05:10

  • related to Bug #7462: isohybrid command returns warnings on Tails 1.1 added

#12 Updated by intrigeri 2017-04-03 08:06:17

Next thing I want to try: some other isohybrid options, see Bug #7462 for historical info about what we used to do, and why we changed it.

#13 Updated by intrigeri 2017-04-12 07:16:58

intrigeri wrote:
> Next thing I want to try: some other isohybrid options, see Bug #7462 for historical info about what we used to do, and why we changed it.

I also want to try:

  • feature/5630-deterministic-builds, that uses xorriso
  • feature/5630-deterministic-builds and let xorriso produce a hybrid ISO itself (--binary-images iso-hybrid) instead of hybriding it ourselves after the fact

#14 Updated by intrigeri 2017-04-12 07:22:16

And these two upstream syslinux commits might be relevant:

commit 32c09027423f61c305e2423e52f5f69ecad8e2c0
Author: Martin Str|mberg <ams@ludd.ltu.se>
Date:   Sun Mar 26 07:32:11 2017 -0400

    mbr/isohdpfx.S: correct stack for heads/sectors; revert

commit 8739e2ff9ba3f92652c8df846924fd00e1ce2753
Author: Martin Str|mberg <ams@ludd.ltu.se>
Date:   Sun Mar 26 07:54:29 2017 -0400

    mbr/isohdpfx.S: Clear CX on INT 13h AH 41h failure

#15 Updated by intrigeri 2017-04-12 08:23:07

And (finally?) I want to try passing --uefi to the isohybrid command.

#16 Updated by intrigeri 2017-04-12 08:24:27

  • Target version changed from Tails_2.12 to Tails_3.0

#17 Updated by intrigeri 2017-05-26 08:26:20

Another potentially relevant upstream commit:

commit 80b0ef5ffd6998818b3785c3c15bf2ae73687e09
Author: Colin Finck <colin@reactos.org>
Date:   Thu Jan 19 00:41:39 2017 +0100

    isohybrid: Open ISO file in binary mode

    Open ISO file in binary mode to ensure that line endings stay untouched.

#18 Updated by intrigeri 2017-05-26 08:56:29

  • Status changed from Confirmed to In Progress

Applied in changeset commit:b1b3500a16070e1f12d2f9dee0416ebe6cc2b3fc.

#19 Updated by intrigeri 2017-05-26 11:02:44

  • Status changed from In Progress to Confirmed

intrigeri wrote:
> * feature/5630-deterministic-builds, that uses xorriso

Tails 3.0~rc1 was built using xorriso, and it exposes the same problem on a MacBook Pro 8,1.

> * feature/5630-deterministic-builds and let xorriso produce a hybrid ISO itself (--binary-images iso-hybrid) instead of hybriding it ourselves after the fact

I’ve tried this (wip/bugfix/12146-hybrid-with-xorriso, based on current testing, formerly aka. feature/stretch, that uses xorriso) and it doesn’t fix this problem on a MacBook Pro 8,1. But even xorriso uses /usr/lib/ISOLINUX/isohdpfx.bin so I’ll retry this approach, combining it with the one discussed below.

I’ve also tried cherry-picking the 3 aforementioned syslinux commits (wip/bugfix/12146-syslinux-fixes): same problem.

Combining both approaches (wip/bugfix/12146-hybrid-with-xorriso+syslinux-fixes) didn’t work any better.

#20 Updated by intrigeri 2017-05-26 12:54:31

intrigeri wrote:
> And (finally?) I want to try passing --uefi to the isohybrid command.

This doesn’t work with our current ISO (output = “unable to find efi image”): http://www.syslinux.org/wiki/index.php?title=Isohybrid#UEFI explains what we need to do to support UEFI boot on hybrid ISOs.

#21 Updated by intrigeri 2017-05-27 06:20:03

  • Target version changed from Tails_3.0 to Tails_3.2

I was looking for an easy and non-risky solution for 3.0, but clearly the only option left that I can think of (adding UEFI support to our isohybrid image) is not easy, and is risky.

#22 Updated by intrigeri 2017-06-05 17:39:46

  • Target version deleted (Tails_3.2)

So this will require quite some work and calls for testing. It’s not clear to me how high I should prioritize it vs. our other plans in the installation area, so dropping the target version until that’s clarified.

#23 Updated by delinquentme 2017-10-31 09:19:38

Ive been able to get a bootable TAILS 3.2 installation using a tool called “Mac Linux USB Loader” https://github.com/SevenBits/Mac-Linux-USB-Loader

Its possible I’ve gotten further than anyone else in this install process on a 2015 MacBook Retina, being that I’ll attach the current bug Im running into here.

When running the tail-installer from the intermediate disk… It fails to start.

It throws an exception from utils.py at:

<code class="python">
parentblock = udisksclient.get_block_for_drive(drive, get_physical=False)
</code>

Giving an error something like:
“Argument 1 does not accept None”

I THINK… parentblock should be something like “/dev/sdc1” even though the comment on the function has something more verbose: “/org/freedesktop/UDisks2/block_devices/sdb”

I think the BlocksProxy object seems to have a few values for its attributes which dont match the type given in the documentation for UDisks2 BlocksProxy Class (https://lazka.github.io/pgi-docs/UDisks-2.0/classes/BlockProxy.html)

It would be very helpful if someone would give me the output of this code in the tails_installer/utils.py file:

<code class="python">
def underlying_physical_device(path):
    ...
    block = udisksclient.get_block_for_dev(rawdev)
    print "------ block="
    print block.connection
    print block.flags
    print block.name
    print block.object_path
    print block.cancellable
    print block.callback
    print block.user_data
    print "------"
    drive = udisksclient.get_drive_for_block(block)

</code>

From the documentation it seems block.object_path and block.name should be strings, but when running my tails-installer they’re instances of other objects, from my recollection Gio.* objects.

#24 Updated by intrigeri 2017-11-11 10:45:05

  • Target version set to Hole in the Roof

(Having our install doc on Mac via USB totally broken seems to qualify.)

#25 Updated by intrigeri 2017-11-11 21:19:16

dumpet will be useful if/when adding UEFI support to our ISO (for DVD boot and then for isohybrid boot).

#26 Updated by intrigeri 2017-11-11 21:27:10

Apparently the simplest way would be to create a FAT image that embeds GRUB2’s BOOTX64.EFI and a GRUB config file that uses our syslinux config, similarly to what we do for 32-bit UEFI already. And then we can point xorriso to this FAT image and finally pass --uefi to the isohybrid command. This should be fairly easy, but we need to teach our live-build fork how to pass additional, custom XORRISO_OPTIONS. The relevant code may already be available in newer versions of live-build, so that’s where we should look first.

Resources:

Now, my comment from Bug #12146#note-22 still stands, so I’ll try hard not to work on this until February.

#27 Updated by intrigeri 2017-12-08 16:51:52

  • Description updated

#28 Updated by intrigeri 2017-12-08 16:52:57

According to Bug #15021 Kali Linux’ ISO, installed to a USB drive with dd, boots fine on MacBookPro 13,2 and MacBookPro 14,3, while Tails fails the exact same test.

#29 Updated by intrigeri 2017-12-08 16:58:37

  • related to Bug #15025: Document that Tails installed using dd is not seen as a bootable device on some MacBook Pro added

#30 Updated by intrigeri 2017-12-08 17:26:22

  • related to Feature #5691: Consider upgrading to current live-build added

#31 Updated by intrigeri 2017-12-08 17:28:54

intrigeri wrote:
> According to Bug #15021 Kali Linux’ ISO, installed to a USB drive with dd, boots fine on MacBookPro 13,2 and MacBookPro 14,3, while Tails fails the exact same test.

It seems that current live-build upstream does the right thing by default (see scripts/build/binary_{grub-efi,iso,syslinux,loopback_cfg} in its Git tree) which is why Kali boots fine. We could replicate this (which is essentially what the plan I described above was except we have a source of inspiration more similar to our current build system) or we could switch to current live-build. Last time we tried porting our code base to a newer live-build (Feature #5691) we gave up but times have changed, and live-build is now maintained in a way that would allow us to contribute our stuff more easily.

#32 Updated by intrigeri 2017-12-08 17:30:19

  • blocked by Feature #11679: Rethink the installation process and upgrade process added

#33 Updated by sajolida 2018-02-04 13:32:08

I can reproduce this bug with Tails 2.2 (2 years old) so it was already happening when we wrote the installation assistant.

#34 Updated by sajolida 2018-02-04 14:29:25

  • Subject changed from Intermediary Tails is not seen as a bootable device on MacBook Pro to Tails installed using dd is not seen as bootable on MacBook Pro

Actually, when the intermediary Tails has been installed using UUI 1.9.8.0 I can boot from it on MacBook Pro 8,1.

Changing the title of this ticket accordingly.

#35 Updated by sajolida 2018-02-04 14:30:30

  • Subject changed from Tails installed using dd is not seen as bootable on MacBook Pro to Tails installed using dd is not seen as a bootable device on MacBook Pro

#36 Updated by intrigeri 2018-02-06 16:05:29

#37 Updated by intrigeri 2018-02-06 16:17:20

  • blocks deleted (Feature #11679: Rethink the installation process and upgrade process)

#38 Updated by intrigeri 2018-02-06 18:02:00

  • Assignee changed from intrigeri to segfault

This will be fixed by Feature #15292 => reassigning to the lead developer for that project :)

#39 Updated by sajolida 2018-02-16 21:30:44

  • related to Feature #14448: Consider documenting Rufus as a workaround in case UUI doesn't work added

#40 Updated by sajolida 2018-02-18 12:59:02

  • related to deleted (Bug #15025: Document that Tails installed using dd is not seen as a bootable device on some MacBook Pro)

#41 Updated by intrigeri 2019-03-06 10:22:40

#42 Updated by intrigeri 2019-03-06 10:23:01

  • Status changed from Confirmed to Rejected
  • Assignee deleted (segfault)

Fixed by Feature #15292.

#43 Updated by intrigeri 2019-03-06 11:35:26

  • Status changed from Rejected to Resolved

(Gah, misclicked.)