On Sat, Aug 20, 2011 at 12:08 AM, Predrag Punosevac <[log in to unmask]> wrote:
> Nico Kadel-Garcia <[log in to unmask]> wrote:
>
>> On Fri, Aug 19, 2011 at 10:25 PM, Predrag Punosevac <[log in to unmask]> wrote:
>> > Deal All,
>> >
>> > I apologize to all of you who find this question trivial. I am
>> > completely new to Linux and to Scientific Linux in particular albeit
>> > Unix (OpenBSD and Solaris) user of over 20 years.
>> >
>> > I have been entrusted with the installation and configuration of NVidia
>> > Tesla c1060 on our university test rig running i386_64 Scientific Linux
>> > 5.5.
>>
>> Wonderful for you you! First, May I suggest that you figure out wither
>> you mean "i386" or "x86_64" Scientific Linux? And second, if feasible,
>
> x86_64 (amd64) of course because I have a lot of RAM which can not be
> fully accessed even with PAE enabled kernel on i386. In my baby tests SL
> 5.5 i386 was limited to 12GB of RAM.

Cool.


>> can I encourage you to update to version 5.6? There are a number of
>> very useful updates and integration improvements in that release.
>
> I could install even 6.1. The only reason I went with 5.5 was that
> NVidia claimed that was "officially supported" version. I am also a bit
> concern about other applications and their availability for SL 6.1. This
> thing must run MATLAB, Maple, Mathematica, SciPy, Numpy and be
> accessible not only via ssh but also via NoMachine NX. In particular NX
> is closed source for version 4.0 and above so I am not sure if the free
> version of server will even install let alone run on SL 6.1.

Wow, you do have a suite of tools that might add up to some support
issues. Since our favorite upstream vendor's version 6 has been out
since October of 2010, I suspect that all of those packages are now
compatible with SL 6.0 or SL 6.1 can attest to NoMachine NX version 3
being compatible: SL 6 has the same bugs as SL 5, because the OpenSSH
is actually compiled on RHEL 3 adn the "xauth" command is not where
the customized SSH server expects it by default. Just remember to set
"XauthLocation" in the relevant sshd_config file.

I wouldn't sweat the binary NoMachine implementation. While I dislike
intensely closed source code, the freeware rebuilds of NX based tools,
such as neatx and freenx, are all abandonware, and NoMachine's
implementation is noticeably superios, especially for the Windows
clients. And hey, with Putty 0.61 out and supporting genuine GSSAPI,
I'm hoping that it can support genuine single-sign-on..

>> > After a bit of pocking around I managed to kill X server, install gcc as
>> > directed by NVidia driver installation script. However, due to the lack
>> > of pre-compiled kernel interfaces on NVidia ftp server I am forced by
>> > installer to compile a kernel interface. This is where my troubles

If you have to do this again, you should be able to run "su" or "sudo"
and run the command "telinit 3". That should switch you to "runlevel
3", which doesn't have that X server running.

>> The NVidia installer scripts can !@#$!@@@#$ my !@[log in to unmask] I've
>> personally had to rewrite them far too many times, and my updated
>> versions have been ignored. They do not play well with updates to the
>> OpenGL libraries, which they replace without informing the RPM system
>> of the replacement, they do not uninstall gracefully unless they've
>> been heavily edited since I last looked, and RPM has no way of knowing
>> about them to deal with kernel updates.
>
> I have heard of the "update issues". Obviously, I am not happy running
> NVidia binary blobs period but I have no choice.

By the way, if this hasn't changed: if you ever have to update the
manually installed NVidia drivers, first *uninstall* the old ones,
then install the updates.

>> There are good RPM's, and notes,on the process, at
>> http://rpmfusion.org/Howto/nVidia. Scientific Linux plays as nicely as
>> it feasibly can with such third party repositories.
>>
>
> Thank you so much for that info!
>
>> > begin. I have no source code for the kernel. I used yum to install
>> > kernel-devel.rpm and all other rpms (since I didn't find kernel-src.rpm)
>> > which contain kernel in the name. Never the less script still complains
>> > about the lack of the kernel source code. Could you please tell me where
>> > can I get kernel source and where is supposed to be placed on Linux?
>>
>> Have you updated the kernel and rebooted since the last kernel update?
>> One thing that the NVidia installers have traditionally been horrid
>> about is detecting what your current kernel is, versus what kernel
>> will be at boot time. I've traditionally dealt with this by having an
>> init script run at boot time to re-install the NVidia drivers, just in
>> case, but the modern "kmod" based tools are supposed to do this for
>> you.
>
> No, I have not updated anything. I run NVidia installation script on
> release version of SL 5.5 in a hope to get working installation while
> learning about SL, CUDA, and having things like MATLAB utilize Tesla.

It sounds like you'd previously done a kernel update, but not rebooted
with the new kernel. That's probably why you had a kernel-devel
installed, matching your current kernel, but weren't actually
*running* with that kernel, so the NVidia installer was looking for
source for the *old* kernel.

> Thank you so much for your frank and helpful post.
>
> Cheers,
> Predrag Punosevac
>
>>
>> > I would welcome any other tip or howto or pointer to documentation since
>> > I really want to do science instead of playing with system
>> > administration.
>> >
>> > Thank you,
>> > Predrg Punosevac
>> >
>> > P.S. Is there TeXLive rmp for Scientific Linux? I saw teTeX which is
>> > probably enough for this machine but if TeXLive is available why not.
>> >
>>
>> http://rpm.pbone.net is your friend for this. I see it apparently
>> built into Scientific Linux 6,

I'd definitely survey for support for your other necessary components,
and switch to Scientific Linux 6 if possible. The base operating
system for SL 5 is over 4 years old, and it's getting harder and
harder to justify doing anything on it that you don't absolutely have
to.