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? Sorry for the delay! Cheers! _______________________________________________ tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev
