Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • T tails
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 971
    • Issues 971
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 26
    • Merge requests 26
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • tails
  • tails
  • Issues
  • #17902
Closed
Open
Issue created Aug 28, 2020 by sajolida@sajolidaMaintainer

Deleted obsolete automatic upgrades still occupy disk space ⇒ no automatic upgrade possible after a while

See #11628 (comment 153906).

This can happen simply by applying enough automatic upgrades in a row. Doing a manual upgrade is not sufficient to fix the problem.

Symptoms

There is a discrepancy between:

  • The disk space used on the system partition (as seen by df) grows after every automatic upgrade more than it should. It reaches 3GB or more.
  • The total size of the files stored on that partition (as seen by du) remains as small as expected, i.e. below 2GB.

Why this happens

During shutdown, after applying an automatic upgrade, we don't cleanly unmount the system partition. So the filesystem is left dirty, with unused clusters still occupying space.

Proposed solution

  • To fix the root cause: try to cleanly unmount the system partition on shutdown

  • To recover filesystems that are already affected by the problem: on boot, repair the filesystem on the system partition and delete fsck recovery files.

    And then:

    • Users who still have enough usable free space to automatically upgrade: apply the automatic upgrade.
    • Users who are already unable to automatically upgrade: manually upgrade.

    I.e. in both cases: do what the Upgrader says. And then, the filesystem will be repaired on next boot. So no need for extra documentation or manual steps.

How users can recover in the meantime

Fresh re-install

To workaround this issue, users can:

  1. Download the latest USB image
  2. Install a fresh USB stick
  3. Back up the old USB stick on the new USB stick: https://tails.boum.org/doc/first_steps/persistence/backup/

Repair the filesystem

From another Linux system (which could be another Tails):

  1. Repair the filesystem
    • Either on the command-line: run fsck.vfat -a -w -V -v on the affected system partition.
    • Or via GNOME Disks: Repair filesystem on the affected system partition.
  2. Mount the system partition read-write
  3. Delete any FSCK*.REC file at the root of the system partition
Edited Mar 29, 2021 by emmapeel
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking