Archive

Posts Tagged ‘slackware64’

Slackware64 14.1 :: Nvidia Proprietary Driver Fail

November 11th, 2013 1 comment

Issue #2 with Slackware64-14.1: The latest Nvidia blob doesn’t install properly and neither do some older ones. The main issue with the latest 331.20 driver being that it provides libEGL for 32-bit but not 64-bit and then gives you whinges such as these:

unable to determine the architecture of the files ‘/usr/X11R6/lib/libEGL.la’, which has an architecture specific conflict
unable to determine the architecture of the files ‘/usr/X11R6/lib64/libEGL.la’, which has an architecture specificconflict
unable to determine the architecture of the files ‘/usr/lib/libEGL.la’ which has an architecture specific conflict
unable to determine the architecture of the files ‘/usr/lib64/libEGL.la’ which has an architecture specific conflict

If you are having any Nvidia blob troubles using Slackware64-14.1, you should be fine if you use 325.15 until Nvidia get their act together:
http://uk.download.nvidia.com/XFree86/Linux-x86_64/325.15/NVIDIA-Linux-x86_64-325.15.run

(By clicking the link, you are confirming that you have read and agree to be bound by the License For Customer Use of NVIDIA Software for use of the driver.)

EDIT: 20140225 Thanks to bmarley for a link to this LinuxQuestions post:

I had the same problem when compiling webkitgtk3, the nvidia driver seems to remove this file, but it backs it up. Use

grep libEGL.la /var/lib/nvidia/log

and copy the file (/var/lib/nvidia/102 in my case) to /usr/lib{,64}/libEGL.la.

Slackware 13.37 Released

April 28th, 2011 No comments

Slackware-13.37 (and Slackware64-13.37) has been released today and I must say I’m extremely happy with it. I previously posted that I thought 13.1 was rushed, and it was, but this release is the polar opposite. Slackware-13.37 has been in beta for nearly two months and has been getting bugfixes, small updates and tweaks that whole time. I’m confident that this is quite simply the best version of Slackware ever to get through the stable door.

I want to personally extend my thanks to the whole Slackware team for their constant efforts to make the core of my infrastructure (and yours too) as good as it can be.

Want a copy now? Right now? Ok. Here’s the official torrents :)

Torrents for Slackware 13.37, 32-bit x86

Torrent for Slackware 13.37, 64-bit x86_64

Upgrading Slackware64-current with multilib

March 12th, 2011 No comments

In order to upgrade your multilib Slackware64-current box to a more recent -current (or perhaps 13.37):

  1. Make sure you have a copy of the version you want to upgrade to available.
  2. Make sure your slackpkg config points to it
