For some packages when i try to install them i get an error like this (used sddm for example)
Running scriptlet: sddm-0.19.0-18.fc35.x86_64 1/1
groupadd: cannot open /etc/group
useradd: group 'sddm' does not exist
error: %prein(sddm-0.19.0-18.fc35.x86_64) scriptlet failed, exit status 6
Error in PREIN scriptlet in rpm package sddm
Verifying : sddm-0.19.0-18.fc35.x86_64 1/1
So pretend I’m a bit dense here … can you confirm you did sudo dnf install sddm, and you got the groupadd and useradd errors during that installation? It would appear that the package installation scriptlet was unable to add group ‘sddm’ due to permission errors, but that would seem unlikely when run under sudo. I’m unfamiliar with the *ddm packages, just read briefly about them a few minutes ago, and unfortunately won’t be able to try to replicate your issue for a few days, but I may be able to come up with some ideas.
Oh, and are you running into this type of issue with the other packages you’re trying to install, or is sddm and the /etc/group issue just one example of multiple disparate issues? From your other posts in this forum it would seem you’re pretty experienced, so this must be a more complex / subtle system issue. I’m looking for any commonality. Thanks
It would appear that the selinux context for /etc/group is incorrect.
In order to update the selinux context for all the files on your system manually you can so sudo restorecon / then wait for that to complete before you do anything more.
If instead you want to do it when you next boot you can do sudo touch /.autorelabel and the next time you reboot it will relabel all the files on the system with the proper context. It may take some time and the boot may seem really slow if there is a lot to do.
You could temporarily disable selinux with sudo setenforce 0, try the installation again, then turn selinux back on with sudo setenforce 1, if you want to verify this is the culprit. You might reference Find if permission denied errors are caused by SELinux for selinux debugging techniques.
Suspicion at this point is that a prior installation or selinux configuration messed this up for you, so if the temporary disabling verifies your issue, seems you’d want to look at your system’s history for clues.
An old bug report for RHEL7, 1333952 – Wrong SELinux label on /etc/group after installation, showed an issue related to a missing /etc/selinux/config corrupting /etc/group permissions, and the workaround was sudo restorecon -rv /etc.
Group effort, glad it is resolved. Please mark it as solved so that others can reference this if they encounter something similar. And if you find what caused this, post the info here for others. Thanks
Just as an aside but related.
There have been a few posts lately about similar issues that have been traced back to some changes in selinux policies where the package upgrade did not also update the file contexts. That meant that file context was not synced with the policy and caused problems.
On almost all (my system included) the fix was to use sudo restorecon -rv / or all or for some smaller portion of the file system