[[_TOC_]]  # New Persistent Storage In the Welcome Screen, we fail to activate the Persistent Storage. I don't know if we freeze, but some users think they have lost their data, while it could be that a `fsck` operation would fix it. WhisperBack reports which show this problem: * ed58ea093d6fda6d6175449e30b11b95 * 6db8ba7f10e5c055574f6793ced1ebcc * c3e724b6d6a7c6eacc394b512c58a9e3 * 7b16f32e2d50ee33cfb33aa5b94db434 # Old implementation plan <details><summary>Old plan</summary> * [x] Phase 0: automatically run `e2fsck -f -p`, log its result and continue in any case (!1351) * [ ] Phase 1.A: Depending on the exit code of `e2fsck -f -p`: * 0, 1: continue mounting * 2: "system should be rebooted" → should never happen in our context (only makes sense when checking the root filesystem) * 4: so we have "File system errors left uncorrected". We could try mounting anyway but we're (almost?) certain it'll fail since fsck marked the filesystem as unclean. This is the situation when a more forceful repair (`fsck -y` or the same via GNOME Disks) is necessary and generally sufficient. * others: indicates a bug somewhere, so probably an error message and then try continue to unlock * [ ] Phase 1.B: Detect buggy hardware (#5856) * [ ] Phase 2: Automate `fsck -y` when `fsck -p` was not enough Phase 1.A and 1.B could happen independently. </details> # Tips ## Corrupted filesystem that `e2fsck -p -f` *can* fix ```sh rm -rf /live/persistence/TailsData_unlocked/lost+found ``` or ```sh dd if=/dev/zero of=/tmp/ext4.img bs=1M count=100 mkfs.ext4 /tmp/ext4.img LOOP=$(losetup -f --show /tmp/ext4.img) mkdir -p /tmp/mnt mount "$LOOP" /tmp/mnt rm -rf /tmp/mnt/lost+found umount /tmp/mnt e2fsck -f -p "$LOOP" losetup --detach "$LOOP" ``` ## Corrupted filesystem that `e2fsck -p -f` *cannot* fix but `e2fsck -y -f` can and which *can* still be mounted. ```sh dd if=/dev/zero of=/dev/mapper/TailsData_unlocked bs=1k seek=10 count=4k ``` or ```sh # Create the filesystem dd if=/dev/zero of=/tmp/ext4.img bs=1M count=100 mkfs.ext4 /tmp/ext4.img # Attach the filesystem LOOP=$(losetup -f --show /tmp/ext4.img) # Create a file on the filesystem mkdir -p /tmp/mnt mount "$LOOP" /tmp/mnt echo foo > /tmp/mnt/foo umount /tmp/mnt # Corrupt the filesystem dd if=/dev/zero of=/tmp/ext4.img bs=1k count=1 seek=10 conv=notrunc # Mount the corrupted filesystem mount "$LOOP" /tmp/mnt ls /tmp/mnt umount /tmp/mnt # Try to fix the corrupted image with -p (this fails) e2fsck -f -p "$LOOP" echo $? # Fix the corrupted image with -y e2fsck -f -y "$LOOP" # Clean up losetup --detach "$LOOP" ``` ## Corrupted filesystem that `e2fsck -p -f` *cannot* fix but `e2fsck -y -f` can and which *cannot* be mounted. ```sh # Create the filesystem dd if=/dev/zero of=/tmp/ext4.img bs=1M count=100 mkfs.ext4 /tmp/ext4.img # Attach the filesystem LOOP=$(losetup -f --show /tmp/ext4.img) # Create a file on the filesystem mkdir -p /tmp/mnt mount "$LOOP" /tmp/mnt echo foo > /tmp/mnt/foo umount /tmp/mnt # Corrupt the filesystem dd if=/dev/zero of=/tmp/ext4.img bs=1k count=1024 seek=10 conv=notrunc # Try to mount the corrupted filesystem (this fails) mount "$LOOP" /tmp/mnt # Try to fix the corrupted image with -p (this fails) e2fsck -f -p "$LOOP" echo $? # Fix the corrupted image with -y e2fsck -f -y "$LOOP" # Mount the filesystem mount "$LOOP" /tmp/mnt # The file we created before is lost ls /tmp/mnt umount /tmp/mnt # Clean up losetup --detach "$LOOP" ``` # Old Persistent Storage _Originally created by @eugene__k on [#15451 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/15451)_ If the user attempts to mount the persistent filesystem from the greeter UI and it happens to be corrupted, the attempting-to-mount animation never goes away, and the “Start Tails” button stops working. There are no errors and it is not apparent to the user why it’s stuck. After that, the user has no choice but to to hard-reboot the system since the OS won’t load. I’ve seen this happen on two separate occasions, probably because the OS was not properly flushing its caches on shutdown (which may be a separate issue) or because the thumb drive was somehow malfunctioning. In both cases, after I rebooted and logged in without mounting persistent storage up front, I could unlock the partition using the “Disks” app with no errors, but the underlying partition was displayed as “Unknown” (rather than “ext4”) and I had to run fsck to repair it. Instead of freezing, the UI should attempt to unlock the filesystem and, if the filesystem is unlocked but can’t be mounted, display an error advising the user that the filesystem may be corrupted.