Things to Do After Installing EndeavourOS: 10 Tested Steps

A fresh EndeavourOS install gets you closer to a finished desktop than plain Arch does, but it isn’t done yet. The things to do after installing EndeavourOS are mostly gaps the installer leaves on purpose. There’s no snapshot tool on Btrfs, no Flatpak and no mirror timer, and one missing GStreamer package stops some apps from opening an ordinary MP4 file. You can close all of them in about an hour and end up with a system you can roll back when an update goes wrong.

Original content from computingforgeeks.com - post 180175

This EndeavourOS post-install guide runs through ten steps in a sensible order, from eos-update and mirror ranking to Timeshift snapshots, codecs, Flathub, NVIDIA drivers and Steam. I went through every step in October 2026 on an EndeavourOS KDE Plasma install (Linux 7.2 kernel, Plasma 6.8) in a Proxmox VM, and every output below comes from that machine.

Check what EndeavourOS already installed

A note on the lab before you trust its output. The VM boots with GRUB on BIOS firmware. It was built from the EndeavourOS repositories with the same KDE package lists the Calamares installer pulls (eos-packagelist), on Btrfs with the installer’s four subvolumes for root, home, cache and logs. Where that build could differ from a stock ISO install, the section says so.

Start by finding out what’s already there, because half the usual Arch post-install list is done for you on EndeavourOS and doing it twice only causes conflicts. The quickest check is one pacman -Q line with every package this guide touches:

pacman -Q yay firewalld reflector reflector-simple eos-rankmirrors eos-update welcome gst-libav gst-plugins-ugly libdvdcss ffmpeg flatpak timeshift snapper steam

Anything not installed comes back as an error at the top, so the four missing packages are easy to spot:

error: package 'flatpak' was not found
error: package 'timeshift' was not found
error: package 'snapper' was not found
error: package 'steam' was not found
yay 13.1.0-1
firewalld 2.5.2-1
reflector 2023-5
reflector-simple 2026.8-2
eos-rankmirrors 26.8-1
eos-update 26.9.2-1
welcome 26.10.2-1
gst-libav 1.28.8-1
gst-plugins-ugly 1.28.8-1
libdvdcss 1.6.0-1
ffmpeg 2:9.0.2-2

The table splits that up, with the default state of each service as systemctl is-enabled reported it.

Item	State after install	What you do
yay (AUR helper)	Installed	Use it, nothing to set up
firewalld	Installed and enabled, public zone	Open services only when an app needs them
reflector	Installed, reflector.timer disabled	Configure it and turn the timer on
eos-rankmirrors	Installed	Run it once on first boot
Codecs (gst-libav, ugly, bad, ffmpeg, libdvdcss)	Installed	Add gst-plugins-good
Snapshot tool	None	Install Timeshift and grub-btrfs
Flatpak	Not installed	Install it and add Flathub
Steam and gaming tools	Not installed	Install from multilib

If you came from Manjaro, the comparison in Manjaro vs EndeavourOS explains why so little is preconfigured: EndeavourOS ships Arch packages straight from the Arch repos and adds a small repo of its own tools on top. That’s also why most of the Arch Linux post-install steps apply here, minus the parts EndeavourOS already did.

Update the system with eos-update

The first update is the one that most often goes wrong on any Arch-based system, usually because a keyring is out of date or a stale lock file is lying around. EndeavourOS ships eos-update for exactly that: it’s a wrapper that runs pacman -Syu, updates the keyrings first, clears a dangling db.lck, checks free disk space and then, with --aur, runs yay for your AUR packages too. Open Konsole and run it as your normal user:

eos-update --aur

It prints each command before it runs it, so you can see exactly what it did. The block below is from the lab VM over SSH, where the run needed --no-keep-system-running (explained in the errors section at the end), with the banner lines trimmed. Nothing was pending yet:

==> sudo pacman -Sy
:: Synchronizing package databases...
 endeavouros downloading...
 core downloading...
 extra downloading...
 multilib downloading...
==> sudo pacman -Su
:: Starting full system upgrade...
 there is nothing to do
==> yay -Sua
:: Searching AUR for updates...
 there is nothing to do
==> All done!

Do not run it with sudo in front. It calls sudo itself for the pacman steps, as the ==> sudo pacman lines show, and a test run of sudo eos-update --aur made yay warn Avoid running yay as root/sudo, because building AUR packages as root is something makepkg is designed to refuse. If you update over SSH rather than from the desktop, you’ll probably hit the inhibit error covered at the end of this guide; --no-keep-system-running gets you past it.

Rank the EndeavourOS and Arch mirrors

EndeavourOS pulls packages from two mirror lists, and each one has its own tool. That’s the part that trips people up, because running only one of them leaves half your downloads on whatever mirror happened to be first:

• You rank /etc/pacman.d/endeavouros-mirrorlist (the small EndeavourOS repo) with eos-rankmirrors.
• You rank /etc/pacman.d/mirrorlist (core, extra and multilib, which is almost everything) with reflector.
• You can do the Arch side from the Welcome app’s “Update Mirrors (Arch, reflector-simple)” button if you prefer a GUI.

The lab showed why this matters before the VM even booted. The stock EndeavourOS list starts with an Australian mirror, and while the KDE packages were installing from Europe it stalled mid-download with Operation too slow. Less than 1 bytes/sec transferred the last 10 seconds until pacman gave up on the whole transaction. Ranking takes less than two minutes, so do it now:

eos-rankmirrors

It tests every mirror in the package’s list, warns about the ones that fail, and writes the fastest first. The run took 36 seconds here and flagged two dead mirrors:

The Australian mirror that stalled the install dropped to 13th place. If a mirror keeps failing for you, eos-rankmirrors --ignore=del2.albony leaves it out of that run (the word only has to match a unique part of the address). To keep it out every time, including the automatic reranks, add the same word to the EOS_IGNORED_MIRRORS=() array in /etc/eos-rankmirrors.conf. Next, rank the Arch mirrors. Swap the countries for the ones closest to you; reflector --list-countries prints the names it accepts:

sudo reflector --country Germany,Netherlands,France --protocol https --age 12 --latest 20 --sort rate --number 10 --save /etc/pacman.d/mirrorlist

This one took 65 seconds because reflector downloads a test file from each of the 20 newest mirrors and times out slow ones after five seconds. A few warnings like these are normal, and the mirrors behind them simply don’t make the list. The output below keeps two of the four warnings and the first three of the ten servers:

