You want Arch’s packages and the AUR without building the install by hand, and the two names everyone throws at you are Manjaro and EndeavourOS. Both run pacman, both install through Calamares, and both lead with KDE Plasma. The Manjaro vs EndeavourOS choice really comes down to whose repositories you are trusting, and how far behind Arch you’re willing to let them drift.
I didn’t want to settle that from forum threads, so I installed both from their current ISOs on the same Proxmox host, on identical virtual hardware, and measured the parts you feel day to day: how far Manjaro’s stable branch trails Arch, how many AUR packages that gap breaks, the size of the first update, boot time, idle RAM and the smallest RAM each desktop survives on. It also covers the EndeavourOS vs Arch question, because the honest answer turns out to be a 60-package overlay. If you’re still deciding between Manjaro and a non-Arch distro, the Ubuntu vs Fedora vs Manjaro benchmarks ran the same scripts on those three.
Ran both side by side in October 2026 on EndeavourOS Titan Nova and Manjaro KDE 26.1, each fully updated before I measured anything.
1. Manjaro vs EndeavourOS at a glance
Every number below came from the two lab VMs or from repository data pulled the same morning. Boot times are medians of three cold boots.
| EndeavourOS | Manjaro KDE | |
|---|---|---|
| Release tested | Titan Nova (ISO of 15 Aug 2026) | 26.1.0 KDE (ISO of 12 Aug 2026) |
| Where packages come from | Arch’s core and extra, plus a 60-package EndeavourOS repo | Manjaro’s own repos, stable branch |
| Shared packages at a different version from Arch | None | 26.4%; the older ones trail by a median of 31.6 days |
| AUR packages with a dependency Arch meets but the repos don’t | 0 | 40 (35 of them plain version lag) |
| Kernel after the first update | 7.2.8 | 7.1.13 |
| First update after install | 451 packages, 1,608 MiB | 377 packages, 1,418 MiB |
| Desktop settled after power-on (median) | 28.1 s | 29.7 s |
| Idle RAM used | 1,141 MB | 1,154 MB |
| Smallest RAM that passed every attempt | 1536 MB (3 of 3; 1024 MB passed 1 of 3) | 1024 MB (3 of 3) |
| Filesystem and bootloader | ext4, systemd-boot | btrfs, GRUB |
| Snapshot before each update | No | Yes (Timeshift) |
| Firewall by default | firewalld, active | None installed |
| AUR helper by default | yay | Pamac (AUR browsing off) |
On boot time and idle memory there’s nothing in it. The gaps that matter are elsewhere: EndeavourOS is current the day Arch is, while a quarter of Manjaro stable trails by about a month and that lag currently trips up 40 AUR packages. Manjaro answers with a safety net (a snapshot before every update), and EndeavourOS answers with a firewall that is on from first boot. The one result I didn’t expect: Manjaro kept a working desktop in less RAM than EndeavourOS did.
2. How the two machines were set up
Both VMs got 2 vCPUs (host CPU type), 4 GB of RAM with ballooning pinned so it never shrinks, a 40 GB virtio-scsi disk, virtio networking and UEFI firmware without Secure Boot keys. I installed each one offline from its own ISO, accepted the installer’s defaults for disk layout, and ran a full update before any benchmark. The only things I changed afterwards were lab plumbing: autologin for the benchmark scripts, SSH (disabled by default on both), a sudoers drop-in and my key.
Offline was deliberate. The EndeavourOS installer asks up front whether you want an online install, where you pick any desktop and get current packages, or an offline one that copies the KDE Plasma system off the ISO:
Manjaro has no equivalent question because you pick the desktop when you choose which ISO to download. Installing both from their ISOs keeps the first-update comparison fair, since the images were built three days apart (Manjaro on 12 August, EndeavourOS on 15 August).
The defaults split early. Manjaro’s erase-disk option formats btrfs with @, @home, @cache and @log subvolumes, a 300 MiB EFI partition and GRUB. EndeavourOS picks systemd-boot (GRUB is one toggle away), formats ext4 and gives the EFI partition a full 2 GiB:
That filesystem choice matters later, because Manjaro’s snapshot-before-update setup is built around this btrfs layout (Timeshift in btrfs mode plus grub-btrfs). On EndeavourOS you’d pick btrfs from the same dropdown and add Snapper or Timeshift yourself. The installer’s own GRUB description points out it is the better choice if you want to boot btrfs snapshots.
3. Where the packages actually come from
This is the difference everything else hangs off. EndeavourOS points pacman at Arch’s own mirrors and adds one small repository of its own in front of them. Manjaro runs its own repositories and moves packages from Arch through unstable, then testing, then stable.
Counting installed packages per repo on the fresh EndeavourOS install (the pacman cheat sheet has the rest of these query flags):
for r in $(pacman-conf --repo-list); do printf '%s installed: ' $r; pacman -Sl $r | grep -c '\[installed'; doneOnly 23 of the installed packages come from the endeavouros repo. Everything else is a stock Arch build from core and extra:
endeavouros installed: 23
core installed: 219
extra installed: 848
multilib installed: 0The whole endeavouros repository held 60 packages when I pulled its database: the installer, the Welcome app, eos-hwtool, eos-update, mirror rankers, theme and settings packages, plus yay and paru. Only one of those 60 shares a name with an Arch package, and that is dracut. Because the EndeavourOS repo is listed first in pacman.conf, its build (112_eos-1) wins over Arch’s 111-1. That’s the entire EndeavourOS vs Arch gap at the package level.
Manjaro is a different animal. I compared the core and extra databases from an Arch mirror and a Manjaro mirror fetched in the same minute. On the stable branch, 4,012 (26.4%) of the 15,200 packages the two share are at a different version, and the ones that are older trail Arch by a median of 31.6 days. Another 641 packages exist only in Manjaro (its kernels, tools like mhwd and pacman-mirrors, branding).
| Branch | Packages shared with Arch | At a different version | Median lag of the older ones |
|---|---|---|---|
| Manjaro stable | 15,200 | 4,012 (26.4%) | 31.6 days |
| Manjaro testing | 15,208 | 3,627 (23.8%) | 25.5 days |
| Manjaro unstable | 15,271 | 389 (2.5%) | 1.9 days |
| EndeavourOS | Pulls core and extra from Arch mirrors | None (its dracut build is the one exception) | None |
The script that produced those numbers is short, and you can rerun it any day to see where the branches sit (it is the same one the Ubuntu, Fedora and Manjaro comparison used):
#!/usr/bin/env python3
# Compare package versions in Arch vs Manjaro stable/testing/unstable repo DBs fetched the same minute.
import tarfile, io, urllib.request, statistics, json, sys, datetime
ARCH = "https://geo.mirror.pkgbuild.com/{repo}/os/x86_64/{repo}.db"
MJ = "https://mirror.init7.net/manjaro/{branch}/{repo}/x86_64/{repo}.db"
def load(url):
data = urllib.request.urlopen(url, timeout=60).read()
out = {}
with tarfile.open(fileobj=io.BytesIO(data)) as t:
for m in t.getmembers():
if not m.name.endswith("/desc"): continue
f = t.extractfile(m).read().decode().split("\n\n")
d = {b.split("\n")[0].strip("%"): b.split("\n")[1:] for b in f if b.startswith("%")}
out[d["NAME"][0]] = (d["VERSION"][0], int(d["BUILDDATE"][0]))
return out
now = datetime.datetime.now(datetime.timezone.utc).isoformat(timespec="seconds")
arch = {}
for r in ("core", "extra"): arch.update(load(ARCH.format(repo=r)))
res = {"fetched_utc": now, "arch_pkgs": len(arch)}
for br in ("stable", "testing", "unstable"):
mj = {}
for r in ("core", "extra"): mj.update(load(MJ.format(branch=br, repo=r)))
common = [n for n in mj if n in arch]
diff = [n for n in common if mj[n][0] != arch[n][0]]
lag = [(arch[n][1] - mj[n][1]) / 86400 for n in diff if arch[n][1] > mj[n][1]]
res[br] = {"pkgs": len(mj), "common": len(common), "differ": len(diff),
"differ_pct": round(100 * len(diff) / len(common), 1),
"older_than_arch": len(lag),
"median_lag_days": round(statistics.median(lag), 1) if lag else 0,
"manjaro_only": len([n for n in mj if n not in arch]),
"sample": {n: [mj[n][0], arch[n][0]] for n in ("linux-firmware", "mesa", "firefox", "gnome-shell", "systemd", "pacman", "python", "gcc", "nvidia-utils") if n in mj and n in arch}}
print(json.dumps(res, indent=1))Stable moves in batches rather than continuously. The last full stable update before my test went out on 7 September, so by 3 October it had been 26 days. Not everything lags: on test day stable carried the same Firefox 157.0, pacman, Python and GCC builds as Arch. Kernels, Mesa, systemd, firmware and the NVIDIA driver were all a step behind. After both VMs had installed every update available to them, this is how far apart they sat:
| Package (after all updates) | EndeavourOS | Manjaro stable |
|---|---|---|
| Kernel | 7.2.8 (linux) | 7.1.13 (linux71) |
| systemd | 262 | 261.2 |
| Plasma | 6.7.5 | 6.7.4 |
| Mesa | 26.2.4 | 26.2.2 |
| linux-firmware | 20260916 | 20260810 |
NVIDIA driver in the repo (nvidia-utils) | 615.71.09 | 610.57.04 |
| Firefox | 157.0 | 157.0 |
| pacman | 7.1.0 | 7.1.0 |
| Python | 3.14.7 | 3.14.7 |
For most desktop use a month-old Plasma or Mesa does not matter. Where it bites is new hardware (the newer linux-firmware and NVIDIA driver stay on the EndeavourOS side until Manjaro’s next stable batch) and the AUR, which is next.
4. The AUR on Manjaro: 40 packages its repos can’t satisfy
AUR packages are written against Arch’s current repositories. When a PKGBUILD declares a minimum version of a repo package, Arch (and so EndeavourOS) satisfies it, and Manjaro stable may not. I measured how often that happens instead of guessing: a script pulled the AUR’s full metadata dump (121,095 packages) and checked every versioned dependency against Arch and against Manjaro stable.
On 3 October, 40 AUR packages declared a versioned dependency that Arch satisfied and Manjaro stable did not. Eleven of them have 10 or more votes, and four have over 100. Five of the 40 aren’t really lag: four pin Arch’s exact kernel build (zfs-linux and friends, which can’t match Manjaro’s own linuxXX kernels anyway) and one trips over Manjaro shipping an unrelated package called pacman-mirrorlist. The other 35 are plain version lag, and that count is a floor, because the script skips dependencies on packages Manjaro does not carry at all yet. Here are the ones with at least 10 votes, minus the kernel pins and the pacman-mirrorlist false positive:
| AUR package | Votes | Needs | Manjaro stable has |
|---|---|---|---|
virtualbox-ext-oracle | 1,371 | virtualbox=7.2.20 | 7.2.16 |
ocrmypdf | 160 | python-pikepdf>=10.15 | 10.13.0.post1 |
dotnet-runtime-bin | 58 | dotnet-host>=10.0.12 | 10.0.11.sdk111 |
include-what-you-use | 49 | clang>=23.1 | 22.1.8 |
lib32-ffmpeg | 38 | ffmpeg>=2:9.0.2 | 2:9.0.1 |
ipfs-desktop | 23 | kubo>=0.43.1 | 0.43.0 |
lib32-glibc-eac | 13 | glibc=2.44+r50+g1848099f063e | 2.44+r24+g16be1518495f |
lib32-aom | 13 | aom>=3.15.1 | 3.15.0 |
Forty out of 121,095 sounds tiny, and for most people it is. The catch is which forty. The most-voted one is the VirtualBox extension pack, which pins an exact VirtualBox version that Manjaro stable won’t have until its next batch. I asked for it on both machines.
On EndeavourOS, yay pulled VirtualBox 7.2.20 from Arch’s extra repo and built the extension pack against it. I ran it non-interactively:
yay -S --needed --noconfirm virtualbox-ext-oracleIt finished with exit code 0. Check what landed:
pacman -Q virtualbox virtualbox-ext-oracleBoth sit at 7.2.20, the version the PKGBUILD pins:
virtualbox 7.2.20-1
virtualbox-ext-oracle 7.2.20-1Manjaro stable only had VirtualBox 7.2.16, so I installed that the normal way (virtualbox plus linux71-virtualbox-host-modules), then asked Pamac for the extension pack. I expected a dependency error. What I got was worse, because it looks like it works:
pamac build virtualbox-ext-oracleTo satisfy virtualbox=7.2.20, Pamac found virtualbox-bin in the AUR and planned to remove Manjaro’s own VirtualBox and its prebuilt kernel modules to make room for it. This is with /etc/pamac.conf left at Manjaro’s default, EnableAUR still commented out. I trimmed the 33-package install list above it (base-devel, the Python build tools and dkms), which the download and size totals include:
To build (2):
virtualbox-bin 7.2.20-1 AUR
virtualbox-ext-oracle 7.2.20-1 AUR
To remove (2):
virtualbox 7.2.16-1 (Conflicts With: virtualbox-bin) extra
linux71-virtualbox-host-modules 7.2.16-9 (Conflicts With: virtualbox-host-dkms) extra
Total download size: 92.5 MB
Total installed size: 411.6 MB
Total removed size: 227.5 MB
Edit build files : [e]
Apply transaction ? [e/y/N] Say yes and you’ve traded Manjaro’s own VirtualBox, with kernel modules prebuilt for each Manjaro kernel, for Oracle’s binary build out of the AUR plus DKMS modules compiled on your machine. That’s the real cost of AUR lag on Manjaro. It is rarely a clean failure. It is a helper quietly routing around the version gap. The same prompt in Konsole:
I answered no. On Manjaro stable the clean fix is to wait for the next batch to bring VirtualBox up to 7.2.20.
5. The first update after installing
Both ISOs were seven weeks old on test day, so the first update was big on both. I counted what pacman wanted to pull, then timed a non-interactive pacman -Su on each machine, one after the other so they weren’t fighting over bandwidth. Each one used the mirror list its installer wrote, so the times include mirror speed and only the package counts and sizes compare cleanly.
First pacman -Syu | EndeavourOS | Manjaro |
|---|---|---|
| Packages pending | 451 | 377 |
| Download size | 1,608 MiB | 1,418 MiB |
Time for pacman -Su | 316 s | 242 s |
| Kernel after the update | 7.1.8 to 7.2.8 | 7.1.8 to 7.1.13 |
| Snapshot taken first | No | Yes (Timeshift, btrfs) |
New .pacnew files | /etc/pam.d/su, endeavouros-mirrorlist | two tpm2-tss profiles |
EndeavourOS pulled more because it caught up all the way to Arch, including a jump to the 7.2 kernel series. Manjaro stopped at the last stable batch and kept you on the 7.1 kernel series you installed. The part I liked on Manjaro happened before a single package changed: a pacman hook took a Timeshift snapshot of the root subvolume first.
sudo timeshift --listOne snapshot, tagged as created by the autosnap hook before the upgrade:
1 snapshots, 32.3 GB free
Num Name Tags Description
------------------------------------------------------------------------------
0 > 2026-10-03_01-28-46 O {timeshift-autosnap} {created before upgrade}After the update the snapshot already had an entry in grub-btrfs‘s GRUB submenu, so you can boot the pre-update system if something breaks, then restore it with Timeshift. EndeavourOS gives you nothing equivalent on its default ext4 layout. If you care about rollbacks there, choose btrfs in the installer and set up Snapper or Timeshift yourself (the Btrfs guide covers the subvolume side).
6. Boot time, idle RAM and the RAM floor
Here’s how each number was taken, so you can repeat it. Boot time is qm start until SSH answers, until plasmashell is running for the autologin user, and until the screen stops changing for 10 seconds (my “desktop settled” mark), over three cold boots. Idle RAM is the balloon driver’s total minus available memory 180 seconds after power-on, and it matched /proc/meminfo inside each guest to the megabyte. Firefox is a headless screenshot of a local file, timed cold and then warm, once on each of three fresh boots.
| Measurement | EndeavourOS | Manjaro KDE |
|---|---|---|
| SSH reachable, median of 3 boots | 17.2 s (17.2, 17.1, 17.2) | 18.1 s (20.8, 18.1, 18.0) |
plasmashell running, median | 20.0 s | 23.5 s |
| Desktop settled, median | 28.1 s (28.2, 27.1, 28.1) | 29.7 s (31.4, 29.7, 29.5) |
| Idle RAM used, 180 s after power-on | 1,141 MB | 1,154 MB |
| Processes at idle | 184 | 186 |
| Firefox cold / warm start, median | 1,026 / 716 ms | 1,035 / 726 ms |
Disk used after the first update (df, pacman cache included) | 9,046 MiB (ext4) | 9,481 MiB (btrfs, zstd, includes the pre-update snapshot) |
Call it a draw. EndeavourOS reached a settled desktop 1.6 seconds sooner, which is less than Manjaro’s own spread across its three boots (29.5 to 31.4 seconds), and it sat 13 MB lighter at idle, about 1% of what either desktop uses. Firefox is the same 157 build on both (Manjaro stable had already caught up to Arch on that one), so matching start times are what you’d expect. Nothing in this table is a reason to pick one over the other.
The RAM floor is where the gap opens up a little. The script steps memory down (2048, 1536, 1024, 768, 512 MB), and a size passes only if two things hold: plasmashell is running in an active seat0 session at 240 seconds with the same PID 60 seconds later, and a screenshot taken at the end shows the panel actually drawn. The second check overrode the first on four Manjaro boots, explained below. Edges are noisy, so I repeated the boundary sizes and I’m giving you every attempt rather than one lucky boot:
| RAM | EndeavourOS | Manjaro KDE |
|---|---|---|
| 2048 MB | Pass (1 of 1) | Pass (1 of 1) |
| 1536 MB | Pass (3 of 3) | Pass (1 of 1) |
| 1024 MB | 1 of 3: plasmashell OOM-killed on the other two | Pass (3 of 3) |
| 768 MB | 0 of 3: black screen | 0 of 3: wallpaper only, no panel, SSH stopped answering |
| 512 MB | Not reached | 0 of 1: black screen |
Manjaro held a working Plasma desktop at 1024 MB on all three boots. EndeavourOS managed it once. On the other two attempts the kernel’s OOM killer took out plasmashell within about four to five minutes of power-on (at 290 seconds on one boot; on the other it was killed at 236 seconds, came back, and was killed again at 308). That’s the nastier way to fail: the desktop comes up, then loses its shell minutes later. The second kill from that boot:
[ 308.802436] eos-desk kernel: Out of memory: Killed process 1507 (plasmashell) total-vm:1526336kB, anon-rss:199208kB, file-rss:920kB, shmem-rss:8300kB, UID:1000 pgtables:1548kB oom_score_adj:200At 768 MB EndeavourOS went down faster. On two of the three boots the journal shows plasmashell killed first and the Wayland compositor one to two minutes later (178 then 303 seconds on one boot, 112 then 189 on the other), and all three boots ended on a black screen:
[ 303.374113] eos-desk kernel: Out of memory: Killed process 537 (kwin_wayland) total-vm:1151296kB, anon-rss:73212kB, file-rss:16kB, shmem-rss:1200kB, UID:1000 pgtables:1016kB oom_score_adj:200
[ 303.785310] eos-desk systemd[467]: plasma-kwin_wayland.service: Failed with result 'oom-kill'.Manjaro’s 768 MB failure looked different. plasmashell stayed alive with the same PID, so a process check alone would call it a pass, but after five minutes the screen still showed only the wallpaper with no panel, and on all three boots SSH stopped answering when the script went back for the journal. A desktop you can’t click isn’t a pass, so it goes in the table as a fail. The single 512 MB boot was the same story: the process check passed, and the screenshot was black. This is what EndeavourOS looked like on its third 1024 MB attempt, with the shell gone and only the Welcome window left:
I don’t want to oversell this. Both passed every attempt at 1.5 GB and up, and nobody should be running Plasma on 1 GB in 2026. What it does tell you is that Manjaro’s KDE image leaves a little more headroom on old hardware, and that the EndeavourOS failure mode at the edge is a shell that dies a few minutes in, not one that never starts.
7. What each one installs and switches on
Both images put KDE Plasma on Wayland in front of you, but the pieces underneath were picked by people with different goals. I pulled these from the freshly installed systems (pacman -Q, systemctl list-unit-files --state=enabled, bootctl status) before installing anything myself:
| Default | EndeavourOS | Manjaro KDE |
|---|---|---|
| Bootloader | systemd-boot | GRUB |
| Root filesystem | ext4 | btrfs, zstd compression |
| Swap | None | None |
| Initramfs generator | dracut | mkinitcpio |
| Login manager | Plasma Login Manager | SDDM |
| Firewall | firewalld, running, allows ssh and dhcpv6-client | None installed |
| SSH server | Installed, disabled | Installed, disabled |
| AUR helper | yay (paru is in the EndeavourOS repo) | None; Pamac’s AUR browsing is off |
| Graphical package manager | None | Pamac |
| Snapshots before updates | None | Timeshift autosnap + grub-btrfs |
| Driver tool | eos-hwtool | mhwd |
| Kernel switching | pacman (linux, add linux-lts yourself) | mhwd-kernel, Manjaro Settings Manager |
| Mirror ranking | eos-rankmirrors, reflector | pacman-mirrors, weekly pamac-mirrorlist.timer |
| Packages after first update | 1,099 | 1,256 |
| 32-bit (multilib) packages | 0 | 65 |
| Bluetooth / CUPS services | Not enabled / not installed | Both enabled |
Two rows surprised me. Manjaro’s KDE image ships without any firewall package at all, so nothing filters inbound traffic until you add one. EndeavourOS has firewalld running from first boot with only ssh and dhcpv6-client open in the public zone, which is a sane laptop default. On Manjaro I’d fix that before anything else:
sudo pacman -S --needed ufw
sudo ufw allow ssh
sudo ufw enable
sudo systemctl enable --now ufw
sudo ufw status verboseAllow SSH before you enable it if you’re working remotely, and answer y at the prompt. Enabling ufw.service is what brings the rules back after a reboot (I rebooted to check). The status shows the default-deny policy with only SSH open:
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To Action From
-- ------ ----
22 ALLOW IN Anywhere
22 (v6) ALLOW IN Anywhere (v6)The other is AUR access. EndeavourOS hands you yay on day one (Manjaro carries yay in its own extra repo but doesn’t install it, and the yay install guide covers both), and the Welcome app’s After Install tab has buttons for mirror ranking, eos-update and AUR updates:
Manjaro gives you Pamac, a graphical front end for pacman that can also build from the AUR, but that support ships switched off: EnableAUR is commented out in /etc/pamac.conf. That only hides the AUR in Pamac’s window, though. As the VirtualBox test showed, pamac build from a terminal reached the AUR and planned a build with that line still commented out. If you’d rather use a terminal helper on either distro, the yay vs paru comparison covers which one to pick.
8. Drivers and kernels: mhwd vs eos-hwtool
The old knock on EndeavourOS was that it handled NVIDIA cards with one blunt default while Manjaro’s mhwd picked a driver for you. Before November 2025 the ISO always shipped the standard nvidia package; the Ganymede release made it detect the GPU and choose between nvidia and nvidia-open, and the Titan release in March 2026 added hardware detection for every GPU and VM, early loading of GPU drivers, and eos-hwtool so you can add or remove driver profiles yourself after install.
Both tools work by profiles. On my VMs there is no physical GPU, so they only see the virtio display adapter. That’s enough to show what each one reports, but I’m not claiming anything about NVIDIA hardware I didn’t test. On EndeavourOS:
eos-hwtool --listIt identifies the hypervisor and offers the matching VM profile. On a machine with an NVIDIA card this is where GPU profiles such as nvidia_open (the example in the tool’s own help) would appear, and --recommended shows which one it picks:
Device: Qemu
Profiles:
vm_qemuManjaro’s equivalent is mhwd, which lists the configs that match your hardware and the ones already installed:
mhwd -lmhwd sees the same virtio GPU and lists three free configs for it, with video-virtualmachine already installed by the installer:
> 0000:00:01.0 (0300:1af4:1050) Display controller Red Hat, Inc.:
--------------------------------------------------------------------------------
NAME VERSION FREEDRIVER TYPE
--------------------------------------------------------------------------------
video-virtualmachine 2025.07.24 true PCI
video-modesetting 2020.01.13 true PCI
video-vesa 2017.03.12 true PCIKernels split the same way. Manjaro packages each kernel series on its own (linux71, linux72, linux612 for the 6.12 LTS) and you switch with mhwd-kernel or the Kernel page in Manjaro Settings Manager. A fresh install stays on the series it shipped with until you add another one, and that is how the first update left Manjaro on 7.1:
mhwd-kernel -liOne kernel installed, the one the ISO came with:
Currently running: 7.1.13-2-MANJARO (linux71)
The following kernels are installed in your system:
* linux71Manjaro stable offered linux72 at 7.2.3 and linux612 at 6.12.108 on test day, so the newer series was there for the taking. EndeavourOS simply tracks Arch’s linux package, which rolled straight to 7.2.8 in the first update. Neither ships an LTS fallback kernel by default; on EndeavourOS you’d add Arch’s linux-lts, on Manjaro a second series through mhwd-kernel.
9. EndeavourOS vs Arch: moving to plain Arch later
People pick EndeavourOS as a stepping stone and then wonder how far they are from “real” Arch. I tested it by doing what you’d do to leave: comment out the [endeavouros] block in /etc/pacman.conf, resync, and ask pacman which installed packages no longer come from any repo:
sudo sed -i '/^\[endeavouros\]/,/^Include/ s/^/#/' /etc/pacman.conf
sudo pacman -Sy
pacman -QmTwenty-three packages turn foreign. Most are branding, the Welcome app and mirror tools:
bash-app-translate 26.1.6-1
downgrade 12.0.3-1
endeavouros-branding 26.03.1.1-1
endeavouros-keyring 20231222-1
endeavouros-konsole-colors 1-2
endeavouros-mirrorlist 26.9.1-1
eos-apps-info 26.6-1
eos-bash-shared 26.9-1
eos-hooks 1.16.2-1
eos-hwtool 1.9-1
eos-log-tool 26-1
eos-packagelist 2.3.1-2
eos-qogir-icons 2025.02.15-3
eos-quickstart 1.4.1-1
eos-rankmirrors 26.8-1
eos-settings-plasma 2.1-1
eos-translations 26.5-1
eos-update 26.9.1-1
iso-create-ml 26.9-1
kernel-install-for-dracut 1.14.2-1
reflector-simple 2026.8-2
welcome 26.8-1
yay 13.0.1-1Two details matter. dracut is not on that list because Arch’s extra has one too, but the EndeavourOS build you are running is newer, so every pacman -Su prints warning: dracut: local (112_eos-1) is newer than extra (111-1) until Arch catches up. And kernel-install-for-dracut is the piece that builds your initramfs and boot entry when the kernel updates, so leave it installed. It keeps working as a foreign package, which a kernel reinstall with the repo disabled confirmed:
sudo pacman -S linuxThe last hooks show kernel-install running without errors, and sudo bootctl list afterwards still listed the 7.2.8 entry and its fallback on the EFI partition:
:: Running post-transaction hooks...
(1/4) Arming ConditionNeedsUpdate...
(2/4) Updating module dependencies...
(3/4) Running kernel-install...
:: kernel-install installing kernel 7.2.8-arch1-2
(4/4) Checking which packages need to be rebuiltBeyond that, removing the branding, the Welcome app and the mirror tools is housekeeping. That’s the honest answer to EndeavourOS vs Arch: it is an Arch install with an installer, a small helper repo and a few defaults (dracut, systemd-boot, firewalld) that a hand-built Arch box might not choose. If you want to see what the from-scratch route looks like, the archinstall walkthrough builds a comparable system and the Arch post-install guide covers what you’d add after.
I didn’t try the same trick on Manjaro, and I wouldn’t. With 641 packages that exist only in Manjaro’s repos, its own kernel naming and mhwd managing drivers, there’s no small list to clean up afterwards. Going from Manjaro to Arch, or to EndeavourOS, is a reinstall.
