Why paru stopped working when using garuda-update?

Feedback
1

After last garuda-update and reboot, paru stopped working. I just want to know why garuda-update would break something that came with the system by default (if I’m not mistaken paru came installed with it).

Details and fix below

paru
paru: error while loading shared libraries: libalpm.so.15: cannot open shared object file: No such file or directory

Finally fixed it using:

cargo install --git https://github.com/Morganamilo/paru.git

Fix from: Paru error after garuda-update

System:
  Kernel: 6.17.9-zen1-1-zen arch: x86_64 bits: 64 compiler: gcc v: 15.2.1
    clocksource: hpet avail: acpi_pm
    parameters: BOOT_IMAGE=/@/boot/vmlinuz-linux-zen
    root=UUID=6108f4c4-717a-4d23-acde-0a4853062406 rw rootflags=subvol=@
    quiet loglevel=3 mem_sleep_default=s2idle
  Desktop: KDE Plasma v: 6.5.4 tk: Qt v: N/A info: frameworks v: 6.21.0
    wm: kwin_x11 vt: 2 dm: SDDM Distro: Garuda base: Arch Linux
Machine:
  Type: Desktop Mobo: Micro-Star model: MAG B550M BAZOOKA (MS-7C95) v: 2.0
    serial: <superuser required> uuid: <superuser required> Firmware: UEFI
    vendor: American Megatrends LLC. v: A.80 date: 12/23/2021
CPU:
  Info: model: AMD Ryzen 5 5600G with Radeon Graphics bits: 64 type: MT MCP
    arch: Zen 3 gen: 3 level: v3 note: check built: 2021-22
    process: TSMC n7 (7nm) family: 0x19 (25) model-id: 0x50 (80) stepping: 0
    microcode: 0xA500012
  Topology: cpus: 1x dies: 1 clusters: 1 cores: 6 threads: 12 tpc: 2
    smt: enabled cache: L1: 384 KiB desc: d-6x32 KiB; i-6x32 KiB L2: 3 MiB
    desc: 6x512 KiB L3: 16 MiB desc: 1x16 MiB
  Speed (MHz): avg: 2368 min/max: 404/4466 boost: enabled scaling:
    driver: amd-pstate-epp governor: powersave cores: 1: 2368 2: 2368 3: 2368
    4: 2368 5: 2368 6: 2368 7: 2368 8: 2368 9: 2368 10: 2368 11: 2368 12: 2368
    bogomips: 93423
  Flags-basic: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a
    ssse3 svm
  Vulnerabilities: <filter>
