The persistent Tor Browser directory and the GNOME bookmarks for persistence are not always created
I've noticed that on feature/stretch-unfrozen but forgot about it and indirectly did #12554 (by merging a branch based on feature/stretch-unfrozen). I at least want to investigate for 3.0~rc1 and try to come up with a fix. Worst case, document on known issues and fix in 3.0 final.
Grant GDM (and thus Tails Greeter) write access to /var/lib/live/config/ (refs: #12561).
Tails Greeter now creates the tails.persistence file directly in there, to avoid
race conditions between the PostLogin script and services run in the systemd
user session that depend on PostLogin.
See commit 7c6a763fd0ea12007f24483d3fe4cce0d25f359c in greeter.git
/usr/local/lib/tails-shell-library/tails-greeter.sh that looks in
/var/lib/live/config/tails.persistence, which is copied from
/var/lib/gdm3/tails.persistence in the
PostLogin file shipped by Tails Greeter. I don't think we have a guarantee that
PostLogin has finished running when we start the systemd user session and run
/usr/local/lib/create-tor-browser-directories. I'll try having Tails Greeter write directly to
/var/lib/live/config/tails.persistence and see if it helps.
- Assignee changed from intrigeri to anonym
- % Done changed from 20 to 50
- QA Check set to Ready for QA
I saw "Scenario: The persistent Tor Browser directory is usable" pass locally so I'm now confident I understood and fixed the root cause of the problem. We'll see if it reappears.
- Status changed from In Progress to Fix committed
- Assignee deleted (
- % Done changed from 50 to 100
- QA Check changed from Ready for QA to Pass
I had this branch merged when I tested something unrelated, but I ran the
The persistent Tor Browser directory is usable scenario which runs the steps:
Then the persistent Tor Browser directory exists And there is a GNOME bookmark for the persistent Tor Browser directory
which seems to cover this. And the code looks good (a definite improvement because of reduced code complexity)! => Merged!