[Unstable Update] January 2024 Edition

Welcome to the new monthly unstable branch thread.

Notable Package Changes

We do a rough comparison to our testing branch and will update it either weekly or when we do a testing snap.

Known Issues / Recent News

Plymouth changes

:warning: WARNING: The plymouth-encrypt and sd-plymouth hooks no longer exist in the package. You should replace them with encrypt and plymouth hooks in your mkinitcpio.conf. The lxdm-plymouth.service, lightdm-plymouth.service and sddm-plymouth.service systemd service files no longer exist in the package. You should enable lxdm.service, lightdm.service or sddm.service instead.

Initramfs image can be bigger on 6.7 kernel due to Nvidia GSP Boot firmware

We all known that kernel 6.7 is very feature rich. One of the features is the inclusion of Nvidia’s GSP Boot firmware into Initramfs. However this will increase your image by 150 MB and the fallback image might be 240 MB in size. A way would be to remove kms from mkinitcpio.conf and redo your initramfs images. A discussion regarding that can be found at Arch Gitlab: kms hook increases the initramfs size heavily starting with 6.7 kernel (#238) · Issues · Arch Linux / Mkinitcpio / mkinitcpio · GitLab

To reduce size add fallback_options="-S autodetect -S kms" to /etc/mkinitcpio.d/linux67.preset

Making dbus-broker our default D-Bus daemon

2024-01-09 - Jan Alexander Steffens

We are making dbus-broker our default implementation of D-Bus, for improved performance, reliability and integration with systemd.

For the foreseeable future we will still support the use of dbus-daemon, the previous implementation. Pacman will ask you whether to install dbus-broker-units or dbus-daemon-units. We recommend picking the default.

For a more detailed rationale, please see our RFC 25.

Arch Linux - News: Making dbus-broker our default D-Bus daemon

bashrc-manjaro is now merged into bash

Yes, replace bashrc-manjaro with bash

pacman and pacman-contrib changes

pacman-contrib is now split out from pacman. If you have anything installed that depends on pacman-contrib, update with:

sudo pacman -Syu --asdeps pacman-contrib

Additional Info

Info about AUR packages

:warning: AUR (Arch User Repository) packages are neither supported by Arch nor Manjaro. Posts about them in Announcements topics are off-topic and will be flagged, moved or removed without warning.

For help with AUR packages, please create a new topic in AUR and a helpful volunteer may be able to assist you.


Get our latest daily developer images now from Github: Plasma, GNOME, XFCE. You can get the latest stable releases of Manjaro from CDN77.

Check if your mirror has already synced:

4 Likes

Oh no you don’t!
image
1h 20min left buddy! (because the whole world circulates around me xD)

Btw, go celebrate!

Happy new year and thanks for all the good work!
:partying_face: :partying_face: :partying_face:

8 Likes

I’m actually on testing branch but I would like to share a hint regards mesa update:

I have Intel HD Graphics 530. After removing the intel driver xf86-video-intel (and therefore switching to the modesetting driver) I could successfully update to 23.3.2 in Arch. Before removal of this package the boot process stucks with a black screen after updating from 23.3.1 to 23.3.2. This might be the same for some Manjaro users on Unstable. :wink:

4 Likes

I had somewhat similar experience last year. video-intel driver sees updates quite seldom, the latest version, for instance, was built almost a year ago. It doesn’t age well esp when combined with fresh mesa. At least that’s what I learnt the hard way.

Not sure why you had that installed to begin with unless you have an older card. It’s generally not recommended, see Intel graphics - ArchWiki.

I never installed it manually, it came either with the ISO or as dependency.

Yes, thanks, removing xf86-video-intel (and using modesetting instead) allowed me to update to mesa 1:23.3.2 and boot successfully. I do have an older computer (12 years old), but it seems to be working well with modesetting.

1 Like

For those seeing this on Intel, this is happening because your setup is broken and falling back to software rendering. If you have a very old system, you can use the intel ddx along with mesa-amber (NOT mesa!), for setups less than 10 years old, you should be using the modesetting ddx with mesa.

For nvidia, see NVIDIA - ArchWiki.
For VMs, please wait for a mesa update.

Yes, it’s a mesa bug, but almost nobody should be hitting it, as you shouldn’t be using swrast. We will revert a commit so even the “borken” systems should work again with an updated mesa package coming up soon …

3 Likes

seems to be trouble on boot kernel for nvidia cards ( desktop and laptop ) and Xorg :
https://bbs.archlinux.org/viewtopic.php?id=291519&p=1

Setup KMS: NVIDIA - ArchWiki or wait for the update …

Still does not work for me in Virtualbox

EDIT: Works as it should now

1 Like

thanks for pushing 1:23.3.2-2 no mesa problems anymore. Arch, garuda, manjaro unstable booting as they should.

1 Like

3 posts were split to a new topic: Reboot and shutdown issues with recent kernels

:information_source: Making dbus-broker our default D-Bus daemon

2024-01-09 - Jan Alexander Steffens

We are making dbus-broker our default implementation of D-Bus, for improved performance, reliability and integration with systemd.

For the foreseeable future we will still support the use of dbus-daemon, the previous implementation. Pacman will ask you whether to install dbus-broker-units or dbus-daemon-units. We recommend picking the default.

For a more detailed rationale, please see our RFC 25.

7 Likes

I got new error messages after updating dbus and installing dbus-broker-units (Do not worry, they are harmless. You can ignore them)

$ journalctl --no-pager -p 3 -b -3 --output=cat
Ignoring duplicate name 'org.freedesktop.Notifications' in service file '/usr/share//dbus-1/services/org.knopwob.dunst.service'
Ignoring duplicate name 'org.freedesktop.Notifications' in service file '/usr/share//dbus-1/services/org.kde.plasma.Notifications.service'
Ignoring duplicate name 'org.freedesktop.Notifications' in service file '/usr/share//dbus-1/services/org.knopwob.dunst.service'

A possible solution for KDE users:

  1. Remove all duplicate files for example: You do not need org.knopwob.dunst.service
$ sudo rm /usr/share/dbus-1/services/org.knopwob.dunst.service

However, when you update dunst, this file will be overwritten again. You can add it to NoExtract to not overwrite it, if you want. But I would not do that for some reason.

  1. But I got an error message:
Ignoring duplicate name 'org.freedesktop.Notifications' in service file '/usr/share//dbus-1/services/org.kde.plasma.Notifications.service'

This error message is related to fixing the old issue of KDE notification

Just remove the file ~/.local/share/dbus-1/services/org.kde.plasma.Notifications.service in the home directory.

  1. Reboot. Done, no more error message.

I am uncertain how to proceed as I get the following message after I chose Default (dbus-broker-units):

conflicting files:
- dbus-broker-units: /usr/lib/systemd/system/dbus.service already exists in filesystem (owned by dbus)
- dbus-broker-units: /usr/lib/systemd/user/dbus.service already exists in filesystem (owned by dbus)

I was missing dbus-daemon-units. All fixed. I apologize. I forgot to update my custom PKGBUILD

JR

I switched to dbus-broker-units as going forward that is default. It is working fine with this as well.

I didn’t get any errors or warnings during the dbus update, but I can’t reach SDDM after reboot. Problems with amdgpu perhaps, since the monitor loses signal. Happens on both 6.6 and 6.7 kernels.
I had to Timeshift via live environment, so I lost the logs.

Edit: To clarify, I did pick dbus-broker-units when asked by pacman.

2 Likes

I have the same problem, I can’t reach sddm too.

“Not possible to comunicate with the configuration server
Not possible to connect: Archive or directory nonexistent”

Using kernel 6.1 happens too. Not possible to change to another tty. Not possible to shutdown.

No problems with dbus-broker here … but I replaced it shortly after install however long ago.
I also dont remember issues doing it on any longer lasting installs either though.

1 Like

Don’t know what happened, after some tries to solve this problem, none of them worked, at least was the response in the chroot, and some reboots, it back to shows SDDM.
I tried to install dbus-daemon-units but pacman ended with “not possible to complete the transaction”.

Now my system is up and running. An old processor doing things, maybe.