Re: Vbox with new Kernel vers. 3.10.0-327.3.1(SL7.1)

[Nico Kadel-Garcia]

On Tue, Dec 29, 2015 at 9:57 PM, Yasha Karant  wrote:
> 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:

>>> 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:

Give credit where it is due. Red Hat goes well beond the minimum
required by vairous licenses, and engages in genuine free software as
a policy where possible, in open source when free software is not
possible, and in closed source only where absolutely necessary to
handle a very real customer demand, and does their very real best to
free up encumbered licenses. The result has been free rebuilds of RHEL
base software such as Whitebox Linux, CentOS, and Scientific Linux.
It's unfortunately been abused by Oracle to make their so-called
"Unbreakable Linux", but the rebuilders of that have been nowhere near
as open and generous with developers and non-buisiness uers.

>>> (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.

Oracle sells their "Unbreakable Linux" as a product. Scientific Linux
does not, and it's left them free to provide direct links to third
party repositories which would be legally problatic in the US.
Repoforge and RPMfusion, in particular, have softwrae that can and
have included MPEG and DECSS software which would be awkward or even
illegal to publish without permission of the patent or DVD lmedia
license holders.

For the exact relationship between CentOS, RHEL, Oracle's Linux, and
Scientific Linux, take a good look at the licenses. There are some
similar weird things happening with SLES and OpenSuSE, which is still
not completely straightened out, and RHEL hiring some of the key
CentOS developers and using git.centos.org to publish source code,
instead of publishing SRPM's, makes it extra fascinating. I'm becoming
convinced that CentOS is filling the old niche fulled by the "free"
Red Hat releases which existed before RHEL was published.

> 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)?

That wouldn 't seem to be a "scientific-linux-users" question, that
would be more of a "scientific-linux-developers" question.  It's also
not one I'd personally worry about. as long as they're willing to
publish, especially with the extra development hooks, and I'm willing
to help out users, then they and I have a deal. Your approach to this
may differ quite a lot.

> 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,

There is nothing preventing Oracle from buying a RHEL license and
maintaining a local RHEL SRPM and/or RPM mirror. I've long published a
tool to do just that at
https://github.com/nkadel/nkadel-rsync-scripts/blob/master/reposync-rhel.sh.
I've used it for maintaining a local yum mirror of RHEL, similar to
the rsync based ones I use for SL and CentOS, because doing yum
updates against a remote mirror can be a serious bandwidth burden.

The licensing of individual packages inside such a local mirror may
prevent CentOS, SL, or Oracle re-publication of them, and our
faviorite upstream developers at Red Hat are clearly doing their best
to unencumber such software for inclusion in RHEL. But it's hard to
stay caught up when clients demand a supported feature. Their efforts
allow rebuilds like CentOS and RHEL, and I'm very happy with their
efforts.

Such an SRPM mirror can also be noticeably safer than a locally cloned
git repository. SRPM's are GPG signed and have much more certain
provenance than a local git clone can have without GPG signed git
tags, and git.centos.org still insists on parsing the text of git
logs, rather than using git tags, to publish specific software
releases. The ability to confuse or poison such log entries is left as
an exercise for developers, but I'll point out the relevant XKCD
cartoon, titled "Exploits of a Mob".

 https://xkcd.com/327/

> 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 

Re: Vbox with new Kernel vers. 3.10.0-327.3.1(SL7.1)

[Connie Sieh]

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
cs...@fnal.gov

Re: Vbox with new Kernel vers. 3.10.0-327.3.1(SL7.1)

[Yasha Karant]

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.


(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

Re: Vbox with new Kernel vers. 3.10.0-327.3.1(SL7.1)

[S A]

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!

Vbox with new Kernel vers. 3.10.0-327.3.1(SL7.1)

[etienne.baeumle]

I have the same problem like Yasha, with Kernel Vers. 3.10.0-327.3.1 (SL7.1). I 
did step back to VBox 5.10_104061_el7-1 and did recompile this but no chance.
With Kernel Vers. 3.10.0-229.20.1.el7 VBox 5.10 did compile and run perfectly.

Looking at vbox-install.log I did get:

KBUILD_VERBOSE=1 SUBDIRS=/tmp/vbox.1 SRCROOT=/tmp/vbox.1 CONFIG_MODULE_SIG= -C 
/lib/modules/3.10.0-327.3.1.el7.x86_64/build modules
test -e include/generated/autoconf.h -a -e include/config/auto.conf
include/generated/autoconf.h or include/config/auto.conf are missing.

Is there something wrong with Kernel Vers. 3.10.0-327.3.1?

Regards, Etienne Bäumle