Red Hat Bugzilla – Bug 618652
libvirt does not install
Last modified: 2010-08-17 08:29:11 EDT
Description of problem:
I try to install libvirt with yum but it does not work:
Error in PREIN scriptlet in rpm package libvirt-0.8.2-1.fc13.x86_64
useradd: group 'kvm' does not exist
error: %pre(libvirt-0.8.2-1.fc13.x86_64) scriptlet failed, exit status 6
error: install: %pre scriptlet failed (2), skipping libvirt-0.8.2-1.fc13
Steps to Reproduce:
1. yum install libvirt
2. The installation fails
The same happens if I install the Virtualization group:
yum groupinstall Virtualization
Created attachment 436232 [details]
List of installed rpm (from rpm -qa)
I have attached the list of installed rpms in the machine, just in case that it helps to troubleshoot the problem.
I would like to increase the severity to high, since it is a critical bug in our platform. However it seems that I don't have permissions to raise the severity.
The 'libvirt' RPM contains a %pre script to create all these accounts, in case your 'setup' RPM hasn't already created them. Something on your system must be preventing this from working, becasue I've verified that this %pre script is correctly creating accounts. Please try running the following manually
getent group kvm >/dev/null || groupadd -g 36 -r kvm
getent group qemu >/dev/null || groupadd -g 107 -r qemu
getent passwd qemu >/dev/null || \
useradd -r -u 107 -g qemu -G kvm -d / -s /sbin/nologin \
-c "qemu user" qemu
The problem is that we are using NIS for the accounts. Group id 36 is already claimed by a NIS group.
I have created the kvm group with gid 37 (getent group kvm >/dev/null || groupadd -g 37 -r kvm) and the installation went through sucesfully. virt-manager seems to connect to libvirt, so everything seems to be ok.
Could it be possible that there is an alternative gid for kvm so that if the default (36) exists there is a fallback solution?
Thank you very much for the support!
I don't think there is any way around this problem. Libvirt is required to use these designated GID/UIDs, since those are what are reserved for us in the 'setup' RPM's default /etc/passwd & /etc/group files. Ordinarily this would not be a problem because those values would have been setup by anaconda during your initial OS install. We only hit a problem here because the GA release of F13 didn't have those values reserved.