Graphics:
  Device-1: NVIDIA TU116 [GeForce GTX 1660 SUPER] vendor: Gigabyte
    driver: nvidia v: 580.105.08 alternate: nouveau,nvidia_drm
    non-free: 550-580.xx+ status: current (as of 2025-11; EOL~2026-12-xx)
    arch: Turing code: TUxxx process: TSMC 12nm FF built: 2018-2022 pcie:
    gen: 2 speed: 5 GT/s lanes: 16 link-max: gen: 3 speed: 8 GT/s ports:
    active: none off: DP-2 empty: DP-1,DP-3,HDMI-A-1 bus-ID: 10:00.0
    chip-ID: 10de:21c4 class-ID: 0300
  Device-2: Advanced Micro Devices [AMD/ATI] Cezanne [Radeon Vega Series /
    Radeon Mobile Series] driver: amdgpu v: kernel arch: GCN-5 code: Vega
    process: GF 14nm built: 2017-20 pcie: gen: 3 speed: 8 GT/s lanes: 16
    ports: active: none empty: DP-4,DP-5,HDMI-A-2 bus-ID: 30:00.0
    chip-ID: 1002:1638 class-ID: 0300 temp: 38.0 C
  Display: x11 server: X.Org v: 21.1.21 with: Xwayland v: 24.1.9
    compositor: kwin_x11 driver: X: loaded: modesetting,nvidia
    alternate: fbdev,nouveau,nv,vesa dri: radeonsi
    gpu: nv_platform,nvidia,nvidia-nvswitch display-ID: :0 screens: 1
  Screen-1: 0 s-res: 1920x1080 s-dpi: 92 s-size: 530x301mm (20.87x11.85")
    s-diag: 610mm (24")
  Monitor-1: DP-2 note: disabled model: LG (GoldStar) ULTRAGEAR
    serial: <filter> built: 2025 res: mode: 1920x1080 hz: 180 scale: 100% (1)
    dpi: 93 gamma: 1.2 size: 527x296mm (20.75x11.65") diag: 604mm (23.8")
    ratio: 16:9 modes: max: 1920x1080 min: 640x480
  API: EGL v: 1.5 hw: drv: nvidia drv: amd radeonsi platforms: device: 0
    drv: nvidia device: 1 drv: radeonsi device: 3 drv: swrast gbm:
    drv: kms_swrast surfaceless: drv: nvidia x11: drv: nvidia
    inactive: wayland,device-2
  API: OpenGL v: 4.6.0 compat-v: 4.5 vendor: nvidia mesa v: 580.105.08
    glx-v: 1.4 direct-render: yes renderer: NVIDIA GeForce GTX 1660
    SUPER/PCIe/SSE2 memory: 5.86 GiB
  API: Vulkan v: 1.4.335 layers: 17 device: 0 type: discrete-gpu name: NVIDIA
    GeForce GTX 1660 SUPER driver: nvidia v: 580.105.08 device-ID: 10de:21c4
    surfaces: N/A device: 1 type: integrated-gpu name: AMD Radeon Graphics
    (RADV RENOIR) driver: mesa radv v: 25.3.1-arch1.2 device-ID: 1002:1638
    surfaces: N/A device: 2 type: cpu name: llvmpipe (LLVM 21.1.6 256 bits)
    driver: mesa llvmpipe v: 25.3.1-arch1.2 (LLVM 21.1.6)
    device-ID: 10005:0000 surfaces: N/A
  Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo
    de: kscreen-console,kscreen-doctor gpu: corectrl, nvidia-settings,
    nvidia-smi wl: wayland-info x11: xdpyinfo, xprop, xrandr
Audio:
  Device-1: NVIDIA TU116 High Definition Audio vendor: Gigabyte
    driver: snd_hda_intel v: kernel pcie: gen: 3 speed: 8 GT/s lanes: 16
    bus-ID: 10:00.1 chip-ID: 10de:1aeb class-ID: 0403
  Device-2: Advanced Micro Devices [AMD/ATI] Renoir/Cezanne HDMI/DP Audio
    vendor: Micro-Star MSI driver: snd_hda_intel v: kernel pcie: gen: 3
    speed: 8 GT/s lanes: 16 bus-ID: 30:00.1 chip-ID: 1002:1637 class-ID: 0403
  Device-3: Advanced Micro Devices [AMD] Ryzen HD Audio
    vendor: Micro-Star MSI driver: snd_hda_intel v: kernel pcie: gen: 3
    speed: 8 GT/s lanes: 16 bus-ID: 30:00.6 chip-ID: 1022:15e3 class-ID: 0403
  API: ALSA v: k6.17.9-zen1-1-zen status: kernel-api with: aoss
    type: oss-emulator tools: alsactl,alsamixer,amixer
  Server-1: PipeWire v: 1.4.9 status: active with: 1: pipewire-pulse
    status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin
    4: pw-jack type: plugin tools: pactl,pw-cat,pw-cli,wpctl
Network:
  Device-1: Realtek RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet
    vendor: Micro-Star MSI driver: r8169 v: kernel pcie: gen: 1 speed: 2.5 GT/s
    lanes: 1 port: e000 bus-ID: 2a:00.0 chip-ID: 10ec:8168 class-ID: 0200
  IF: enp42s0 state: up speed: 1000 Mbps duplex: full mac: <filter>
  IF-ID-1: tailscale0 state: unknown speed: -1 duplex: full mac: N/A
  Info: services: NetworkManager,systemd-timesyncd
Drives:
  Local Storage: total: 476.94 GiB used: 106.04 GiB (22.2%)
  SMART Message: Unable to run smartctl. Root privileges required.
  ID-1: /dev/nvme0n1 maj-min: 259:0 model: ZADAK TWSG3 512GB
    size: 476.94 GiB block-size: physical: 512 B logical: 512 B speed: 31.6 Gb/s
    lanes: 4 tech: SSD serial: <filter> fw-rev: V1.6 temp: 47.9 C scheme: GPT
Partition:
  ID-1: / raw-size: 242.79 GiB size: 242.79 GiB (100.00%)
    used: 106 GiB (43.7%) fs: btrfs dev: /dev/nvme0n1p6 maj-min: 259:6
  ID-2: /boot/efi raw-size: 99 MiB size: 95 MiB (95.96%)
    used: 33.4 MiB (35.2%) fs: vfat dev: /dev/nvme0n1p2 maj-min: 259:2
  ID-3: /home raw-size: 242.79 GiB size: 242.79 GiB (100.00%)
    used: 106 GiB (43.7%) fs: btrfs dev: /dev/nvme0n1p6 maj-min: 259:6
  ID-4: /var/log raw-size: 242.79 GiB size: 242.79 GiB (100.00%)
    used: 106 GiB (43.7%) fs: btrfs dev: /dev/nvme0n1p6 maj-min: 259:6
  ID-5: /var/tmp raw-size: 242.79 GiB size: 242.79 GiB (100.00%)
    used: 106 GiB (43.7%) fs: btrfs dev: /dev/nvme0n1p6 maj-min: 259:6
Swap:
  Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default) zswap: no
  ID-1: swap-1 type: zram size: 15.01 GiB used: 0 KiB (0.0%) priority: 100
    comp: zstd avail: lzo-rle,lzo,lz4,lz4hc,deflate,842 dev: /dev/zram0
Sensors:
  System Temperatures: cpu: 47.4 C mobo: N/A
  Fan Speeds (rpm): N/A
  GPU: device: nvidia screen: :0.0 temp: 50 C fan: 0% device: amdgpu
    temp: 38.0 C
Info:
  Memory: total: 16 GiB note: est. available: 15.01 GiB used: 4.22 GiB (28.1%)
  Processes: 388 Power: uptime: 10m states: freeze,mem,disk suspend: s2idle
    avail: deep wakeups: 0 hibernate: platform avail: shutdown, reboot,
    suspend, test_resume image: 5.96 GiB services: org_kde_powerdevil,
    power-profiles-daemon, upowerd Init: systemd v: 258 default: graphical
    tool: systemctl
  Packages: 1905 pm: pacman pkgs: 1892 libs: 514 tools: octopi,paru
    pm: flatpak pkgs: 13 Compilers: clang: 21.1.6 gcc: 15.2.1 Shell: Bash
    v: 5.3.8 default: Zsh v: 5.9 running-in: konsole inxi: 3.3.40
Garuda (2.11.1-1):
  System install date:     2025-11-14
  Garuda release:          251103
  Last full system update: 2025-12-14 ↻
  Is partially upgraded:   No
  Relevant software:       snapper NetworkManager dracut nvidia-utils nvidia-open-dkms garuda-hardware-profile-nvidia garuda-hardware-profile-standard
  Windows dual boot:       Probably (Run as root to verify)
  Failed units:            
--- System Health Check Report ---
25/26 checks run in 0.90 seconds ⌛
Powered by garuda-health 🦅

--- INFO ---
 - A reboot is pending (update applied since last reboot)

✅ System health check passed. No issues found.
1 Like
Das libalpm.so.15 Problem
2

For your information, garuda-update break nothing.

Do you really believe that our small team is responsible for every library or program that is delivered on the ISO, and that Garuda has to fix these “bugs”?

4 Likes
3

Might want to search the forum and see how many times the devs have added a patch / fix to fix third party issues not break the system. Then you might want to search for that issue here and in your search engine of choice before blaming garuda-update thus the garuda devs. Now please have a wonderful rest of your week end.

1 Like
4

Problem is libalpm.
It is expected libalpm.so.15.0.0 but through the update we stay on libalpm.so.16.
I had also the problem and this time i used snapshot to have a functioning system again with regard to “garuda-update”
Pacseek or octopi is not running with libalpm.so.16.
The current pacman update break the system.
If downgrade pacman or wait. (my mind)

4 Likes
5

I can’t speak to Octopi but Bauh is running fine. The issue seems to have been fixed. It’s just some items might need to be rebuilt to work properly again.

2 Likes
6
5 Likes
7

Every year we have this problem..lol “the libalpm”. Last year it was on september (if I remember correctly)

4 Likes
8

Octopi is also not launching after updating. Restored with a manual snapshot I always keep around.

9

Of course, all apps with dependence for libalpm.so.15.
If, wait (prevent pacman from update in pacman.conf) or make the manual steps to solve this for pacseek, paru, oktopi or downgrade pacman.
It “must” be rebuild, but that takes time and that can’t fixed with a snap of the fingers.
Only example from 2024..lol

6 Likes
10

Just bookmarked your post and took advantage of the new reminder feature that bookmarking triggers to setup a reminder for Oct 1 2026.

1 Like
11

Sorry I didn’t mean to be rude. I’m new to arch linux.
Still then it wasn’t garuda-update that updated libpalm to libalpm.so.16 ?

12

No, an update of pacman upgraded libalpm (a library, which can be used by anyone for package management), so now all the packages using libalpm need an adjustment.
Between these, paru, which garuda-update uses to check which AUR packages need a rebuild (or actually to update AUR packages).
This was 100% trasparent to Garuda.

8 Likes
13

Maybe on these change events with this pkg, since for paru its already in the git there could be a garuda hotfix to switch over to git then back some time later after its fixed in “stable”.

14

It’s a widespread thing we don’t have any influence on. If you read the linked GitHub issue, it’s at 124 upvotes and an outrageous amount of people comment on it with no value whatsoever.

This is also not fixing it. It needs some Rust libs to be updated and the hacks suggested won’t be done.

6 Likes
15

gotcha for me I just had to rebuild paru I dont use the other apps so I cant say. but it all makes perfect sense. It would definitely be messy.

16

Arch and its derivitives use what’s called a rolling release model. The way rolling release works is- everything gets updated to the latest running version on your system, as frequently as you can get away with. There isn’t really such a thing as individual releases of the distro because everything included with it is always ‘rolling’ forward into the most recent version of every package you have, so there’s not really supposed to be anything that needs a major upgrade. This means you get much more recent feature additions compared to other distros that freeze package versions and test them, but it can also cause breakage on occasion. You have to upgrade the whole system at once whenever possible rather than partial upgrades because in an environment where every package is expecting the most recent version of whatever it depends on, it’s risky to hold package versions back. That can cause chain reactions of packages that depend on each other failing or behaving in unexpected ways.

On the flip side, developers cannot always communicate or mitigate breaking changes to other developers who are using their project as a dependency on time. They try to coordinate interlocked upgrades and usually it goes well, but sometimes something gets overlooked, or for some reason a package deliberately specifies a certain version of something it’s depending on as a safety measure for the sake of making sure things don’t break in the most catastrophic way if things go south. That latter case is what’s happened here. A dependency that several packages make use of upgraded by a version number, and those packages need to be tested against the dependency’s changes and rebuilt in a way that specifies that the new version of the dependency will work ok. The communication wasn’t perfect, but once the packages are checked and patched, garuda can trigger a package rebuild in the repositories and then garuda-update will pull down the updated versions and everything works again.

9 Likes
17

FWIW, this didn’t fix anything for me, and in fact didn’t complete because of libalpm issues:

What did get paru back to a working state while upstream releases an updated version that uses the latest libalpm library was finding the libalpm.so.15 file in a previous snapshot. I then copied just that one file to ~/.local/lib/ and then pre-pended the command-line with:
LD_PRELOAD=/home/[user]/.local/lib/libalpm.so.15 and then ran either paru or garuda-update

Adding the LD_PRELOAD to the cargo instgall command also didn’t fix the issue.

Until upstream releases an update, not sure what else can be done to continue being able to use garuda-update. If anyone else has any suggestions, I’m open to it!

Edit: There’s a PR with an updated PKGBUILD in the github repo. It hasn’t been merged yet, but if anyone is intrepid enough, you can compile a functioning, updated paru by cloning the AUR repo, then replacing the PKGBUILD with the contents from here:

1 Like
18

Never forget this option people, it’s Garuda’s preferred solution to this type of case. The latest and greatest can wait for you a few dozen hours.

3 Likes
Pacman breaks other dependencies when trying to update
19

garuda-heath --fix didnt fix. tried many stuff and reinstalling didnt fix it.

gemini bro told finally to delete paru and use Yay and to rebuild octopi. done and octopi working again.

also some Downloaduser=alpm couldnt recognise error happened with new pacman.conf update and merging pacnew. again bro gemini told to fix resolv.conf permission. everything is good so far.

1 Like
20

I’d scrutinize instructions from “Gemini Bro” just to be sure it won’t break things later on. Be careful with just making changes based on suggestions from an AI that is only passably versed in Arch, and nearly not at all with Garuda, specifically. Some changes it would recommend could have cascading effects down the line after you’ve forgotten you’ve made changes.

3 Likes