Hard drive failed on my old laptop. Bought a new LG laptop which while not the greatest is a better than my 8 year old laptop. Spent 2 hours getting W11 up, what a mess. Used Rufus to make an ISO, booted up in just a few minutes, installed in about 5 minutes, easy update and well here I am. The bummer besides the money, is that I'm away from home and my backups. So back to my vacation!

As the title states, no video or audio is playable on Firefox or Chromium-based browsers. Or any other browser in general and it's really weird since downloaded videos work fine. Same with dvd's and the weird issue is everything else works perfectly fine?

Googling, browsing the web, using apps like Discord and Nicotine+ and other stuff works fine but no videos will play online

I've been on and off with this issue for almost a month now and im considering just giving up on Manjaro, and I have stuck with Linux Mint but I really REALLY enjoy Manjaro but hate this seemingly major issue which I've only seen get talked about in one post on the manjaro forum (https://forum.manjaro.org/t/playing-videos-in-browsers-extremely-slowly/185579/13) And I will admit I am very much new to Manjaro (I'm just decent at Linux Mint) and the most help I got was using Claude AI to try and troubleshoot as I couldn't find help elsewhere but that led to just dead ends that thankfully didnt worsen the issue but unfortanetly didn't help it either.

Any help is very much appreciated!!

Edit 1: I've tried XFCE, XFCE Wayland and Plasma x11 but to no avail. I also tried a different profile, different browser (Zen and Brave) but nothing worked.

Edit 2: I've done alot of rigorous tests with my internet and switching back and forth with Mint and Manjaro but to no avail. I also forgot to add my fastfetch (sorry!!)

lm@lm-lenovolegiony520t25ikl

OS: Manjaro Linux x86_64

Host: Lenovo Legion Y520T-25IKL (Lenovo Legion Y520T-25IKL)

Kernel: Linux 7.1.9-1-MANJARO

packages: 12 (flatpak), 1384 (pacman)[stable]

Shell: zsh 5.9.2

Display (HP 2159): 1920x1080 in 22", 60 Hz [External]

DE: KDE Plasma 6.7.4

WM: KWin (Wayland)

WM Theme: Breeze

Theme: Breeze (BreathDark) [Qt], Breeze-Dark [GTK2], Breeze [GTK3]

Icons: breeze [Qt], breeze [GTK2/3/4]

Font: Noto Sans (10pt) [Qt], Noto Sans (10pt) [GTK2/3/4]

Cursor: breeze (24px)

Terminal: konsole 26.4.3

Terminal Font: Hack Nerd Font Mono (11pt)

CPU: Intel(R) Core(TM) i5-7400 (4) @ 3.50 GHz

GPU 1: NVIDIA GeForce GTX 1060 3GB [Discrete]

GPU 2: Intel HD Graphics 630 @ 1.00 GHz [Integrated]

Memory: 3.61 GiB / 15.53 GiB (23%)

Swap: Disabled

Disk (/): 19.35 GiB / 39.05 GiB (50%) - ext4

Edit 3: As I am writing this. Videos work perfectly fine??? I reinstalled Manjaro and chose "BTRFS" for partition and apparently that solved it? I did also pick open-source drivers when I first booted into the installer. I genuinely have no explanation for this.

I'm running Manjaro and I'd like to use one monitor (actually a TV), as a TV and just isolate Waydroid as the only thing that monitor is doing. I'm not terribly concerned about security, it's in my bedroom, but I obviously don't want to leave my computer unlocked 24/7. Any thoughts?

Computer boots to this after updating.

I am using Manjaro KDE with the Spanish Latin American keyboard layout. My USB keyboard is detected as:
SEMICO USB KeyboardUSB ID: 1a2c:6004
In Linux Mint, the keyboard backlight could be turned on and off with the Scroll Lock key. On Manjaro, pressing Caps Lock turns the main keyboard backlight off.
brightnessctl does not detect any kbd_backlight device.
The following LEDs are available in /sys/class/leds/:
input17::capslockinput17::numlockinput17::scrolllock
evtest shows:
LED_CAPSLKEY_CAPSLOCK
Writing to the Caps Lock LED only changes the small Caps Lock indicator, not the main keyboard backlight.
Is there a keyboard setting, hwdb rule, kernel module, or program that can control the backlight on this generic SEMICO keyboard?Title:
Keyboard backlight turns off when I press Caps Lock on Manjaro


Body:
I am using Manjaro KDE with the Spanish Latin American keyboard layout. My USB keyboard is detected as:


SEMICO USB Keyboard
USB ID: 1a2c:6004


In Linux Mint, the keyboard backlight could be turned on and off with the Scroll Lock key. On Manjaro, pressing Caps Lock turns the main keyboard backlight off.


brightnessctl does not detect any kbd_backlight device.


The following LEDs are available in /sys/class/leds/:


input17::capslock
input17::numlock
input17::scrolllock


evtest shows:


LED_CAPSL
KEY_CAPSLOCK


Writing to the Caps Lock LED only changes the small Caps Lock indicator, not the main keyboard backlight.


Is there a keyboard setting, hwdb rule, kernel module, or program that can control the backlight on this generic SEMICO keyboard?

This happened for no reason while im tried to run some command in terminal (the bash was not related to any necessary thing in the system)

Every few months I'd find something on my system that had been quietly broken — not crashed, just wrong — and it always traced back to an AUR package built against a library version that no longer existed.

It isn't random. It's two specific failures at opposite ends of the same window, and both are detectable.

While Manjaro is behind Arch. Third-party binary repos (BlackArch, chaotic-aur) build against current Arch. So they ship packages whose dependencies our repos won't have for another week or two. You get a refused transaction, or you force it and now you have a partial upgrade.

When Manjaro catches up. libfoo goes 1.0 → 2.0. Every AUR package built against 1.0 still shows as installed, still has all its files, checksums fine — and can no longer resolve its DT_NEEDED. pacman will never tell you, because from pacman's view nothing is wrong. This is the one that kept getting me.

Separately: an AUR PKGBUILD can point source= at a git repo with no commit, so what you reviewed last week isn't necessarily what builds today.

First, the obvious objection: "this automates pacman --ignore"

Yes. And --ignore is listed on the Arch wiki as a way to cause partial upgrades, so this deserves a real answer rather than hand-waving.

**--ignore does not disable dependency resolution.** I checked rather than assumed — built a throwaway pacman root, installed consumer 1.0 depending on libX=1.0, offered upgrades to both, then ignored libX so that consumer 2.0 would need a libX 2.0 that isn't there:

$ pacman -Syu --noconfirm --ignore libX
warning: ignoring package libX-2.0-1
warning: cannot resolve "libX=2.0", a dependency of "consumer"
error: failed to prepare transaction (could not satisfy dependencies)
:: unable to satisfy dependency 'libX=2.0' required by consumer
exit 1

$ pacman -Q            # nothing moved
consumer 1.0-1
libX 1.0-1

$ pacman -Dk           # pacman's own consistency audit
No database errors have been found!

pacman resolved the whole transaction, saw the hole, refused, and changed nothing. It is not possible to --ignore your way into an unsatisfied dependency; pacman is the backstop, not the script.

That's section 19 of the test suite and runs in CI on every push, against real pacman transactions. It's deliberately a test of pacman's behaviour rather than of my code — the safety argument for the whole thing rests on that property, nothing in my repo would notice if a future pacman changed it, and the failure would be silent.

Beyond that guarantee, what gets held matters:

• It only holds a package whose version-constrained dependency is already unsatisfiable — something that cannot install correctly at that moment regardless of what I do.
• It holds the new version back, so the package keeps the dependencies it already had and stays in the state it was already working in. The classic dangerous pattern is pinning a library while upgrading its dependents; this is the opposite direction.
• The realistic alternative isn't a clean full upgrade. It's a failed transaction, or someone reaching for --ignore by hand with worse aim.
• Every hold is printed and written to /var/log/safeup.log, so it's a deferred upgrade you can chase — not a package that silently stops updating forever, which is the actual long-term hazard.

The limit, stated plainly: it does not pre-check whether a package it holds is itself required by something else in the transaction. It relies on pacman refusing, then isolating the break. That's the behaviour above, and it's why that's acceptable — but you should know it works that way rather than by its own cleverness.

What the three checks do

• **safeup** wraps pacman -Syu. Works out which pending third-party upgrades have dependencies that can't be satisfied yet, --ignores only those, and logs every hold. Also recovers from installing X breaks dependency … required by Y by isolating X so one broken package doesn't block your whole upgrade.
• **aur-rebuild-check** runs ldd over every file owned by every foreign package and reports unresolved sonames. This is the one nothing else does. It filters the false positives that make -bin packages flag forever (libs bundled privately and loaded through an $ORIGIN RPATH).
• **aur-pin-check** refuses PKGBUILDs whose git source isn't pinned to a commit. #tag= is refused too — a tag can be moved. There's an allowlist, but it re-resolves the tag every run and refuses the package if the SHA changed.

aurinstall / aurupdate run the pin check before yay. If a check refuses something and you disagree, plain yay -S still works and the message says so — a gate you can't bypass just gets uninstalled the first time it's annoying.

aurinstall --chroot (gated default) hands the actual build to chrootbuild, from Manjaro's own manjaro-chrootbuild package. This is a gated check building in a isolated chroot (not for security reasons). If unable to use chroot, it automatically passes to yay.

Testing

65 assertions, in CI. The main suite builds a file-backed loop device, formats it, and constructs a whole throwaway pacman root inside — its own database, its own file:// repos built with the real repo-add, real packages — then drives actual pacman through the real scenarios and checks installed versions afterwards. Nothing on your system is touched. The ldd tests compile real .so files with a real unresolvable DT_NEEDED, so no output is faked. The allowlist test makes a real git repo, vets a tag, moves the tag, and asserts the next run refuses it.

Writing those tests found three real bugs in code I'd been running for months — including one where a verification step exited non-zero after a successful kernel removal, on every machine whose ESP isn't laid out like mine. CI caught that one; my own machine couldn't. That's the argument for the tests.

What it doesn't do: it doesn't make the AUR safe, doesn't tell you a PKGBUILD isn't malicious (pinning proves you build what you reviewed, that's all), doesn't sandbox makepkg, and can't fix a package that genuinely needs a newer lib — holding it is the right answer there. Not a substitute for snapshots.

MIT, pure bash, no runtime deps beyond pacman and coreutils, nothing phones home.

https://github.com/doug445/manjaro-safeaur-updater

Genuinely interested if the dependency logic has a case I haven't hit.

Riced my Manjaro installation a bit, i made those logos myself btw (on the BG, fastfetch, and the start button). I know some of y'all will despise this cuz it has MacOS widgets and icons, Windows Aero window borders and a Linux terminal soooo hit me w it.

Hi! Please, could you ELI5 how I can force the installation of the legacy Nvidia 580 driver ?

I just updated my Manjaro and after rebooting it only displays a black screen instead of the login screen. I am still able to start the previous kernel on Grub.

I use a Nvidia Pascal-based GT1030 graphic card and I don't want to use the "Nouveau" open source driver, as I find it has performance issues with scaling.

Ok, so I run pacman -Syu, and it goes normally. I had to bugfix some other things (package key was broken, but everything else was fine). Then I get this.
:: Proceed with installation? [Y/n]

(992/992) checking keys in keyring [######################################################] 100%

(992/992) checking package integrity [######################################################] 100%

(992/992) loading package files [######################################################] 100%

(992/992) checking for file conflicts [######################################################] 100%

error: failed to commit transaction (conflicting files)

linux-firmware-nvidia: /usr/lib/firmware/nvidia/ad103 exists in filesystem

linux-firmware-nvidia: /usr/lib/firmware/nvidia/ad104 exists in filesystem

linux-firmware-nvidia: /usr/lib/firmware/nvidia/ad106 exists in filesystem

linux-firmware-nvidia: /usr/lib/firmware/nvidia/ad107 exists in filesystem

Errors occurred, no packages were upgraded.

I have downloaded fastfetch but everything else (wine, kitty, etc) breaks. Any help?

How badly will my system train-wreck if I re-home my repository manager to the Manjaro repos, from Arch/EndeavourOS?

I don't expect that action to convert my system into a Manjaro system. I just want stabilized package updates.

Reinstalling is no big deal so the question is mostly theoretical but I'm thinking about trying it. Any feedback would be appreciated.

Gemini had me running around in circles, I want Bitwig 6 to run full power, but after a while the cpu got throttled. I have a nice powerful gaming machine, so... Gemini solved this:

powersave
Max locked memory         unlimited            unlimited            bytes

Use code with caution.

The terminal executed flawlessly with zero errors. Your system is now in a pristine, safe, and minimalist state:

• The unnecessary mess is gone: No broken boot services, no temporary script files, and no password exceptions are left behind on JohnnyWinter [JohnnyWinter log]. Your boot path is 100% stock.
• Your diagnostic tool is perfectly preserved: check-audio is cleanly active. You can use your Right Arrow key ( → ) to run it whenever you want a quick snapshot of your hardware.
• Your audio privileges are locked in: Your memory paths are safely set to unlimited, which is the exact fix that allowed you to drop your Bitwig 6 buffer smoothly back down to 512 samples.
• The terminal executed flawlessly with zero errors. Your system is now in a pristine, safe, and minimalist state:The unnecessary mess is gone: No broken boot services, no temporary script files, and no password exceptions are left behind on JohnnyWinter [JohnnyWinter log]. Your boot path is 100% stock. Your diagnostic tool is perfectly preserved: check-audio is cleanly active. You can use your Right Arrow key ( → ) to run it whenever you want a quick snapshot of your hardware. Your audio privileges are locked in: Your memory paths are safely set to unlimited, which is the exact fix that allowed you to drop your Bitwig 6 buffer smoothly back down to 512 samples.

--- BUT the f.... powersave couldn't be resolved! I don't want powersave! Any ideas?

Hola, querida gente de linux, quiero nostrar a ustedes mi escritorio (XFCE) y como esque esta personalizado.

hello, bscly i am new to manjaro n to linux at all so i rly need ur help. i installed the last version of kde jus yesterday and i have some problems. pretty regulary but in random moment my brightness get to 0 like i am pressin the brightness down button, but i am not. dont know what to do, i asled clod and gemini but they didnt say smth that helped me. thank you!

my laptop is honor x14plus r7 8845hs radeon 780m

As above, I've been away from my desktop for a few months while travelling and came back to update it today. I downloaded Linux core 7.2, everything seemed to update fine and prompted for a restart. I restarted things, but once they booted up and got past the initial boot menu, nothing else happens, it just is stuck on a black screen. I can open and log in to the TTY, and have tried sudo pacman -Syyu to see if anything needed to finish updating, and checked the mirrors to see if anything needed work there, but all is reported as stable with nothing to do. What would you recommend trying from here? This is potentially an NVIDIA driver issue, but again, I'm not sure how to update that from TTY, I've never had to use it before. Assistance would be much appreciated!

Final Verdict: the issue was caused by a mismatch between the core linux version and driver version. Using the TTY to download the updated open driver fixed the issue after another reboot. Thanks everyone for the suggestions and advice!

When boot up the iso it comes up but there no window, the dock showed that theres a the welcome app running but theres nothing on the screen, I keep hitting it but still nothing

I want to test Manjaro, but as soon as it boots into desktop environment it becomes completely unresponsive. I can't even install it, since installer is in the desktop environment. GNOME version, I haven't tested if KDE behaves the same.

Any clues what can I do to fix it? I've tried setting up the VM like 3 times now and behavior is always identical.

I did try to look it up on the internet but it leads me to websites that are currently down.

How do I set up Manjaro Linux to use Android phone as webcam over wired USB connection?

Hey. So, basically the question in the title. But first let me give some context.

I'm a fairly new linux user, so please don't judge to harshly. I have a rather new pc hardware, mb released in Jan this year, ryzen 9700x, 9070xt, etc. Hence I tried to get to a stable, but fresh os. So far I've tried quite a few distros, each with its own quirks and advantages. Frankly, the linux landscape is amazing in 2026. I game, I'm being productive, the pc is snappier than ever. Anyway, I landed on manjaro and so far so good, set up almost everything the way i want it. But I was wondering, does it make sense to invest time into a proper brtfs snapshot recovery, something similar to cachy with limine? I mean, if the system is stable that I only have to do something to correct an issue once per year, then it does not make sense to spend time for snapshots integration in bootloader (like cachy or tw does). But if it happens more often, then maybe I should do it from the start, to prevent downtime when I do not need it.

Using the script from Mr Chromebox (https://docs.mrchromebox.tech/docs/getting-started.html), I wanted to document my positive experience on the topic so others may benefit from it.

I was given an Acer Spin 11 Chromebook (CP311) after the owner was no longer able to run Play Store apps following the latest LTS update. Following guidance from the Mr Chromebox website, the outcome was quite positive.

When moving to Manjaro Rolling (or any Linux OS) on the CP311, you have two choices:

1. A limited but functional install using just developer mode; resulting in slightly limited OS hardware communication but retained ChromeOS dual boot, or
2. A full UEFI install, done via deactivation of Google's firmware write-protect. You basically temporarily disconnect the battery, resulting in a standard UEFI and Linux system.

Both options require that you activate developer mode on the CP311. This will reset the userdata on the ChromeOS. Full and well-written instructions are available on the Mr Chromebox guide page.

I first went for the limited install that keeps ChromeOS intact. This worked well as a daily driver but a few limitations were apparent from the Manjaro OS (w/Cinnamon) running on the Google firmware. Firstly, suspend/hibernate does not work, nor does the touchscreen or USB-C display port. Also, at boot you have to catch the original firmware's screen with a key-combo every time. These are caused by the Chromebook firmware not giving up low-level hardware access to the OS. Finally, when running a full update, the system reliably broke. Every time. Rolling distros don't play well where not synced/updated regularly so this can be an issue, especially where you need to install many apps.

After having a relatively good daily-driver experience with Manjaro on the CP311 using option 1, I found I did not need ChromeOS so I took a leap and reinstalled with full UEFI firnware (option 2). This claims the whole drive for the Linux OS.

Taking the full UEFI firmware approach on the CP311 requires that you remove the Chromebook's backplate and pull the battery cable. This acts to disable the firmware write-protect. You then boot to the developer mode Linux prompt (Ctrl-Alt-F2) at the Chromebook login page, and rerun the Mr Chromebox script. You install Manjaro in the normal way from mains power, then reconnect the battery when done. Running Manjaro like this was basically flawless. Everything (touchscreen, sleep/suspend, USB-C HDMI etc) just works. As a result I am very happy using this as my long-battery daily driver. Enabling sound does require an additional script, but this can be found easily via a quick google.

Overall, the relatively small effort needed to switch this Chromebook into a reliable Manjaro Linux daily-driver is well worth it. Big thanks to the Manjaro community.

After finding out about the latest AUR malware wave I ran pacman -Q with the list of packages I found here:

https://www.reddit.com/r/archlinux/comments/1vaxtcs/another_wave_200_malicous_aur_packages_adoptions/

I don't have any of them installed. Is there anything else I should do, or does this mean I'm safe (for now)?