Feature #7747
Document that physically removing the USB stick to stop Tails might damage the persistent volume
50%
Description
People reported having problems (bad superblock) using the persistent volume after pulling out the USB stick to shutdown Tails.
This technique works, but shall we document that it is recommended to rather shutdown properly, as pulling out might leave the filesystem on the USB stick in a transitional state?
That would go as a caution on this page: https://tails.boum.org/doc/first_steps/shutdown/
Files
Subtasks
Related issues
| Related to Tails - Feature #7588: Evaluate the impact and interest of mounting persistence synchronized | Confirmed | 2014-07-13 |
History
#1 Updated by intrigeri 2014-08-06 07:40:12
- related to Feature #7588: Evaluate the impact and interest of mounting persistence synchronized added
#2 Updated by sajolida 2014-08-08 09:23:40
- Description updated
#3 Updated by emmapeel 2014-08-21 10:50:47
Maybe a native speaker can check the phrasing:
This method has been reported to sometimes make your Persistence setup become unstable.
It is safer for the data to use the previous methods when is not an emergency.Here the patch for https://tails.boum.org/doc/first_steps/shutdown/
#4 Updated by emmapeel 2014-08-21 10:53:10
- Assignee set to emmapeel
#5 Updated by BitingBird 2014-08-21 18:14:00
- Status changed from New to In Progress
- Assignee deleted (
emmapeel) - QA Check set to Ready for QA
a patch is proposed -> “ready for QA” and no assignee because anybody can review (I guess that will be sajolida though ;))
#6 Updated by sajolida 2014-08-22 12:17:49
>
> This method has been reported to sometimes make your Persistence setup become unstable.
> It is safer for the data to use the previous methods when is not an emergency.
> As this can damage data I think it deserves a
note. Look for examples on how we do that in the rest of the website.
I find the phrasing “has been reported to sometimes become unstable” a
bit long and blurry:
- “has been reported” is not useful if we are sure about what we’re
saying in the first place.
- “sometimes” maybe we can “in rare occasions” if that’s more precise.
I think that this problem is not sore common.
- "unstable: what can happen exactly? If this can lead to data loss we
should say it explicitly.
Regarding the second sentence:
- “safer for the data”, once the first sentence is fixed I think that
we can say “safer” only and the context will make it clear that we are
talking about data integrity here.
- “the previous methods”, let’s be more explicit and say “the system
shutdown icon”
#7 Updated by emmapeel 2014-08-22 15:32:37
very good suggestions indeed, so, what about this one:
This method may in rare occasions cause your Persistence setup become unstable.
You can [[recover|doc/first_steps/persistence/copy]] most of it, but you risk to lose the files you were working on when you did the emergency shutdown.
It is safer to use the system shutdown icon when not on an emergency.
(a new report from a user last week didn’t reported data loss).
#8 Updated by sajolida 2014-08-31 10:13:35
- Assignee set to emmapeel
- QA Check changed from Ready for QA to Dev Needed
That’s better.
I still have a few comments:
* “unstable” is still not explicit enough for me. What about “unusable” instead?
* “Persistence setup”, we use “persistent volume” to designate that storage. We sometime use “persistence” as a noun but here we are really talking about the storage itself.
* About the last sentence, what about putting it in an affirmative way and say “Only use this method in case of emergency.” which is even a bit shorter.
* About the second sentence, I feel weird saying “you can recover most of it” without explaining how. So what about moving that part at the end of the
and say “If this happens to you, you should be able to recover your data by doing a filesystem check on the persistent volume using GNOME Disk Utility”. We don’t really explain how to do this step by step but that’s a good start. Especially since I couldn’t find any online documentation for GNOME Disk Utility :(
#9 Updated by emmapeel 2014-09-01 07:02:01
> * About the second sentence, I feel weird saying “you can recover most of it” without explaining how.
So, you think that is not good to link to the howto on the wiki? Or maybe we need to do a new page about recovering? I thought that linking the howto on backp up your persistent volume would suffice…
This method may in rare occasions cause your Persistent volume become unusable.
If this happens to you, you should be able to recover your data by doing a filesystem check on the persistent volume using GNOME Disk Utility.
Do it only in case of emergency.
#10 Updated by sajolida 2014-09-02 01:45:15
- % Done changed from 0 to 50
- QA Check changed from Dev Needed to Ready for QA
- Feature Branch set to doc/7747-persistent-volume-damage
- Starter changed from Yes to No
If I understand correctly, the problem here is about broken filesystems that need recovering by doing a fsck of some sort. We have nothing like this documented on our website so far. But maybe you refer to another problem? (That’s why I find “unstable” not explicit enough.)
Yes, if we want to do that, it could fit on /doc/first_steps/persistence/copy/. But most of the time doing a filesystem check is not needed to do a backup, and a backup if not needed to fix a broken filesystem. So that could be a different page.
I wrote doc/7747-persistent-volume-damage to try to address this, can you have a look?
#11 Updated by sajolida 2014-09-14 10:33:47
- Status changed from In Progress to Resolved
- Assignee deleted (
emmapeel) - QA Check deleted (
Ready for QA)