Pacman is failing at start sometimes?

This is sorta more of a feedback than an actual issue, because I've seen someone else complaining about it already but I can't remember where.
Sometimes, when I'm starting the system, I get a message at plymouth that says something about pacman files couldn't be loaded or something alike (i don't really remember the words and they go so fast at plymouth). It happened like 3 times, only since last week or so.

Generally, when it happens, I can't get past my login screen and have to reboot, but seems today, the 3rd time I noticed it, I could get to login and use the system and even do an update? I only noticed it when I rebooted the system and saw the message there, so...

I have absolutely no idea what's happening here, all I know is, it happens rarely and a reboot takes care of it, which is weird, and which is why I'm making this messy post. Thanks for reading.

LXQt or Cinnamon?

Why do you not post your inxi -Faz?

1 Like

Lxqt and because I thought it wouldn't be of any help?
Anyway, if its needed:

inxi -Faz
System:    Kernel: 5.14.6-zen1-1-zen x86_64 bits: 64 compiler: gcc v: 11.1.0 
           parameters: BOOT_IMAGE=/@/boot/vmlinuz-linux-zen root=UUID=1409d596-84e3-4768-b0e5-996dc20bb2a5 rw 
           [email protected] quiet splash rd.udev.log_priority=3 vt.global_cursor_default=0 
           systemd.unified_cgroup_hierarchy=1 loglevel=3 
           Desktop: LXQt 0.17.1 tk: Qt 5.15.2 info: cairo-dock, lxqt-panel wm: kwin_x11 vt: 1 dm: SDDM Distro: Garuda Linux 
           base: Arch Linux 
Machine:   Type: Desktop Mobo: INTEL model: HM65DESK serial: <filter> UEFI: American Megatrends v: 4.6.5 date: 02/23/2019 
CPU:       Info: Dual Core model: Intel Core i7-2620M bits: 64 type: MT MCP arch: Sandy Bridge family: 6 model-id: 2A (42) 
           stepping: 7 microcode: 2F cache: L2: 4 MiB 
           flags: avx lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 bogomips: 21551 
           Speed: 1005 MHz min/max: 800/3400 MHz Core speeds (MHz): 1: 1005 2: 3192 3: 1679 4: 1282 
           Vulnerabilities: Type: itlb_multihit status: KVM: VMX unsupported 
           Type: l1tf mitigation: PTE Inversion 
           Type: mds mitigation: Clear CPU buffers; SMT vulnerable 
           Type: meltdown mitigation: PTI 
           Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via prctl and seccomp 
           Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization 
           Type: spectre_v2 mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling 
           Type: srbds status: Not affected 
           Type: tsx_async_abort status: Not affected 
Graphics:  Device-1: NVIDIA GM107 [GeForce GTX 750] driver: nvidia v: 470.63.01 alternate: nouveau,nvidia_drm bus-ID: 01:00.0 
           chip-ID: 10de:1381 class-ID: 0300 
           Display: x11 server: X.Org 1.20.13 compositor: kwin_x11 driver: loaded: nvidia display-ID: :0 screens: 1 
           Screen-1: 0 s-res: 1360x768 s-dpi: 90 s-size: 384x300mm (15.1x11.8") s-diag: 487mm (19.2") 
           Monitor-1: HDMI-0 res: 1360x768 hz: 60 dpi: 49 size: 708x398mm (27.9x15.7") diag: 812mm (32") 
           OpenGL: renderer: NVIDIA GeForce GTX 750/PCIe/SSE2 v: 4.6.0 NVIDIA 470.63.01 direct render: Yes 
Audio:     Device-1: Intel 6 Series/C200 Series Family High Definition Audio driver: snd_hda_intel v: kernel bus-ID: 00:1b.0 
           chip-ID: 8086:1c20 class-ID: 0403 
           Device-2: NVIDIA GM107 High Definition Audio [GeForce 940MX] driver: snd_hda_intel v: kernel bus-ID: 01:00.1 
           chip-ID: 10de:0fbc class-ID: 0403 
           Sound Server-1: ALSA v: k5.14.6-zen1-1-zen running: yes 
           Sound Server-2: JACK v: 1.9.19 running: no 
           Sound Server-3: PulseAudio v: 15.0 running: yes 
           Sound Server-4: PipeWire v: 0.3.35 running: yes 
Network:   Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169 v: kernel port: d000 bus-ID: 03:00.0 
           chip-ID: 10ec:8168 class-ID: 0200 
           IF: enp3s0 state: up speed: 1000 Mbps duplex: full mac: <filter> 
Drives:    Local Storage: total: 2.78 TiB used: 681.4 GiB (23.9%) 
           SMART Message: Required tool smartctl not installed. Check --recommends 
           ID-1: /dev/sda maj-min: 8:0 model: SATA SSD size: 55.9 GiB block-size: physical: 512 B logical: 512 B 
           speed: 3.0 Gb/s type: SSD serial: <filter> rev: Sb10 scheme: GPT 
           ID-2: /dev/sdb maj-min: 8:16 vendor: Seagate model: ST3000NM0053 size: 2.73 TiB block-size: physical: 512 B 
           logical: 512 B speed: 3.0 Gb/s type: HDD rpm: 7200 serial: <filter> rev: G00A scheme: GPT 
Partition: ID-1: / raw-size: 389.6 GiB size: 389.6 GiB (100.00%) used: 287.73 GiB (73.9%) fs: btrfs dev: /dev/sdb4 
           maj-min: 8:20 
           ID-2: /boot/efi raw-size: 5.59 GiB size: 5.58 GiB (99.80%) used: 235.9 MiB (4.1%) fs: vfat dev: /dev/sda2 
           maj-min: 8:2 
           ID-3: /home raw-size: 389.6 GiB size: 389.6 GiB (100.00%) used: 287.73 GiB (73.9%) fs: btrfs dev: /dev/sdb4 
           maj-min: 8:20 
           ID-4: /var/log raw-size: 389.6 GiB size: 389.6 GiB (100.00%) used: 287.73 GiB (73.9%) fs: btrfs dev: /dev/sdb4 
           maj-min: 8:20 
           ID-5: /var/tmp raw-size: 389.6 GiB size: 389.6 GiB (100.00%) used: 287.73 GiB (73.9%) fs: btrfs dev: /dev/sdb4 
           maj-min: 8:20 
Swap:      Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default) 
           ID-1: swap-1 type: zram size: 3.79 GiB used: 19.2 MiB (0.5%) priority: 100 dev: /dev/zram0 
Sensors:   System Temperatures: cpu: 29.8 C mobo: 27.8 C gpu: nvidia temp: 28 C 
           Fan Speeds (RPM): N/A gpu: nvidia fan: 33% 
Info:      Processes: 255 Uptime: 5m wakeups: 0 Memory: 3.79 GiB used: 2.39 GiB (63.1%) Init: systemd v: 249 tool: systemctl 
           Compilers: gcc: 11.1.0 clang: 12.0.1 Packages: pacman: 1886 lib: 527 flatpak: 0 Shell: fish v: 3.3.1 
           running-in: qterminal inxi: 3.3.06

Without this information it's going to be impossible to know what the problem is.

Look in your journal for the affected boot. For example, if it's the previous boot then look in

journalctl -b-1

This will display the journal for the "-1"st boot (i.e. the previous one).


Got it, so this

Got me to retrieve the error, which is:

systemd[1]: Failed to start pacman files database update.


What's in the journal for pkgfile-update.service?

journalctl -eu pkgfile-update.service

Also, not really sure that pkgfile is necessary given pacman will do file search in the same way...


It simply says "no entries" o.o
Guess it really is not being used

systemctl status pkgfile-update.service
systemctl status pkgfile-update.timer


systemctl status pkgfile-update.service
○ pkgfile-update.service - pkgfile database update
     Loaded: loaded (/usr/lib/systemd/system/pkgfile-update.service; static)
     Active: inactive (dead)
systemctl status pkgfile-update.timer
○ pkgfile-update.timer - pkgfile database update timer
     Loaded: loaded (/usr/lib/systemd/system/pkgfile-update.timer; disabled; vendor preset: disabled)
     Active: inactive (dead)
    Trigger: n/a
   Triggers: ● pkgfile-update.service

I do also see this error occurring randomly in my system.
Checking in the journal, I see it happens when unit=pacman-files fails.
This is the Unit/Service

File: /usr/lib/systemd/system/pacman-files.service
Description=pacman files database update

ExecStart=/usr/bin/pacman -Fy

I guess this might be due to the service trying to start when is not really finished (network is not online). In-fact, when it fails there are many error: failed retrieving file in the journal due to this pacman -Fy (synchronizing databases?).
I don't think this is anything really important, and, at least in my case, it is not so frequent and I have no login problem whatsoever when it occurs.
In my opinion, if you follow the good practice to always update the system before installing new packages, this is no problem at all.


Where is this service from?

pacman -Qo /usr/lib/systemd/system/pacman-files.service

(I can't find it in the Arch repos...)

1 Like

Sorry, I had to leave for now, I'll check later.
What I remember is that pacman-files.service is triggered daily by pacman-files.timer.
I also searched in the arch and aur but with no luck.
This evening I'll check with pacman -Qo.


it comes from find the command package
pacman files are needed for that to work


So the next question is whether this affects the boot process, or is it just an adjacent issue? :thinking:

@AoriOjin If you disable the service and monitor the boot process for a while (e.g. a couple of days) it might narrow down whether this has any effect.

1 Like

it only errors that service failed but does not in any way hinder boot process


OK, so it's a "red herring".

@AoriOjin did the journal have any other information in it?


Alright so what I could grasp: it's an issue regarding just the iniciation because of network signal and besides that, it should have no effects on boot or usability whatsoever.
So the solution is just to ignore it and let the devs think about what they will or won't do about it?

Also, @jonathon I could disable the stuff and monitor the boot, but that would be more work for you people because Idk that much about how to disable anything. And as I have no idea about what 99% of the logs means, I'm sorry to say that's the only message I saw as an error there, specifically because I was looking for it :V

I'll disable it this evening, just to see if everything will be fine, especially tomorrow (I seem to recall that pacman-files.service is triggered by pacman-files.timer (I'll recheck that as well), which runs daily, and this would explain why the error seemed random to me).
Anyway, as I see it only runs pacman -Fy to synchronize the database, I really think there will be no problems at all disabling it.

1 Like

If it's only ever triggered by the timer, disable the timer.

1 Like

Here we go, from the upstream url in the AUR package, how it works and why there's that timer.

1 Like