Project

General

Profile

Bug #6228

Persistent partition needs recovery after clean shutdown

Added by sjmurdoch about 6 years ago. Updated almost 6 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Persistence
Target version:
-
Start date:
08/09/2013
Due date:
% Done:

0%

Feature Branch:
bugfix/unmount-persistent-volume-on-shutdown
Type of work:
Code
Blueprint:
Starter:
No
Affected tool:

Description

After performing a clean shutdown by choosing "Shutdown immediately", the persistent ext4 partition needs to perform recovery. As a result, if the USB drive is set read-only thought its hardware switch, the tails boot will hang after the persistent disk encryption password is entered. This is because if ext4 detects that it needs to recover by is read only, the mount will fail. If the disk is not read-only there is a dmesg log entry saying EXT4 recovery complete.

I was able to fix this by manually unmounting all the persistent partitions, and removing the cryptsetup mapping, before shutting down.

This is using Tails 0.19 with persistence (apt-cache, apt-lists, persistent folder and dotfiles)

Associated revisions

Revision 6e08de14 (diff)
Added by Tails developers about 6 years ago

Remount persistence devices read-only at shutdown/reboot time (Closes: #6228).

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/*).

Therefore, it can't remount them read-only at shutdown/reboot time. So, let's
patch the upstream file at build time for now, to let it know about
our mountpoints.

A possibly better long-term solution would be to have this change merged
upstream, but it's likely not to please them so much.

An even better long-term solution would be to have the live-boot code we use in
live-persist also move the mounts to the expected place. This could be part of
upstreaming live-persist, presumably.

On the other hand, all this upstreaming would be only so that our weird usecase
is better supported there; it does not look like similar features have been
asked by anyone else, so we may be as well served by maintaining this patch
directly in Tails.

History

#1 Updated by intrigeri about 6 years ago

sjmurdoch will try and reproduce it in the next few days, save fuser -m /live/persistence/*_unlocked and the results each time, so that we can see if there's a pattern.

#2 Updated by sjmurdoch about 6 years ago

On reboot (with the h/w switch set to read-write but the greeter read-only option enabled) the following appears in /var/log/syslog

Aug  9 12:54:56 localhost kernel: [   58.531199] EXT4-fs (dm-0): INFO: recovery required on readonly filesystem
Aug  9 12:54:56 localhost kernel: [   58.531205] EXT4-fs (dm-0): write access will be enabled during recovery
Aug  9 12:54:56 localhost kernel: [   58.589742] EXT4-fs (dm-0): recovery complete
Aug  9 12:54:56 localhost kernel: [   58.600295] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)

#3 Updated by sjmurdoch about 6 years ago

When the problem occurs, the only user of the partition (according to fuser) is that xmpp-client is being executed from it. xmpp-client appears to terminate when sent signal 15, so I would have not thought it would cause a problem for an unmount.

It would be interesting to know if other people have this problem. It could be that other people have this issue but do not notice because EXT4 will automatically recover unless the USB drive has a hardware read-only switch. Look in /var/log/syslog for "EXT4" to see if "recovery complete" is mentioned.

#4 Updated by sjmurdoch about 6 years ago

I just ran this test without starting xmpp-client (or starting any other applications explicitly) and the problem remains. So maybe it is not to do with xmpp-client and rather something else which is causing either the disk to not be unmounted properly or other changes happening after it was unmounted.

#5 Updated by intrigeri about 6 years ago

I just ran this test without starting xmpp-client (or starting any other applications
explicitly) and the problem remains. So maybe it is not to do with xmpp-client and
rather something else which is causing either the disk to not be unmounted properly
or other changes happening after it was unmounted.

May you please retry with Tails 0.20 and confirm it's affected too?

#6 Updated by sjmurdoch about 6 years ago

May you please retry with Tails 0.20 and confirm it's affected too?

Sure, but I won't be able to do so for a few days.

#7 Updated by intrigeri about 6 years ago

  • Assignee set to sjmurdoch

#8 Updated by sjmurdoch about 6 years ago

intrigeri wrote:

May you please retry with Tails 0.20 and confirm it's affected too?

I've now checked and the behaviour appears unchanged in Tails 0.20.

Before shutdown there are no users of /live/persistence/*_unlocked reported by fuser.

I investigated further by editing /etc/rc0.d/K11unmountroot to start a shell after remounting / read-only

The screenshot here shows the status: http://www.cl.cam.ac.uk/~sjm217/volatile/tails-shutdown.jpg

As you can see, the persistence partitions have not been unmounted, which would explain why the filesystems require repair on boot. At what stage were they supposed to have been umounted.

#9 Updated by sjmurdoch about 6 years ago

Here is the script I run before shutdown which seems to work-around the issue:

#!/bin/bash

for fs in `mount | awk '{print $1}' | grep --color=never /live/persistence/.*_unlocked`; do
  umount "$fs" 
done

for fs in `mount | awk '{print $1}' | grep --color=never /dev/mapper/.*_unlocked`; do
  umount "$fs" 
done

cryptsetup luksClose $(echo $(dmsetup status --target crypt) | cut -d: -f1)

#10 Updated by intrigeri about 6 years ago

  • Status changed from New to In Progress
  • Assignee changed from sjmurdoch to intrigeri

I can confirm this, and I think I've tracked it down to a bug in live-config. I'm working on a fix that I will submit upstream.

sjmurdoch: thanks for the detailed bug report and analysis!

#11 Updated by intrigeri about 6 years ago

  • Category set to Persistence
  • Assignee changed from intrigeri to anonym
  • QA Check set to Ready for QA
  • Feature Branch set to bugfix/unmount-persistent-volume-on-shutdown

#12 Updated by intrigeri almost 6 years ago

  • Status changed from In Progress to Fix committed
  • Assignee deleted (anonym)
  • QA Check changed from Ready for QA to Pass

#13 Updated by intrigeri almost 6 years ago

  • Status changed from Fix committed to Resolved

Fixed in 0.20.1.

Also available in: Atom PDF