Tails

#2 Updated by anonym 2019-10-23 15:04:25

anonym wrote:
> The changes we did in Bug #16748 were probably incomplete: for example, even if we run chroot/usr/bin/syslinux, that binary will probably look for its data files (MBR and such) in / and not in chroot/, so there’s a change that we were still mixing up bits of Stretch (from the Vagrant box) with bits from Buster (from the chroot).

We should verify this before we implement the suggested solution. I guess we could just run the same commands under strace or similar to record which files are actually accessed.

#4 Updated by intrigeri 2019-12-31 22:14:25

anonym wrote:

> We should verify this before we implement the suggested solution.

Absolutely!

> I guess we could just run the same commands under strace or similar to record which files are actually accessed.

This, or… build in a basebox that has no syslinux bits at all, and see if the build fails :)

#8 Updated by intrigeri 2020-01-11 17:48:28

Woohoo!

First, welcome aboard, johanbluecreek :)

anonym wrote:
> I have pushed your branch to our CI infra to get your work automatically tested before marking this as Needs Validation.

I understand that you expect johanbluecreek to manually test the image that will land in https://nightly.tails.boum.org/build_Tails_ISO_bugfix-17179-proper-chroot-for-syslinux/lastSuccessful within 24h after the 4.2.1 release.

johanbluecreek, once you’ve done so, please report back and deassign yourself, and then a Foundations Team member will check Jenkins results and review the code changes :)

#9 Updated by anonym 2020-01-12 18:50:32

intrigeri wrote:
> anonym wrote:
> > I have pushed your branch to our CI infra to get your work automatically tested before marking this as Needs Validation.
>
> I understand that you expect johanbluecreek to manually test the image that will land in https://nightly.tails.boum.org/build_Tails_ISO_bugfix-17179-proper-chroot-for-syslinux/lastSuccessful within 24h after the 4.2.1 release.

From what I understand he has built it himself and tested it, but he hasn’t run the automated test suite, so that’s why I pushed it (and what we are waiting for)!

> johanbluecreek, once you’ve done so, please report back and deassign yourself, and then a Foundations Team member will check Jenkins results and review the code changes :)

Since he does not have access to Jenkins’ test results, I’ll monitor this for him, and do those steps. Would be great if we could give read-only access ( publicly?) as a remedy.

#10 Updated by intrigeri 2020-01-12 19:01:55

anonym wrote:
> Since he does not have access to Jenkins’ test results, I’ll monitor this for him, and do those steps.

Great! :)

> Would be great if we could give read-only access ( publicly?) as a remedy.

Yep (Feature #6270). The main blocker we had for years (Bug #10068) is gone. I don’t know how much work Feature #6270 would take.

Meanwhile, some of the results can be found on https://nightly.tails.boum.org/, but not everything is accessible, because log files contain passwords.

#14 Updated by johanbluecreek 2020-02-06 16:20:01

Hi,

I pushed some new commits to my gitlab…

intrigeri wrote:
> My only significant concerns about this branch are:
>
> * The lack of cleanup in case of errors between the new mount and umount: if for whatever reason something fails in between, the build machine (e.g. a CI worker) could be stuck in a broken state until someone repairs it manually. AFAIK the Pythonic way to handle this is with a contextmanager, see e.g. how we do things with mount_iso in the same script.

Fixed. There is now a contextmanager decorated function that handles the mounting/unmounting

> * The 2 × mv dance in auto/build, which may be costly on systems that don’t build entirely in RAM, so if we can cheaply avoid it, I would prefer we do so. Couldn’t we also use the bind-mount trick there? We can assume we’re root in that script.

I replaced it with a bind-mount, as suggested.

With the new commits, it builds locally for me.

>
> Nitpicking/FYI/FWIW/YMMV/$acronym:
>
> * Calling out to mkdir and touch feels slightly wrong in a Python script. OTOH they’re in between shell commands and execute gives us some logging, so I’m fine with keeping it as-is.
> * Next time, please ensure you do atomic commits: e.g. the wiki/src/contribute/how/code/HACKING.mdwn file udpates don’t belong to commit:fa4ce1c8abf8786ad781c29c90f7e128ac71075a :)

OK, thanks. I will keep this in mind for the future.

#18 Updated by intrigeri 2020-02-07 09:46:08

> Sorry for making a mess. It appears I switched “Assignee” when I replied. That was not my intention.

I think that was not caused by a mistake on your side, but by a know Redmine UX bug related to caching. Thankfully in a few months Redmine will be a thing of the past for Tails :)

#20 Updated by intrigeri 2020-02-07 13:50:38

Code review passes, build succeeds here as well once merged into current stable.

Manual testing:

• The ISO boots fine from DVD in a VM.
• I’ve dd’ed the ISO to a USB stick and it boots fine on a laptop I have here, that only supports legacy BIOS boot. IIRC (to be checked!) we don’t support this officially anymore but well, we still make the ISO hybrid so I wanted to make sure we did not regress. I wonder if we should perhaps drop the isohybrid thing entirely at some point: it’s a kludge and it can break the boot in supported use cases, so perhaps not worth the risk?
• I’ve dd’ed the USB image to a USB stick and it boots fine on 1 legacy BIOS laptop and 1 UEFI laptop.

⇒ I’ll merge if my local test suite run passes!