Tails

#1 Updated by intrigeri 2019-06-18 10:18:10

• Description updated
• Category set to Hardware support
• Type of work changed from Code to Research

@sajolida, a few questions:

• This machine is booting in UEFI mode, right? (grey background in the boot loader, no nice Tails custom syslinux theme)
• Just to make sure we can reasonably eliminate a faulty USB stick or corrupted data, can you please retry this with another USB stick on which you’ve installed from scratch a brand new feature/buster?

Meanwhile, I’m going to briefly research the error message to see if there’s another explanation.

#3 Updated by intrigeri 2019-06-18 10:30:28

• related to Bug #16755: Call for testing: feature/buster (June 2019 edition) added

#5 Updated by intrigeri 2019-06-18 11:36:33

• Priority changed from Normal to Elevated

#6 Updated by sajolida 2019-06-19 09:38:25

• blocks Feature #8393: Replace sound-juicer with Goobox (aka. GNOME CD Player) added

#8 Updated by intrigeri 2019-06-19 10:46:38

• Subject changed from Impossible to start on Mac to Impossible to start on MacBookPro 8,1

#9 Updated by intrigeri 2019-06-19 10:48:04

• Status changed from New to Confirmed

Thank you.

The “faulty USB stick” hypothesis has been fully invalidated ⇒ time to try & fix this. Bug #16818#note-4 has my ideas.

#10 Updated by intrigeri 2019-07-05 11:57:45

• Assignee set to intrigeri

So:

• the aufs.ko we build ourselves from upstream sources is 20MB and running strings on it yields 290564 lines, including strings I would not expect there, such as scsi (35 times) and sndbuf_policy (34 times); file says that it is compiled with debug_info and not stripped; gzip’ing it with default settings gives me a 5.8MB file
• the aufs.ko compiled on my sid by dkms is 572KB and running strings on it yields 3319 lines; not stripped, but no debug info; gzip’ing it → 147KB

So it looks like we could save a few MB on the initramfs size (therefore making boot faster for every user, and shortening the time between the bootloader and the plymouth splash, on top of hopefully fixing the problem this ticket is about), by removing this debug_info. I’ll look into this option before starting to remove kernel modules.

#11 Updated by intrigeri 2019-07-05 12:05:01

• Feature Branch set to bugfix/16818-smaller-aufs-module

#12 Updated by intrigeri 2019-07-05 12:05:18

• Status changed from Confirmed to In Progress

Applied in changeset commit:tails|4e7504c7e51bf30b019147df7ee06daef2ade7c6.

#13 Updated by intrigeri 2019-07-05 15:49:50

• Status changed from In Progress to Needs Validation
• Assignee changed from intrigeri to sajolida

initrd.img is down to 29MB on this branch => merged into feature/buster so I can ask sajolida to test it (my branch is based on stable so Jenkins won’t build it for Buster).

@sajolida, can you please try booting a feature/buster USB image dated from tomorrow (earliest) on this MacBookPro 8,1 and tell me if it helps?

#18 Updated by intrigeri 2019-07-06 08:06:39

• Assignee deleted (sajolida)
• Target version changed from Tails_4.0 to Tails_3.15

intrigeri wrote:
> And to be clear, regardless of sajolida’s feedback, I’ll request a proper review and merge into stable once I’ve seen Jenkins results.

