Skip to content

"Additional software packages are installed even without network" test always fail in my environment

Hi! I’ve briefly mentioned this a few times already but never managed to file a ticket, so here we go. I’m aware that this test works fine on your machine and on lizard, but the fact it always fails in my environment (a replica of our Jenkins setup modulo I have a poor Internet connection), which otherwise runs the rest of the test suite in a more reliable manner than lizard, may be an indicator of a real problem, that could potentially affect more developers and not just me.

01:59:04   Scenario: Additional software packages are installed even without network                                                                       # features/additional_software_packages.feature:8
02:06:13     Given I have started Tails without network from a USB drive with a persistent partition enabled and logged in with an administration password # features/step_definitions/snapshots.rb:186
02:06:13     And the network is plugged                                                                                                                    # features/step_definitions/common_steps.rb:79
02:06:13     And Tor is ready                                                                                                                              # features/step_definitions/common_steps.rb:347
02:06:13       Tor failed to bootstrap (TorBootstrapFailure)
02:06:13       ./features/support/helpers/misc_helpers.rb:170:in `rescue in wait_until_tor_is_working'
02:06:13       ./features/support/helpers/misc_helpers.rb:164:in `/^Tor has built a circuit$/'
02:06:13       features/additional_software_packages.feature:11:in `And Tor is ready'

I’m attaching all the debug artifacts Jenkins saved for this scenario when I’ve run the full test suite on the 3.9~rc1 tentative ISO.

Potentially fishy things:

  • tor-has-bootstrapped returns 1 for 4 seconds and then returns 3 forever.
  • Logs begin at Fri 2018-08-17 00:50:17 UTC, end at Fri 2018-08-17 02:04:12 UTC means — I guess — that the oldest snapshot in the tree used here is already more than 1h old when we run this scenario; I wonder if ordering matters and if it’s just bad luck if this scenario fails and perhaps another similar one that would run at the same (relative) time would expose the same problem; I’ll try running only this scenario in the same environment, and perhaps running it at a different (relative) time
  • In the logs I see: Unexpected valid-until: [2018-08-17 02:02:00] is not [2018-08-17 02:01:40 + 3h]. Could this possibly make tor fail to bootstrap?

What other info should I provide to help you debug this? E.g. I could apply patches you give me to get more debug output, this sort of things.

Feature Branch: test/13541-more-robust-tor-bootstrap+force-all-tests

Attachments

Parent Task: #14568 (closed)

Related issues

Original created by @intrigeri on 15799 (Redmine)

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information