The problem descriptions:
* Your system boots fine (maybe because it’s running on software raid), but your /dev/sd* files are gone.
* Your system doesn’t boot anymore, complaining about not finding your boot device when booting your custom kernel, but the stock kernel does work.
* Mounting partitions doesn’t work anymore, saying stuff like mount: special device /dev/sda does not exist

Reason:
* Your custom kernel has CONFIG_SYSFS_DEPRECATED enabled. To find out:

Since udev version 151 (or something close to that) this will sparsely populate /dev. Yay.

If you don’t believe it, check out /usr/share/doc/udev-*/README:

Another problem solved.

First stop: the installation on Slackware 64. (you may skip this if you run some flavor of Pokemon OS ).

As I mentioned in my previous rant, the developers of Awesome have decided that they’re complete and utter idiots. That is, they forced me through CMake, which usually fills me with anger. Fortunately they didn’t include Boost in the mix, so after some cursing it can be installed.
In order to get Awesome 3.4.3 installed, I needed to:

• Upgrade my xcb-proto to version 1.6 ** (source)
• Upgrade my libxcb to version 1.5 ** (source)
• Upgrade my xcb-util to version 0.3.6 ** (source)
• Install libstartup-notification version 0.10 or higher ** (source)
• Install libxdg-basedir version 1.0.2 or higher ** (source)
• Install libev ** (source)
• ** indicates that the whole ‘wget, tar, configure, make, makepkg’ riddle works fine with my slackbuild.pl script

That was pretty easy with slackbuild.pl. Note that you might have to recompile cairo to enable xcb support (it’s a configure flag that used to be disabled on Slackware). Mine didn’t need it though.
Next is building Awesome. If you don’t want Awesome scattered all over /usr/local/share you might want to give CMake some hints. See my previous rant about setting this permanently.
Today I used this:

After that, ‘make’ should compile it properly, and you can use slackbuild.pl to make a package out of it. (or make DESTDIR=bla, makepkg yadieyada).

Second stop: Testing Awesome

I still like to type startx every time I booted my machine, so for me the thing to change was the file ~/.xinitrc.
Something like:

Kill your X and startx, and voila! The first error.

Awesome's first error!

First impression: looks clean.
A tiny menu bar / panel / whatever you want to call it that shows the running programs and the date.
The default shortcut to do everything seems to be the windows button, or mod4. I’m not sure if I like this, since alt was already cramping my thumb every now and then
However, this can be changed, so no big deal. mod4-enter starts a console. Good. It’s fast too!
Hitting mod4-enter a few times looks like this:

Awesome after hitting mod4-enter a bunch of times

Needless to say there are tons of things to try out and customize, but you might want to check out this guide for starting out with awesome. I did

Maybe it will even replace Fluxbox…. we’ll see. Time to mess around with it some more.
Keep up the good work Awesome developers…. and switch to autoconf!

Last time I explained in detail the steps needed to build it on slackware 64. So I’ll only summarize and tell you about the new problems I ran into.
First, install libnotify. The new xpcom stuff seems to require it.

How I love my slackbuild sometimes

Next, get the FF3.6 source and build the xpcom stuff:

Finally, symlink the newly built xpcom tools over the google provided ones and build gears. I assume you can check out the google gears sources yourself, otherwise see my previous rant on this.

If you’re wondering about the CPPFLAGS, if you skip this the thing will break down completely. THAT’s why intelligent people use a configure script for that shit. Too difficult for google I suppose.

Anyhow, now we still want a nice .xpi installer.

Which barfs because some slut thought it also needed ff3(1) junk. Which I don’t agree with. So note that this breaks the .xpi for firefox ancient edition.

Tada. Installer at bin-opt/installers/gears-linux-x86_64-opt-0.5.34.0.xpi.

So I wondered how to figure out the problem. Digging around in libc gave some insight:

Say what? Will always fail? That explains…. but why?!
Apparently there is another libc library that normally gets used that DOES have the proper epoll support, it is in /lib/tls . Weren’t it that the tls dir was renamed because Xen complained about it, so it doesn’t get used.

No warnings. However, a quick workaround to test this conclusion with LD_PRELOAD:

Ha, that’s more like it. Yeah, it fails to start because I still have the beta 12 running in another dir, but it doesn’t give the error anymore.

Googling a bit to find some details on Slackware 11 and glibc gave me a discussion somewhere on a mailinglist that mentioned that the glibc in /lib was compiled against
2.4 headers, while the /lib/tls version was compiled against 2.6 headers. That explains!
In other words, time to recompile glibc against the proper headers.
However, that task is a bit too cumbersome to post here. Long story short: it took me half the day to meddle with the glibc.Slackbuild script (and get the right kernel headers installed, etc) and I finally have a new glibc which works.

So, if you’re looking for a quick fix: use the LD_PRELOAD trick. For the more daring amongst you: upgrade your glibc — but beware that this is a DANGEROUS thing to do since it will break many things. Of course you could also upgrade to Slackware 13 and be done with it

Anyway, Teamspeak 3 has a much better view of the world. They offer a -free- personal (that means non commercial!) non-profit license. This means if you’re a guild you can obtain a license
from them for free over here which allows you to host your own Teamspeak 3 server with 10 virtual servers and 512 slots. That’s more like it!
And if you ARE commercial, their licenses are well defined and very affordable. For instance a 1 year license for 25 slots is only $25. Compare that to Ventrilo 2 providers that ask you E10,- per month. Ha.
Oh, did I mention that they DO have a linux client? And windows and mac of course…. including the 64 bit versions. Lovely

However, as it’s still in beta I run into some problems every now and then. Today I was asked to upgade the b12 server to the latest. So I tried.
Result:

…. welcome back my friend…. BOOST …. always the fucking same with that piece of rubbish.
However, to be fair this could very well be a “learn to code” problem by teamspeak, but still… it’s always boost the brings the curses.
So what is it complaining now? I don’t have epoll? Seriously? Let’s see about that.

So that’s not it.
The forum has this thread suggesting it might be glibc that’s too old.
However, this particular slackware 11 server has glibc version 2.3.6, which should be old enough (according to that forum thread at least). Just in case it’s not I’ll try upgrading that later.
In the meanwhile I created a thread on this problem on the forums, let’s see what they suggest. I’ll put updates here.

Interesting. Suddenly I reminded myself of some Slackware updates that probably installed a new version of boost yesterday, replacing my own version.

Oh well, since it seems to be the libtorrent part that’s bugging, I might as well upgrade it:

(or you could have used slackbuild.pl, it’s easier )

After upgrading the package, deluge starts again. Wheee.

Anyway, suphp is still nice to have for simple sites that don’t get many hits or don’t need to be very fast. Therefore I wanted to have both options available. Here’s how.
I started out with the Slackware packages for php and apache, but soon found both to be inadequate. Php lacked some modules that some site wanted, and apache didn’t even bring suexec along.
However, the slackware layout is good enough so I altered the slackbuild script a bit and built my own apache. You might need to install some packages as dependencies though. For instance I didn’t have ‘expat’ and ‘db44′ installed.

Now edit the slackbuild file so it compiles with your compile flags. My changes were:
1. Changed VERSION to 2.2.14 (was 2.2.13)
2. Added these to the configure flags (to enable suexec) around line 103:

Compile and install it. Note that the suexec part requires root permissions, so I did this as root.

PHP and suPHP

Note that since php is a pleuris product it will ignore the DESTDIR variable that usually works for creating a package. If you want a nice package for php, consider using the slackware build script instead. (I was too lazy for it this time). Next suPHP:

That went smooth. PHP could learn something from this. Now we still need to configure suphp. To do this we create 2 files and alter httpd.conf a little.
First suphp.conf:

Personally I left most to default, but I did change the log path and the docroot.
Next we need to enable it in apache, but to keep module stuff in their own section we put this in mod_suphp.conf which we include in the httpd.conf.

That should be enough. Now for sites that you want to enable suphp, simply add a few lines to their vhost config like this:

Now you should have a working suPHP installation (provided that you restarted apache etc).
If something fails, check the logs, especially suphp.log and of course the apache error_log.

FastCGI

To get this running I loosely followed this blog post. It pretty much worked like Brandon explained, after I recompiled my apache for suexec support that is. Thus a summary:

Install FastCGI

Now for the magic part, enabling it in a vhost.
First we need a php wrapper script:

Note the -d apc.shm_size=64 option. This specific option is to set the cache size for APC, but this way you can give php custom settings per vhost. Neat huh? If you want to give this vhost its own php.ini you can add this to the script:

PHP will check for a php.ini in that dir. Make sure to check the permissions on these dirs though, especially on the wrapper script. Your users might do stuff you don’t want if you let them alter these things.
Finally to enable FastCGI per vhost, add something to the vhost configuration like this (make sure to disable suphp on that vhost!):

Restart apache and you should see stuff like this in the process list:

APC

Now for some speedup. Let’s see apachebench on that magento vhost without APC and FastCGI:

As you can see it takes more than a second to get the page to load. Well, 0.8s mean across all, but 2.5s per request.
Let’s install APC:

Restart apache and voila. Time for a new benchmark.

W000t…. that’s a lot quicker, almost 4 times as fast. Nice

So not wanting to give up immediately I decided to google for it a bit, and noticed that the Pokemon OS guys do have a gears version for their 64 bit Karmic and Lucid releases. Well, that must mean it’s possible! I took a quick look at their .deb file and didn’t see anything shocking, so I decided to try and build gears from svn.

Command not found? huh?

It’s right there…. ohhh, probably a 32 bit issue.

So maybe THAT’s why they’re incompetent (read: lazy). Let’s see if we can get xipdl in a way that doesn’t need ancient 32 bit rubbish
Mozilla has some stuff about that tool here. However, actually finding the download link for the source of that tool is challenging.
I’ll save you the trouble, you can get it here: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/latest/source/. Be aware, it’s a whopping 45MB download. That’s right, in the firefox sources.
Let’s see if it compiles:

After this we finally have a working xpidl executable that is actually 64 bits.

Back to GEARS! The easiest way I could determine to get it to work was replacing their xipdl with our new version. I’m sure there’s an easier way through setting an environment variable or something, but I got tired of their Makefile includes and third party libraries before I could work that out. The easy way:

Ghoooh, idiots. Maybe they should invest in a configure script or something. After messing with environment variables for a while, I decided that their Makefiles are about as kanker as their effort of giving us a 64 bit package in the first place. I would expect to be able to set CXXFLAGS="-include /usr/include/stdlib.h", but that was completely ignored. CPPFLAGS did seem to work however. Since another file missed another include, I added that as well.

RAAAH, this keeps getting better and better. This fix was simple enough, simply edit that header file and remove all occurances of ‘NS_OUTPARAM’, whatever the heck that might be:

Aha, they request warnings to be error by default. Seems like running it with MODE=opt fixes this issue.

GODQ@#($*@#*^%^& STUPID … *tries to contain the daemon within* … *RAAAGE*. Another missing include…. *sigh*

Needless to say building an optimized version goes to another directory, so now you need to do the above NS_OUTPARAM thing again on the interfaces.h file in the bin-opt dir.
Anyway, finally it compiled after messing with it for hours. Hopefully this log contains some useful info for you

Last but not least, we still need to make an installer for it:

Finally we end up with a bin-opt/installers/gears-linux-x86_64-opt-0.5.34.0.xpi that we can install in firefox. Phew.

Now what was I doing that needed gears anyway? … can’t remember. Feh.

Gears and Firefox 3.5.5 on Slackware 64

• It has to run on Slackware
• It has to run as a daemon (in daemontools if possible)
• There has to be an easy way to control and view the status, like a web based GUI.

A few years ago I used mldonkey for it. Worked fine, but their torrent support was getting worse and worse. (basically they didn’t update their product for ages, and when they did it didn’t improve much). It had a web interface that worked nicely though, and it was easy to control. Another cute thing was that it also supported other protocols that I still used back then like Edonkey.