Jenkins is happy enough (https://jenkins.tails.boum.org/view/Tails_ISO/job/test_Tails_ISO_bugfix-16818-smaller-aufs-module/, https://jenkins.tails.boum.org/job/test_Tails_ISO_feature-buster/) so please review and merge into stable; but don’t mark this ticket as “Fix Committed” until we have sajolida’s or alant’s feedback. segfault, anonym, @hefee: anyone?

#19 Updated by segfault 2019-07-07 11:36:45

• Assignee set to segfault

#20 Updated by segfault 2019-07-07 11:40:53

• Status changed from Needs Validation to In Progress

Applied in changeset commit:tails|f636011767eedd0567598689a8b392b3cac03821.

#21 Updated by segfault 2019-07-07 11:44:21

• Assignee changed from segfault to sajolida

Merged into stable -> devel -> feature/buster. Assigning to sajolida to provide feedback.

#23 Updated by sajolida 2019-07-09 06:45:38

• Assignee changed from sajolida to intrigeri

#25 Updated by intrigeri 2019-07-09 08:19:13

• Target version changed from Tails_3.15 to Tails_3.16

#26 Updated by intrigeri 2019-07-09 08:39:14

• Feature Branch deleted (bugfix/16818-smaller-aufs-module)

#28 Updated by intrigeri 2019-07-09 09:13:57

• Target version changed from Tails_3.16 to Tails_4.0

> I’m coming back with bad news: it got worse :(

Ouch!

> * Install 5712f23dbe from June 19 on another USB stick
> As reported initially, it shows up in the Mac startup disks, then displays the UEFI mode bootloader (gray background) and the kernel panic
> * Install 2007a18fa5 from July 8 on another USB stick
> This time it doesn’t even appear in the Mac startup disks.
> The same USB stick starts fine on a X200.

I’ve looked at the changes between these 2 images:

• on our side (5712f23dbe..2007a18fa5):
  • no change to partitioning or MBR -related stuff
  • only update between 3.14 and 3.15 APT suites: Thunderbird
• on Debian side: no syslinux update

So I really don’t understand how behavior can have changed for you :/

You initially reported “At first I had a hard time making the USB stick appear in the Mac startup disks”, about an earlier version (bc022ef71e, June 8), which suggests that there’s some amount of non-determinism around all this, and makes me wonder why an intermediary version (5712f23dbe, June 19) works better than that one. So I’d like to know how many times you did both tests (the successful one and the failing one) and whether you did them in exactly the same way: all kinds of small details can matter here, for example “was the USB stick already started on another computer before?”, “did you reboot or power off?”, “was that ‘another USB stick’ the same one in both cases?”, etc.

Also, it would be useful to know whether a feature/buster USB stick cloned with Tails Installer displays the same behavior or not: there’s a small chance that the bootloader bits on the resulting USB stick are 100% Buster while the ones you’ve tested are a mix between Stretch and Buster (see below for technical details if curious). This would help tell if the problem comes from the ISO to USB image conversion process.

In any case, it seems clear that you’ve never had any issue with 3.x but you see trouble with feature/buster, so let’s try some things that may help us understand where the problem comes from:

• Buster with Stretch’s syslinux
• Buster built in a Buster Vagrant box: I’m concerned that since commit:6e097195f13e44a4664051cad79f32dc2f134c9f, auto/scripts/create-usb-image-from-iso uses the syslinux binary from the (Buster) chroot, but it’s not run with chroot, so there’s a chance that it uses files from the Vagrant box (e.g. the MBR or whatnot), which might create inconsistencies and trouble

> NB: You changed the target version from 4.0 to 3.15 while this bug is only affecting feature/buster, but you probably have a good reason for that :)

That was because I wanted bugfix/16818-smaller-aufs-module into 3.15 which is now done ⇒ reverting.

#29 Updated by intrigeri 2019-07-09 09:37:16

• Feature Branch set to bugfix/16818-buster-vagrant-box

#30 Updated by sajolida 2019-07-09 11:34:52

• Status changed from In Progress to Resolved

OMG! You rock! It’s working now :)

This morning I missed the fact that I had USB images for bc022ef71e and 5712f23dbe but an ISO image for 2007a18fa5. D’oh!

Now I downloaded an USB image for 7523d0b2a0 and it starts fine :)))

Also, in my previous tests I managed to get rid of the non-determinism by always getting to the startup disks menu before plugging the USB stick.

#31 Updated by intrigeri 2019-07-09 11:57:39

• blocks Feature #16209: Core work: Foundations Team added