kernel error in SL 6.9

[Bill Maidment]

Hi
I am getting kernel errors in several SL 6 machines after yum update:
kernel: gam_server[2941]: segfault at 58f5f7aa ip 0040a2b9 sp 
7ffe56238e80 error 4 in gam_server[40+16000]
What is a gam_server? Should I be worried by this?

Cheers
Bill Maidment

Re: Licensing and EULA

[Nico Kadel-Garcia]

On Tue, Apr 18, 2017 at 6:58 AM, Cankaya, Yilmaz 
wrote:

> Dear All,
>
>
>
> We are as Airbus DS CyberSecurity running projects with the aim of
> introducing some cyber security products mainly for defence and ICS
> industry.
>
>
>
> We want to use Linux OS in our products (hardware, software or even
> service) and therefore we are in the process of getting FOSS (Free Open
> Source Software) clearance for those products.   The product will be
> commercial and distributed to the customers in a hardware box with
> following conditions:
>

You'll want to check upstream to Red Hat Enterprise Linux licensing for
almost all of the software, since Scientific Linux is a free rebuild of
RHEL. That means that components which are *not* free software, open source
software, or compatible with those licenses is not being included by our
friends over at Fermi Lab who have been graciously hosting and publishing
this work for the rest of us, and who've as best I can tell carefully
stayed away from the small set of proprietary components RHEL includes.

1.   *No visibility of OS and Trademark*:  The product will be a
> hardware box and the OS will never we visible to the end user even in the
> documentation.  We do not (normal use)  expect any customer to interface
> with the product OS in any manner.   In  conjunction with this, we do not
> aim at using/displaying the trademark of the OS in any form.
>

That may require extra work. Gnome, for example, includes various
trademarks, as does KDE, in its basic default configuration. What precisely
are you planning to run on these boxes?


> 2.   *No Source Code Change:* The software running on the box  is
> developed from scratch with some shared libraries.  The licensing for those
> libraries is currently handled separately.  But, practically, we do not
> change any source code of another software or OS component.
>

Out of personal curiosity, if you change source, do you publish or intend
to publish your changes? One of the great opportunities with free software
and open source software is the chance to enhance tools and fix issues, and
to share those as active members of the open source security.


> 3.   *OS changes*:  We mainly change the network configuration,
> syslog configuration, OS startup configuration, security hardening (based
> on the recommendations of the to be used OS distribution) and add some
> folders and new files for our purpose under /opt and /etc.
>
You've my sympathies, I've certainly done this.

4.   *Custom Repository*:  We strictly differentiate between our own
> packages and Linux OS packages.  So, we will provide a custom repository
> for own packages.  OS updates and any other updates would be retrieved from
> one of the distribution repositories.
>
Sounds like you're trying to do things right, and legally.  Good for you!
If you need some help with working structures for build environments for
building suites of internal RPM's and their dependencies, I've a few
examples of such over at https://github.com/nkadel/ you're welcome to look
at.



> SL 7.3 release notes given below
>
>
>
> ftp://ftp.scientificlinux.org/linux/scientific/7x/x86_64/os/
> sl-release-notes.html#_packages_removed_from_upstream
>
>
>
> states  “*There is a new Scientific Linux End User License Agreement
> (EULA). The EULA now contains information about the U.S. Government
> contract under which Fermilab produces Scientific Linux*”.
>
>
>
> And the EULA allows
>
>
>
> ftp://ftp.scientificlinux.org/linux/scientific/7x/x86_64/os/EULA
>
>
>
> redistribution and commercial usage so long as GPL v2 is satisfied.
>
>
>
> We would be glad to use SL 7.3 as our choice of Linux OS but we need on
> our side to assure that this will not change in the upcoming releases or at
> least this EULA will be valid for all 7.x releases.  What are your comments
> on this?  Is there a communication partner by Fermi Lab that could assist
> us in this manner?
>
>
>
> Thanks
>
>
>
>
>
> Beste Grüße – Kind Regards,
>
>
>
> Yilmaz Cankaya
>
> Project-/Bid Manager
>
> CyberSecurity
>
>
>
> Willy-Messerschmitt-Straße 1
>
> 82024  Taufkirchen
>
> Germany
>
> T:   +49 (0) 89 3179 7609 <+49%2089%2031797609>
>
> E:   *yilmaz.cank...@airbus.com *
>
>
>
> www.airbusdefenceandspace.com ; www.cassidiancybersecurity.com
>
>
>
> Cassidian Cybersecurity GmbH
> Registered Office: Ottobrunn
> District Court of Munich HRB 149698
> Managing Director: Michael Gerhards
>
>
>
>
> The information in this e-mail is confidential. The contents may not be 
> disclosed or used by anyone other than the addressee. Access to this e-mail 
> by anyone else is unauthorised.
> If you are not the intended recipient, please notify Airbus immediately and 
> delete this e-mail.
> Airbus cannot accept any responsibility for the accuracy or completeness of 
> this e-mail as it has been sent over public networks. If you have any 
> concerns over the content of this 

