[solved] Rebuilding the pacman database

Gede · 2018-08-19 19:31:59

Hello all. I think I messed up, but let me use this as a learning opportunity.

Background story:
When I installed Arch Linux I used btrfs subvolumes for /, /home and /var. It all worked out mostly fine for many years.
At some point I was concluding some very important work and I did not want to risk doing system updates. That took about 7 months. Then I got some conflicts, and I took a snapshot of / and resorted to the Arch Linux Archive for the upgrade.
Well, I went backwards and forwards in ALA because, there was some graphic card problem around April-May-June. SDDM would hand with a garbled screen and even starting-up in text-mode would not work well. I now have kept the system at this point in time.

The problem:
I took care of the / subvolume, but not with the /var subvolume (oops!). When trying to upgrade one of the / subvolumes for experimentation, I get an error from pacman saying that many files already exist in the filesystem. That leads me to believe that is is some problem of the database expecting different packages being installed.

The solutions:
I suppose that I can discard those experimentation snapshots and branching off from the current point, where / and /var are in sync. I don't recall if I have tried that one. But what other possibility exists? Forcing the installation of the packages, seeing if the X problem persists and throwing away those filesystem versions? Forcing the removal and re-installation of every package in a long series? I'm open to ideas and learning a bit more about pacman.

Thank you for your attention.

Last edited by Gede (2018-10-04 21:45:34)

eschwartz · 2018-08-19 21:24:09

The primary issue is that pacman itself stores its databases in /var by default, so you cannot even keep track of which packages are installed, let alone which versions.

Gede · 2018-08-19 21:56:15

I figured that much. I also suppose that the same goes for most distributions.

If there is such an interconnection between the contents of /var and most other directories, why do I see so many recommendations to keep /var in a separate partition? How should I have reorganized my subvolumes better?

eschwartz · 2018-08-19 22:08:57

That recommendation comes from the mindset of "set max limits for disk usage by embedding this information in the partition table", whereas ideally this would be done using quotas.

It's not necessarily bad to have them in separate subvolumes... it's just not sufficient reason to say "okay it is safe to let them get out of sync".

Also some people might use e.g. along the lines of http://0pointer.net/blog/projects/stateless.html where /var is non-persistent data (tmpfs) and /usr is a read-only static snapshot of some known -good system which will be used in containers etc.

Last edited by eschwartz (2018-08-19 22:13:03)

Gede · 2018-08-21 22:35:55

So, it is impossible to reconstruct that information. I'll update the title once I overcome this hurdle.

/var is not independent of the package manager, but lots of its subdirectories are: mail, spool, log, tmp... Then we have /home, /usr/local and /opt. (I'm not even mentioning directories that typically host other filesystems). Any more?

My objective was to have a filesystem that I could wipe and re-install (even another distro if needed), or simply re-use from another boot (I understand the problem of shared libraries for some executables, but those are not central).
What would you say? It would likely take a lot of symlinks if I wanted to cover the maximum number of possibilities as possible.

eschwartz · 2018-08-21 22:39:28

Well, pacman.conf supports relocating this via the "DBPath" option. My point is that you shouldn't automatically assume it is safe to recreate /var -- many things should work, some might not, and you need to make sure you've accounted for everything that stores files there.

Gede · 2018-10-04 21:45:11

Finally I managed to find the time and solved this problem. Thank you for your help.
I copied the root subvolume and merged the /var data into it, mounted it during boot as the new root and managed to update Arch Linux.

Arch Linux

#1 2018-08-19 19:31:59

[solved] Rebuilding the pacman database

#2 2018-08-19 21:24:09

Re: [solved] Rebuilding the pacman database

#3 2018-08-19 21:56:15

Re: [solved] Rebuilding the pacman database

#4 2018-08-19 22:08:57

Re: [solved] Rebuilding the pacman database

#5 2018-08-21 22:35:55

Re: [solved] Rebuilding the pacman database

#6 2018-08-21 22:39:28

Re: [solved] Rebuilding the pacman database

#7 2018-10-04 21:45:11

Re: [solved] Rebuilding the pacman database

Board footer