[Unstable Update] September 2024 Edition

Welcome to the new monthly unstable branch thread.

Recent News

Notable Package Changes

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:

5 Likes

A post was split to a new topic: Plasma hangs on intel machine

A post was split to a new topic: Non-“modern mobile device” weirdness

2024-09-05T06:30:00Z

Todays update should be run from a TTY - at least if you are on Plasma - better safe than sorry, right?

The desktop was reset and I was logged out to displaymanager. I am fairly certain that if had I rebooted the system - I would have been toast.

I ensured consistency by switching to TTY - even if a pacman -Syu says nothing to do - I was fairly certain the kernel hooks had not run.

pacman -Qqn > pkgs.txt
sudo pacman -Syu - < pkgs.txt

Let the update finish in TTY - then reboot

1 Like

I don’t understand what that means. I am using Plasma and I just ran an update in a desktop-based GUI terminal without having seen your comment here, and the update seems to have worked without errors, but I haven’t yet rebooted, so I don’t know how screwed my system is. Can you elaborate on what the cause of what you’ve mentioned is and why it should need to be run from a TTY?

4 Likes

Then you should be OK - it may have been local to my system - if your desktop did not reset and thereby logging you off mid update session - then you should be OK.

My update did reset mid session - therefore I did the above - to ensure my system was not toast upon reboot.

1 Like

OK. That’s good general advice: if an update is interrupted mid-installation, it’s good to run pacman -Qqn | sudo pacman -Syu - and probably sudo mkinitcpio -P && sudo update-grub afterward from a TTY to guarantee a working system before rebooting.

I ran those just to be safe, rebooted, and everything works. I’m guessing it would have worked anyway since my update was not interrupted, but better safe than sorry.

3 Likes

Thats probably overkill but will do the job.
Just think about why it’s bad if an upgrade is interrupted: most probably because some package might only have been halfway installed (the one worked on when the interruption occurred) and more importantly the post installation hooks will not run.
If you’re on unstable and your package update list was small enough you could fix this by just reinstalling the current batch again - which will run their hooks (and should do the mkinitcpio and grub runs if necessary).

Yup, I agree. It’s probably not necessary, and I have no idea why @linux-aarhus’ update in particular was interrupted, but since they’re on the Manjaro team and they said “Today’s update should be run from a TTY” and stuff like that, I took extra caution. I’m thinking now that their issue was something unrelated that happened on their machine and would not have affected any other Manjaro users, but I wouldn’t want to risk it.

I tend to run sudo mkinitcpio -P && sudo update-grub manually now after big updates because there have been at least 3 times when the update system should have run them but didn’t and my system couldn’t boot any more. Overkill is better than underkill, which would make the system not be able to boot.

By the way, I’d never heard of this pacman -Qqn | sudo pacman -Syu - command and it led me to discover that I’d had both manjaro-xfce-settings and manjaro-kde-settings installed since my migration to KDE a while back, which was good to know. I’m not sure how I had both since they had a conflicting file owned by both packages, but it was easily solvable. I removed manjaro-xfce-settings and fresh-installed manjaro-kde-settings to have a consistent system in case of creating any new user accounts.

I had no way of knowing if this was specific to my system and the only reason I made the comment was to - hopefully - help others to avoid a toasted system - if the kernel went missing - that is - if they subscribe to the unstable announcement channel - if not then they could be :t_rex:'ed.

Technically it generates a list of native packages - I use a precautionary intermediate file - the piping does the same thing :slight_smile: without the file.

Calamares broken, wants libboost 1.83.0 unstable has 1.86.0 symlinking works. Then calamares can’t find a file it needs in 1.86.0 so still broken.

1 Like

Rebuilds are pushed. :package:

2 Likes

This really is stale news, but folks on wayland with old intel-gpus (i965 driver) your VA-API maybe broken with the latest libva - 2.22.0. downgrading only partially solved it for me, with functional acceleration on MPV but not in VLC. for further info refer;

5 posts were split to a new topic: Pacman 7conflicts with libpamac

Before anyone asks…

warning: /boot/grub/grub.cfg saved as /boot/grub/grub.cfg.pacsave

Yes, remove the useless grub.cfg.pacsave. That file should never have been backed up to begin with as it’s not a file that a user should ever manually edit.

❯ sudo cat /boot/grub/grub.cfg

#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
9 Likes

There is a new dependency for grub: libusbx but this is marked “obsolete”…
(and cannot be installed ==> “file not exists”

1 Like

It is listed in the optional dependencies, but yeah it’s weird it’s there considering it’s not available to be installed.

1 Like

Update with Pamac did not show this but after update boot fails at the grub prompt
AMD A6-3670 APU with Radeon HD Graphics
Type: Desktop Mobo: Gigabyte model: GA-A75M-S2V
Hybrid Bios. efi boot on a bios

1 Like

Fixed with grub 2.12-6 coming along shortly.

2 Likes

O.k. something new: something tries write acess to the SPD of my RAMs…
Using kernel 6.11.0-rc7-2 ( EXPERIMENTAL :innocent:) and branch unstable.
Not using kernel 6.10.9-2

Sep 11 16:37:14 kernel: ee1004 12-0053: probe with driver ee1004 failed with error -5
Sep 12 17:28:41 kernel: ee1004 12-0050: probe with driver ee1004 failed with error -5
----------------------------------------------------------------------------------------------
> sudo dmesg | grep ee1004                            
[    9.667562] ee1004 10-0052: 512 byte EE1004-compliant SPD EEPROM, read-only
[    9.669804] ee1004 10-0053: 512 byte EE1004-compliant SPD EEPROM, read-only
[    9.670434] ee1004 12-0050: probe with driver ee1004 failed with error -5
----------------------------------------------------------------------------------------------
> lsmod | grep ee1004                                 
ee1004                 16384  0
---------------------------------------------------------------------------------------------
>  sudo modprobe ee1004
   result: empty (loaded)
----------------------------------------------------------------------------------------------
> ls /sys/bus/i2c/drivers/ee1004/                     
10-0052  10-0053  bind  module  uevent  unbind
----------------------------------------------------------------------------------------------