mkdir -p /mirror/slackware
cd !$
lftp -c "open http://connie.slackware.com/~alien/; mirror multilib"
slackpkg update
slackpkg install-new
slackpkg upgrade-all
upgradepkg --reinstall --install-new  /mirror/slackware/multilib/current/{*.t?z,slackware64-compat32/*/*.t?z}
slackpkg clean-system

Bear in mind that you need to know what modifications you’ve made to your system in the “clean-system” stage. slackpkg will offer to remove any package that’s not part of the version you’re upgrading to. If you need to keep any extra packages that you’ve installed you need to make sure you don’t uninstall them at this stage. For this reason I heavily recommend that you blacklist SlackBuilds.Org packages in the slackpkg blacklist file.

NetBackup 7 Server on Slackware64 13.1

February 22nd, 2010 2 comments

Let me start by clarifying that I’m actually talking about slackware64-current as of Tue Mar 2 19:07:31 UTC 2010, but for longevity I have titled the post 13.1 because I believe -current to be pretty close to a 13.1 release and I will be updating this server to 13.1 at release and halting updates there.

That said, Symantec have released (Veritas) NetBackup 7. Woo. As insane as it sounds, NetBackup 6.5′s Linux server component was only available for x86 and IA64, but NetBackup 7′s Linux server component is only available for x86_64. Way to screw everybody over, Symantec(!)

Thankfully, this just happens to be beneficial for me as I am at the point of being able to move our NetBackup server from Solaris10-SPARC to Slackware Linux and it means that I get to deploy it on Slackware64. In this case, the server I am using has had alienBOB’s Multilib Conversion; but this is not necessary to support NetBackup 7.

Perversely, the new “OpsCenter” (x86_64) that Symantec won’t shut up about does require 32-bit libs, however it’s also much more tightly bound to RHEL/SLES. NetBackup Server works well out of the box in Slackware, but OpsCenter won’t install on anything but RHEL or SLES and manually extracting the RPMs and forcing it in is much more work that I can be bothered with for a component I probably won’t even need. As far as I can tell, the main reason they are giving away OpsCenter is because they want managers to see it so that they can persuade them to buy OpsCenter Analytics which I’m certain will not be cheap.

That’s the ranting out of the way. Onto the details…

Installation really is a breeze. I used the RHEL version of the installer (NetBackup_7.0_LinuxR_x86_64_GA.tar.gz) not the SLES version (NetBackup_7.0_LinuxS_x86_64_GA.tar.gz) because I am more familiar with RHEL than SLES and I have always been successful in the past using Veritas’ RHEL releases on Slackware. Feel free to play with the SLES version and report back.

Extract the tarball and run the installer. I used the defaults for pretty much every option. Feel free to change the install path from /usr/openv to /opt/openv for correctness, but I am personally very familiar with /usr/openv (as is the software, obviously) and the software lives almost entirely in that subdirectory without polluting the rest of the machine; so it’s a safe choice.

The installer will modify the inetd configuration and add entires to your /etc/services file and put two startup scripts (netbackup and vxpbx_exchanged) in /etc/rc.d/init.d. It will also put symlinks to these in the run-level numbered /etc/rc.d/rc*.d directories. Worth remembering that under Slackware /etc/init.d is a symlink to /etc/rc.d/init.d. In my previous post about running NetBackup client software on Slackware (http://blog.tpa.me.uk/2009/08/30/veritas-netbackup-slackware/) I suggested that you should remove the symlinks and move the netbackup startup script to /etc/rc.d/rc.netbackup. Technically I still believe that advice as I am somewhat of a purist, but I can also be pragmatic when necessary. Slackware has a startup script deisgned to deal with SysV-style scripts called /etc/rc.d/rc.sysvinit and there’s no real reason you shouldn’t just let it do its job and leave the NetBackup scripts where they are. It will certainly help out when it comes to upgrade time; you just have to remember to use /etc/init.d/netbackup (shortest option) rather than /etc/rc.d/rc.netbackup.

Now it’s time for…
The bit that will catch you out:

As is widely known, Slackware still does not contain PAM. There are reasons this is good and there are reasons this is bad. Pat is well aware of all of these reasons and continues to consider his options. In the meantime, we have to be aware of the lack of PAM and work around it where necessary (assuming you don’t choose to install PAM yourself, I know I don’t).

Awkwardly, there is one component of NetBackup server that requires PAM: /usr/openv/netbackup/bin/bpjava-msvc. Unfortunately it’s a critical component. In order to administer a NetBackup server, you use the Java NetBackup Administration Console. When you connect to the NetBackup server with the console, the server authenticates the request by launching the authentication service from inetd; which is bpjava-msvc. Unfortunately for us, and for anyone else that doesn’t have PAM installed (even if they are running RHEL) bpjava-msvc is linked against the main PAM library libpam.so.0 and cannot launch without it:

# ldd /usr/openv/netbackup/bin/bpjava-msvc
...
        libpam.so.0 => not found
...
# /usr/openv/netbackup/bin/bpjava-msvc
/usr/openv/netbackup/bin/bpjava-msvc: error while loading shared
libraries: libpam.so.0: cannot open shared object file: No such file or
directory

I have spoken with Symantec about this and they clearly state that NetBackup is not dependant upon PAM, in its absence the Java client authentication service will happily authenticate against shadow, it just happens that the binary is linked to the pam library so needs it to be present to run. While there’s not much they are prepared to do about it right now, there is an “Idea” in the Symantec Connect portal’s Ideas section that requests the development team deal with this issue, and it is the right channel for communicating with product development. If you would like to see the issue dealt with, I heavily recommend you “Vote Up” the idea to bring it to their attention:
https://www-secure.symantec.com/connect/idea/bpjava-msvc-linked-against-pam-unnecessarily-making-it-dependency-entire-application

In the meantime, there is a really ugly workaround. It wants libpam.so.0? Well give it one; just not the rest of the PAM package. If you get the latest PAM source and compile it, you can copy the libpam.so.0 file into the NetBackup lib directory and voilá; everything works perfectly. While you could put it in /usr/lib64 or put it in /opt/pamlib and add /opt/pamlib to /etc/ld.so.conf, I recommend putting it in the NetBackup installation to save from unnecessary modification or pollution of your system. KISS. So put it in /usr/openv/netbackup/lib.

And that’s all there is to it. Now to add your tape/disk/removable devices and setup your backup policies.

Thanks to Symantec, migrating from my Solaris10-SPARC system is not an option. Even changing the hostname of the NetBackup server is not a supported operation and will break everything unless handled very delicately. Symantec say the only way they will help you is if you pay them a bucketload for Symantec Consultation Services. Well I can tell you now that just isn’t going to happen. In practice this means I am going to have to import all historic tapes into the new system (http://seer.entsupport.symantec.com/docs/327873.htm), but thankfully I have a Sun StorageTek C4 Robotic Tape Library that will hold 32 tapes at a time and I only need to import 60 or so tapes. It will probably take the best part of a week, but it’s acceptable.

YMMV :)

Beauty, thy name is Slackware.

February 18th, 2010 No comments

Some days are just better than others.

I’ve just finished completely eviscerating a powerful server that was running Windows 2003 R2.

It’s now running Slackware64-current and very very beautifully so:

Kernel: 2.6.32.7
Kernel Image Size: 2299 KB
Module Tree Size: 33936 KB

CPU: Intel(R) Xeon(R) CPU E5345 @ 2.33GHz

Total RAM Available: 4054384KB
Total RAM Used (+/- b/c): 42240 KB

/dev/sda: 6x SAS disks
MegaRAID hardware controller
4 disk in RAID10.
2 global hot spares.

hdparm -tT /dev/sda:
/dev/sda:
Timing cached reads: 8206 MB in 2.00 seconds = 4106.44 MB/sec
Timing buffered disk reads: 552 MB in 3.01 seconds = 183.66 MB/sec

It’s name according to the Simpsons naming scheme?

Wolfcastle

:D

Slackware, 3ware & RAID61 = Win

September 29th, 2009 No comments

I have a new page up detailing my adventures in putting together a brand new storage system here at work with the primary purpose of increasing redundancy, reducing cost and increasing efficiency.

The page itself doesn’t look very good because I am still fighting with wordpress. I finally pick a theme I like, but the header css is god-awful. I’m no graphic designer and I thought WordPress was supposed to take care of that, well it doesn’t.

The link:

http://blog.tpa.me.uk/high-availability-storage-with-slackware-drbd-pacemaker/