[2026-10-30 02:55:22] WARNING: failed to rate http(s) download (https://ftp.halifax.rwth-aachen.de/archlinux/extra/os/x86_64/extra.db): Download timed out after 5 second(s).
[2026-10-30 02:56:03] WARNING: failed to rate http(s) download (https://de-nue.soulharsh007.dev/archlinux/extra/os/x86_64/extra.db): HTTP Error 403: Forbidden
Server = https://frankfurt.mirror.pkgbuild.com/$repo/os/$arch
Server = https://berlin.mirror.pkgbuild.com/$repo/os/$arch
Server = https://arch.alhp.dev/$repo/os/$arch

Mirrors go stale over months, so you’ll want reflector to redo this weekly. The timer reads its flags from a config file, and the default one only keeps the five most recently synced mirrors sorted by age, which says nothing about speed. Open it:

sudo vim /etc/xdg/reflector/reflector.conf

Replace the contents with the same flags you just ran by hand, one per line:

--save /etc/pacman.d/mirrorlist
--protocol https
--country Germany,Netherlands,France
--age 12
--latest 20
--sort rate
--number 10

Then enable the timer and confirm when it’ll fire next:

sudo systemctl enable --now reflector.timer
systemctl list-timers reflector.timer --no-pager

It’s a weekly timer, so the first run lands a few days out:

NEXT                          LEFT LAST PASSED UNIT            ACTIVATES
Mon 2026-11-02 07:05:40 UTC 3 days -         - reflector.timer reflector.service

The EndeavourOS list does not need a timer of its own: eos-rankmirrors ships a pacman hook that reranks it whenever the endeavouros-mirrorlist package updates. More country and filter examples are in our guide to generating a pacman mirrorlist by country.

Use yay for AUR packages and keep the cache small

You don’t need to install yay on EndeavourOS, since it’s part of the base package group, so skip the build-from-git steps you’ll find in Arch guides. It takes the same flags as pacman, searches the AUR and the official repos together, and builds AUR packages as your user. Check what you’ve got:

yay -Ps

The stats page is a handy health check. Note the pacman cache line, which had already grown to 2.3 GiB on this VM after the first round of installs:

==> Yay version v13.1.0
===========================================
==> Total installed packages: 1213
==> Foreign installed packages: 1
==> Explicitly installed packages: 205
==> Total Size occupied by packages: 7.1 GiB
==> Size of pacman cache /var/cache/pacman/pkg/: 2.3 GiB
==> Size of yay cache /home/lorna/.cache/yay: 2.6 MiB

Pacman keeps every version of every package it downloads, which is useful for a downgrade and wasteful forever after. EndeavourOS installs pacman-contrib, and its paccache timer trims the cache to the last three versions of each package every week. The timer is off by default, so turn it on.

sudo systemctl enable --now paccache.timer

You’ll use yay for real in the snapshot section, where the one AUR package this guide needs gets built. If you want the full yay workflow (reviewing PKGBUILDs, cleaning orphans, pinning), our yay guide for Arch, Manjaro and EndeavourOS covers it, and yay vs pacman vs paru helps if you’re wondering whether to switch to paru.

Check the firewall before you open ports

EndeavourOS turns on firewalld during install, so you’re already behind a firewall and shouldn’t add ufw on top of it. Two firewalls managing the same nftables rules end up overwriting each other, and you’re left guessing which one blocked a connection. Confirm what’s running and what’s allowed in:

sudo firewall-cmd --state
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --list-services

The default public zone lets in only SSH and DHCPv6 replies:

running
public (default)
  interfaces: ens18
dhcpv6-client ssh

SSH being allowed does not mean an SSH server is listening; that only happens if you enable sshd, which our SSH server guide for EndeavourOS walks through. The first time you’ll actually need to change the firewall is usually KDE Connect or Steam, and firewalld already has named services for both, so you don’t have to look up port numbers:

sudo firewall-cmd --get-services | tr " " "\n" | grep -E "kdeconnect|steam"

Three matches came back, one for KDE Connect and two for Steam:

kdeconnect
steam-lan-transfer
steam-streaming

Add the one you need permanently, reload, and check it stuck. KDE Connect is the example here, because the phone pairing silently fails without it:

sudo firewall-cmd --permanent --add-service=kdeconnect
sudo firewall-cmd --reload
sudo firewall-cmd --list-services

The new service shows up alongside the two defaults:

dhcpv6-client kdeconnect ssh

If you’d rather click than type, the firewall-applet tray icon that EndeavourOS installs opens the same settings in a window. Without --permanent a rule lasts only until the next reload or reboot, which is handy for testing and confusing when you forget you did it.

Set up Btrfs snapshots with Timeshift and grub-btrfs

If you picked Btrfs in the installer, this is the step that pays for itself the first time a rolling update breaks your desktop. EndeavourOS creates the subvolume layout Timeshift expects (@ for root and @home for home) but installs no snapshot tool, so on day one you have the filesystem feature and nothing using it. The setup below follows the EndeavourOS wiki’s Timeshift and grub-btrfs approach, and it gives you three things:

1. You can take a snapshot of the root subvolume in under a second.
2. You get an automatic snapshot before every package upgrade.
3. You can boot any snapshot straight from the GRUB menu when the system won’t start.

The GRUB part needs GRUB. On UEFI machines EndeavourOS defaults to systemd-boot, and grub-btrfs can’t add entries to it, so on systemd-boot you still get the snapshots but restore them from Timeshift (or from the live ISO if the desktop won’t load). Be careful there: with systemd-boot the kernels live on the EFI partition at /efi, outside the @ snapshot, so restoring a snapshot older than your last kernel update leaves the kernel and its modules out of step. If a restored system won’t boot, the usual repair is to chroot in from the live ISO and reinstall the kernels, which the EndeavourOS forum thread on systemd-boot restores walks through. That path wasn’t tested in this lab, which runs GRUB. Install the three packages from the official repos:

sudo pacman -S --needed timeshift grub-btrfs inotify-tools

Take the first snapshot now, while the system is clean. Timeshift picks Btrfs mode and the system disk by itself on this layout, so you don’t pass a device:

sudo timeshift --create --comments "clean install" --tags D

You’ll see it select BTRFS mode and finish almost instantly, because a Btrfs snapshot copies no data until files change. A first try with --snapshot-device /dev/sdb2 only got a warning that the option doesn’t apply in Btrfs mode, so leave that flag out. The Failed to show notification line at the end only appears when no desktop session is attached, like over SSH. Next, make grub-btrfs watch Timeshift’s snapshot folder instead of Snapper’s, which is its default. Create a drop-in for the service:

sudo mkdir -p /etc/systemd/system/grub-btrfsd.service.d
sudo vim /etc/systemd/system/grub-btrfsd.service.d/override.conf

Add these three lines. The empty ExecStart= clears the packaged command before the new one replaces it, which systemd requires for that key:

[Service]
ExecStart=
ExecStart=/usr/bin/grub-btrfsd --syslog --timeshift-auto

Reload systemd, start the watcher, and regenerate the GRUB config once so the snapshots submenu exists:

sudo systemctl daemon-reload
sudo systemctl enable --now grub-btrfsd
sudo grub-mkconfig -o /boot/grub/grub.cfg

Look for Found snapshot near the end of the GRUB output. From now on grub-btrfsd updates the menu by itself every time a snapshot appears or disappears. The last piece is the automatic snapshot before upgrades, which lives in the AUR, so this is where yay earns its place:

yay -S timeshift-autosnap

yay shows you the PKGBUILD diff and builds the package in your home folder. Before you rely on it, look at its config. It keeps only three automatic snapshots, and it refuses to take another one within 18 hours of the last, so a second update the same day isn’t covered. The first test on the lab VM produced no snapshot at all for that reason. Lower the gap to zero if you update often:

sudo sed -i "s/^minHoursBetweenSnapshots=18/minHoursBetweenSnapshots=0/" /etc/timeshift-autosnap.conf

The hook only fires on upgrades, not on fresh installs, so you can test it by reinstalling any small package:

sudo pacman -S nano

The snapshot happens in pacman’s pre-transaction hooks, before a single file changes, and the autosnap script leaves the GRUB update to grub-btrfsd so the two don’t race:

:: Running pre-transaction hooks...
(1/1) Creating Timeshift snapshot before upgrade...
Creating new backup...(BTRFS)
BTRFS Snapshot saved successfully (0s)
Tagged snapshot '2026-10-30_02-59-45': ondemand
------------------------------------------------------------------------------
==> grub-btrfsd service is running. Skipping GRUB update to prevent
==> race condition between timeshift-autosnap and grub-btrfsd service

Because new installs don’t trigger the hook, take a manual snapshot before anything big, like the gaming packages later in this guide. After doing that, sudo timeshift --list showed all three snapshots and GRUB picked up every one:

Timeshift snapshots only @ by default, so your home folder is not rolled back with the system. That’s usually what you want, since restoring root after a bad update shouldn’t throw away the documents you saved this morning. You can include @home in the Timeshift window’s Users tab if you’d rather have both. Snapper with snap-pac is the other common choice on Arch-based systems, and it’s what our CachyOS post-install guide uses with Limine; Timeshift wins here because the EndeavourOS wiki documents it and its restore window is easier for a first rollback.

Install the GStreamer plugins the codec set leaves out

Codecs are mostly handled on EndeavourOS, which is a nice change from distros that make you hunt for them. FFmpeg, libav, the bad and ugly GStreamer sets and libdvdcss are all there after install. That means mpv, Haruna and Firefox play H.264, H.265 and AAC right away. GStreamer apps are a different story. gst-plugins-good and gst-plugins-base were missing on the lab VM, and neither name appears in the installer’s KDE package lists or in the ISO’s own packages.x86_64. The good set holds the MP4 (QuickTime) demuxer. To test it, make a three-second H.264 and AAC file with ffmpeg:

ffmpeg -loglevel error -f lavfi -i testsrc=duration=3:size=1280x720:rate=30 -f lavfi -i sine=duration=3 -c:v libx264 -c:a aac -shortest ~/sample-h264.mp4

Then ask GStreamer to read it:

gst-discoverer-1.0 ~/sample-h264.mp4

Without the good plugins it can’t even open the container, and that same Missing plugins message is what GStreamer-based players and thumbnailers hit when an MP4 won’t open:

Analyzing file:///home/lorna/sample-h264.mp4
Done discovering file:///home/lorna/sample-h264.mp4
Missing plugins
 (gstreamer|1.0|gst-discoverer-1.0|Quicktime demuxer|decoder-video/quicktime, variant=(string)iso)

Install the two missing sets, 13.48 MiB in total:

sudo pacman -S --needed gst-plugins-base gst-plugins-good

Running the same check again, the file opens and both streams are recognised:

You don’t need anything else for everyday playback. Hardware video decoding is a separate question that depends on your GPU: Intel and AMD use VA-API through Mesa, and you can check what your card offers with vainfo from the libva-utils package. It was already on the lab VM as a dependency of the KDE set; if the command is missing on yours, install it with sudo pacman -S libva-utils.

Add Flatpak and Flathub

Flatpak isn’t installed on EndeavourOS, and you can live without it, since the AUR covers most apps. It’s still worth adding for proprietary apps that publish an official Flathub build and for anything you’d like sandboxed. Installing the package isn’t enough, though, because on Arch it comes with no remotes at all; flatpak remotes printed an empty line on the lab VM. Install it, then add Flathub:

sudo pacman -S flatpak
sudo flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
flatpak remotes

Flathub now shows as a system-wide remote:

flathub	system

Flatseal makes a good first app, because it’s the permissions editor you’ll want the moment a sandboxed app can’t see a folder:

sudo flatpak install -y flathub com.github.tchx84.Flatseal
flatpak list --app

Your first install also pulls the GNOME runtime and the Flatpak codecs extension, so it takes longer than the app’s size suggests. After that, apps sharing a runtime install quickly:

Flatseal	com.github.tchx84.Flatseal	2.4.1	stable	system

Log out and back in once so the Plasma menu picks up the Flatpak apps. Flatpaks update separately from pacman and the KDE package set doesn’t include Discover, so add flatpak update to your routine next to eos-update, or you’ll find month-old apps sitting next to a fully updated system.

Install NVIDIA drivers with nvidia-inst

If you have an NVIDIA card, EndeavourOS has its own helper for it, nvidia-inst, and it beats picking packages by hand, because the right package changed in December 2025. Arch replaced nvidia with nvidia-open and nvidia-dkms with nvidia-open-dkms, and the main driver no longer supports Pascal and older cards (the Arch news post has the details). Check what you already have first: the EndeavourOS ISO detects NVIDIA cards and can install nvidia-open during setup, so your driver may already be in place. The helper reads your GPU family and picks for you:

• On Turing (GTX 16xx, RTX 20xx) and newer, you get the open kernel modules, with the dkms variant by default.
• On older cards it falls back to nouveau; the EndeavourOS wiki points Maxwell and Pascal owners to nvidia-580xx-dkms from the AUR instead.
• With --32 you also get the 32-bit libraries Steam needs, which works only with multilib enabled.

The lab VM has no NVIDIA card, so the actual driver install wasn’t run there, and you should treat the rest of this section as notes rather than a tested walkthrough. What did run is the package install and its dry-run mode. It changes nothing, and it’s the right first step on real hardware too:

sudo pacman -S --needed nvidia-inst
nvidia-inst --test

Test mode lists the NVIDIA-related packages already installed (the quickest way to see whether the installer set up a driver for you), prints the inxi graphics report, and states what it would do. On the VM’s virtual display adapter the last lines were these, which is the expected result with no NVIDIA GPU present:

2026-10-30 03:19:09: Info: nvidia-inst version 26.1.1-1
2026-10-30 03:19:09: Info: Command line: nvidia-inst --test
2026-10-30 03:19:09: Warning: could not find Nvidia GPU.

On a machine where the test finds your card, its help text says that running nvidia-inst without --test performs the install, and --32 adds the Steam libraries. Laptops with Intel or AMD graphics plus NVIDIA also want --prime for render offload. Reboot afterwards, and run updates through eos-update --nvidia if you chose the non-dkms packages, since that option checks the driver against the kernel version before it upgrades. The EndeavourOS NVIDIA page lists which family needs which package.

Set up Steam, GameMode and MangoHud

On Arch, you need the 32-bit [multilib] repository for Steam, plus a 32-bit Vulkan driver that matches your GPU. Check multilib first, because nothing else in this section installs without it:

grep -A1 "^\[multilib\]" /etc/pacman.conf

Two uncommented lines mean it’s on, which is how EndeavourOS’s own pacman.conf ships:

[multilib]
Include = /etc/pacman.d/mirrorlist

If the lines start with #, remove the two # characters in /etc/pacman.conf and run sudo pacman -Sy. Next comes the Vulkan driver, which is the choice people get wrong most often. Pick the line for your GPU:

• If you have an AMD card, you need vulkan-radeon lib32-vulkan-radeon.
• If you have Intel graphics, you need vulkan-intel lib32-vulkan-intel.
• If you have NVIDIA, you already have nvidia-utils from the driver, and nvidia-inst --32 added lib32-nvidia-utils.

Take a manual snapshot before you start, since this is the biggest install in the guide (623 MiB here) and the autosnap hook doesn’t fire for new packages. Then install Steam with GameMode and MangoHud. The VM got the AMD drivers:

sudo timeshift --create --comments "before gaming setup" --tags D
sudo pacman -S --needed steam vulkan-radeon lib32-vulkan-radeon gamemode lib32-gamemode mangohud lib32-mangohud

GameMode runs as a user service that games ask for a performance boost. Switching the CPU governor goes through a polkit rule that lets members of the gamemode group do it without a password prompt, and the package doesn’t add you to it, so do that first and then log out and back in:

sudo usermod -aG gamemode $USER

After the new login, id -nG should list gamemode. Then enable the service and run its self-test:

systemctl --user enable --now gamemoded
gamemoded -t

On the VM every test passed except the CPU governor check, before and after joining the group:

:: Feature tests
::: Verifying CPU governor setting
::: Failed!
::: Verifying Scripts
::: Passed (no scripts configured to run)
::: Verifying GPU Optimisations
::: Passed (gpu optimisations not configured to run)
::: Verifying renice
::: Passed (no renice configured)
::: Verifying ioprio
::: Passed
: Tests Failed!

If you see that failure in a virtual machine, that’s normal. The VM exposes no /sys/devices/system/cpu/cpu0/cpufreq directory, so there’s no governor for GameMode to switch. On real hardware the governor check needs both a cpufreq driver and the group membership above; this lab couldn’t test that part. To confirm GameMode actually activates, start something through gamemoderun and ask the daemon:

gamemoderun sleep 1 & sleep 0.5; gamemoded -s; wait

You should see the daemon report gamemode is active while the command runs. In Steam, you use both tools the same way, through a game’s Properties, Launch Options field: gamemoderun mangohud %command% turns on GameMode and the MangoHud overlay for that game. For Windows games, open Steam’s Settings, Compatibility page and enable Steam Play for all titles so Proton handles them. If you also want Lutris or Heroic for non-Steam launchers, the EndeavourOS gaming notes are a good next read, and they use the same multilib setup you just checked.

Fix the errors you might hit along the way

These errors came up while building and testing the lab VM, with the fix that worked for each. None of them needs a reinstall, and you can fix each one in a minute or two.

Error: “Failed to inhibit: Access denied as the requested operation requires interactive authentication”

You’ll get this from eos-update in an SSH session. By default it blocks sleep and shutdown while it runs, and polkit only lets a local desktop session do that without a password prompt. Over SSH, either run it from the desktop or add --no-keep-system-running, which skips the inhibit and runs the same pacman -Syu and yay steps. Just don’t suspend the machine halfway through.

Error: “Operation too slow. Less than 1 bytes/sec transferred the last 10 seconds”

A mirror stalled. Pacman skips it after a few failures, but the transaction can still fail with failed to commit transaction (unexpected error). Run eos-rankmirrors and the reflector command from the mirrors section, then repeat the update. If the stalled mirror was in the EndeavourOS list and keeps coming back, add part of its hostname to the EOS_IGNORED_MIRRORS=() array in /etc/eos-rankmirrors.conf so every future ranking skips it.

Error: “signature from … is unknown trust”

Pacman doesn’t trust the key a package was signed with, and it offers to delete the downloaded file as corrupted. On the lab VM it hit grub-btrfs and inotify-tools, and the cause was a side effect of how the VM was built (pacstrap left the keyring unpopulated), so a normal Calamares install is less likely to see it. Repopulating both keyrings fixed it, after which the install went through:

sudo pacman-key --populate archlinux endeavouros

If it keeps coming back after that, eos-update --keyrings-reset rebuilds both keyrings from scratch. The pacman and yay cheat sheet has the other keyring and database commands worth knowing when an update misbehaves.