However, at some point I got fed up with it and searched for a better product. Especially since I didn’t care about the other protocols anymore I could search for a pure torrent client. Many of them only support running as a client with some kind of fancy GUI… not good for running on our server. But then I found Rtorrent.
While it was a bitch to run on my server since it demanded to run in a terminal (and therefore refused to run under daemontools) — a problem I made bearable by running it in screen under a new user that was accessible through ssh keys — it worked very nicely. I had it running with a web interface called wtorrent.
But then yesterday I got very needy and demanded that it used IPv6 to connect to others. Sadly it fails to do that. Don’t know if it’s a configuration problem or simply because the author doesn’t have enough time to fix it. I tried the latest development builds and compiling it with –enable-ipv6, but it doesn’t seem to listen. In other words: time for a new client.

So after some searching I ran into Deluge. It seems to fulfill all my requirements, so I decided to give it a shot. A few bonus points are immediately earned because Deluge uses the more commonly used libtorrent, not to be confused by the other libtorrent that rtorrent uses. The bonus points are because the rasterbar libtorrent has plugin support among things and in general is a bit more up to date on the whole torrent protocol as far as I can tell. (makes you wonder why rtorrent doesn’t use it).
Time for installation!
Slackbuild had no problems chewing through libtorrent and spitting out a nice slackware package. However, Deluge is built in python so some manual work to get a package from it. (I seriously need to get some time to work on slackbuild to support this stuff).

Voila, a nice package. After installing it, and creating a new user for it, it was time to see if it would work in daemontools.
However, I didn’t check any dependencies so trying to run the deluge program failed:

Meh, xdg… fine. Fortunately python has easy_install as perl has cpan, so I installed a bunch of required things for it (like twisted, pyopenssl, chardet, mako). For xdg easy_install didn’t work though, so I handed it to easy_install using this url. After this it started up, even in daemontools! Another success.
For those who are interested, my daemontools run file looks like this:

You obviously need to adjust the paths and interface and whatnot to your own ideals
After starting it for the first time it created some configuration and state files and is now waiting for connections. Woohoo.

So now, how do we connect to it? Seems like the web interface isn’t running yet. This is because deluge uses a client/server model where the daemon does
all the work, but it doesn’t deal with the interface side. So to run the web interface we have to start a separate deluge process. Let’s also put that in daemontools:

After firing this one up you can connect using your browser on port 8112. Default password is deluge. After logging in you get the connection manager which shows the running daemon that you started up earlier. (or at least, that’s what it did here):

Deluge Connection Manager

configure: error: There is something wrong. Please check config.log for more information.

Gee, that’s really…. helpful. OF COURSE THERE’S SOMETHING WRONG, I’M TRYING TO INSTALL PHP!!!!
But let’s not get angry yet, I’m sure it’ll throw more tantrums at us while we try to chunk it together.
In case you’re wondering, I’m trying to configure php so it has curl support. Apparently php’s configure has decided for me that in order to have curl support, it also requires ldap.

“Then don’t configure it with ldap support!”
I didn’t. In fact, I explicity told it NOT to support ldap. –without-ldap. Doesn’t matter. Somehow it picked up the requirement to include ldap in the tests. After some searching I found out that the real source for this problem is the curl-config script:

Note the -lldap there. So basically this is Slackware’s fault. Meh.

Solution 1:
* Get rid of ldap in curl. This involves recompiling curl from source.
Solution 2: Probably the easiest way is to hack curl-config

Solution 3:
* Install the openldap-client package. However, now you have ldap on your system which you probably don’t use on a webserver.

I went for solution 1, recompiling it myself from the slackware sources:

After upgrading the curl package with this build it worked for me without the ldap nonsense.

Well, I’ll give you the details: it’s missing an assembler. You can find out about this if you actually bother to read the config.log file in the srclib/apr dir:

The simple fix: install an assembler. Slackware has the binutils package for that.
slackpkg install binutils, done.

Sun Oct 4 00:17:50 CDT 2009
ap/mysql-5.1.39-x86_64-1.txz: Upgraded.
This bumps the version of the shared libraries to .so.16.0.0.

Yeah, that’s all great, but for me this broke on several of my machines. Not because of the expected recompiles (after all, a new library, so stuff like vpopmail might need a recompile, I’m fine with that), but because MySQL failed to handle my configuration files on those machines. You see, I like my data more than I like MySQL, and prefer their InnoDB tables above MyISAM for that matter (yeah yeah, it’s still MySQL, whatever). Means I have some configuration lines about InnoDB in my /etc/my.cnf, like this:

So after the upgrade of the package, mysql came down as fast as it came up:

Aha… so, I need to run some kind of upgrade tool called mysql_upgrade, good that they told me about that in advance. (Thanks Slackware guys )
So we try running the upgrade tool:

Yeah… mysql didn’t quite come up because of the configuration issues, right. You’d hope an upgrade tool would fix that too, but oh well, guess we’ll have to do that ourselves.
In fact, let’s read what they have to say about it themselves. Upgrading from MySQL 5.0 to 5.1.
Let’s see…. backup, check… read this document… (gee, wonder what we’re doing now)… read about changes… yeah yeah, cute, plugin api, whatever… run the upgrade tool… yeah that failed. If this bla, if that bla… and then the magic:

If problems occur, such as that the new mysqld server does not start or that you cannot connect without a password, verify that you do not have an old my.cnf file from your previous installation.

Guess I do huh. So yeah, obviously MySQL starts fine whenever you empty the config file. But what about my old config settings? Are they still needed?
Apparently you can now choose betwen running InnoDB native or as a plugin. Guess I’ll stick to native.
Now for the fun part. Checking the options to put in the my.cnf file. Huh, the option that it barfed about still exists… how can this be? This document tells us how to set up InnoDB… nothing new in there. Conclusion: Slackware fucked up. (that is, you can probably run it as a plugin, but I don’t want it as a plugin! At least tell me about this in the Changelog guys!)
In case -you- want to run it as a plugin, the page I linked describes it. Basically you have to put this in your /etc/my.cnf:

Checking the mysql.Slackbuild script from slackware64-current confirms my suspicions:

Fine. So I change the mysql.Slackbuild:

Ironically, running the patched mysql.Slackbuild killed my running mysqld because of the famous OOM killer. Guess 1GB of memory isn’t enough for both compiling AND running MySQL these days :p
Anyway, it gave my a package, and after upgrading to it I finally had InnoDB back the way I wanted. Yeah, my old configuration file works fine again too.

****UPDATE****
Seems like the guys at slackware fixed it, from their Changelog:

