Author: anonym Date: To: The Tails public development discussion list Subject: Re: [Tails-dev] Please review'n'merge
bugfix/unmount-persistent-volume-on-shutdown (#6228)
03/09/13 15:08, intrigeri wrote: > intrigeri wrote (22 Aug 2013 13:25:18 GMT) :
>> please review'n'merge bugfix/unmount-persistent-volume-on-shutdown,
>> that fixes ticket #6228, into stable and devel.
My tests show that an old Tails install that consistently had to do
recovery after boot consistently didn't have to do recovery once
upgraded to a version with the fix. With "consistently" I mean something
like "three reboots", in boot cases (well, an extra we're you get a
recovery for the latter scenario since it'd have to do deal with the
mess from the last shutdown with the older version).
I do, however, have a two questions:
1. I don't see how this unmounting performed in boot-init.sh deals with
removing LUKS' DM mappings, which should prevent TailsData from being
unmounted cleanly. The mappings are unmounted, and after that there's a
sync, but is that enough? I don't see any mentions of recovery for the
TailsData partition in syslog, so maybe it's all fine. Just something
for consideration.
2. Next, let me cite your git commit message:
> The upstream live-boot initscript (shipped by live-config) doesn't know about
> our persistent mounts (/live/persistence/*), since they are performed from GDM,
> and not further moved to the same place as mounts done during initramfs are
> (/lib/live/mount/persistence/*).
So, instead of patching boot-init.sh, why don't we make Tails Greeter
mount its persistent volumes in the same directory as live-boot? My
understanding is that our mount point is just an artifact of us using an
old (development) version of live-boot, which used that directory, at
the time Tails Greeter was extended with persistence support, but I may
be wrong.
If this makes sense, perhaps we should re-work
feature/consistent-peristence-path (also in the Tails Greeter repo) to
use the same persistence path, and then drop this chroot patch?
---
Even if 1 is something we care about this branch only makes the
situation better, and 2 is something we'd want in a new feature for a
major release, not a bugfix release like 0.20.1, so I merged this into
stable (and devel).
>> I've assigned the ticket to anonym for review, since he's the one who
>> knows our persistence code best, but I'm sure many others would be
>> able to grep for "recovery" in dmesg output, and confirm this patch
>> does what it pretends to :)
>
> Ping? anonym, do you think you can do this in time for the freeze, or
> should I nag someone else?
