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.
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?
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.
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.
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 'ed.
Technically it generates a list of native packages - I use a precautionary intermediate file - the piping does the same thing without the file.
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;
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
#
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
O.k. something new: something tries write acess to the SPD of my RAMs…
Using kernel 6.11.0-rc7-2 ( EXPERIMENTAL ) and branch unstable.
Not using kernel 6.10.9-2