[Unstable Update] May 2024 Edition

Welcome to the new monthly unstable branch thread.

Recent News

Noticeable Package changes

Latest package changes: https://gitlab.manjaro.org/-/snippets/1016/raw/main/boxit-update-2024-05-16.txt

Known Issues

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:

2 Likes

Is it right to change permissions of this directory?

(14/18) updating libvirt [------------------------------------------ --] 100%
attention: directory permissions differ on /var/lib/libvirt/swtpm/
file system: 755 package: 711

*I didn’t change anything, as the directory is empty.

There is a known issue that lib32-glibc-2.39-3 breaks steam for nvidia. I downgraded to -2 and it’s working for me now.

2 Likes

Should be fixed with glibc-2.39-4 in arch core-testing at the moment.

1 Like

today live minimal dev image 240503 booting to x11 does not let me change the menu to application menu
switching to wayland let me do that

Well, that’s just Manjaro switching back to working technology. :joy:

2 Likes

Something weird showed up in my /etc/mkinitcpio.d/ folder last night after updating mkinitcpio (and various other non-kernel packages):

linux516.preset
# mkinitcpio preset file for the '%PKGBASE%' package

#ALL_config="/etc/mkinitcpio.conf"
ALL_kver="/boot/vmlinuz-"

PRESETS=('default' 'fallback')

#default_config="/etc/mkinitcpio.conf"
default_image="/boot/initramfs-.img"
#default_uki="/efi/EFI/Linux/manjaro-.efi"
#default_options="--splash /usr/share/systemd/bootctl/splash-manjaro.bmp"

#fallback_config="/etc/mkinitcpio.conf"
fallback_image="/boot/initramfs--fallback.img"
#fallback_uki="/efi/EFI/Linux/manjaro--fallback.efi"
fallback_options="-S autodetect"

…those image locations don’t point to anything and I only have linux66 and linux68 installed. This particular file’s birth time coincides with these alpm hooks:

[2024-05-03T20:35:25-0500] [ALPM] running '30-systemd-daemon-reload-system.hook'...
[2024-05-03T20:35:25-0500] [ALPM] running '30-systemd-tmpfiles.hook'...
[2024-05-03T20:35:25-0500] [ALPM] running '30-systemd-udev-reload.hook'...
[2024-05-03T20:35:26-0500] [ALPM] running '30-systemd-update.hook'...
[2024-05-03T20:35:26-0500] [ALPM] running '80-cronie.hook'...
[2024-05-03T20:35:26-0500] [ALPM] running '90-mkinitcpio-install.hook'...

My best guess is some kind of bug in /usr/share/libalpm/scripts/mkinitcpio. Anyone have any hints? Anyway, I simply rm’d this phantom preset, regenerated my other 2 legitimate presets, and all seems well with no errors.

Extra odd … as 5.16 is not an available/supported kernel.

I believe I know what happened in my case. I removed the manjaro package kernel-alive in 2022 around my initial installation time and neglected to manually rm the backup modules (and the .old file) located in /lib/modules/. Mkinitcpio apparently underwent some minor changes recently where it now generates .presets on its own upgrade instead of waiting for other triggers, and I’m guessing it’s going off what’s inside the modules directory. I rm’d an existing 5.16.5-1-MANJARO/ directory and the .old file, reinstalled mkinitcpio to test, and no further presets were generated. Looks like I just deferred some spring cleaning on my own system.:slightly_smiling_face:

3 Likes

pacnew-checker

I tried using it for the first time. pacnew-checker.
Is good.
thank you.

It’s about me.

"I noticed that many people don’t know about pacnew files or at least don’t pay attention to their creation during the upgrade phase. "

@romangg
Got this from recent mkinitcpio update:

==> Check if we need to add "kms" to hooks.
  -> "kms" hook does not exist yet. Adding it to the HOOKS line.
  -> Did not find "modconf" hook. Adding "kms" hook at the end.

That commit isn’t working on a default mkinitcpio.conf (which I do not even use, I’ve placed my actual HOOKS line in a dropin config in /etc/mkinitcpio.conf.d/) because it assumes HOOKS with an (old) string value rather than current array HOOKS=(...).
The kms hook was already present, and despite the final message it wasn’t added anywhere.

Thanks for the feedback. It should be resolved with mkinitcpio 39-4 coming along shortly.

2 Likes

after a recent update i got switched back to the X11 session of plasma

1 Like
==> Check if we need to add "kms" to hooks.
  -> "kms" hook does not exist yet. Adding it to the HOOKS line.

Adding where? My /etc/mkinitcpio.conf.d/ is empty, and /etc/mkinitcpio.conf had it already :thinking:
I updated from -1 to -4, if that matters.

Scroll up 2 posts; or 3 posts, for more context.

Cheers.

1 Like

I know. I’m not getting the third line, so this is after the current latest change.
I’m not familiar with the scripting in use, but this if statement doesn’t seem to function right, at least for my system:

if [[ $(sed -n '/^HOOKS=".*\bkms\b.*/p' /etc/mkinitcpio.conf) ]]; then
      printf '  -> "kms" hook already exists. Doing nothing.\n'
    else
      printf '  -> "kms" hook does not exist yet. Adding it to the HOOKS line.\n'

Whatever the issue is, it looks like:

Read my post as well, I am at that already…

It pays to be specific with versions, thanks.

So, you are then experiencing what appears to be the same issue, only now with mkinitcpio v39-4. @Yochanan

I updated from -1 to -4, if that matters.

:person_shrugging: