[ovirt-users] ovirt 3.6 Failed to execute stage 'Environment setup'

[Richard Neuboeck]

It turns out that there has been a problem in Intels EFI on
R1304GZ4GC server systems. As long as EFI optimizations were on
dmidecode did not work. Disabling EFI optimization is one option but
updating to the latest firmware did do the trick too in this case.

Cheers
Richard

On 09/01/2015 11:25 AM, Richard Neuboeck wrote:
> The dmidecode problem really only affects those three machines I'm
> trying to set up as ovirt hosts. Since I couldn't find anything
> wrong in the CentOS setup I tried Fedora 22 and got the same result.
> /dev/mem: Operation not permitted
> 
> I'm sorry to have bothered you guys with this problem that is
> obviously not ovirt related. I'll try to find a solution and keep
> you posted.
> 
> All the best
> Richard
> 
> On 09/01/2015 11:14 AM, Simone Tiraboschi wrote:
>> Adding Oved
>>
>>     On Tue, Sep 1, 2015 at 10:47 AM, Richard Neuboeck
>>     <hawk at tbi.univie.ac.at <mailto:hawk at tbi.univie.ac.at>> wrote:
>>
>>         On 09/01/2015 09:55 AM, Simone Tiraboschi wrote:
>>         > Indeed you had:
>>         > Thread-64::DEBUG::2015-08-31
>>         > 12:33:15,127::utils::661::root::(execCmd) /usr/bin/sudo -n
>>         > /usr/sbin/dmidecode -s system-uuid (cwd None)
>>         > Thread-64::DEBUG::2015-08-31
>>         > 12:33:15,153::utils::679::root::(execCmd) FAILED: <err> = '/dev/mem:
>>         > Operation not permitted\n'; <rc> = 1
>>         > Thread-64::WARNING::2015-08-31
>>         > 12:33:15,154::utils::812::root::(getHostUUID) Could not find host UUID.
>>         > Thread-64::DEBUG::2015-08-31
>>         >
>>         > Can you please try executing?
>>         > /usr/sbin/dmidecode -s system-uuid
>>
>>         dmidecode always fails and according to the things I've read
>>         this is
>>         caused by the kernel restricting access to /dev/mem. But this
>>         shouldn't affect the root user. It does anyway. I've tried with
>>         selinux on and off. Is there a way around this problem? So far I
>>         didn't find anything really helpful by googling around. This
>>         problem
>>         seems only to affect these kind of machines. CentOS 7.1
>>         installations with the same kernel on another machine lets
>>         me run
>>         dmidecode without problems. I guess I'm missing something.
>>
>>         [root at cube-one tmp]# dmidecode
>>         # dmidecode 2.12
>>         # SMBIOS entry point at 0xbafbaca0
>>         /dev/mem: Operation not permitted
>>
>>         [root at cube-one tmp]# /usr/sbin/dmidecode -s system-uuid
>>         /dev/mem: Operation not permitted
>>
>>  
>> dmidecode -s system-uuid is failing cause it cannot read /dev/mem so
>> VDSM fails getting the host UUID and so vdscli raise an exception
>> about a None value on 'uuid' when hosted-engine
>> calls getVdsCapabilities.
>> Any hint on that or any workaround?
>>
>>         [root at cube-one tmp]# grep DEVMEM
>>         /boot/config-3.10.0-229.11.1.el7.x86_64
>>         CONFIG_STRICT_DEVMEM=y
>>
>>         Cheers
>>         Richard
>>
>>         --
>>         /dev/null
>>
>>
>>
> 
> 
> 
> 
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 


-- 
/dev/null

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ovirt.org/pipermail/users/attachments/20150902/679d3548/attachment-0001.sig>