linuxmint / linuxmint/timeshift

Trouble after switching distros (Mint 22.2 -> LMDE 7)

Open
#489 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Vala
Stars
4.3k
Forks
155
PR merge metrics
No merged PRs in 30d

Description

I recently switched from Mint 22.2 to LMDE 7. I knew that a best practice for Timeshift would be to use a new backup drive, but the type of trouble I had might be worth a warning in the documentation or the code itself.

First off, I knew this was a different distro and package base, so I was not surprised that Timeshift made an entirely new copy of everything. The Timeshift progress bar indicated this went as expected. The problems happened after the backup appeared to be finished:

  • The backup hard drive would not unmount.
  • Any file operation on the backup hard drive took an extremely long time.
  • Application Menu button for shutdown would only log off.
  • Login screen buttons for shutdown/restart were non-existent.
  • Attempting sudo shutdown resulted in an error message.
  • Invoking systemctl was the only way to shutdown or restart the computer.
  • Reformatting the backup hard drive on the same device did not resolve any of these issues. However, reformatting it on a different device did.

My own problem appears resolved; I have not had further trouble with Timeshift on LMDE. I did not lose any current user data, however, I lost all previous backups.

I realize I could have avoided this with wiser decisions. However, if someone without troubleshooting skills or a second machine attempts this, they might conclude Timeshift damaged their backup drive. Possibly worth adding a warning either in the documentation or the code.

I hope this is helpful. Thanks!

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

The issue names no files, tests, or entry points. Start by reviewing the documented distro-switch and backup-drive scenario, then inspect the relevant documentation or code warning surfaces mentioned in the report. Done means producing a confirmed, actionable warning or documenting why the behavior cannot be addressed.

Written by the indexing model from the issue text.

Assessment

Tech stack
linux
Domain
documentation, operating-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.