Re: CUDA Setup Failing

[Andrew Zyman]

Eric my last experiments were with it on version 6.so.. check if you have
the original driver installed correctly not the RPM version of it.

On Apr 18, 2017 19:30, "Lofgren, Eric"  wrote:

Hey all,

I’m relatively new to Linux generally and SL in particular. I’m running
SL7, and have run aground trying to follow the setup instructions at
http://developer.download.nvidia.com/compute/cuda/8.0/
secure/Prod2/docs/sidebar/CUDA_Installation_Guide_Linux.
pdf?autho=1492553753_fc0d9c1b985f0ba78200964ccf8f1d
da=CUDA_Installation_Guide_Linux.pdf

I’ve been following the RHEL/CentOS instructions, as my understanding is
that SL7 should just be a drop in for those. Things seem to go well until
the “Verify the Installation” step at 6.2.2 in the document.

Verifying the Driver Version with $cat /proc/driver/nvidia/version returns
‘No such file or directory’

The examples compile fine in 6.2.2.3, but when you run the deviceQuery
binary, rather than finding the Quadro K620 sitting in the machine at the
moment, it returns:

./deviceQuery Starting…

CUDA Device Query (Runtime API) version (CUDART static linking)

cudaGetDeviceCount returned 30
-> unknown error
Result = FAIL

That’s where I stopped, as it appears the GPU isn’t talking nicely with
CUDA. lspci can see the GPU - is this just a driver issue? If so, is sudo
yum install cuda-drivers likely the easiest fix?

Thanks in advance for the help,

Eric

Re: [SCIENTIFIC-LINUX-USERS] SL5 initrd.img

[Mark Stodola]

Thanks for the pointer.  I've started down that path after writing the 
email.  It seems buildinstall calls mk-images, etc, etc.  Looks like I 
just need to get the kernel-lt rpms in place and possibly modify 
mk-images to look for it.


It's been a while since I've had to dig into this sort of thing.

-Mark

On 04/18/2017 03:21 PM, Pat Riehecky wrote:

I believe that is all generated via the buildinstall script from the
anaconda-runtime rpm under /usr/lib/anaconda-runtime.

If memory serves it spits out usage information if you don't provide any
args.

Pat

On 04/18/2017 02:48 PM, Mark Stodola wrote:

Is there a resource/information/script on generating the initrd.img
used in the SL5 installation media?  I'm trying to inject kernel-lt
from ELrepo in place of the usual one.  Replacing vmlinuz is easy, but
I'm not sure where to start getting the initrd updated with the
appropriate kernel modules.

I already know how to unpack the initrd, but I'm unsure how/where the
modules included in it are selected, gathered, and supporting files
created.

-Mark

SL5 initrd.img

[Mark Stodola]

Is there a resource/information/script on generating the initrd.img used 
in the SL5 installation media?  I'm trying to inject kernel-lt from 
ELrepo in place of the usual one.  Replacing vmlinuz is easy, but I'm 
not sure where to start getting the initrd updated with the appropriate 
kernel modules.


I already know how to unpack the initrd, but I'm unsure how/where the 
modules included in it are selected, gathered, and supporting files created.


-Mark

Re: Licensing and EULA

