[Testing Update] 2023-03-25 - Kernels, Firefox, Deepin, GNOME, NVIDIA, Wine

Are you fully up to date? I thought we fixed that.

Either way, it can be safely removed manually:

sudo rm /etc/mkinitcpio.d/linux60.preset
2 Likes

I don’t think that this is very clear wording for people who have not studied the packaging of nvidia-utils, as is evident from the confusion in this thread. A more clear way to put it might be:

nvidia-settings has been decoupled from nvidia-utils into its own package. nvidia-settings will be available for installation after you have updated nvidia-utils, as it is considered part of nvidia-utils until you have updated.

2 Likes

Problem solved, I installed nvidia 530 settings.

Yes, I edited my reply. :wink:

How’s this?

1 Like

Yes that does help a little. I think it could still use a mention that you won’t be able to find nvidia-settings in your package manager until you update nvidia-utils, as that is the main confusion people are having.

Right. Before updating, it didn’t exist and you already had the binary version as part of nvidia-utils. :wink:

Yes, that makes sense. My point is that a lot of people aren’t going to connect those dots without a bit of prodding, especially once this hits stable branch

It is a little strange, but plymouth (automatically installed during initial installation) was marked as orphan after this upgrade. My regular ‘pamac remove -o’ removed it. The update itself removed gdm-plymouth and dependencies and replaced it by gdm (maybe that’s how plymouth became an orphan?).

All this slipped my attention, so a later mkinitcpio (I have plymouth hooks in the config) failed (again unnoticed) and wrecked my system.

A gigantic lot of own stupidity, and everything repaired now. But I thought I mention it. It seems that something happened during the upgrade.

Indeed. One can either install plymouth-theme-manjaro (or any other Plymouth theme) and it won’t be an orphan or plymouth can be removed if it is not desired by the user. Note that plymouth-theme-manjaro is installed by default on all official ISOs.

Explanation:

We now have a temporary gdm overlay with Plymouth support instead of the separate gdm-plymouth package which had previously accomplished the same thing.

That means we are temporarily packaging gdm instead of importing it directly from Arch like most packages. Arch has recently imported plymouth into their community repo from the AUR with 580 votes. They should be enabling Plymouth support soon, hence why the overlay is only temporary.

2 Likes

I had the same messages, thanks for the cleanup steps @Yochanan !

zfs module for kernel 6.2 won’t load…

If you use ZFS on external disks:

Or wait for the new release of OpenZFS

Nothing like that, compilation problem, kernel and module dont’ match, symbol error.
6.1 loads fine…

Yes, stay LTS if it’s ZFS compatible and you don’t need features/improvement and new device support on new kernel versions in the future.

2 Likes

Hi Tefter, join the club … Developers are working on it. I went back to 6.1
On arch the 6.2.8-1-cachyos kernel kept the pool working for me.

More information on

https://aur.archlinux.org/packages/zfs-dkms

1 Like

A post was split to a new topic: Gpg: packet with unknown version 252

A post was merged into an existing topic: Gpg: packet with unknown version 252

Regarding the nvidia-settings splitout from nvidia-uitls there is an ongoing discussion: [pci] add nvidia-settings, nvidia-470xx-settings, nvidia-390xx-settings (!17) · Merge requests · Applications / mhwd-db · GitLab. Yes from a users point of view we managed to remove some piece of software which was installed before and you’re used to it. Having the option to have a headless install is not wanted in most cases.

The MHWD profile update will install nvidia-settings on new systems but it seems not on existing installations. So we can now add nvidia-settings as a hard dependecy of nvidia-utils, even it might be the wrong build order and loose the headless option, which we avoid anyway due a hard dependency on mhwd profiles, or revert back to the binary versions.

Manjaro is not Arch and sometimes we should not follow what they do. You as a user will have a binary in the end anyway. It is nice to see that there is now the source code available for review.

Some may know the manjaro-system package: Commits · master · Packages / Core / manjaro-system · GitLab We hardly update it the last years as some projects like https://manjarno.snorlax.sh/ you can find under Miscellaneous a comment why a remove of the pacman database lock might be a bad idea. Here is why we had that in the past. Arch had the sync first option, which we still patch into our alpm. With that we are able to install specific packages before an update happens. With our hacks we try to automate the manual needed inventions so you simply hit update and magic happens. A simple if nvidia-utils is under version without nvidia-settings then install it would help here so you won’t even notice that there was a technical split. Now you can argue if a controlled removal of the pacman database lock makes sense or not. So far we didn’t found a better solution to invade a running update process to seed manual tasks into it. The mentioned security issue was fixed a long time btw.

Technically there is now extra added workload for packaging the stuff as in one existing package that binary got removed and in an also existing package it changed to a split package. Whoever maintains the package updates of nvidia drivers doesn’t have extra workload.

The only thing what is missing here is a proper way for existing installs to get nvidia-settings installed without user intervention. Not everyone is reading those update announcements. Based on the installed systems with Manjaro only a fraction of our user base have even a forum account or may read it as a guest.

4 Likes