[Unstable Update] May 2024 Edition

Sorry, kms is relevant for boot times only indeed.
Only amd-gpu / free grapic-drivers are affected by time of “boot-time”.
That is only of academic interest, as you wrote (I presume), I admit.

1 Like


All systems have boot-time.
And kms affects more than that.

Please explain…

I already linked directly to the archwiki page here, which I shouldnt have needed to do either.


Although “uname -r” output kernel “6.9.0-1-MANJARO” in my grub menu and “/boot” I have this:


The other kernels are normal.
vmlinuz in /boot is vmlinuz-


So, I installed 6.9 yesterday, made a reboot, everything worked fine so I decided to remove old 6.8 kernel and now manjaro isn’t in grub boot menu. Any ideas what might’ve happened?

You got the bad mkinitcpio (seemed to only affect kernel 6.9 for some reason).
Replace with newest 39.1-2 and it will work again.


1 Like

Do I need to install manjaro on live usb and do it from there or is there a better way?

Unless you have some other image or way to boot.

You could maybe use grub commands to finger the boot path and image.

But its somewhat involved.

Here is a random quickly found search hit for a guide. I have not vetted it.


Otherwise if you dont have something else in the system to boot from then chroot may be the next best option.

Alright, I’ve used live usb since I couldn’t find or generate initramfs from grub terminal. Problem kinda persists though. Updating the package alone didn’t fix anything. I installed 6.8 to get into the os again, reinstalled 6.9, removed 6.8 and got back where I started, no Manjaro in boot menu. So, what do I need to do to fix it without keeping 6.8?

It’s always a good idea to keep a second kernel installed (preferably an LTS), this way you can often avoid needing to resort to using a live usb when a you run into a problem.


Sure, I don’t mind keeping an older kernel but the complete solution to the problem would still be useful.

No idea, but “hard reset” and to boot with the fallback-entry of any kernel sometimes saved my ass…


If using Unstable branch, always update using pacman in a terminal, and read what it throws at you during the process. In case of a doubt or an error act prior to reboot. Backup before you entered “y” and hit Enter. Don’t use funny filesystems, only ext4 could be considered stable. Avoid unnecessarily complicated Grub bootloader, use stub or systemd-boot. Keep several kernels installed just in case even if you don’t use them regularly.

The above is my “mantra” I’ve been following for several years to keep my system reliable and breakage-resistant. Being on Unstable branch is a risk by itself, I like to tinker with some stuff, but on the other hand, I need to keep the surface for potential breakage as low as I can.


After recent update of qtermwidget (1.4.0-2 → 2.0.0-1) octopi doesn’t start anymore.

octopi                                                             ✔
octopi: error while loading shared libraries: libqtermwidget5.so.1: cannot open shared object file: No such file or directory
1 Like

Also had an octopi error related to “Aborting octopi as ‘octopi-sudo’ binary could not be found! [ “/usr/local/bin/qt-sudo” ]”. A symlink to /usr/bin/qt-sudo fixed that error.

The Octopi Qt6 version is now complete with fixes including a correct version. You may need to install it manually as the new version is 0.15.0+19+ga081ac2b-1. There was a “newer” broken 0.16dev.r19.ga081ac2b-1 version pushed erroneously earlier.

Remove that. No, creating symlinks in the system is never a “fix”.

Note that it now depends on qt-sudo and replaces the old notifier packages.


:information_source: ICU 75 rebuilds are live. If you have manjaro-settings-manager installed, remove it temporarily, update then wait for the fixed rebuild later.

EDIT: The rebuild is done with 0.5.7-22.


I have installed Manjaro-Settings-Manager 0.5.7-21, is 0.5.7-22 the rebuild? I didn’t do any update yet from yesterday.