Test suite on Buster: tor fails to bootstrap
Originally created by @CyrilBrulebois on #17689 (Redmine)
The title is based on my findings, please adjust if it turns out not to be accurate.
I’ve documented my need for “manually automated test suite follow-ups” during the 4.6 release process in #17684 (closed); that is: tests that were failing to pass in Jenkins, and that I needed to run locally.
Despite numerous attempts at trying to get those specific test suite items to pass, I’ve never ever manager to get Tor bootstrapped. I’ve even gone as far as bumping the max delay for tor from 270 to 10 times that, to make sure.
I’ve tried various things with 4.6 images, using the 4.6 test suite:
- test suite on buster-based system (AppArmor enabled): FAIL (Tor never bootstrapped).
- test suite on stretch-based system (AppArmor enabled): test suite OK (besides issues pointed in #17684 (closed) of course).
- manual tests within QEMU on the buster-system: Clock sync/Tor OK.
- manual tests on baremetal: Clock sync/Tor OK.
Looking at the failing tests on the buster-based system, it seemed the clock sync step was failing.
I’ve then investigated how the clock sync works, and learned about
htpdate. Therefore, I’ve thrown a tcpdump tcp port https -i any at
my buster-based system, and I’m seeing lots of traffic in the manual
QEMU case but none in the test suite case. I suspect if one doesn’t ask
for the time, one doesn’t get to know what time it is?
I’ve also checked again the https://tails.boum.org/contribute/release_process/test/setup/ page (the machine got installed a month ago, so I was pretty sure those didn’t change much), and I think my machine seems to comply with the documented prerequisites. It has no other purpose than building+testing Tails whatsoever, so I cannot imagine what could conflict…
In the logs, tor is stuck at Bootstrapped 5% (conn): Connecting to a relay.