So what things are missing in the vanilla Qmail 1.03 package?

• IPv6 support
• A ton of antispam features like SPF, DomainKeys, MFCHECK, etc
• Authentication support
• Filter support for stuff like Spamassassin, ClamAV, /dev/null
• Virtual domains

Probably more, but these are things I care about. Some of these points are not entirely true, for instance you could add filter support by mangling the .qmail files for all users, but these are things you want centralized so all things have to pass the filter, not for only a few accounts.
In order to fix the missing features I use a few things.
First of all: John M. Simpson’s combined patch. This patch fixes more than half of the list. It’s a collection of smaller patches all rolled together in a nice patch that cleanly applies to qmail 1.0.3 as supplied by D.J. Bernstein. Thanks a lot to Mr Simpson! His pages also have a lot of notes and scripts on how to get qmail up and running, and how to run the services from daemontools. You might want to check them out.
Next, I use vpopmail to handle the virtual domains problem. Together with qmailadmin they make the virtual domains thing very easy.

Anyway, that is all old stuff. New stuff is having Qmail working correctly using IPv6.
It’s easy to get it up and running, basically just compile qmail as usual and patch ucspi-tcp using Fefe’s IPv6 patch. Make a few new qmail-smtp services for the IPv6 enabled addressses and go!
While this does work for receiving mail, it fails for a few things in the combined patch – like SPF checking.
You will run into stuff like:

Obviously this is a lie, but at least it’s dealt with gracefully. However, you want SPF checking for the IPv6 address!
Fortunately, Brandon Turner has patched this with a patch that applies to Qmail 1.0.3 when already patched with John’s patch. Enough patches for you?
After recompiling and restarting your services you will see that it works now. Thanks Brandon!

What does Slackware have to do with this?
Nothing, I just like the way it runs the qmail services :-p

Through a mobile phone!

Lotjuh has an LG Chocolate (of which the battery is dying), and with it came a little cable that connects the device to a USB port. So hopefully I plugged it into my laptop. The one that runs pokemon os. dmesg showed some gibberish, but it was only about some kind of mass storage device it found. Bah.
The phone showed a screen with:

If you use modem, select “Connectivity-modem”

However, it didn’t respond to any keypresses. After disconnecting it again and going through the menu I finally found the holy grail that I was looking for. It was filled with candy. And modem. It was hidden at Menu -> Settings -> Connectivity -> Modem -> YES YES YES!!!
Connecting it again now gave cdc_acm 3-1:1.0: ttyACM0: USB ACM device. Woohoo!
But how do we use such a thing? And since I’m not bringing this laptop, how do we use it on slackware?

Google was more helpful this time and showed me wvdial. Sounds easy, so I got the wvstreams library and ran it through slackbuild. However, it complained about not finding Qt and readline. Qt was fixed by installing the official qt3 package and sourcing /etc/profile.d/qt.sh, but readline failed because of this:

This problem was quickly fixed by adding the ncurses library to the LIBS environment variable like this:

This time around configure didn’t complain anymore and we continued to build the package.
That also failed:

No surprise that it couldn’t find libdus there. Not only that, it’s the wrong library, I don’t have the thing statically linked.
Here’s a patch that suppsedly fixes it:
wvstreams 4.6 dbus patch - Version - SHA: d64703eb27da74348ac0e745c498138c78650f5c
You’d expect it to work now, but ha! It doesn’t. Somehow it fails to set DBUS_LIBDIR to /usr/lib (or /usr/lib64 if you have a 64 bit version of slackware), so help him with it and it’ll work:

Now it should compile fine after you run configure again (I used slackbuild of course) and you’ll have the wvstreams package. (it even worked on 64 bit!)

Next the wvdial tool was pulled through slackbuild.
However, this thing doesn’t even include configure, only a Makefile. So edit the Makefile to change the paths and use make to compile.
Or take my packages if you trust me for not formatting your harddisk and rootkitting your mom:
32 bit slackware 13 package:
wvdial 32 bit slackware 13 package - Version - SHA: c19693808861373fa403ea5e9caf427c2cc64924
64 bit slackware 13 package:
wvdial slackware 13 (i386) package - Version 1.60 - SHA: 19d67b45ca26542adc7967725483266415710ff6

Then finally, time to test the mobile connection!
First for the configuration of the modem, run wvdialconf and it will write a config file for you to /etc/wvdial.conf.

Next, edit the configuration file and change the Phone, User, and Password line to reflect your account that you got from your ISP. When that’s done you can finally try to dial up!

Woohoo, it logged in! At this point wvdial will be stuck until you want to disconnect (CTRL-C or kill).
Have fun paying for your expensive slow as dirt dial-up internet. But hopefully it will be good enough for me to check mail and play Billy this weekend

… huh? What’s taking so long? Our server with issues? That’s unlikely since I still used it 5 minutes earlier. After checking out the NFS server and deciding nothing was wrong with it (or at least, it didn’t look like it) I got fed up with it and went to bed.
Don’t you hate it when stuff stops working just when you’re tired and want to go to sleep? Fortunately for me this is our own internal problem so I could actually do so

Today I decided to go find out what the hell was wrong with it. So again I booted the machine to find out the above kernel messages.
Time for some tcpdump on the nfs server to see if that can shine some light on this situation. (needless to say there were no useful log entries anywhere).
Tcpdump:

Hmm, interesting. The first request seems to “work” (read: it receives an answer) while the rest of the messages are somehow ignored. Wonder why…
Just to make sure I checked the firewall on the server, which should allow pretty much everything:

Well, that seems to be true. Maybe something weird in the mount options? Let’s see the /etc/fstab for the NFS client:

Nothing weird… or is there? After messing around with it for a bit I decided it really wasn’t anything in there.
Time to do a test on a different machine in the network. On my workstation I tried to mount the root path after giving myself permissions and re-exporting the nfs paths:

And there it was, being stuck for what seems to be forever. So in other words: the mount worked, but then it doesn’t respond for the ls command. What… the… fuck.
Mind boggling, while the logs on the nfs server gave no hints at all. (as usual).
To make this even more interesting, there is another export on that same nfs server that most workstation use, called general_stores. (to access the music collection etc).
Can’t remember that being broken…. let’s test:

How can this be?! This mount works fine while the other doesn’t? What the hell is so special about that NFS client’s export?

And then it hit me.

*WHACK*
(ouch)

The window that I had open with the ls -al tmp suddenly decided to work. It gave this listing:

Doh! /proc … of course that’s the problem! That’s why tcpdump showed the “proc” entries!

But why?

Well, recently I moved some disks around and added a ‘crossmnt‘ option in the /etc/exports file on the NFS server.
This option gives the nfs clients the ability to cross mount borders, so for example if I have this on the nfs server:
* /mnt/disk with device /dev/sda1 mounted there
* /mnt/disk/stuff with device /dev/sdb1 mounted there
And then export /mnt/disk and mount it on my nfs client, I can see /mnt/disk/stuff with its contents because of the crossmnt option. Without that option the directory would be empty on nfs clients.

So how does this relate to proc? Well, since proc is “special” it has a ton of special files that nfs can’t deal with and therefore can not export.
Now normally this wouldn’t be an issue, since it shouldn’t be mounted in the first place (the nfs server has its own /proc, the nfs cilent mounts its own version so it only needs a place to mount it on). However, a little earlier my girly friend mounted it “because she had to build E“. Don’t ask.
E again…. always the same…
After unmounting the proc dir and rebooting the NFS client it had no more problems and booted fine.

Conclusion:
NFS can’t deal with proc. Don’t hide a mounted procfs in your nfs exports.
NFS sucks because of stuff like this, but I haven’t found anything better so far. Guess we’ll stick with it for now.

Anyway, I decided to upgrade my 0.9.15 installation since it still glitches every now and then.
With glitches I mean “The music played by mpd suddenly sounds as if you have quad damage in quake 3 arena and filter out most of the music frequencies”. You know, when you shoot a quad damage rocket through a hallway, that kind of sound. Restarting pulseaudio always fixes this. (I’ve been running into this glitch ever since I started using pulse). Seems to occur randomly though… sometimes when the server is busy, sometimes when switching from a .mod file to a .mp3 file, sometimes just when the lights turn on. You know the kind of glitch.
Other than I kind of enjoy pulseaudio, even though it’s a struggle to get going. It does allow our server to stream to other servers and stuff like that, which is very cute. Oh, and per application volume levels and mixing etc… also good.
This pulseaudio installation runs on our local server — in daemon/server mode — btw, on which we have connected our amplifier and speakers as to enlighten our office/game room/throne chamber.

So for compiling version 0.9.16 the first thing I ran into was libsndfile that was outdated. Version 1.0.17 was too old, so I ran slackbuild on the new libsndfile v1.0.20.tar.gz. Out came a package, upgrade, voila.
Next, I noticed the pulseaudio configure output telling me:

I kinda wondered why, since my system definately runs udev. In config.log we find:

Aha.
New challenge!
Let’s see if we can grab the official slackware udev sources and get them to run a newer package! Today the latest udev is udev version 1.4.6.
So I changed the udev.Slackbuild to pick version 1.4.6

Running udev.Slackbuild now soon brought another set of issues to my attention. The first being that the slackware patch for the rule generator breaks.
Without looking too much at the script I simply manually patched it and created a new diff. Here it is:
rule_generator.diff.gz - Version 0.1 - SHA: cf73f104543ce989fd11b383c440405110e915a2

Running the slackbuild now gave me a new error:

It never takes me long to realize that this error stems from the new kernel I installed earlier. (did I mention that linux 2.6.31 is released? ).
Google brought me this, which informs us about something that should have been in 2.6.31 if you ask me. Fine, we’ll fix it ourselves.
Another slackbuild run takes us past this error and gives us a new udev package. Inspecting the new package I noticed a /libexec directory that shouldn’t be in the root of the package. Meh, probably explains the configure: WARNING: unrecognized options: --with-libdir-name.
So we change the udev.Slackbuild again with some new configure options (stolen from their own INSTALL file):

Btw, can someone explain to me why I always manage to fuck up the file order to diff? (my patches normally come out reversed )
Here’s the complete file if you want it:
udev.Slackbuild - Version 1.4.6 - SHA: d550e146bdf34d1ad0e256936a94b7f9b7d62fd2

So after building and upgrading the package, it even restarted without glitches. Woei.
Back to pulseaudio!

Running configure now correctly informs us about udev being YES. HAL->udev compat still said “no” though. I don’t care for now, let’s see if it works.
My slackbuild.pl ran the make part and showed a ton of “leer coden, mongool” warnings (people should simply disable warnings if they don’t handle them if you ask me).
Regardless of the warnings the compilation completed and I now have a shiny new package.
After upgrading and restarting pulseaudio, there’s even sound coming out of my speakers when I hinted mpd to play. Woei.

Oh. Boost….. that time of the month. If there’s one piece of trash I’ve run into very often on my compilation expeditions…. it’s boost. What a cancer piece of trash that is. You wouldn’t believe the amount of cursing I’ve gone through on my trails through “build from source” land because of boost. It never works, and when it does it’s limping on. They should have called it “blast” instead.
These days boost is in the official slackware repositories. You’d think that would help, since I can’t mess up the paths etc anymore. (compiling boost is another disaster btw, don’t go there unless you like torture). But noo, as usual the programs that use boost (“because we can’t code ™”, or at least, that’s what I think) are so good at coding stuff themselves that they fail the autoconf for it as well. Prutsers. Well, to be honest, if they can’t code it themselves it’s probably smart to use a library that handles it for them….. but boost? :/

Anyway, back to qBitTorrent. Actually, it’s libtorrent-rasterbar that’s failing. Attempt 1, configure with only a prefix and no other options:

WHat?! Do you ahve Boost::System? Yes. I mean no!
… seriously, who comes up with this shit….
So we dig into config.log and find:

Or in other words: nothing we didn’t already know. FUCK.
Time for a trace.

…. /usr/lib? Says who? Not me, that’s for sure. idiots.
In fact, I’m quite sure that it’s in /usr/lib64.

Jup, as expected. Boost is kanker. Since boost doesn’t have the usual pkgconfig issues, we can only conclude that the reason is that either this configure.in was written by a moron, or that
boost supplies invalid tests for finding itself through the autoconf system. I suspect the latter, but that’s just me

In this case the solution is simple, since the configure script has an override option. Wonder why… maybe they ran into boost idiocies before?
The solution:

This runs through configure, it finds the boost garbage and runs through. And guess what? It even compiles!

The gist of this rant: autoconf is pretty useless if you make assumptions that autoconf is supposed to detect. If you write software, don’t assume this stuff, try to detect it.
Also: when it fails, give me an error message that is useful, not some generic error code. “Library not found” vs “library not found because libblabla.so doesn’t exist in /usr/lib”.

About qbittorrent: it’s a cute little torrent client for linux. Especially if you like faily lightweight stuff that does has a gui. The thing I like about those lightweight clients: they’re fast.
This one even has an RSS reader these days…. cute.
Here’s a screenie:

qbittorrent v1.5.0

So qBittorrent: keep up the good work, and get rid of boost

Since we got Xen up and running yesterday, it’s now time for actually having some fun with it.
The goals are:

1. Getting xend started automagically when booting without destroying my network connection
2. Getting a domU up and running with a network connection
3. Getting an internal network between the domUs and dom0, shielded from the big bad internet.

First things first, yesterday we got xen installed and all, but that’s about as far as we got before the bed was required. Xend almost got it right when it put a startup script in /etc/rc.d/init.d called ‘xend’, but alas, slackware will ignore that file. Personally I simply add the thing to /etc/rc.d/rc.local:

This fixes issue #1, but only the first part.

Before you reboot you might want to alter some xend settings. The file to molest for this is /etc/xend/xend-config.sxp. Mine looks a bit like this:

Almost everything is set to the default value. However, you will want to pay attention to the network-script part at the very least. As you can see I changed this to a little wrapper script.
I won’t go into detail about all the possible Xen networking stuff, see the mailing list and the Xen docs for that, but what we want is the external network bridged to all domU’s, so they can have their own network space there and their external IP address and whatever they want to do without having to mess around in the dom0. To get this working you could stick to the default (network-script network-bridge). Back in the Xen 3.0.3 days this molested my default gateway because their bridge script sucked (it failed to parse some stuff if I remember correctly), but when I tested it today it simply worked.

We want to have an internal network though, so we have to create our own bridge wrapper script.The only thing this script wrapper does is
1. call the network bridge script as the default would do.
2. create a second xen bridge.
Here we go:

As you can see I also add an internal IP address to the bridge. You can make this bridge setup script as complex or as neat as you want, but I can’t be bothered to spend more time on it. It works for me ™

Now that all that is in place, let’s try out the creation of a domU. For testing purposes I steal my images from what used to be jailtime.org, these days it’s called Stacklet. Too bad they don’t have a 64 bit slackware domU yet, but I guess I’ll create that myself a little later. Also, to keep stuff in a place where I can track it, I usually create a /xen directory where I store my host configurations and images.

Edit the slackware.12-2.x86.xen3.cfg file and fix the location of the image file and the kernel. I simply used the same kernel that I use to boot my dom0 for now. Now let’s try it! Try

and it should enter the console of the now booting domU. To get out of the console hit CTRL-[.

Over here I got a bunch of kernel warnings like these:

While these are a nuisance in dmesg, they seem to be fairly harmless. Somewhere on the Xen mailing list someone claims that you can disable CONFIG_DMI in the kernel to get rid of these, which I tend to believe but can’t be bothered. If I’m going to build a new kernel for my domU, I will take the latest vanilla kernel and add Xen domU support in that. It’s a mainline kernel option these days, you can see my post about it here: Xen and booting domU using a vanilla kernel
Login on the domU using root/password, note that your networking actually works, but you still have to enter an IP for eth1 if you want the internal network.

Woohoo, it works!

For an overview of the currently running domains you can use

The xm command has a ton of useful things, so check out the manpage/help for it.

For my real domU I will be using LVM partitions and install slackware 64 on it, but that’s fairly trivial to figure out once you’re this far. So have fun with your Xen install ^^

Needless to say I went for the source ball. Through my famous slackbuild script of course!
That went fine, until configure barfed about some CEGUI thing.
What’s a CEGUI thing?
Apparently it’s some kind of windowing/widget library. Yeah, another one.
So I ram it through slackbuild, which went fine as usual after I did a make distclean in the source dir. Some how the first build fucked up, don’t ask me why.
Anyhow, I installed the CEGUI package and ran back to the smc source dir.
Slackbuild had no other issues this time so out rolled a package. After installation I tried to run it.

Here’s what it said after my screen went black for about a second and came back:

Yeah, that’s what I get for trusting yet another crap library with widgets. *sigh*

However, I had just enough energy left to try one detour into bug/issue fixing land.
Google came up with basically only 1 thing, so after trying my best to read some italian forum I trashed it back through google’s own translation service.
Now that it was in dutch it was a bit more readable, it hinted about using the freeimage library instead of the default TGA codec (which obviously failed).

Installing the freeimage library was pretty trivial, although they don’t use autoconf so I had to go through their Makefiles manually.
The first hint of trouble is usually when source packages come delivered in the famous .zip format. Oh, sorry, I meant .ZIP-EVERYTHING_IS_CAPS format. Seriously, don’t get me started on how many times those kankerthings exploded in my /usr/src dir so far, completely splattering up everything there.
Good thing I’m good with rm. Anyhow, this zip package was decent and created a dir (without version number though).
After fiddling with the makefiles and building freeimage, I also build freeimage plus and stashed it into a package with makepkg.
Phew, sweat on my forehead. Hopefully slackbuild will be able to handle this some day….. (dream on)

Back to CEGUI — compiling it with the freeimage library went without problems, and after upgrading my previous CEGUI package it was finally time to retry SMC.
By the way, did I note that all these packages compiled on x86_64? Good job on that one guys

This time the screen actually came up with some mario^H^Hyo like stuff! Just like the good old days with the SNES!
It looked a bit like this:

On the background the theme music played that reminded me quite a bit of the original snes game.

Messing around with it a bit I quickly got myself killed a few times and had some fun.

I soon realized that the SNES version had better controls, but then again… playing on a keyboard is kinda cramped for platform games.
So I reconnected my Logitech Rumblepad 2 to see if it would work. Well, if works great
Not a snes pad (the thing is a lot like the original playstation controller), but it played a hell of a lot better.

Conclusion: if you’re feeling bored, give it a shot. Good for a bit of fun, and it has a level editor as well!
(which can be seen in this impressive edit I made here

Keep up the good work, guys from SMC!

So we fire up xpdf on the document, hit the print icon, lpr, GO!
*time passes*
Mhm, what is it now?
*check http://localhost:631*
Nope, no document there, seems like it was handled by the printer.
*check cups error_log*
Heaps of garbage there.

Remember that we had this issue left in our previous cups story? Something about PDF printing causing issues?
Well, since then cups got upgraded to version 1.3.11 and some other stuff too, like ghostscript.
This time the error log showed something like this (only the relevant part here):

Some weird definition of ‘successfully’ you have there, cups.
After a few hours of debugging through that error_log, fucking with filters in /usr/share/cups/filters (cursing at Brother for their half baked wrapper scripts), turning on and off debug and log options
I was getting more and more annoyed with it. Considering on how to pick up the Brother DCP-135C and smashing it through the 2nd story window onto the pavement, but then not being
sure if it really was the brother’s fault at all, I decided to make sure once and for all which one I had to throw through the window.

Time for a manual debug session with the filters again. If you are having trouble with stuff like this, I can commend it to you. The steps I took (after the usual turning on debug and log options etc):

1. Grab your input file, in my case some PDF document which I ran through xpdf.
2. Instead of sending it to the printer, print using the “save to file” option so we have the source that cups has to deal with to work with.
3. Manually run this file through the filters as cups does. I curse on cups for not being more specific — EVEN WITH THE LogLevel debug2 OPTION TURNED ON (it just becomes MORE unreadable, but without more information) — about how it runs these filters, but there are some shell scripts floating around that you can use. What I did was just use
   strace -qfve execve -p `pidof cupsd` -s 250

   to figure out how my filters were called, but be ready to read tons of output on that one
   Anyhow, to save you some trouble, the call syntax seems to be

   filterprogram PRINTER JobNum User title copies documentoptions [file]

   or a real example from my test case:

   /usr/lib/cups/filter/pstops "DCP135C" 666 benv jemoeder 1 "document-name=4a93e8d852a17 number-up=1 job-uuid=urn:uuid:873e2907-cf50-35e2-5626-741377b394be" "/var/spool/cups/d00666-001"
4. Find out which part fails. The pstops had some output that looked fine by me, as far as I can read postscript as it scrolls through my terminal.

Funny thing is…. it seemed to me like pstops worked fine, as did the brother cups wrapper….
However, there was still this soab left:

Execution of /usr/bin/gs showed up in strace as well btw, don’t worry
So now the big question was: when did ghostscript become retarded?

I took my “print to file” postscript document, and tried opening it in ghostview.
It just looked at me like a cow looks at an oncoming train. Or in its own words:

Ah-HA!

….

What?

Since I’m by no means an expert on postscript, I googled it. The search revealed that apparently this could be the result of an eps image conversion gone bad.
Postscript doesn’t like to deal with binary data, so it’s not supposed to be there.
This can mean only one thing!
xpdf failed!!!!!!

Some testing revealed that xpdf on the old slackware32 chroot environment still does work, and printing the exact same PDF file there works fine, while printing that document from the 64 bit
slackware envrionment fails with the above story. Fascinating. Seems like it isn’t a library issue though, unless it’s cleverly hidden in the X libraries. I hope they’ll fix this soon
Just for reference, this is the xpdf-3.02pl3-x86_64-1 package that fails.

Well, now that we all know the details we can go to bed.
And if you need to print that pdf document: simply use pdf2ps, it works. (and stay away from habbokrat reader)

Solution:

Now it -will- run through configure. Thanks. (yeah yeah, it’s hidden in the docs somewhere).

*edit*
This works for rrdtool 1.4 as well.

It’s a tiny little shell script that takes the configure options and barfs out some prefixes and stuff based on the options presented to it.
So when I tell it prefix=/usr, it will decide that sysconfdir=/etc instead of sysconfdir=/usr/etc.

You can get my my version here:
config.site - Version 0.1 - SHA:

Now the important tidbit. In order for configure to automagically use this script, you wil need to set the environment variable CONFIG_SITE.
Personally I do this through a profile file. Download the config.site script, put it in /etc and put the profile file in /etc/profile.d. Logout/login, done.
Oh, here’s the profile file:
config_site.sh - Version 0.1 - SHA: 3a6145987d03811f274ace34f5d08738f266f131

Now if everything worked out allright, running configure should start with something like this:

Wonderful isn’t it?

So after the latest local root exploit thing, and testing it on some machines during har2009, I figured it might be nice to get the patch into my kernels. Running a webserver usually means you’re at risk after all, especially when it’s running wordpress

So I grabbed the latest kernel that had that patch and went for the usual make menuconfig ordeal. After half an hour of selecting “yes”, “maybe”, “I guess so”, and
some XEN options (CONFIG_PARAVIRT_GUEST=y, CONFIG_XEN=y, CONFIG_HVC_DRIVER=y, CONFIG_XEN_BLKDEV_FRONTEND=y, CONFIG_XEN_NETDEV_FRONTEND=y, CONFIG_XEN_KBDDEV_FRONTEND=y, CONFIG_HVC_XEN=y, CONFIG_XEN_BALLOON=y, CONFIG_XEN_SCRUB_PAGES=y, CONFIG_XENFS=y, CONFIG_XEN_COMPAT_XENFS=y) I built the thing.
As I usually build bzImages I also did so here. make bzImage modules modules_install.
Half an hour later I had a shiny bzImage. Let’s try it on a test domain!

I copied the bzImage to /boot, changed the kernel = "/boot/vmlinuz-xen-old" option to the new place, and GO!
This is what it told me:

Huh, where’s my console?
Checking xm list it seemed to be there… but paused… and with constantly increasing ids. Waaait a minute!
Checking the log files (xend.log in this case) revealed a secret:

Note the ‘WARNING’ line. Crashed?!
Gee, that’s … interesting. Why? Took me 5 minutes to find the other log file, but xend-debug.log had a magic line:
ERROR Invalid kernel: xc_dom_find_loader: no loader found
… great. Another why.
In case you’re wondering, the increasing status in ‘xm list’ was caused by the on_crash = 'reboot' line in the xen host config.
I quickly destroyed the doman and changed it to a oneshot try: on_crash = 'destroy'

After some searching another hint presented itself. Aren’t they nice?
This hint was: “Xen is a retarded piece of cancer and can’t decypher the bzImage format, try vmlinux instead”. Aha!
Back to the kernel, make vmlinux, copy, and another try to boot it. Obviously this was way too simple. It still crashed.
Checking my old kernel that works for both dom0 and domU with file I noticed that gz should at least work.

Some more details about the crashing domains can be found using xm dmesg
It gave me something like:

As you can see, that’s really useful…..

A useful page with some info can be found here. It confirms that a gz kernel should work (but bz probably doesn’t) since I’m still running Xen 3.2. However, I can’t find a good reason for why it won’t work.

Google to the rescue! Hard to find a useful keyword, since most xen kernel issues seem to be similar, but eventually I found this tidbit:
tiny kernel patch.
Weird that this should be needed, one would hope that basic shit like this would work after 8 kernel versions, but obviously they’re all retards when it comes to this.
Thanks Jeremy Fitzhardinge for the patch!
Just for quick reference, this is the actual patch:

So much for ‘vanilla’.

However, it boots now:

and a lot more yadieyada until it hits a new wall: root device.
Well, that sounds solvable.

In fact, here’s a solution. What you say?
“AAAAH, I GET NOTHING, IT WON’T EVEN CRASH ANYMORE, JUST NO OUTPUT???!”
Ah yeah, I forgot to mention: they changed the console device as well as the block device. So here’s a solution for both issues:
Edit your xen host config file and make it so:

(xvda1 is what used to be sda1, you can figure out the rest).

And after all this: HAHA! Success is mine!
Except of course for the undeniable fact that my domU has a fucked up fstab and all, but no issues there
Now go mess up your own system! Oh, I see… you already did. Good luck fixing it

Update

I just tested a testing kernel — 2.6.31-rc8, and it seems like they fixed it. Probably has been fixed in the testing branch for quite a while now, but still not in stable 2.6.30
Let’s hope they release 2.6.31 soon.

Attempt 1:

Easy. It even works, the printer starts rumbling and out it comes. Oh…. seems like the barcode is a bit screwed…. mhm, wonder how it managed to do that. (the rest looked fine).
Browsing through the cups error_log gave some gibberish, this line caught my attention:

Mhm, interesting. Google returned a bunch of filter thingies, and I was like “maybe it’ll work better if I try converting it to ps myself first”.
So I ran pdf2ps (instead of pdftops as cups does) and viewed the resulting ps file. Looks a lot better. Print it!
lpr on the file, and out it comes. Huh, no landscape? I try lpr -o landscape stupidfile.ps which also does portrait. RAAAH, STUPID KANKER CUPS.
After an hour of google and cursing I said “Fine, you do it” to lotjuh, who asked me earlier if she had to do it with her Habbokrat Reader…. what a piece of garbage that is….

Anyway, lotjuh soon ran into a new issue. First of all, her new Windows 7 didn’t have a printer driver, and trying to install the Vista on failed. Our printer is a cheap Brother DCP135C, which isn’t THAT old I thought. Oh well, that’s your windows problems for you
So she booted to linux. Surprise! Print didn’t work. That is, it said “OK” but out came nothing. Jobs just collected at her local cups.

*grumble*WHYYYYY???

Debugging this is a tough, since none of the logs give any useful information whatsoever, even in debug mode.

To understand this problem you might want some more network background info:
We have our internet through xs4all, who gave us a Fritzbox for that. Since I couldn’t get it to work like our previous internet setup with the external IP address on our local server,
we eventually decided that the thing could route for us, but we have our own DHCP server running on our local server.
So in our LAN the default gateway is the fritzbox, but our local server has most ports forwarded to it. In order to also run a dns server and dns cache it has multiple IP addresses in our local lan.
In fact, it has 3 IPs in the 192.168.1.x range on a single ethernet device.

Back to cups:
In cupsd.conf I have Listen 192.168.1.1:631. That should work, right?
However, BrowseAddress only accepts a .255 at the end, or an @IF statement. So I had @IF(eth_local) there.
Result: clients get confused, try to send data to all 3 IP addresses on the network. And since I can’t put the primary IP address in the BrowseAddress…. it fails.
My guess is that cups detects all 3 IP addresses on that interface and happily announces those, while only 1 of them should be used. Especially because of the listen statement.
I fixed this by using the second address, which I conviently have on a ‘different’ ethernet device eth_local:0. This seems to work a lot better, the clients now have a single printer in their cups
configuration and it even provides its location!

instead of the old

However, my first problem was still present. The whining about invalid PDF files. Printing from KWord also gave this error. The local cups would happily forward my job to our server, which then barfed on the thing:

… well, that’s just lovely.
(insert your curse of the day here).

Oh btw, if anyone ever wonders about the status of their printer and cups and everything:

So far I haven’t found a solution for this problem yet, except for a print to file, scp, manually convert, lpr style workaround, but that’s tedious.
If anyone knows, I’m interested in the cause and fix for it.

What the…. CDT ? When did we move?

Well, not recently… that’s for sure.

Note that this box is running an ancient slackware version – 11.0. I keep it up2date regarding security issues using slackpkg and half the stuff running on it is built by myself anyway.
And so I realized that glibc-zoneinfo was recently upgraded to version 2.3.6. Ah yeah…. and so we suddenly moved.
Checking another box that had the same update a few days ago I found it had the same problem. Joy.

I see 2 solutions, except for “wait for the slackware fix”.

• # rm -f /etc/localtime
  ln -s /usr/share/zoneinfo/CET /etc/localtime
• # rm -f /etc/localtime
  ln -s /usr/share/zoneinfo/Europe/Paris /etc/localtime

(of course there are plenty more solutions, like recompile glibc, but I’m not in the mood for that).

For testing timezones, you can use this:

Or for figuring out what zone a timezone file is:

Go view it if you run slackware, or get bent if you run anything else.