Tails

#4 Updated by intrigeri 2015-12-09 14:05:22

I think I should tell the test suite to run the Installer with DEBUG=1, and to gather the debug log as part of the Jenkins artifacts somehow.

#6 Updated by intrigeri 2015-12-18 13:25:07

intrigeri wrote:
> I think I should tell the test suite to run the Installer with DEBUG=1, and to gather the debug log as part of the Jenkins artifacts somehow.

Done, so next runs of https://jenkins.tails.boum.org/view/Raw/job/test_Tails_ISO_bugfix-10720-installer-freezes-on-jenkins/ should hopefully tell me more about this problem :)

#7 Updated by intrigeri 2016-01-11 02:16:15

Strangely, I don’t see this failure anymore. But all recent builds fail “Scenario: Booting Tails from a USB drive without a persistent partition and creating one” and the next scenarios that use the “I have started Tails without network from a USB drive without a persistent partition and stopped at Tails Greeter’s login screen” snapshot: the video only shows “No bootable device”. What’s interesting is that “I can view and print a PDF file stored in persistent /home/amnesia/Persistent” and “Watching MP4 videos stored on the persistent volume should work as expected given our AppArmor confinement” pass, while they use a snapshot that is a child of the one that we fail to restore. I suspect there is a problem with the platform, possibly triggered only when we run the entire test suite at once.

#8 Updated by intrigeri 2016-01-11 02:19:13

Next debugging step: reorder features to run usb_install.feature first.

#9 Updated by intrigeri 2016-01-12 11:21:45

intrigeri wrote:
> Next debugging step: reorder features to run usb_install.feature first.

Done in the topic branch, and then the USB install tests passed for the first time in a while, while a couple other persistence -using tests started failing again like they used to fail a few weeks ago, before these “No bootable device” issues started to show up.

#12 Updated by intrigeri 2016-01-24 18:34:21

It’s back:

• https://jenkins.tails.boum.org/job/test_Tails_ISO_bugfix-10720-installer-freezes-on-jenkins/44/artifact/build-artifacts/03%3A33%3A31_Installing_an_old_version_of_Tails_to_a_pristine_USB_drive.png
• https://jenkins.tails.boum.org/job/test_Tails_ISO_bugfix-10720-installer-freezes-on-jenkins/45/artifact/build-artifacts/02%3A32%3A46_Installing_Tails_to_a_pristine_USB_drive.png
• https://jenkins.tails.boum.org/job/test_Tails_ISO_bugfix-10720-installer-freezes-on-jenkins/45/artifact/build-artifacts/03%3A32%3A24_Installing_an_old_version_of_Tails_to_a_pristine_USB_drive.png

#13 Updated by intrigeri 2016-01-24 18:53:46

The line that triggers this error is: system_partition.call_set_name_sync(self.label, GLib.Variant('a{sv}', None))

#15 Updated by intrigeri 2016-01-24 19:17:05

> The line that triggers this error is: […]

I’ve asked Alan, who added this line in a commit that didn’t really document why, if he had any idea what it is useful for.

#20 Updated by intrigeri 2016-01-24 19:38:58

The affected code is:

        # XXX: sometimes fails (https://labs.riseup.net/code/issues/10987)
        system_partition.call_set_type_sync(ESP_GUID, GLib.Variant('a{sv}', None))
        # XXX: sometimes fails (https://labs.riseup.net/code/issues/10720)
        system_partition.call_set_name_sync(self.label, GLib.Variant('a{sv}', None))

… and given the error message, I wonder if we need to wait for something between these two statements.

#21 Updated by intrigeri 2016-02-20 11:17:43

intrigeri wrote:
> > The line that triggers this error is: […]
>
> I’ve asked Alan, who added this line in a commit that didn’t really document why, if he had any idea what it is useful for.

… and he tells me that this line was added just in case it might be useful, but according to him, after reading udisks code it doesn’t seem to be useful. So I think I’ll remove that line, and upload a snapshot package to the topic branch’s APT suite, so we can see on Jenkins if it helps or not.

#25 Updated by anonym 2016-06-16 08:09:11

I’ve refreshed the feature branch. I also pinned the fixed tails-installer version so we actually test this with intrigeri’s fix, so we should revert commit:5107c485ff29e48bf983c1432e84089ed706e6ab before potentially merging this branch.

#27 Updated by intrigeri 2016-07-19 02:58:00

anonym wrote:
> I’ve refreshed the feature branch. I also pinned the fixed tails-installer version so we actually test this with intrigeri’s fix, so we should revert commit:5107c485ff29e48bf983c1432e84089ed706e6ab before potentially merging this branch.

Tried to fix that pinning with commit:3a243660ed3dc67b389fe57b6ca621807ef0f156, that should therefore be reverted as well.

#29 Updated by intrigeri 2016-07-20 02:16:14

> Next steps:
>
> * sync/settle/wait and retrieve a fresh partition object after call_set_type_sync;

Done in 4.4.10+dfsg-0tails1+bugfix.10720~1.gbp1473f2, building on Jenkins.

> * fix my tweak to include Tails Installer’s debug log in the test suite’s, as it does not work.

Still the case.

#30 Updated by intrigeri 2016-07-20 09:22:56

intrigeri wrote:
> > * sync/settle/wait and retrieve a fresh partition object after call_set_type_sync;
> Done in 4.4.10+dfsg-0tails1+bugfix.10720~1.gbp1473f2, building on Jenkins.

This makes partition_device exit successfully, but then switch_drive_to_system_partition is called, and calls _set_drive, which fails with “Cannot find device /dev/sda1”, that happens whenever self.drives.has_key(drive) is false.

#31 Updated by intrigeri 2016-07-20 10:02:53

> > * fix my tweak to include Tails Installer’s debug log in the test suite’s, as it does not work.

Done in 4.4.10+dfsg-0tails1+bugfix.10720~3.gbpe9be10.

#35 Updated by intrigeri 2016-07-22 03:26:08

Status: I’ve seen a couple successful test suite runs from that branch on Jenkins! I’d like to get the installer robustness improvements produced here into 2.6, so that they benefit human users even though they might not be good enough to mark the tests as non-fragile on Jenkins yet.