Cant install some packages

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 

Failed:
  sddm-0.19.0-18.fc35.x86_64                       

anyone know how to fix this?

Are you running dnf as root? or using sudo? If not a regular user cannot write the data during the update.

running as root, i would have gotten an error saying i didnt have permission other wise, like this

dnf in sddm

Error: This command has to be run with superuser privileges (under the root user on most systems).

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

1 Like
sudo dnf install sddm
...
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                        1/1 
  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 

Failed:
  sddm-0.19.0-18.fc35.x86_64                                                    

Error: Transaction failed

also with chrome remote desktop

total                                           7.8 MB/s |  15 MB     00:01     
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Running scriptlet: chrome-remote-desktop-99.0.4844.84-1.fc35.x86_64       1/1 
  Preparing        :                                                        1/1 
  Running scriptlet: chrome-remote-desktop-99.0.4844.84-1.fc35.x86_64       1/1 
groupadd: cannot open /etc/group
error: %prein(chrome-remote-desktop-99.0.4844.84-1.fc35.x86_64) scriptlet failed, exit status 10

Error in PREIN scriptlet in rpm package chrome-remote-desktop
  Verifying        : chrome-remote-desktop-99.0.4844.84-1.fc35.x86_64       1/1 

Failed:
  chrome-remote-desktop-99.0.4844.84-1.fc35.x86_64                              

Error: Transaction failed

What are the permissions on /etc/group? What is the output of ls -laZ /etc/group?

2 Likes

I found this on a old unofficial french fedora forum topic :

sudo setenforce 0   # temporarily disable selinux
sudo dnf clean expire-cache  
sudo dnf update selinux-policy\*
sudo setenforce 1   # enable selinux

Source: [Résolu] Error in PREIN scriptlet in rpm package / [Anciennes versions] Support général / Fedora-Fr - Communauté francophone Fedora - Linux see mongos answer.
Sorry it is french… but i did put the answer in a translater.

I even made it on my machine. But as i do not have the problem the selinux-policy* not updated.

heres the output

-rw-r--r--. 1 root root unconfined_u:object_r:etc_t:s0 1027 Apr 26 22:29 /etc/group

this did not do anything to my knowledge i ran the install again and i got the same error

Mine is -rw-r--r--. 1 root root system_u:object_r:passwd_file_t:s0 971 Apr 10 11:16 /etc/group . Try sudo restorecon /etc/group.

I did that and nothing changed

Did SELinux context of the /etc/group file changed to system_u:object_r:passwd_file_t:s0 or stayed the same (unconfined_u:object_r:etc_t:s0)?

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.

1 Like

Stayed the same (unconfined_u:object_r:etc_t:s0)

After doing sudo setenforce 0 I installed without issue, so it was definitely a SELinux issue and doing sudo restorecon -rv /etc fixed the issue! Thank you so much.

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

1 Like

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

2 Likes