Hi,
On Sat, 23 Nov 2013 18:36:32 +0100 intrigeri <intrigeri@???> wrote:
> > but
> > the documentation I'm pointed to from the notification is not
> > really clear I think. It might be better to write bolder that one
> > should first try to upgrade to 0.21.
>
> In doc/first_steps/persistence/upgrade, in the first section
> ("Automatic upgrade"), the first bullet point is "If you have skipped
> the Tails 0.21 upgrade and have upgraded to a newer version", which
> points to how to the 0.21 upgrade process (maybe it's not *that* clear
> there, I don't know). We could be make the "have skipped 0.21" case
> higher priority on this page somehow, but it would make the doc less
> clear for people going the 0.20.1 -> 0.21 way, that is basically the
> same people, one hour later, so I'm not sure we gain anything.
>
> Frankly, I don't think I'm able to do much better. sajolida, if you
> feel this should be improved and see how, you're much welcome
> (deadline: December 7).
>
> Alternatively, you could try and follow the doc, and tell me exactly
> where you get lost, or where it's unclear. I know it too well to do
> that myself.
>
I think the text is basically right, but the presentation trigger my
eyes on the bold parts of the ordered list, not on the introductive
paragraph, which contains the best solution. I suggest:
We designed a **migration mechanism** that allows, in most cases,
**to upgrade automatically to those more secure persistent volume
settings**. To do this upgrade:
0. **start Tails 0.21**
1. **enable persistence** without the read-only option. If the
upgrade is successful, Tails starts as usual and no notification
appears. This upgrade is done once and for all. Activating the
read-only option prevents Tails from starting correctly until the
upgrade is made.
2. If the upgrade is successful upgrade to the latest Tails
But this automatic [...]
Then, keep the text but transform the ordred list to an unordered one
(so it looks less like the order of actions to perform).
> > That also means we sould let 0.21
> > download-able on mirrors for a while
>
> Sure. We always keep one or three old versions in the "obsolete"
> directory anyway, so nothing new.
>
> > 2. enabling persistence from 0.20.1, upgrade to 0.21, add a
> > live-additional-software.conf as root, upgrade to experimental.
>
> > Persistence works but live-additional software is disabled, and an
> > empty file is created: OK
>
> I don't get why it's OK that live-additional-software is disabled.
> Does "add a live-additional-software.conf as root" imply "with correct
> access rights" or "with wrong access rights"?
>
With wrong access rights (actually, what I would do with 0.21
doc says: just create it as root).
> > *But* if I doesn't delete the .insecure_disabled file, on next boot
> > I still get the warning notification, even though additional
> > software are actually configured. That's a bit confusing. (I don't
> > think this is a blocker, but it should be fixed at leaset for next
> > release).
>
> Unless I missed something, the doc page you're pointed to in this case
> (doc/first_steps/persistence/recover_insecure) tells you to do *one*
> thing:
>
> To enable again your persistent volume, follow the instructions to
> [[manually copy your persistent data to a new
> device|copy_to_a_new_device]].
>
> Incidentally, it doesn't tell you "alternatively, feel free to do
> whatever you want instead, we'll take care of the consequences of
> every possible creative action you might take, and we promise we'll
> make your life as painless as possible" :)
>
> In the described situation, Tails is in a broken state. We're pointing
> the user at documentation that explains how to repair it. If one does
> not follow these instructions, no wonder Tails is still broken (and
> protests in a different way, I admit that may be confusing). I don't
> think we should even try to support this case, and I don't find it
> a good use of my time to improve it. So, I beg to strongly disagree
> with your "it should be fixed at least for next release". Fair enough?
>
OK
> OTOH, we could as well teach live-persist that files owned by root are
> OK, *but* this will add diversity in what's deployed in the wild, and
> make things needlessly more complex when we want to add some GUI for
> the additional software feature, so I'd rather avoid that.
>
OK
