Hoping someone can help me understand this pacman db.lck issue

General system Pacman
1

Hello everyone!

This is my first post here, hoping I can get someone to help me understand if this is by design or if there might be configuration issue on my end. For background context, I have been a Windows sys admin for 15 years, have dabbled in various Linux distros over the years but always came back to Windows because it’s what I know. But for various reasons, I’m ready to dedicate myself to Linux, choosing Arch/endeavourOS as my OS.

Before expanding on my issue, here is some information about my system: I have installed eOS Mercury, the new ISO, onto my laptop. I went with btrfs for my ssd, it is encrypted with luks. i use grub as my bootloader so i can take advantage of restoring snapshots from bootloader menu. This concept will help me stay with Linux, so I’m very interested in this. After the install, I installed snapper-support, which contains snapper, pac-scap, and grub-btrfs. I have also installed btrfs assistant as a GUI, just in case.

What Works: I have it all configured, I can see the snapshots in GRUB when I boot. I can successfully restore to said snapshots, and I can confirm that the system is working by testing the removal/installation of neofetch via pacman. Once I confirm that the snapshot rollback worked, I use btrfs to Restore to that snapshot, reboot, choose the usual kernel (LTS), and login. Testing again, confirm that it is working as intended.

The issue: When I run sudo pacman -Syyu, or really any pacman command, I get this response from the terminal:

error: failed to synchronize all databases (unable to lock database)

I have done some research, and it seems like I have to use this command to unlock the db:

sudo rm /var/lib/pacman/db.lck

My research also indicates that I must first check to make sure no other package manager processes are running at the time, to prevent data corruption or other issues.

I am able to verify that no other services which would be problematic are running. I then run the above rm command to get rid of the issue. I then run sudo pacman -Syyu and it updates fine. I don’t see any “issue” afterward per se, but I feel like this is not correct. I can’t seem to find any verifiable information about this either through the Arch documentation, various google research, or elsewhere.

Would someone be able to shine some light on this issue, why it is happening, if it is preventable, or if there might be a better way to accomplish the end goal? My guess is that I can create a subvolume for /var/lib/pacman/ and exclude it from snapshots, but I am very unsure. Any information is super appreciated! :slight_smile:

2

It’s usually cause by something interfering with the package check or update. It has only happen to me 2 or 3 times in the last 15+ years.

sudo rm /var/lib/pacman/db.lck

Is the correct way to get out of the that situation.

Usually I use yay or if you use pacman use sudo pacman -Syu

pacman will not update aur packages.

4 Likes
3

Thanks for the response! I am thinking that there may be something else going on, because this is happening to me every time I restore from a snapshot. I’ve tested it on this laptop 4 times, and my desktop yesterday as well. Each time I choose a snapshot from GRUB to boot into, or when I use btrfs assistant to Restore to a prior snapshot, this pacman db.lck issue occurs. I can’t see anything technically problematic, but I don’t see anyone else having the same issue. Because it is happening across devices, and I am configuring them the same, makes me think it is something wrong with how I have it configured, or how the method I am using might not perform as expected on this new Mercury ISO release. This is what leads me to believe it might be worth trying to create /var/lib/pacman as its own subvolume, so that snapper doesn’t rollback that directory. But maybe my theories are very wrong. Do you use btrfs/grub/snapper to rollback changes in case of system failure?

4

I do and don’t have any issues.

Edit: Maybe you are not doing it correctly?

Edit: When you boot there are snapshots in the grub menu that you can select to boot from. Then when you have a successful boot you can go into btrfs-assistant and restore a particular snapshot and then reboot into it. It also automatically makes a backup when you do this. I usually don’t keep these. I also go in and delete all the snapshot after the one i decide to restore. Maybe that’s a bad thing or unnecessary but that’s just what i do right or wrong.

1 Like
5

Doesn’t it do that because of the booting into the snapshot which was taken because an update was running (thus locked db)?
It’s easy enough to just remove the lock file and not worry about it.

6

Maybe. I don’t see any issue with removing the db lock.

Edit: I don’t think I’ve come across this happening on my own system that i can remember but it’s possible i just don’t recall. :man_shrugging:

7

Thanks for the response!

I am essentially following this person’s blog to get it done. He also mentions the process you are talking about, which I am following. It does create the snapshots, I am able to boot into the snapshot from GRUB, once I am logged in I check/confirm that the snapshot did load successfully and verify changes in files, then I use btrfs assistant to Restore to that same checkpoint, reboot, let GRUB boot as normal, and that’s where the pacman/db.lck issue occurs, everytime. If I am missing something, please let me know! :slight_smile:

8

I am not sure if this is normal, as I don’t seem to find anyone else mentioning that this issue happens each time. While the solution is simple, I just want to make sure my understanding is 100% about the process, and why this is happening to me each time during the process.

9

It makes sense, but I have never been into snapshots, so I do not know definitively.

1 Like
10

I don’t normally restore to the same snapshot i boot into. So not sure if that’s the issue? I’m not an expert on this, i just use it myself.

11

You could use eos-update for updating your system because

  • it deletes the lock file with rm -f when it detects lock is not in use
  • if it notices lock is in use, it uses rm -i instead

See eos-update -h for more details.

2 Likes
12

Thanks @manuel , I learned something new today.
:+1:

1 Like
13

Wow, thanks for this!

Just as another example, I just tried to install hyprland by following the wikis, things did inevitably go wrong, so I had to boot from a snapshot that was taken before I ran the sudo pacman -S hyprland command. This allowed me to get right back into KDE Plasma with no issue, ran terminal to check if the packages I had downloaded before existed; they do not. In short, it works as expected. However, when trying to run sudo pacman -Syu, I got the same error I originally posted about. However, I ran your suggested eos-update and what do you know, it worked without me having to remember the directory for the remove command for the db.lck file.

So thanks alot for this shortcut! I am still just curious why this happens to me every time, if it’s by design or not, and why it seems my experience is different than other people who’ve responded on this post. Either way, it works, so it’s just nitpicking at this point, and curiousity :stuck_out_tongue:

14

A dangling lock file typically comes from an interrupted update or install.
And maybe those snapshots have remembered them, though not sure if that’s possible.

15

If things inevitably go wrong, it would be better to do your testing in a virtual machine, make sure everything works, and then think about doing it on hardware. Just a thought. :wink:

1 Like
16

What exactly did go wrong? Why couldn’t you just uninstall hyprland if that is causing issues? Which wiki did you follow?

17

For sure! But hyprland mentions that VMs aren’t fully supported yet and YMMV, so I didn’t want to go that route. I could always try, but I don’t mind using an SSD for it, I have plenty!

18

Once hyprland was installed, it was great. It worked just fine in the beginning, but I think something related to KDG portals messed up, and instead of going down that rabbit hole, I just said “nah” and reverted back to full on KDE plasma, I’ll start testing Hyprland in a separate SSD so I don’t have any conflicting issues!