Hello,
'yum update' runs into the following error message.
Package libuser-devel-0.54.7-2.1.el5_5.2.i386.rpm is not signed
regards Olaf
On 21/04/11 5:26 AM, Olaf Mueller wrote:
Hello,
'yum update' runs into the following error message.
Package libuser-devel-0.54.7-2.1.el5_5.2.i386.rpm is not signed
I got this too, there's two ways around it:
1) Wait until the package is signed and then update.
2) Run: yum update --nogpgcheck
Regards, Ben
'yum update' runs into the following error message.
Package libuser-devel-0.54.7-2.1.el5_5.2.i386.rpm is not signed
I got this too, there's two ways around it:
Wait until the package is signed and then update.
Run: yum update --nogpgcheck
Other workarounds for this particular issue have just been suggested here: http://lists.centos.org/pipermail/centos/2011-April/110547.html http://lists.centos.org/pipermail/centos/2011-April/110551.html
On 04/21/2011 01:04 AM, Mathieu Baudier wrote:
'yum update' runs into the following error message.
Package libuser-devel-0.54.7-2.1.el5_5.2.i386.rpm is not signed
I got this too, there's two ways around it:
Wait until the package is signed and then update.
Run: yum update --nogpgcheck
Other workarounds for this particular issue have just been suggested here: http://lists.centos.org/pipermail/centos/2011-April/110547.html http://lists.centos.org/pipermail/centos/2011-April/110551.html
This issue has been taken care of on all the CentOS mirrors about 10 hours ago.
On 04/21/2011 09:26 AM, Johnny Hughes wrote:
Other workarounds for this particular issue have just been suggested here: http://lists.centos.org/pipermail/centos/2011-April/110547.html http://lists.centos.org/pipermail/centos/2011-April/110551.html
I find it strange that people are making such recommendations. A non verifyable signature is a MASSIVE deal. Working 'around' that is to stop doing what you are doing, and not do any package centric operation till the issue is fixed and resolved in an acceptable manner.
- KB
On Thu, 21 Apr 2011, Karanbir Singh wrote:
On 04/21/2011 09:26 AM, Johnny Hughes wrote:
Other workarounds for this particular issue have just been suggested here: http://lists.centos.org/pipermail/centos/2011-April/110547.html http://lists.centos.org/pipermail/centos/2011-April/110551.html
I find it strange that people are making such recommendations. A non verifyable signature is a MASSIVE deal. Working 'around' that is to stop doing what you are doing, and not do any package centric operation till the issue is fixed and resolved in an acceptable manner.
It's all too often the advice you'll see. On Spacewalk, the standard response to dealing with unsigned (or signed with an unimported key) is to disable all gpg checks. It's cringeworthy, and wrong on so many levels.
jh
After the upgrade, my VMs stopped loading. Found others with the problem and followed the guidance to use virsh to dump the xml file of the VM, undefine the VM, edit the xml file to change 'raw' to 'qcow2', redefine the VM from the edited xml, and restart the machine. I still get the following error when I try to start the VM:
redlibvirtError: internal error Process exited while reading console log output: qemu: could not open disk image /dev/hda
A libvirt update came in last night, so I was hoping the update would allow libvirt to automatically recognize the type of image file (as previous versions did). Nope.
Any other thoughts?
Dave M
On 04/21/2011 06:11 AM, David McGuffey wrote:
After the upgrade, my VMs stopped loading. Found others with the problem and followed the guidance to use virsh to dump the xml file of the VM, undefine the VM, edit the xml file to change 'raw' to 'qcow2', redefine the VM from the edited xml, and restart the machine. I still get the following error when I try to start the VM:
redlibvirtError: internal error Process exited while reading console log output: qemu: could not open disk image /dev/hda
You should not need to do anything in virsh to dump a file ... there should be an xml file in /etc/libvirt/qemu/ for every VM already. In that file, you need to go to the "<disk type='file' device='disk'>" section and look for a line that says:
<driver name='qemu' type='raw' cache='none'/>
and change it to
<driver name='qemu' type='qcow2' cache='none'/>
(the cache might be different, but you can leave it alone)
The key is to change the type=raw to type=qcow2
2011/4/21 Johnny Hughes johnny@centos.org:
On 04/21/2011 06:11 AM, David McGuffey wrote:
redlibvirtError: internal error Process exited while reading console log output: qemu: could not open disk image /dev/hda
You should not need to do anything in virsh to dump a file ... there should be an xml file in /etc/libvirt/qemu/ for every VM already.
The XML-files in /etc/libvirt/qemu represent libvirt defined VMs, you should never edit these files directly while the libvirtd service is running. You should either use 'virsh edit [vm_name]' or alternatively virsh dump followed by virsh define. If you edit the file directly while some manager is running (like virt-manager in CentOS), your changes will most likely conflict with, or get overwritten by, virt-manager. Nothing critical should happen, but I don't see any reason for encouraging doing it The Wrong Way(TM).
Best regards Kenni
On 04/21/2011 11:01 AM, Kenni Lund wrote:
2011/4/21 Johnny Hughes johnny@centos.org:
On 04/21/2011 06:11 AM, David McGuffey wrote:
redlibvirtError: internal error Process exited while reading console log output: qemu: could not open disk image /dev/hda
You should not need to do anything in virsh to dump a file ... there should be an xml file in /etc/libvirt/qemu/ for every VM already.
The XML-files in /etc/libvirt/qemu represent libvirt defined VMs, you should never edit these files directly while the libvirtd service is running. You should either use 'virsh edit [vm_name]' or alternatively virsh dump followed by virsh define. If you edit the file directly while some manager is running (like virt-manager in CentOS), your changes will most likely conflict with, or get overwritten by, virt-manager. Nothing critical should happen, but I don't see any reason for encouraging doing it The Wrong Way(TM).
OK ... I just turn off libvirtd and edit the file, then restart libvirtd and start the VM.
I am an old school SysIII unix admin, so I just edit files by hand all the time.
If it is wrong, then I guess doing it right is OK. Though dumping and importing seem much harder than vi to me.
On Thu, Apr 21, 2011 at 12:10 PM, Johnny Hughes johnny@centos.org wrote:
On 04/21/2011 11:01 AM, Kenni Lund wrote:
The XML-files in /etc/libvirt/qemu represent libvirt defined VMs, you should never edit these files directly while the libvirtd service is running. You should either use 'virsh edit [vm_name]' or alternatively virsh dump followed by virsh define. If you edit the file directly while some manager is running (like virt-manager in CentOS), your changes will most likely conflict with, or get overwritten by, virt-manager. Nothing critical should happen, but I don't see any reason for encouraging doing it The Wrong Way(TM).
OK ... I just turn off libvirtd and edit the file, then restart libvirtd and start the VM.
I am an old school SysIII unix admin, so I just edit files by hand all the time.
I hear you :-D
If it is wrong, then I guess doing it right is OK.
If what I have seen/read is correct, 'virsh edit' has an additional feature. It will check for errors upon exit. So, it's much like visudo (versus vi).
When you move kvm guests across different platforms (for example Fedora to CentOS), editing config files using 'virsh edit' will help. In this case, you will be running 'virsh define' which may also have a checking mechanism (not quite sure about this though).
Akemi
On Thu, 2011-04-21 at 18:01 +0200, Kenni Lund wrote:
2011/4/21 Johnny Hughes johnny@centos.org:
On 04/21/2011 06:11 AM, David McGuffey wrote:
redlibvirtError: internal error Process exited while reading console log output: qemu: could not open disk image /dev/hda
You should not need to do anything in virsh to dump a file ... there should be an xml file in /etc/libvirt/qemu/ for every VM already.
The XML-files in /etc/libvirt/qemu represent libvirt defined VMs, you should never edit these files directly while the libvirtd service is running. You should either use 'virsh edit [vm_name]' or alternatively virsh dump followed by virsh define. If you edit the file directly while some manager is running (like virt-manager in CentOS), your changes will most likely conflict with, or get overwritten by, virt-manager. Nothing critical should happen, but I don't see any reason for encouraging doing it The Wrong Way(TM).
Best regards Kenni
Problem may be an SELinux problem. Here is the alert. Notice the reference to '/dev/hda' (which is the virtual machine boot disk), and the SELinux context 'virt_content_t'
I'm going to create /.autorelable and reboot to ensure the upgrade properly relabled the filesystems.
Summary:
SELinux is preventing pam_console_app (pam_console_t) "getattr" to /dev/hda (virt_content_t).
Detailed Description:
SELinux denied access requested by pam_console_app. It is not expected that this access is required by pam_console_app and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access.
Allowing Access:
Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for /dev/hda,
restorecon -v '/dev/hda'
If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package.
Additional Information:
Source Context system_u:system_r:pam_console_t:SystemLow- SystemHigh Target Context system_u:object_r:virt_content_t Target Objects /dev/hda [ blk_file ] Source pam_console_app Source Path /sbin/pam_console_apply Port <Unknown> Host desk@mydomain.net Source RPM Packages pam-0.99.6.2-6.el5_5.2 Target RPM Packages Policy RPM selinux-policy-2.4.6-300.el5 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name desk@mydomain.net Platform Linux desk@mydomain.net 2.6.18-238.9.1.el5 #1 SMP Tue Apr 12 18:10:13 EDT 2011 x86_64 x86_64 Alert Count 48 First Seen Wed 13 Apr 2011 08:41:32 AM EDT Last Seen Thu 21 Apr 2011 07:05:23 AM EDT Local ID 9ee6c9a9-3eda-4082-84d3-5741ea9ff688 Line Numbers
Raw Audit Messages
host= desk@mydomain.net type=AVC msg=audit(1303383923.130:356): avc: denied { getattr } for pid=15025 comm="pam_console_app" path="/dev/hda" dev=tmpfs ino=6206 scontext=system_u:system_r:pam_console_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_content_t:s0 tclass=blk_file
host= desk@mydomain.net type=SYSCALL msg=audit(1303383923.130:356): arch=c000003e syscall=4 success=no exit=-13 a0=7fff2014b170 a1=7fff2014b1a0 a2=7fff2014b1a0 a3=18cba490 items=0 ppid=15014 pid=15025 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="pam_console_app" exe="/sbin/pam_console_apply" subj=system_u:system_r:pam_console_t:s0-s0:c0.c1023 key=(null)
Dave M
On Thu, 2011-04-21 at 21:09 -0400, David McGuffey wrote:
On Thu, 2011-04-21 at 18:01 +0200, Kenni Lund wrote:
2011/4/21 Johnny Hughes johnny@centos.org:
On 04/21/2011 06:11 AM, David McGuffey wrote:
redlibvirtError: internal error Process exited while reading console log output: qemu: could not open disk image /dev/hda
You should not need to do anything in virsh to dump a file ... there should be an xml file in /etc/libvirt/qemu/ for every VM already.
The XML-files in /etc/libvirt/qemu represent libvirt defined VMs, you should never edit these files directly while the libvirtd service is running. You should either use 'virsh edit [vm_name]' or alternatively virsh dump followed by virsh define. If you edit the file directly while some manager is running (like virt-manager in CentOS), your changes will most likely conflict with, or get overwritten by, virt-manager. Nothing critical should happen, but I don't see any reason for encouraging doing it The Wrong Way(TM).
Best regards Kenni
Problem may be an SELinux problem. Here is the alert. Notice the reference to '/dev/hda' (which is the virtual machine boot disk), and the SELinux context 'virt_content_t'
I'm going to create /.autorelable and reboot to ensure the upgrade properly relabled the filesystems.
Summary:
SELinux is preventing pam_console_app (pam_console_t) "getattr" to /dev/hda (virt_content_t).
Detailed Description:
SELinux denied access requested by pam_console_app. It is not expected that this access is required by pam_console_app and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access.
Allowing Access:
Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for /dev/hda,
restorecon -v '/dev/hda'
Yep...each time I try to start the VM, sealert increments this error by one.
I created /.autorelable and rebooted. SELinux relabeled everything, but the sealert still fires when I try to start the VM.
I did a qemu-img <path_to_vm>/vm.img and the format is declared 'raw' Therefore I should not be editing the vm.xml file and changing 'raw' to 'qcow2'
Problem is definately with the SELlnux labels in the 5.6 upgrade.
Dave M
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/21/2011 09:47 PM, David McGuffey wrote:
On Thu, 2011-04-21 at 21:09 -0400, David McGuffey wrote:
On Thu, 2011-04-21 at 18:01 +0200, Kenni Lund wrote:
2011/4/21 Johnny Hughes johnny@centos.org:
On 04/21/2011 06:11 AM, David McGuffey wrote:
redlibvirtError: internal error Process exited while reading console log output: qemu: could not open disk image /dev/hda
You should not need to do anything in virsh to dump a file ... there should be an xml file in /etc/libvirt/qemu/ for every VM already.
The XML-files in /etc/libvirt/qemu represent libvirt defined VMs, you should never edit these files directly while the libvirtd service is running. You should either use 'virsh edit [vm_name]' or alternatively virsh dump followed by virsh define. If you edit the file directly while some manager is running (like virt-manager in CentOS), your changes will most likely conflict with, or get overwritten by, virt-manager. Nothing critical should happen, but I don't see any reason for encouraging doing it The Wrong Way(TM).
Best regards Kenni
Problem may be an SELinux problem. Here is the alert. Notice the reference to '/dev/hda' (which is the virtual machine boot disk), and the SELinux context 'virt_content_t'
I'm going to create /.autorelable and reboot to ensure the upgrade properly relabled the filesystems.
Summary:
SELinux is preventing pam_console_app (pam_console_t) "getattr" to /dev/hda (virt_content_t).
Detailed Description:
SELinux denied access requested by pam_console_app. It is not expected that this access is required by pam_console_app and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access.
Allowing Access:
Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for /dev/hda,
restorecon -v '/dev/hda'
Yep...each time I try to start the VM, sealert increments this error by one.
I created /.autorelable and rebooted. SELinux relabeled everything, but the sealert still fires when I try to start the VM.
I did a qemu-img <path_to_vm>/vm.img and the format is declared 'raw' Therefore I should not be editing the vm.xml file and changing 'raw' to 'qcow2'
Problem is definately with the SELlnux labels in the 5.6 upgrade.
Dave M
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
This is an SELinux issue. It really has no effect on the virtual machine. The problem is the label is not something pam_console policy expected to have on a blk device.
On Fri, 2011-04-22 at 06:18 -0400, Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/21/2011 09:47 PM, David McGuffey wrote:
On Thu, 2011-04-21 at 21:09 -0400, David McGuffey wrote:
On Thu, 2011-04-21 at 18:01 +0200, Kenni Lund wrote:
2011/4/21 Johnny Hughes johnny@centos.org:
On 04/21/2011 06:11 AM, David McGuffey wrote:
redlibvirtError: internal error Process exited while reading console log output: qemu: could not open disk image /dev/hda
Problem may be an SELinux problem. Here is the alert. Notice the reference to '/dev/hda' (which is the virtual machine boot disk), and the SELinux context 'virt_content_t'
Summary:
SELinux is preventing pam_console_app (pam_console_t) "getattr" to /dev/hda (virt_content_t).
...
Detailed Description:
SELinux denied access requested by pam_console_app. It is not expected that this access is required by pam_console_app and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access.
...
Yep...each time I try to start the VM, sealert increments this error by one.
I created /.autorelable and rebooted. SELinux relabeled everything, but the sealert still fires when I try to start the VM.
I did a qemu-img <path_to_vm>/vm.img and the format is declared 'raw' Therefore I should not be editing the vm.xml file and changing 'raw' to 'qcow2'
Problem is definately with the SELlnux labels in the 5.6 upgrade.
Dave M
...
This is an SELinux issue. It really has no effect on the virtual machine. The problem is the label is not something pam_console policy expected to have on a blk device.
Yes, I was lured by the coincidence of the sealert and my effort to start the VM. The fact that the blk device in question happens to register as /dev/hda and the VM also uses an internal "virtual" device called /dev/hda can lead one astray.
I'm still left without an answer as to why virsh won't create or define-->start a VM after the upgrade.
[root@desk dev]# cd /etc/libvirt/qemu
[root@desk qemu]# virsh create Win7-base.xml error: Failed to create domain from Win7-base.xml error: internal error Process exited while reading console log output: qemu: could not open disk image /dev/hda
using qemu-img against the image file reports 'raw' not 'qcow2' So...I should not have to edit the .xml file...it is already correct.
[root@desk images]# qemu-img info Win7-base.img image: Win7-base.img file format: raw virtual size: 29G (31457280000 bytes) disk size: 29G
This is not good. I've been developing a prototype which uses several VMs under qemu-kvm. I'm now starting to question whether CentOS is the right tool to be using for prototyping capability that may eventually roll onto regular RHEL.
Dave M
On Fri, 2011-04-22 at 06:50 -0400, David McGuffey wrote:
On Fri, 2011-04-22 at 06:18 -0400, Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/21/2011 09:47 PM, David McGuffey wrote:
On Thu, 2011-04-21 at 21:09 -0400, David McGuffey wrote:
On Thu, 2011-04-21 at 18:01 +0200, Kenni Lund wrote:
2011/4/21 Johnny Hughes johnny@centos.org:
On 04/21/2011 06:11 AM, David McGuffey wrote: > redlibvirtError: internal error Process exited while reading console log > output: qemu: could not open disk image /dev/hda
Problem may be an SELinux problem. Here is the alert. Notice the reference to '/dev/hda' (which is the virtual machine boot disk), and the SELinux context 'virt_content_t'
Summary:
SELinux is preventing pam_console_app (pam_console_t) "getattr" to /dev/hda (virt_content_t).
...
Detailed Description:
SELinux denied access requested by pam_console_app. It is not expected that this access is required by pam_console_app and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access.
...
Yep...each time I try to start the VM, sealert increments this error by one.
I created /.autorelable and rebooted. SELinux relabeled everything, but the sealert still fires when I try to start the VM.
I did a qemu-img <path_to_vm>/vm.img and the format is declared 'raw' Therefore I should not be editing the vm.xml file and changing 'raw' to 'qcow2'
Problem is definately with the SELlnux labels in the 5.6 upgrade.
Dave M
...
This is an SELinux issue. It really has no effect on the virtual machine. The problem is the label is not something pam_console policy expected to have on a blk device.
Yes, I was lured by the coincidence of the sealert and my effort to start the VM. The fact that the blk device in question happens to register as /dev/hda and the VM also uses an internal "virtual" device called /dev/hda can lead one astray.
I'm still left without an answer as to why virsh won't create or define-->start a VM after the upgrade.
[root@desk dev]# cd /etc/libvirt/qemu
[root@desk qemu]# virsh create Win7-base.xml error: Failed to create domain from Win7-base.xml error: internal error Process exited while reading console log output: qemu: could not open disk image /dev/hda
using qemu-img against the image file reports 'raw' not 'qcow2' So...I should not have to edit the .xml file...it is already correct.
[root@desk images]# qemu-img info Win7-base.img image: Win7-base.img file format: raw virtual size: 29G (31457280000 bytes) disk size: 29G
This is not good. I've been developing a prototype which uses several VMs under qemu-kvm. I'm now starting to question whether CentOS is the right tool to be using for prototyping capability that may eventually roll onto regular RHEL.
Did some more poking around and this is an SELinux problem. SELinux is denying access to /dev/hda. /dev/hda turns out to be the CDROM/DVD R/W device on the EIDE port of the motherboard. Lots of alias devices are linked to it.
When I try to start a VM that has a cdrom defined, selinux stops the access and virsh (and Virtual Machine Manager) will report an error accessing /dev/hda (the cdrom). Here is the cdrom portion of the xml
<disk type='block' device='cdrom'> <driver name='qemu' type='raw'/> <source dev='/dev/hda'/> <target dev='hdc' bus='ide'/> <readonly/> <address type='drive' controller='0' bus='1' unit='0'/> </disk>
As soon as I detached the cdrom device from the VM, the VM starts and runs A-OK.
Here is a listing of all the hda devices (blk and links) in /dev
[root@desk ~]# cd /dev/ [root@desk dev]# ls -Z |grep hda lrwxrwxrwx root root system_u:object_r:device_t cdrom-hda lrwxrwxrwx root root system_u:object_r:device_t cdrw-hda lrwxrwxrwx root root system_u:object_r:device_t cdwriter-hda lrwxrwxrwx root root system_u:object_r:device_t dvd-hda lrwxrwxrwx root root system_u:object_r:device_t dvdrw-hda lrwxrwxrwx root root system_u:object_r:device_t dvdwriter-hda brw------- dave disk system_u:object_r:virt_content_t hda
Notice the selinux context includes 'virt_content_t' I'm not sure this is right or wrong.
What is strange is the owner:group of hda is my normal (unprivileged) user login 'dave' I would have thought it would be root:kvm (where dave is a member of kvm).
Methinks either the owner:group or the selinux context of hda is wrong, or the linked devices may also need to have the 'virt_content_t' context.
I just downloaded a fresh 5.6 iso and will build it on a spare machine. Goal is to see what kind of devices are created and what kind of owner:group permissions are given and what kind of selinux context is given to /dev/hda. They may be different from an upgrade.
All this came up with the upgrade from 5.5 to 5.6, so it is both a CentOS 5.6 problem and an selinux problem. Should I leave this here or summarize what I found over on the fedora selinux forum?
Dave M
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/23/2011 07:51 AM, David McGuffey wrote:
On Fri, 2011-04-22 at 06:50 -0400, David McGuffey wrote:
On Fri, 2011-04-22 at 06:18 -0400, Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/21/2011 09:47 PM, David McGuffey wrote:
On Thu, 2011-04-21 at 21:09 -0400, David McGuffey wrote:
On Thu, 2011-04-21 at 18:01 +0200, Kenni Lund wrote:
2011/4/21 Johnny Hughes johnny@centos.org: > On 04/21/2011 06:11 AM, David McGuffey wrote: >> redlibvirtError: internal error Process exited while reading console log >> output: qemu: could not open disk image /dev/hda >
Problem may be an SELinux problem. Here is the alert. Notice the reference to '/dev/hda' (which is the virtual machine boot disk), and the SELinux context 'virt_content_t'
Summary:
SELinux is preventing pam_console_app (pam_console_t) "getattr" to /dev/hda (virt_content_t).
...
Detailed Description:
SELinux denied access requested by pam_console_app. It is not expected that this access is required by pam_console_app and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access.
...
Yep...each time I try to start the VM, sealert increments this error by one.
I created /.autorelable and rebooted. SELinux relabeled everything, but the sealert still fires when I try to start the VM.
I did a qemu-img <path_to_vm>/vm.img and the format is declared 'raw' Therefore I should not be editing the vm.xml file and changing 'raw' to 'qcow2'
Problem is definately with the SELlnux labels in the 5.6 upgrade.
Dave M
...
This is an SELinux issue. It really has no effect on the virtual machine. The problem is the label is not something pam_console policy expected to have on a blk device.
Yes, I was lured by the coincidence of the sealert and my effort to start the VM. The fact that the blk device in question happens to register as /dev/hda and the VM also uses an internal "virtual" device called /dev/hda can lead one astray.
I'm still left without an answer as to why virsh won't create or define-->start a VM after the upgrade.
[root@desk dev]# cd /etc/libvirt/qemu
[root@desk qemu]# virsh create Win7-base.xml error: Failed to create domain from Win7-base.xml error: internal error Process exited while reading console log output: qemu: could not open disk image /dev/hda
using qemu-img against the image file reports 'raw' not 'qcow2' So...I should not have to edit the .xml file...it is already correct.
[root@desk images]# qemu-img info Win7-base.img image: Win7-base.img file format: raw virtual size: 29G (31457280000 bytes) disk size: 29G
This is not good. I've been developing a prototype which uses several VMs under qemu-kvm. I'm now starting to question whether CentOS is the right tool to be using for prototyping capability that may eventually roll onto regular RHEL.
Did some more poking around and this is an SELinux problem. SELinux is denying access to /dev/hda. /dev/hda turns out to be the CDROM/DVD R/W device on the EIDE port of the motherboard. Lots of alias devices are linked to it.
When I try to start a VM that has a cdrom defined, selinux stops the access and virsh (and Virtual Machine Manager) will report an error accessing /dev/hda (the cdrom). Here is the cdrom portion of the xml
<disk type='block' device='cdrom'> <driver name='qemu' type='raw'/> <source dev='/dev/hda'/> <target dev='hdc' bus='ide'/> <readonly/> <address type='drive' controller='0' bus='1' unit='0'/> </disk>
As soon as I detached the cdrom device from the VM, the VM starts and runs A-OK.
Here is a listing of all the hda devices (blk and links) in /dev
[root@desk ~]# cd /dev/ [root@desk dev]# ls -Z |grep hda lrwxrwxrwx root root system_u:object_r:device_t cdrom-hda lrwxrwxrwx root root system_u:object_r:device_t cdrw-hda lrwxrwxrwx root root system_u:object_r:device_t cdwriter-hda lrwxrwxrwx root root system_u:object_r:device_t dvd-hda lrwxrwxrwx root root system_u:object_r:device_t dvdrw-hda lrwxrwxrwx root root system_u:object_r:device_t dvdwriter-hda brw------- dave disk system_u:object_r:virt_content_t hda
Notice the selinux context includes 'virt_content_t' I'm not sure this is right or wrong.
What is strange is the owner:group of hda is my normal (unprivileged) user login 'dave' I would have thought it would be root:kvm (where dave is a member of kvm).
Methinks either the owner:group or the selinux context of hda is wrong, or the linked devices may also need to have the 'virt_content_t' context.
I just downloaded a fresh 5.6 iso and will build it on a spare machine. Goal is to see what kind of devices are created and what kind of owner:group permissions are given and what kind of selinux context is given to /dev/hda. They may be different from an upgrade.
All this came up with the upgrade from 5.5 to 5.6, so it is both a CentOS 5.6 problem and an selinux problem. Should I leave this here or summarize what I found over on the fedora selinux forum?
Dave M
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Try restorecon -RF on the device.
I still get the following error when I try to start the VM:
redlibvirtError: internal error Process exited while reading console log output: qemu: could not open disk image /dev/had
Is the disk image a qcow2 type file?
Someone wrote:
You should not need to do anything in virsh to dump a file ... there should be an xml file in /etc/libvirt/qemu/ for every VM already.
There are 2 xml files if the VM is set to run automatically at boot. Using virsh to dump the file, and the rest of the instructions makes it a cleaner repair.
Other workarounds for this particular issue have just been suggested here: http://lists.centos.org/pipermail/centos/2011-April/110547.html http://lists.centos.org/pipermail/centos/2011-April/110551.html
I find it strange that people are making such recommendations. A non verifyable signature is a MASSIVE deal. Working 'around' that is to stop doing what you are doing, and not do any package centric operation till the issue is fixed and resolved in an acceptable manner.
Sorry, but not everybody is on production machines.
Since the OP could not analyze himself the error message, one could safely assume he is not dealing with critical production environments. Maybe he was just told: "install quickly this CentOS in VirtualBox, just to make sure our app is compatible", and in that case the sooner the better.
My "advice" and those of others where underlying the security risk. The one of Akemi seems pretty safe (not installing the update).
To put it shortly: Freedom, as in "free software", is about doing whatever you want.
This being say, I do agree that having a non signed package is a MASSIVE deal. Do we have more details about what's going on here?
On Thu, 21 Apr 2011, Mathieu Baudier wrote:
Sorry, but not everybody is on production machines.
Since the OP could not analyze himself the error message, one could safely assume he is not dealing with critical production environments. Maybe he was just told: "install quickly this CentOS in VirtualBox, just to make sure our app is compatible", and in that case the sooner the better.
My "advice" and those of others where underlying the security risk. The one of Akemi seems pretty safe (not installing the update).
To put it shortly: Freedom, as in "free software", is about doing whatever you want.
Not updating is entirely sensible and sounds like the best default position. Installing a package you'd expect to be signed when it isn't signed should ring alarm bells.
Freedom includes being free to make poor decisions.
jh
Not updating is entirely sensible and sounds like the best default position. Installing a package you'd expect to be signed when it isn't signed should ring alarm bells.
I agree that my first answer was probably wrong, even with all disclaimers and warnings.
I thought of a technical way (--nogpgcheck) to solve the issue, whereas the right answer was definitely procedural (as you point out, not updating, what I would have done on my own systems).
I apologize, but I did my best...
Freedom includes being free to make poor decisions.
I fully agree with you.
On 04/21/2011 08:34 AM, Mathieu Baudier wrote:
Not updating is entirely sensible and sounds like the best default position. Installing a package you'd expect to be signed when it isn't signed should ring alarm bells.
I agree that my first answer was probably wrong, even with all disclaimers and warnings.
I thought of a technical way (--nogpgcheck) to solve the issue, whereas the right answer was definitely procedural (as you point out, not updating, what I would have done on my own systems).
I apologize, but I did my best...
Freedom includes being free to make poor decisions.
I fully agree with you.
Maybe this would work out:
yum --nogpgcheck update libuser-devel
then you can update everything else later with gpg on.
Although, like I said, this particular issue has now been corrected.
Johnny Hughes wrote:
On 04/21/2011 08:34 AM, Mathieu Baudier wrote:
Not updating is entirely sensible and sounds like the best default position. Installing a package you'd expect to be signed when it isn't signed should ring alarm bells.
I agree that my first answer was probably wrong, even with all disclaimers and warnings.
<snip>
Maybe this would work out:
yum --nogpgcheck update libuser-devel
then you can update everything else later with gpg on.
I *like* that answer. And command line only, so the next time you go to yum update, it'll get the fixed package.
Although, like I said, this particular issue has now been corrected.
And *very* quickly.
mark
On 04/21/2011 12:26 PM, Mathieu Baudier wrote:
Sorry, but not everybody is on production machines.
Security and integrity of an install is not optional, wherever you might be. Imho anyway.
Maybe he was just told: "install quickly this CentOS in VirtualBox, just to make sure our app is compatible", and in that case the sooner the better.
My "advice" and those of others where underlying the security risk. The one of Akemi seems pretty safe (not installing the update).
If there is reason to suspect a mirror or installation is compromised, one should - again imho - not be doing any operations against that.
To put it shortly: Freedom, as in "free software", is about doing whatever you want.
thats true, but there is also a sense of responsibility that comes with that advice that is handed out and who / where its being handed out. One could potentially assume that the people on this list would know what they are talking about and would only advice based on whats considered best practices. The fact that the OP didnt know what was going on would be a good sign to assume that he was looking for people who did know what was going on eg. Telling people to jump off a cliff, just because you can isnt nice. Freedom or otherwise.
This being say, I do agree that having a non signed package is a MASSIVE deal. Do we have more details about what's going on here?
yes, a package was released, unsigned, and has been fixed. ( and 4 more tests added to the release process to make sure that this does not happen again; or atleast reduce the chance of this going out ).
- KB
On Thu, 21 Apr 2011, Karanbir Singh wrote:
yes, a package was released, unsigned, and has been fixed. ( and 4 more tests added to the release process to make sure that this does not happen again; or atleast reduce the chance of this going out ).
And if people stick with the sane practice of only trusting signed packages, this is quickly caught and the only cost is a short delay while updated packages are pushed out.
If people think that disabling gpg checking is a good idea, you risk this finding its way into their yum.conf. That's exactly what you've seen amongst some spacewalk users.
jh
On Thursday, April 21, 2011 07:56:27 AM John Hodrien wrote:
If people think that disabling gpg checking is a good idea, you risk this finding its way into their yum.conf. That's exactly what you've seen amongst some spacewalk users.
FWIW, there are some out there who don't even think unsigned packages are a problem. As an extreme example of this, recently I saw on LinuxToday where there was a thread in an archlinux list about signed packages; most of the devs didn't consider them a priority. At all.
One reason arch won't be in production here any time soon.
Unless you know exactly what you are doing and the full ramifications of doing it you should never disable gpgcheck, since mirrors can be hacked.
-
Akemi Yagi -
Ben McGinnes -
compdoc -
Daniel J Walsh -
David McGuffey -
John Hodrien -
Johnny Hughes -
Karanbir Singh -
Kenni Lund -
Lamar Owen -
m.roth＠5-cent.us -
Mathieu Baudier -
Olaf Mueller