I agree with the dependency between two Linux installations.
I disagree with the dependency between the installed kernels.
It is likely to be the grub configuration that is causing the issues.
Installing a new Kernel on system1 without updating the correct grub config that is loaded in UEFI , as this is maintained through system2 … this could be the issue.
Look if you have 2 efi partitiones and figure out what efi partition is the prime one and managed through what linux installation
5 posts were split to a new topic: Questions about UEFI and file permissions
I had a random instance of Plasmashell eating up a massive amount of ram and swap overnight after this update yesterday. 32gb of ram + 12gb of swap.
I will keep an eye on things and try to investigate what happened. It might just be a once off, I am only posting so if others see it, we can pool data.
Just noticed my GPU isn’t reporting sensor information; I’m 99% sure it was prior to this update but I can’t get it to report despite re-running sensors-detect.
sensors shows:
amdgpu-pci-0100
Adapter: PCI adapter
vddgfx: N/A
edge: N/A (crit = +89.0°C, hyst = -273.1°C)
ERROR: Can't get value of subfeature power1_cap: Can't read
PPT: N/A (cap = 0.00 W)
sclk: N/A
mclk: N/A
inxi -G:
Graphics:
Device-1: Intel HD Graphics 630 driver: i915 v: kernel
Device-2: Advanced Micro Devices [AMD/ATI] Polaris 22 XL [Radeon RX Vega
M GL] driver: amdgpu v: kernel
Device-3: Realtek Integrated_Webcam_HD driver: uvcvideo type: USB
Display: wayland server: X.org v: 1.21.1.21 with: Xwayland v: 24.1.9
compositor: kwin_wayland driver: X: loaded: amdgpu,modesetting
dri: iris,radeonsi gpu: i915 resolution: 2560x1440~60Hz
API: EGL v: 1.5 drivers: iris,radeonsi,swrast
platforms: gbm,wayland,x11,surfaceless,device
API: OpenGL v: 4.6 compat-v: 4.5 vendor: intel mesa v: 25.3.3-arch1.1
renderer: Mesa Intel HD Graphics 630 (KBL GT2)
API: Vulkan v: 1.4.335 drivers: intel,radv surfaces: N/A
Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo
de: kscreen-console,kscreen-doctor wl: wayland-info
x11: xdpyinfo, xprop, xrandr
Will report this on lm-sensors github issues also but since sensors wasn’t updated I guess it’s likely the GPU drivers or mesa???
Once again, pamac GUI crashed and disappeared while the update continued running in background. This has been mentioned before: Pamac-cli and pamac-manager unreliable
Could this potentially happen because I had uninstalled packagekit and packagekit-qt5 and packagekitd years ago? I’ll mention this on that thread.
I highly doubt it, since I don’t have those installed:
$ pamac search --installed packagekit
But I never use the GUI, so cannot say for certain…but, once again, I highly doubt it.
I can confirm Merlin’s assessment.
I have a similar setup.
first OS installed was Manjaro, during this setup boot/efi partition was made. Manjaro set up its own grub as usual, but being the only OS at that time it was not showing up as an actual menu during the boot process. from time to time updates required the update-grub procedure. during kernel updates manjaro did seem to manage update of the grub entries itself.
as a second OS I installed Fedora a while later. this means the fedora-managed Grub boot menu took over, showing three Fedora kernels and the installed Manjaro kernels. (I also found that the manjaro os-prober did not recognise the fedora installation at that time, hence no entry in the Manjaro Grub).
that meant, every time a kernel update or a gub update on the manjaro side was made, I needed to update the FEDORA grub, in order to catch these changes and show the new entries in the boot menu.
I think this is similar to your situation @Jaco.
You could check if you can update the grub entries in your second installation.
as far as I see it the actual kernels and driver employments are independent in each of the installed OS. they simply share the boot menu, but one of the installed OS is in charge of keeping the entries up-todate. In order to do this, it needs to know that the other OS has been updated. that is basically what a os-prober run or a update-grub routine is doing.
I am also still a newbie, please correct me in case I said something wrong.
Right on the nail! @SpuckIgel…That is exactly my present set-up and what I was up against and came to realise just a couple of hours after my first post here on this topic, where updating the kernel on the new GRUB fixed that issue immediately.
The latest grub install takes over and needs to be updated to the latest kernel too, for the older OS install to boot when its standing kernel has become obsolete and a new one is part of its update routine… I’m reiterating what you’ve just described in my own words.
I learn as I go, and there’s something new to learn everyday of the year, isn’t there?
I’m sure your well articulated observation, will help a lot folks who may be trying out this kind of double OS set-up for the first time.
You could try Refind, which automagically finds OSes. I have both, Grub and Refind. I just set timer to 2 secs on each (to cut down on boot-time), and changed default boot option on Refind to Manjaro. Refind menu shows up first, then Manjaros Grub menu. Could also just use Refind alone.
For Refind, I set “default selection ” inside /boot/efi/EFI/refind/refind.conf
Refind starts counting from 1. So 1st option is number 1. And “timeout 2”
Another option would be to update the GRUB menu on the “other” partition using chroot.
sudo mount /dev/otherroot /mnt
sudo mount -B /run /mnt/run
sudo mount -B /sys /mnt/sys
sudo mount -B /dev /mnt/dev
sudo mount -B /proc /mnt/proc
sudo chroot /mnt update-grub
sudo umount /mnt/run
sudo umount /mnt/sys
sudo umount /mnt/dev
sudo umount /mnt/proc
sudo umount /mnt
This assumes /etc/default/grub on the other root partition has:
GRUB_DISABLE_OS_PROBER=false
Unfortunately, this issue seems to persist for over half a year now. It’s been reported on Github.
At this point, I suggest the same thing as the Stable branch - BIG update BEST practice: Run updates from the terminal
Unfortunately, that post recommends using the terminal tools, including pamac (AKA pamac-cli). But that is also unreliable. The most stable alternative is to skip pamac and just go for pacman. (Or, as some people suggest, octopi GUI, but I haven’t tried it yet.)
For the Polkit issue, none of the ‘fixes’ actually work (I didn’t try to disable Polkit Agent as it defeats fixing anything, if you disable it). I had to switch the kernel to version 6.12 or above for the affected computers (then the journal errors about Pidfd not supported on this platform, disable polkit-agent-helper.socket and use setuid helper disappears). Not sure how the provided fixes helped others, maybe there are various Polkit issues. I added the note to the wiki post.
@omano most likely your issue is die to Drop setuid bit from polkit-agent-helper-1 binary (#5) · Issues · Arch Linux / Packaging / Packages / polkit · GitLab See also Pidfd not supported on this platform, disable polkit-agent-helper.socket and use setuid helper Polkit auth broken after update (Pidfd not supported on kernel 5.15)
7 posts were split to a new topic: Black screen after updating plymouth-theme-manjaro
I’m having an issue with screen flickering after upgrading to nvidia 590 from 575, which is the same issue I had going to nvidia 580.
I run Manjaro i3 (kernel 618) on a Ryzen 7 7300X3D with 128 GB RAM, nvidia RTX 4060 using the proprietary drivers. It is so bad with some apps like urxvt, pcmanfm, ranger etc that it renders the desktop unusable. Is there another fix other than deprecating to 575 again?
Let’s reverse that question: is there a reason why you would not want to use the 575 driver?
I use the 575xx series without a problem. So, 
I don’t think there’s a difference to the average person, really.
I want to be able to update to the latest nvidia driver.
Here’s what I found:
And surely enough, turning picom off seems to get rid of the flickering. It also messes up my conky transparency and transparent terminal windows. Any suggestions? Maybe this is just a picom problem and a different compositor would work better? I’m running i3.
On polkit issue, I think there is a typo, or is not very clear. On reply from discobot:
fixing the suid permissions manually with
sudo chmod 755 /usr/lib/polkit-1/polkitd /usr/lib/polkit-1/polkit-agent-helper-1
and then, a little further down:
sudo chmod 4755 /usr/lib/polkit-1/polkit-agent-helper-1
This was not very clear to me (polkit-agent-helper-1 is repeated twice but with two different permissions), and I followed the first command.
After some days of work to resolve issue without success, I found that the correct one for me, is the second one (chmod 4755).
`