Project

General

Profile

Bug #12146

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

Added by intrigeri over 2 years ago. Updated 4 months ago.

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

100%

Feature Branch:
Type of work:
Research
Blueprint:
Starter:
Affected tool:
Installation Assistant

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 (#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 ProResolved

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


Related issues

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

Associated revisions

Revision 6d44a908 (diff)
Added by intrigeri about 2 years ago

Let xorriso hybrid the ISO image, instead of doing it ourselves (refs: #12146).

Revision b1b3500a (diff)
Added by intrigeri about 2 years ago

Enable the bugfix-12146-syslinux-fixes APT overlay (refs: #12146).

Changes in that overlay:

syslinux (3:6.03+dfsg-14.1+tails1) bugfix-12146-syslinux-fixes; urgency=medium

  • Cherry-pick 3 upstream commits that might fix isohybrid issues
    (refs: Tails#12146).
-- intrigeri <>  Fri, 26 May 2017 08:47:28 +0000

History

#1 Updated by intrigeri over 2 years ago

  • 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 over 2 years ago

  • 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 over 2 years ago

  • 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 over 2 years ago

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 over 2 years ago

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

Can you please report a separate bug about this?

#6 Updated by mercedes508 over 2 years ago

created #12244

#7 Updated by intrigeri over 2 years ago

  • 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 (#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 over 2 years ago

  • 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 over 2 years ago

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

#10 Updated by intrigeri over 2 years ago

  • Description updated (diff)

#11 Updated by intrigeri over 2 years ago

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

#12 Updated by intrigeri over 2 years ago

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

#13 Updated by intrigeri over 2 years ago

intrigeri wrote:

Next thing I want to try: some other isohybrid options, see #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 over 2 years ago

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 over 2 years ago

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

#16 Updated by intrigeri over 2 years ago

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

#17 Updated by intrigeri about 2 years ago

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 about 2 years ago

  • Status changed from Confirmed to In Progress

#19 Updated by intrigeri about 2 years ago

  • 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 about 2 years ago

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 about 2 years ago

  • 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 about 2 years ago

  • 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 over 1 year ago

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:

parentblock = udisksclient.get_block_for_drive(drive, get_physical=False)

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:

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)

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 over 1 year ago

  • 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 over 1 year ago

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

#26 Updated by intrigeri over 1 year ago

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 #12146#note-22 still stands, so I'll try hard not to work on this until February.

#27 Updated by intrigeri over 1 year ago

  • Description updated (diff)

#28 Updated by intrigeri over 1 year ago

According to #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 over 1 year ago

  • 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 over 1 year ago

#31 Updated by intrigeri over 1 year ago

intrigeri wrote:

According to #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 (#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 over 1 year ago

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

#33 Updated by sajolida over 1 year ago

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 over 1 year ago

  • 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 over 1 year ago

  • 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 over 1 year ago

#37 Updated by intrigeri over 1 year ago

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

#38 Updated by intrigeri over 1 year ago

  • Assignee changed from intrigeri to segfault

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

#39 Updated by sajolida over 1 year ago

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

#40 Updated by sajolida over 1 year ago

  • 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 4 months ago

#42 Updated by intrigeri 4 months ago

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

Fixed by #15292.

#43 Updated by intrigeri 4 months ago

  • Status changed from Rejected to Resolved

(Gah, misclicked.)

Also available in: Atom PDF