My company has been bought. While this means a lot of good and bad all over the place, it means one thing that’s very sad; I am about to commence work on tearing down the network I have so lovingly crafted over the last four years. Within a year I don’t expect there to be more than one or two Slackware boxes still running, if any. Black armbands please.
I was trying to build partclone to read an image created with clonezilla, and discovered it won’t build with XFS support on Slackware because Slackware lacks libxfs.h. I think this is somewhat intentional in that the XFS Makefile only installs the header if you explicitly target “install-qa”. It seems libxfs.h is only supposed to be used by XFS devs and 3rd party software should not require it, and I’m happy with that.
Just in case there is a reason you should need libxfs.h on Slackware:
You now have libxfs.h installed at /usr/include/xfs/libxfs.h
If you are building your own packages from SlackBuild scripts, then you need to make sure your umask is 022 before you start!
Because of the nature of the shared environment in which I work, I changed my default umask to 002 in /etc/profile. I’ve just discovered a big problem as a result. When directories such as $PKG/etc aknd $PKG/usr are created as part of the SlackBuild, they are created with file permission 775 as per the umask. Then when it comes to installing those directories from the package, the installer overwrites the permissions on the directories in your system with the permissions set in the package.
So, if $PKG/etc was created with 775, your /etc directory will be modified from 755 to 775 and this can do harm. This especially the case with directories such as /etc/mail which are checked by daemons for security before they run. If the permissions are too loose, the daemons don’t run.
Before you run a SlackBuild script, check that your umask is 022!!
I have a right pain of a problem in this network in that individual machines are slow to get network access at boot. I haven’t had the opportunity to properly find out why, but my instinct says the blame lies with the Allied Telesyn switches.
The big problem this causes is that any machines with a remote filesystem, such as an NFS share, in their fstab fail to mount the shares at boot; which means I have to manually ssh in and issue a mount command as root.
The solution is to ask rc.inet2 if it would kindly consider waiting just a little longer for the network to come up and not mount remote filesystems if it doesn’t.
The following patch attempts to ping an always-on host, preferably the host that serves the filesystem(s) you are going to mount.
rc.inet2.diff (download rc.inet2.diff.gz):
In order to apply the above patch, do the following as root:
Do not forget to manually edit your newly patched file to replace “<known up host, or remote filesystem server>” with a valid hostname or IP address.
By default, USB support does not work when installing VirtualBox PUEL on a Slackware host. Essentially it is a permissions issue. There are a number of ways around it, but the simplest is this ridiculously small change to rc.S.
rc.S (downloadable rc.S.diff.gz):
This patch effectively changes the automatic permissions on USB devices so that the group owner is the plugdev group and so the group owner has write permissions. Make sure any users in the vboxusers group are also in the plugdev group… but you knew that.
In order to apply the above patch, do the following as root:
Or just make the change by hand, given how small it is.
As per the release announcement Slackware 13.1 has been released. Unfortunately I have to report I am less than happy with the 2.6.33.4 kernel with which it comes. I have come across too many bugs over too short a period of time to be able to trust this kernel with production servers; and this is a huge shame. Usually the only OS I’m truly happy to trust for my production servers is Slackware. It has always been simple, stable and secure. Unfortunately stable is just not the right word for 13.1. It feels rushed. It’s just not quite ready. If anything it feels like 13.1 is a running snapshot of -current rather than an end result. Pat has been tracking KDE SC and other software pretty closely putting the latest releases into -current as soon as possible and the current selection doesn’t feel like a well-tested stable collection, but just an arbitrary snapshot in time.
To be fair, most of the software in 13.1 is working pretty well without fault. Certainly I’m not aware of any specific complaints with the latest KDE SC, but the kernel is another matter. The 2.6.33.4 kernel has some major problems. There’s a bug between the versions of LVM and DRBD that causes massive data corruption. There’s a bug in LVM startup scanning that stops some LVM devices from being properly configured. There’s new ACPI bugs. All of these being major problems for production systems.
In practice this means that all my production stuff is halted at Slackware 13.0 which is pretty rock-solid. I really truly hope that Pat is planning to run a 13.2 in a few months and more than that I hope he doesn’t bow to any pressure to release anything prematurely. To give an indication of what I mean, it took just two weeks for Slackware 13.1 beta1 to go through rc1 and rc2 all the way to full release and in the melee it appears Pat forgot to update the README files in usb-and-pxe-installers.
Also, to clarify my concerns about the kernel, there are a number of features in 2.6.33 that people have been asking for but it is brand-spanking new and will only be supported for 6 months or so. Pat missed a golden opportunity to release 13.1 with the 2.6.32 kernel which is very stable and well tested and will be supported for between 2 and 3 years because it has been designated for long term support.
Could the people who really wanted a 2.6.33 kernel not have upgraded to it on their own without taking the whole stable Slackware release with them?
I can only hope for my own sake that 2.6.34 (or at least 35 or 36) proves itself rock solid so that I will be able to upgrade the servers that matter but still have a kernel I can trust.
Basic, but not obvious if you haven’t done it before.
Firstly, there are two options, the open source driver and the proprietary driver. Many people use the open source driver, I prefer to not. NVidia made the GPU, why not use their driver as it’s most likely to be the best performing option (and allows for VDPAU too). So that’s what these instructions are for.
Now that you’ve picked the proprietary driver, there are two more options; you can either use the installer provided by NVidia, or use the nvidia-driver and nvidia-kernel SlackBuilds provided by Heinz Wiesinger. Personally I use the NVidia-provided installer for a few reasons:
That said I have the utmost respect for Heinz’s SlackBuild and recommend you consider it as an option depending on your needs, especially if you are playing with different setups rather than just doing a one-time install on a box for which you know exactly what you need.
So, off we go..
Firstly, read my post about the nouveau kernel module: slackware-current and nvidia
Option 1: NVidia Installer
Then go to http://www.nvidia.co.uk/Download/index.aspx and get the latest driver for your architecture. Right now, for me, this would be:
Then head to tty6 (Ctrl-Alt-F6), login as root, drop to runlevel 3, make the installer executable and then run it:
Go through the installer with all defaults. If you are on Slackware64 with multilb (as so many are) say yes when it asks if you want the 32bit compatibility bits.
Once it’s done, you should find yourself with a new xorg config in /etc/X11/xorg.conf; but don’t start X back up just yet, you need to strip some lines out of the xorg.conf so as not to confuse X. In Slackware 13.0+, xorg takes its information about your input devices from HAL (see Slackware 13.0 – Xorg + Hal). NVidia doesn’t acknowledge this and adds default entries in the xorg.conf it creates for a mouse and a keyboard.
Here is a default xorg.conf created by the NVidia installer (this is an example, don’t just copy and paste.. do what I tell you to with YOUR copy):
And here’s what you need to make it look like by stripping out the input parts:
Of all of that the absolute minimum you need is:
But I recommend keeping the other bits that NVidia provide because if you use nvidia-settings later to specifically adjust your config, there may be a number of options it sets and the xorg.conf it will generate will include these anyway. So just take what NVidia give you and strip out the input devices as above.
Option 2: SlackBuilds
Install nvidia-driver and nvidia-kernel. I recommend doing so with sbopkg.
Then create yourself a valid xorg.conf. If you’re not sure how, then you won’t go far wrong with using the default NVidia-created xorg.conf from above.
Finally…
Once you’re done, you can start X back up, either by issuing “startx” at the command line, or re-entering runlevel 4 with “init 4″.
Now that you are back in X you should have fully functional DRI and compositing.
If you have a non-standard setup such as multiple-monitors or you need to boost the gamma on a bad monitor or something like that, then you need to configure the driver to do what you want. This is done very simply with the NVidia configuration tool:
Play with the settings however you need, but remember that this is not Windows. Clicking “Apply” will apply the settings for this session only. If you want the changes to be permanent you must save the settings to a new xorg.conf. Since you’re not running X as root because you’re not an idiot, you will likely not have permissions to overwrite the xorg.conf. There are ways around this, but the simple way is to just save the new xorg.conf in your home directory and move it to /etc/X11 manually (remembering to back up your working copy first).
And that’s it. Go enjoy your new graphics driver and, if your GPU supports VPDAU, go get the VDPAU-enabled MPlayer too.
Have fun!
For those hoping to update to slackware-current (2.6.33.1) and make use of alienBOB’s KDE SC 4.4.2 with PolicyKit packages, you need to be aware of one caveat. If you use the proprietary NVidia driver, you will need to blacklist the nouveau driver in order for it to work.
/etc/modprobe.d/nouveau.conf
UPDATE: 20100428
A package has been added to slackware-current to do this for you:
x/xf86-video-nouveau-blacklist-noarch-1.txz
This is a the text of a support case I have just raised with Symantec regarding administration of NetBackup Server 7.0:
Support has been dropped for 32-bit Linux clients. I appreciate that NetBackup Server will still work with v6.5 on 32-bit Linux hosts.
However, the java client for administering the NetBackup Server installation is not a 64-bit application, it works regardless of the environment so long as a valid JRE is available. However, the way it is distributed is such that it cannot be installed on a 32-bit Linux machine and I do not see why.
I do my daily work from a 32-bit Linux machine. This machine is not a backup client nor does it need to be. All I need is to be able to administer the NetBackup server. Up to now I have been having to remotely access the NetBackup server and send the display back to the X server on my 32-bit machine in order to administer the server. This isn’t really an acceptable solution.
Obviously, the first thing I did was to try the java administration client that comes with NetBackup v6.5, however much to my amusement, the 6.5 client refuses to speak to the 7.0 server.
This leaves me only with the option to use the 7.0 Java client on a 32-bit Linux machine.
I cannot use the cp_to_client script as it detects the lack of an x86_64 environment and dies. I cannot use the extract_java script because it lacks a client environment to install into. I could screw around with these scripts to bypass the checks but it’s a waste of time considering how little the java client actually is and would leave me with 64-bit client software I neither want nor need and a 64-bit JRE.
Bottom line:
I installed the 6.5 client software, removed /usr/openv/java and manually extracted NB-Java.tar.gz over the top. To provide a JRE I successfully tested both the JRE that comes with 6.5 (1.4.2_13) and my own installed JRE (1.6.0_18) and both work flawlessly.
HOWEVER.. I first had to modify jnbSA (and jbpSA not that I use it) to remove the setting of the PLAT64FLAG=”-d64″ variable.
Having done so, the client works absolutley perfectly on my 32-Bit Linux machine just as I would expect it to, being a java application.
So, the question is.. why have you done this? I can understand, if not condone, your wish to kill multiple architecture support for the Server and Client software, but regardless of the platform the backups run on, the System Administrator needs to be able to administer the system from wherever he/she works.
Since you already have a working java admin client that works perfectly on pretty much anything with a JVM installed, why are you going to such lengths to prevent it from running on a 32-bit Linux machine?
In order to provide this ability all you need to do is ship a 32-bit JRE as well as the 64-bit JRE (or even just allow a user to specify the location of his own JRE if he has a 32-bit client) and provide an installer that will install it regardless of the platform or whether the backup client software is also installed.
I could personally knock such a thing up in about 10 minutes, would you be prepared to?
The response from Symantec support:
As you know, the Java GUI is provided as a bundle for Linux and is not separated out into its own install. Because of the limitation of x86_64 Linux servers only that they decided to place on the product, the install script includes a check for x64.
At this time, Symantec does not plan to release an x86 installer version of the Java GUI for Linux. As you know, this isn’t due to any limitation, but it’s due to a decision made by the developers. At this time, I do not believe any plans are in place to create an x86 installer package for the Java GUI on Linux, however we can help speed up the process. We have a community enhancement request page http://seer.entsupport.symantec.com/docs/318008.htm where enhancements can be voted on and pushed into the product faster. This site is monitored by the Product Managers. The more votes an enhancement gets, the faster it gets implemented.
Since the only way this little mess can get sorted out is to have customer support for it demonstrated through the Ideas portal, I have again created an Idea on the portal and would appreciate any interested parties voting up the idea to bring it to the attention of the product managers.
My DRBD SlackBuild has been updated for 8.3.7 and split into two: drbd-tools and drbd-kernel.
They have been submitted to SlackBuilds.Org and are available there. They have been updated for proper Slackware64 compatibility and include notes regarding DRBD entering the Linux Kernel as of kernel 2.6.33.
TAKE NOTE:
Slackware{,64}-current has moved to kernel 2.6.33. DRBD’s kernel code is now part of the Linux kernel. You should not attempt to install drbd-kernel on a system with a 2.6.33 or later kernel. While it is technically possible, version 8.3.7 will not compile externally against 2.6.33. A fix is pending for the next release of DRBD but is nonetheless not required.
Users of Slackware{,64}-13.0 and earlier should use both packages.
DRBD v8.3.7 Kernel Module SlackBuild
DRBD v8.3.7 Userland Tools SlackBuild
Recent Comments