17

As I imagine a lot of Linux users do, over the years I've followed the advice of countless different threads, blogposts, videos etc. and made various changes to system files in order to improve my setup.

Some of those were motivated by personal preferences and customisations, e.g. changing/modifying keyboard layouts or mouse settings. Others were more fix-oriented, such as fixing my laptop not being able to wake up from sleep due to some manufacturer-specific issue, or messing with audio driver configs to get audio to work properly.

I now want to start over with a fresh installation. I'm planning to use the same distribution, and the same laptop, so most likely I will need to make those changes again to get things working the way I want them to - or even to get them working at all.

Is there a smart way to go about figuring out what changes I've made over the years that I will likely need to remake after reinstalling?

I've thought about checking to see which system files have been manually edited by me (assuming that it's possible), or even doing a diff on specific folders between my installation and a vanilla one. However, I definitely don't remember most of the files I've had to edit, and I don't know enough about Linux to know which files/directories are the important ones, which ones I can safely ignore etc.

EDIT: To clarify, I'm not talking about dotfiles; I keep those under version control.

EDIT 2: The distribution in question is Manjaro, i3wm version.

7
  • 2
    You could have a look at etckeeper Feb 20, 2022 at 16:31
  • Thanks for the suggestion @StéphaneChazelas, while this doesn't solve my current issue I'll make sure to start using it in my new installation to avoid having this issue in the future.
    – Dimitris
    Feb 20, 2022 at 16:37
  • 2
    As this might be very distribution specific, can you add your distribution to the question?
    – Zeta
    Feb 20, 2022 at 17:37
  • Having done this myself, may I suggest creating a list of package you have installed in your old system? It is easy to take package X for granted and be confused when you find yourself missing a key piece of functionality in your new system.
    – pypi
    Feb 21, 2022 at 8:21
  • 2
    It won't help you recover past mods you have made, and it is not useful for binary files, but in general, I just add a comment above any lines I change in system config files with my name in capital letters and a URL of what I was looking at when I made the change. Then I run a find and grep for my name and pipe that into tar to make backups of all the files I have changed. I tend to also save the previous version of any file I changed but with the date appended to its name so it isn't used by anything but is available. Feb 21, 2022 at 14:26

6 Answers 6

8

You can query the package database with pacman for Arch and its derivatives:

pacman -Qii | awk '/^MODIFIED/ { print $2 }'

This will give you a list of all modified files. To see the actual modifications you'd have to compare the files to the original ones from the respective package, but I wouldn't bother with that. Instead, backup all files from the resulting list and then diff those against your new installation.

2

I would make a clean install (in a vm, for instance) of the same distro/version with the same packages. It would be trivial to compare checksums etcetera.

2

