On 12/29/2015 02:42 PM, Connie Sieh wrote:
> On Tue, 29 Dec 2015, Yasha Karant wrote:
>
>> On 12/28/2015 01:37 PM, S A wrote:
>>> Hi,
>>>
>>> I was out for holiday last week and came back to my SL 7.1 desktop 
>>> needing a slew of updates.  I had been running 
>>> VirtualBox-5.0-5.0.10_104061_el7-1.x86_64 against 
>>> kernel-3.10.0-229.14.1.el7.x86_64 with out issue.  After installing 
>>> the latest kernel mentioned by Etienne, and attempting to rebuild 
>>> the vboxdrv modules, I had similar failures.  Afterward, I attempted 
>>> to upgrade to VirtualBox-5.0-5.0.12_104815_el7-1.x86_64, I 
>>> discovered the libdevmapper issue noted in the previous post which 
>>> prevented the newer version from installing.
>>>
>>> It seems that there is a VirtualBox bug filed against the EL7.2 
>>> 3.10.0-327 kernel noted here: 
>>> https://www.virtualbox.org/ticket/14866 which may be causing the 
>>> issues you are encountering.  Unfortunately, the testing build for 
>>> EL7: 
>>> https://www.virtualbox.org/download/testcase/VirtualBox-5.0-5.0.11_104721_el7-1.x86_64.rpm, 
>>> does not install due to the same libdevmapper issue.  I had hoped 
>>> maybe the devmapper issue was introduced in builds between the 
>>> latest testbuild and the release build for 5.0.12, no such luck.
>>>
>>> I have device-mapper-libs-1.02.93-3.el7_1.1.x86_64 installed, but it 
>>> seems that the VirtualBox package is calling for 
>>> device-mapper-libs-1.02.97, which doesn't seem to be available for 
>>> SL7.  The CentOS and Oracle Linux public yum repo's latest version 
>>> is device-mapper-libs-1.02.107-5.el7.x86_64.  Is that in the 
>>> pipeline for release to SL7 soon?
>>>
>>> Thanks!
>> I am confused.  As I thought I understood the current EL situation, Red
>> Hat owns CentOS and distributes EL full source, per GPL, Linux, etc.,
>> licenses, through CentOS for all non-RH rebuilds (e.g., Oracle) to use
>> (sans Red Hat logos, services, etc.).  In this case, two questions:
>>
>> (1) Is Fermilab/CERN not funded well enough to have the same
>> rebuliding/packaging resources as Oracle just to rebuild from the RH
>> CentOS sources, and thus is delayed in production binary (RPM) release
>> compared to Oracle?  Both Fermilab and CERN are funded through their
>> respective governments that support fundamental research.
>
> CERN is NOT involved in SL 7 .
>
>>
>> (2) If (1) is true, during the interval before the "current" RH
>> production release is a SL release, can one simply use the CentOS or
>> Oracle RPMs (e.g., in this case,
>> device-mapper-libs-1.02.107-5.el7.x86_64.rpm) to maintain compatibility
>> with Oracle licensed-for-free products (e.g., VirtualBox)?
>>
>> Yasha Karant
>>
>
> device-mapper-libs-1.02.107-5.el7.x86_64.rpm is available via the 
> "rolling" repo now.
>
> -- 
>
> Connie J. Sieh
> Computing Services Specialist III
>
> Fermi National Accelerator Laboratory
> 630 840 8531 office
>
> http://www.fnal.gov
> [log in to unmask]
I did not know that CERN had stopped in the extra-CERN SL work -- was SL 
6 the last "public" joint Fermilab-CERN "supported" release? Is CERN 
still using EL (presumably 7) internally, or has CERN switch to 
something else (e.g., SuSE)?

May I assume from your response that Fermilab currently is not funded 
well enough to bring out RHEL production releases (presumably via RedHat 
owned CentOS) as rapidly as, say, Oracle?   Presumably, Oracle also is 
forced to use the CentOS source as Red Hat regards Oracle as a 
competitor, particularly because, unlike SL, Oracle claims to offer the 
same "quality" support-for-fee that Red Hat claims, providing the same 
sort of "cradle to grave" support that many IT departments require.  (As 
an academic research unit, we are "self-supporting").  For those of us 
in the USA, would it help SL staffing to attempt to get earmarked 
funding through Congress?

Regards,

Yasha Karant