BenV's notes

So far I like what Valve has been doing with Steam on Linux. Obviously there’s always a lot to be improved, but they try and it works pretty well for me.
Since they don’t have a native 64 bit steam client yet and I don’t want to clobber my Slackware64 install with multilibs and other 32 bit garbage I still have my old 32 bit Slackware-current install mounted that I can chroot into and run 32 bit garbage.
Running steam for me looks a bit like:

benv@steammachine:~$ su -lc "chroot /slackware32"
Password: jemoeder
root@steammachine:~# su benv
benv@steammachine:~$ steam


A bit of a hassle but it works, and I need that 32 bit chroot for running windows garbage in wine32 anyway.

Lately I noticed a lot of games that have a linux version under Steam crashed. When running them a window pops up, disappears, and your last played date is set to “Today” in steam. Trying to run the game on the console shows something like this:

benv@steammachine:~/.local/share/Steam/SteamApps/common/Ittle Dew:0>./IttleDew.x86
Set current directory to /home/benv/.local/share/Steam/SteamApps/common/Ittle Dew
Found path: /home/benv/.local/share/Steam/SteamApps/common/Ittle Dew/IttleDew.x86
Mono path[0] = '/home/benv/.local/share/Steam/SteamApps/common/Ittle Dew/IttleDew_Data/Managed'
Mono path[1] = '/home/benv/.local/share/Steam/SteamApps/common/Ittle Dew/IttleDew_Data/Mono'
Mono config path = '/home/benv/.local/share/Steam/SteamApps/common/Ittle Dew/IttleDew_Data/Mono/etc'
Aborted (core dumped)

The reason was simple, but took me a lot of digging through strace etc to figure out. (gdb didn’t help since the included libmono that caused this segmentation fault was obviously stripped). At some point the program tries to read from /sys/devices/, which failed since I hadn’t bothered to mount /sys in my chroot. My mistake. (note that I did bother to mount /dev to get gamepad support etc).

Strace output:
[pid 16978] openat(AT_FDCWD, "/sys/devices/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
segfault

Conclusion: make sure that Steam for Linux games have access to /sys/devices/ 😉

At work they’ve been busy changing the building a bit. In fact, lots of bits. This resulted in me having to indicate how and where they had to move the server rack to, and having to point out obvious facts such as that the cabling has to be redone.
So last week they moved the rack, fucked up the cabling and wondered why outgoing phonecalls didn’t work anymore (“because you put the line jack in the wrong port”) and why the printer didn’t work (“Because it doesn’t work on a telephone line, try connecting the network port next time”) etc.
Another casualty of this was the windows 2008 server. Scheduled to be replaced by a virtual machine soon(TM) along with the rest of the obsolete hardware in the rack, it decided it wouldn’t boot anymore after being shutdown. Fortunately giving it a new power supply helped it move along for another couple of days.
Today however, after another shutdown, it didn’t want to boot anymore again. Being sick of the old failing hardware I decided to move it temporarily to a new workstation for the CAD division until the new server is ready. The old hardware was a lousy Pentium 4 (3Ghz orso) with 8GB RAM, the temporary workstation is a HP Z420 with a quad core Xeon E5-1620 and 16GB of ECC. Quite an upgrade…. if only windows would agree.

The problem with changing hardware in windows is simple: It’ll BSOD on boot. Who cares about your business, you changed the hardware, so you’d better make some time to either reinstall windows (from backup if you’re lucky) or kick it hard enough to work on the new hardware. Microsoft has some details on fixing it here.
For me it fortunately would still boot in safe mode, where I could issue from an administrator command prompt:

BCDEDIT /set detecthal YES

After this it would reboot without a BSOD and I could get busy installing 23984732984723 drivers, obviously starting with an ethernet driver. (in 2013… still having to install ethernet drivers for run of the mill broadcom cards… pffrt.)
Oh well, at least I didn’t need a reinstall. YET.

Did I mention it wants to be reactivated? 😉

One of my older (stable, works like a train) database servers still on Slackware 11 — well, heavily modified Slackware 11 😉 — is running MariaDB 5.1.something. Because I was tinkering with mysql settings I decided ‘hej, let’s see if upgrading to the latest version is a fun project!’.
Well, it sure is 😉

First of all, the newer MySQL and therefore also MariaDB versions have dumped a perfectly fine autoconf system for Cancer Make aka CMake. Well, that’s just great. There’s no cmake in Slackware 11, so I figured to grab the latest slackware cmake sources and build it myself. No big deal, except in order to use the latest slackware sources you’ll need tar with xz support. Well, while we’re at it anyway might as well build them. So I headed over to the nearest slackware repository and built myself a new xz, tar, findutils and pkgtools using the slackware 14 build scripts (slightly helped/modified to handle the absense of xz in my old system). There, now back to cmake. (continue reading…)

If Opera continues living the way it does right now it’ll die within a few years. At least, that’s what I expect. Every new release there are more and more little nuisances. New features? Yeah, they have plenty of new garbage slowing the browser down.
Soon they’ll dump their rendering engine for Webkit. Who knows, it might even improve the browser, but then again… soon I might jump to Chrome or another piece of garbage.
I wonder why browser vendors have determined they all have to inject cancer into them. Must be contageous or something.

Anyhow, my Opera issue for today: Webfonts.
Ever seen a page rendered like this?

(continue reading…)

Those of you running Slackware 14 or current probably have noticed the move to the Apache httpd v2.4 already.
On my webservers I haven’t yet dared to upgrade from the stable 2.2 version, but I figured it might be a good time to test out an upgrade procedure.

Notable problems / changes

This new version of the Apache httpd brings a few things that you should really pay attention to before attempting to upgrade. Well, you could ignore it, but it would surprise me if you wouldn’t end up with a broken webserver 😉
So you might want to look into these things:

1. Configuration syntax changes
2. Handling the Pleuris-Hoeren-Paaltjes aka PHP disaster
3. Switching to the MPM-event module

Of course you’ve already done your homework and read upgrading to 2.4 from 2.2, right? 😉 (continue reading…)

Just for fun I’m coding a bit for Android these days. No fancy setup so far, I’m using eclipse under my 32 bit Slackware chroot. (64 bit eclipse is no problem, but those failures at Google haven’t had the decency yet to bring out their SDK for 64 bit. They simply say “Oh you want 64 bit? No problem, just make sure your 64 bit linux version is capable of running 32 bits libraries”).

Anyhow, setting up that stuff is easy enough. What I couldn’t figure out for a while was how to make a screenshot of my running program. I guess you can blame eclipse (or google’s eclipse plugin) for not having this option builtin, because it is certainly possible. Here’s how:
1. In the android-sdk-linux dir (that you got from unzipping/untarring the google android sdk that you -should- be able to download from the link above, but somehow I can’t get their download button to work in Opera 12.14 atm) there’s a tools dir, which has a (deprecated: ddms) ‘monitor‘ tool. Start it:

benv@32bitchroot:~$ cd android-sdk-linux/tools
benv@32bitchroot:~/android-sdk-linux/tools$ ./monitor

2. You should get a list of devices on the left. Select your device, and click the screen capture button.

3. Hit save and you can write it to a file 🙂

Unfortunately I haven’t been able to figure out a way to do this without starting all that graphical garbage yet. If any of you know how to do that so I can attach a shortcut to it in my fluxbox, that would be great. Maybe Google can take a hint? :-p

Oh yeah, here’s a screenshot to show you guys it worked 😉

Good news everyone! Linux 3.8 has been released! Obviously I immediately fired up my compiled to upgrade from the by now ancient 3.6.8 kernel that I was running.
After rebooting my Slackware64 machine into the new kernel without a problem it was time to recompile the NVIDIA binary blob. You know, this piece of garbage. It doesn’t matter if you pick the latest official release version (seems to be 310.32 atm) or the beta that I picked, it won’t compile.
Running the installer will fail and leave you a /var/log/nvidia-installer.log that contains something like this:

root@machine:/# tail /var/log/nvidia-installer.log
/tmp/selfgz7139/NVIDIA-Linux-x86_64-313.18/kernel/nv.c: In function ‘nv_kern_open’:
/tmp/selfgz7139/NVIDIA-Linux-x86_64-313.18/kernel/nv.c:1521:30: warning: passing argument 2 of ‘request_irq’ from incompatible pointer type [enabled by default]
In file included from /tmp/selfgz7139/NVIDIA-Linux-x86_64-313.18/kernel/nv-linux.h:128:0,
from /tmp/selfgz7139/NVIDIA-Linux-x86_64-313.18/kernel/nv.c:13:
include/linux/interrupt.h:130:1: note: expected ‘irq_handler_t’ but argument is of type ‘enum irqreturn_t (*)(int, void *, struct pt_regs *)’
/tmp/selfgz7139/NVIDIA-Linux-x86_64-313.18/kernel/nv.c:1525:17: error: implicit declaration of function ‘NV_TASKQUEUE_INIT’ [-Werror=implicit-function-declaration]
/tmp/selfgz7139/NVIDIA-Linux-x86_64-313.18/kernel/nv.c:1537:25: warning: passing argument 2 of ‘request_irq’ from incompatible pointer type [enabled by default]
In file included from /tmp/selfgz7139/NVIDIA-Linux-x86_64-313.18/kernel/nv-linux.h:128:0,
from /tmp/selfgz7139/NVIDIA-Linux-x86_64-313.18/kernel/nv.c:13:
include/linux/interrupt.h:130:1: note: expected ‘irq_handler_t’ but argument is of type ‘enum irqreturn_t (*)(int, void *, struct pt_regs *)’
cc1: some warnings being treated as errors
make[3]: *** [/tmp/selfgz7139/NVIDIA-Linux-x86_64-313.18/kernel/nv.o] Error 1
make[2]: *** [_module_/tmp/selfgz7139/NVIDIA-Linux-x86_64-313.18/kernel] Error 2
NVIDIA: left KBUILD.
nvidia.ko failed to build!
make[1]: *** [module] Error 1
make: *** [module] Error 2
-> Error.
ERROR: Unable to build the NVIDIA kernel module.

Fortunately here’s a little patch you can run to fix it. This assumes you have your linux 3.8 kernel sources symlinked in /usr/src/linux!

root@machine:/usr/src# wget -q ftp://download.nvidia.com/XFree86/Linux-x86_64/313.18/NVIDIA-Linux-x86_64-313.18.run
root@machine:/usr/src# bash NVIDIA-Linux-x86_64-313.18.run -x
root@machine:/usr/src# cd NVIDIA-Linux-x86_64-313.18
root@machine:/usr/src/NVIDIA-Linux-x86_64-313.18# wget -q http://notes.benv.junerules.com/wp-content/uploads/2013/02/nvidia-313.18-linux-3.8.patch
root@machine:/usr/src/NVIDIA-Linux-x86_64-313.18# patch -p1 < nvidia-313.18-linux-3.8.patch root@machine:/usr/src/NVIDIA-Linux-x86_64-313.18# ./nvidia-installer # now it should work
Works for me at least 😉

Yep, you read it right, they already released it. Not much new to report about the client though, they fixed a few things, but still no Slackware release, only Ubuntu. No problem there though, you can follow my post on how to get Steam for Linux running in a 32-bit Slackware chroot environment.

As you can see from the image above, they’re even having a celebration sale! An excellent time to pick up a few great games such as Faster Than Light — although you’re probably better off buying it from the Faster Than Light site so you’ll also get the DRM-free version 😉

Keep up the good work Steam!

Some days shit is just weird. Like this morning.
Somehow my mutt managed to get disconnected from our mailserver, so I restarted it. Mutt goes “Hej, good morning, how about I connect to your mailserver, one moment please”.
“Sure sure”, I think, not really paying attention. After a while it still said “Loggin in…” though. Huh, why is this taking forever?
After checking strace and seeing it wait on a read(3, …) call I figured maybe the connection was somehow weird. However, after killing and restarting mutt a few times (since that always works, right? :-p) it still got stuck on “Logging in…”.

Obviously the first thing I should have done was think “What changed since it last worked properly?”, but I didn’t and went ahead to check out all the logs and other junk on my mailserver. It had one positive (I think) effect: I upgrade my Dovecot from 2.1.6 to 2.1.15 😉
Other than that everything worked great on my mailserver. (Which a working webmail and no complaints from clients confirmed)
Long story short: It’s not the mailserver, dummy.

What changed since yesterday when everything was still great?
OpenSSL.
Slackware had an upgrade for libopenssl to version 1.0.1d, to fix some security issues. Apparently it introduced a new bug. Bugger.
Meanwhile they fixed that library again, so now we’re at version 1.0.1e. Guess what.
After upgrading to 1.0.1e Mutt magically works again 😉

Moral of the story:
Don’t touch OpenSSL if you don’t have to. This thing causes more headaches than brain cancer.

The challenge of today: Installing the latest Magento version on some virtual host owned by a generic webhoster on the other side of the planet for some friends. Shouldn’t be too hard, right? Well, it isn’t really, but I ran into two annoying things that took me longer to work around than I would like.
So if you found this article through google, maybe this saves you the time :-p

First annoyance: Where do we get the source for the latest Magento release?
“Stupid BenV. Obviously you get that from the Magento homepage from their downloads section”.
Yeah, that’s what you’d think. So you go there, hit ‘download’ (or go to /download in your url bar, surprisingly it works) and now you have to “Select your format“. So much for getting a wget-able url here, but we’ll copy paste that from our browser, right?

Well, after selecting your format (“Your disk.” Ha. Ha.) and clicking on the Download buttong, you are faced with?
Oh of course.

The URL shown when hovering the download button already gave it away – “http://www.magentocommerce.com/download/login_form“. A fucking login form. FOR A FREE OPEN SOURCE PRODUCT. *RAGE*.
“Login, it’s Easy!“, they say.
“Join the community now and take advantage of the following: *bullshit*“, they say.
Well “FUCK YOU MAGENTO WEBSITE“, I say.
(if you do take the time to fill out their login form, make sure to enter something@mangetocommerce.com as your email address and enable all the checkboxes)

Until they change it again you can use this wget command to work around this bullshit:

benv@vhost:~$ wget --referer http://www.magentocommerce.com/download/get-started http://www.magentocommerce.com/getmagento/1.7.0.2/magento-1.7.0.2.tar.bz2


Next up, the issue I ran into. After creating a database, untarring the tarball and pointing the webserver to the right place it was time for the web based installer. Just click next a few times, enter the database info, next …. what’s that?
PHP Extension “pdo_mysql” must be loaded..
Errh… ok. So I check what this webhoster’s PHP configuration flags are … phew, they included PDO. As a shared module. Oh well, guess we’ll need to enable this in php.ini then. Long story short: it’s not enough to just include pdo_mysql.so.
If you include only pdo_mysql.so, PHP will not complain, at least not in any log file I could find on that webhost, but PDO is still not loaded.

Solution:
Make sure php.ini contains:

extension=pdo.so
extension=pdo_mysql.so
extension=mcrypt.so

(that mcryp one should not be necessary there, but they say without it you could run into other issues, like mcrypt not being loaded either).

PHP. What’s worse than having to work with PHP? Working with PHP that you didn’t compile yourself :-p