[Bonnie King]

Hi Yilmaz,

Thanks for the inquiry. Questions like these should be directed to 
Fermilab's Office of Partnerships and Technology Transfer.


The email address is o...@fnal.gov.

On 04/18/2017 05:58 AM, Cankaya, Yilmaz wrote:

Dear All,



We are as Airbus DS CyberSecurity running projects with the aim of
introducing some cyber security products mainly for defence and ICS
industry.



We want to use Linux OS in our products (hardware, software or even
service) and therefore we are in the process of getting FOSS (Free Open
Source Software) clearance for those products.   The product will be
commercial and distributed to the customers in a hardware box with
following conditions:



1.   *No visibility of OS and Trademark*:  The product will be a
hardware box and the OS will never we visible to the end user even in
the documentation.  We do not (normal use)  expect any customer to
interface with the product OS in any manner.   In  conjunction with
this, we do not aim at using/displaying the trademark of the OS in any
form.

2.   *No Source Code Change:*The software running on the box  is
developed from scratch with some shared libraries.  The licensing for
those libraries is currently handled separately.  But, practically, we
do not change any source code of another software or OS component.

3.   *OS changes*:  We mainly change the network configuration,
syslog configuration, OS startup configuration, security hardening
(based on the recommendations of the to be used OS distribution) and add
some folders and new files for our purpose under /opt and /etc.

4.   *Custom Repository*:  We strictly differentiate between our own
packages and Linux OS packages.  So, we will provide a custom repository
for own packages.  OS updates and any other updates would be retrieved
from one of the distribution repositories.



SL 7.3 release notes given below



ftp://ftp.scientificlinux.org/linux/scientific/7x/x86_64/os/sl-release-notes.html#_packages_removed_from_upstream

* *

states  “/There is a new Scientific Linux End User License Agreement
(EULA). The EULA now contains information about the U.S. Government
contract under which Fermilab produces Scientific Linux/”.



And the EULA allows



ftp://ftp.scientificlinux.org/linux/scientific/7x/x86_64/os/EULA



redistribution and commercial usage so long as GPL v2 is satisfied.



We would be glad to use SL 7.3 as our choice of Linux OS but we need on
our side to assure that this will not change in the upcoming releases or
at least this EULA will be valid for all 7.x releases.  What are your
comments on this?  Is there a communication partner by Fermi Lab that
could assist us in this manner?



Thanks





Beste Grüße – Kind Regards,



Yilmaz Cankaya

Project-/Bid Manager

CyberSecurity



Willy-Messerschmitt-Straße 1

82024  Taufkirchen

Germany

T:   +49 (0) 89 3179 7609

E:   _yilmaz.cank...@airbus.com _



www.airbusdefenceandspace.com 
;www.cassidiancybersecurity.com 



Cassidian Cybersecurity GmbH
Registered Office: Ottobrunn
District Court of Munich HRB 149698
Managing Director: Michael Gerhards



The information in this e-mail is confidential. The contents may not be
disclosed or used by anyone other than the addressee. Access to this
e-mail by anyone else is unauthorised. If you are not the intended
recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness
of this e-mail as it has been sent over public networks. If you have any
concerns over the content of this message or its Accuracy or Integrity,
please contact Airbus immediately. All outgoing e-mails from Airbus are
checked using regularly updated virus scanning software but you should
take whatever measures you deem to be appropriate to ensure that this
message and any attachments are virus free.




--
Bonnie King
Group Leader
Scientific Linux & Architecture Management

Fermi National Accelerator Laboratory
www.fnal.gov

Re: Scientific Linux 6.9 now Released for i386/x86_64

[Andrew C Aitchison]

On Mon, 17 Apr 2017, Pat Riehecky wrote:


Scientific Linux 6.9 i386/x86_64   Apr 17, 2017

SL 6x users:
  Please run   yum clean expire-cache


That did not work for me, but
yum clean metadata
did.

Sorry, I have lost the original error message, but it was to the effect 
that the cached metadata was newer than the downloaded metadata

and I was using a server or mirror at ftp.scientificlinux.org.




SL Mirrors should consider running a sync at this time.