As suggested already you can create clear install, generate hash of all files (exclude temporary ones in /tmp , /var/tmp and compare the hash values. But IMHO this will not give you a lot of information because if your system is installed for example 2 or 3 years ago you will see (almost) all the files changed because of new versions of packages. About the config files you can try to backup them and restore them in new installation or use diff to reveal the changes.

In the future if you want really to track the changes you can use audit subsystem which exist in (almost) all linux distributions.

5
  • It would be easy, on most distro's, to install the same versions as on the original source system. For Debian and lookalikes an 'apt install package=version' would do it.
    – JdeHaan
    Feb 20, 2022 at 17:27
  • @JdeHaan, yes and no. How will the OP remember the exact version of all packages when he/she install the system? Feb 20, 2022 at 17:34
  • by querying them? 'dpkg -l' shows a lot. If you want to format them 'dpkg-query' is your friend. 'dpkg-query --show --showformat='${Package}=${Version}\n'' to be exact.
    – JdeHaan
    Feb 20, 2022 at 17:35
  • 1
    @JdeHaan, think about situation the original installation was 3 years ago. dpkg will show CURRENT version. Feb 20, 2022 at 18:01
  • 1
    Which is exactly what the OP needs: comparing the difference between his current installation and a pristine.
    – JdeHaan
    Feb 21, 2022 at 15:52
1

You could start a git repository at the root of your filesystem /. You should gitignore everything (echo '*' > .gitignore) and instead use git add -f to manually track relevant files and git commit as you wish (or design a program that maps filesystem changes to commits).

Now you have a space-efficient database of the changes to your system: the git repo. You have all the features of git at your disposal. For example, you can easily go back in time in the git repository at the root of the filesystem with git checkout to a particular commit, branch, tag.

However if you do that at runtime I'm not exactly sure what can happen to running processes if you arbitrarily overwrite parts of the filesystem like that. I imagine it's best to avoid it at runtime. Ideally maybe you should find a way for e.g. git checkout operations to run before the Linux init process runs or something along those lines.

2
  • 2
    Making root into a git repo is emphatically not a good idea. Lots of things should be ignored, and it's not at all obvious what sort of filesystem changes should be tracked. A better solution would be to only track /etc, and then etckeeper solves most obvious problems. Unfortunately, the OP says in the comments that won't work for them. Feb 21, 2022 at 16:01
  • 1
    Good points. You can gitignore everything * and control yourself exactly what gets tracked by using git add -f to slowly add things to the repository that you want to track.
    – fabiomaia
    Feb 21, 2022 at 17:03
1

For now:

  1. Boot from USB and make a backup of your system on another disk
  2. Reinstall the OS using exactly the same version you are using now
  3. Reinstall all software and update it to to exactly the same version you are using now (but don't change the config)
  4. Boot again from USB, mount the new and the old system somewhere and compare the differences between the files (e.g. sudo diff -Naur /mnt/old /mnt/new)

Some creative use of find will also help you.
For example: Things like sudo find /mnt/old -xdev -mtime -100 will show you all files changed in the last 100 days.

I don't suggest doing exactly what I mentioned, otherwise the information you will get will be gigantic. You'll have to tweak a bit to your needs. (e.g. only compare some directories). find will help you with this.

For the future:

  • More version control (e.g. etckeeper)
  • More backups (e.g. rsync) and compare them from time to time (e.g. diff)
  • Filesystem with COW (e.g. btrfs )
0

Unlike most other existing answers, I'd like to suggest a less technical, more strategic solution.

The usual use case is not a reinstall on the same system, of the same operating system. Usually, you're migrating to a newer machine, or install a newer operating system version (or both at the same time). Naturally, then there are differences, and while any technical solution can reproduce a previous state easily, manual intervention is necessary to adapt to a new environment; in fact, changes may be so large that a lot of what you did in the past does not apply any longer, or at least not in the form you've recorded it.

If you're careful about system maintenance (meaning regular backups, imaging of the system partition, use of ephemeral VMs to try out software, and so on), these re-installations should be very rare, but eventually they do happen. To keep track of customizations and software installations, I keep a manual, written log, where I record important changes. I keep this on a cloud drive, so that it can even be edited during the initial system setup, or to record troubleshooting steps after fatal system failures.

I personally use plain text files (downside: no screenshots can be inserted, positive: easily accessible and searchable, can directly redirect diffs to it), but any note-taking program (like OneNote or Xournal++) should do as well. Here's an example of a software installation and system configuration:

20-Dec-2020 12:40
- Install Nextcloud.
$ sudo add-apt-repository ppa:nextcloud-devs/client
$ sudo apt update && sudo apt install nautilus-nextcloud
- Configure Nextcloud
  Applications > Accessories > Nextcloud desktop sync client
    (Login in browser)
    (O) Sync everything from server
    [v] Ask for confirmation for larger than 500 MB
    [v] Ask before syncing external storage
    Local Folder: /home/inkarkat/cloud
    General > General Settings
    [v] Launch on System Startup
    Network > Proxy Settings
    (O) Use system proxy

11-Jan-2021 07:52
- Set grub selection to indefinite wait, and remember the previous choice:
  --- /etc/default/grub.orig      2021-01-11 07:49:21.794532830 +0100
  +++ /etc/default/grub   2021-01-11 07:51:03.200229531 +0100
  @@ -3,9 +3,10 @@
  # For full documentation of the options in this file, see:
  #   info -f grub -n 'Simple configuration'
  
  -GRUB_DEFAULT=0
  -GRUB_TIMEOUT_STYLE=hidden
  -GRUB_TIMEOUT=10
  +GRUB_DEFAULT=saved
  +GRUB_SAVEDEFAULT=true
  +GRUB_TIMEOUT_STYLE=menu
  +GRUB_TIMEOUT=-1
  GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
  GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
  GRUB_CMDLINE_LINUX=""
  $ sudo update-grub

On a new system, I go over the old log and reapply things. Being able to copy-and-paste saves time and prevents errors, and it's very little extra effort to adapt to changes in the software that have happened in the meantime. (It also encourages you to prefer the command-line over GUI apps, as that's easier to document.) Changes can be applied in a different order, and one can apply judgement as to whether something is really needed ("application Foo? Let's see... never upgraded that one on the old system; I guess I can drop that on the new one.").

Of course, all of that will only help you with the upgrade after this one, but not with the current one - for that, you still have to work with your brittle memory and a bit of digging through the old system. I recommend this approach because I've been using this for 20 years, on numerous systems, and it has served me well.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .