BenV's notes

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

Short note:
When compiling deluge and it errors complaining about “KeyError: ‘libtorrent’“, this probably means nothing about libtorrent, it means python is being fucking retarded again. Upgrade your setuptools (from 6c9 to 6c12 or whatever version they have now: pip install –upgrade setuptools) and try again.

Every now and then you find out that this huge disk you’ve been using — you know, the one that when you bought it you thought “How on earth am I ever going to fill this one up? My biggest game can fit on this disk 100 times!” — … isn’t as huge anymore. Or at least all the free space on it has disappeared and nagios is whining that your disk is full or about to explode.
Some background info: My fileserver here at home has 3 linux software raid arrays (raid-1 mirrors) on top of 4 physical disks. The first and also smallest array is used as root filesystem to boot from into Slackware linux. The second and third arrays are both big and simply for storage of games, music, series, etc.
When I created that first array a few years ago I figured “Hm, 20GB should be enough for a slackware install, right? Well, let’s just make it 50GB to be sure, we have plenty of space anyway on this huge disk“. Back then the ‘huge’ disks were 500GB. Meanwhile those 500GBs have been replaced with 1TB ones, but that array remained the same. Today I have a set of 1.5TB drives to replace the 1TB ones. Not a huge upgrade, but I didn’t have to buy these disks since they came from a server that had its drives upgraded as well. Anyhow, the 50GB partition managed to get filled with over 40GB of stuff that I can’t trash (mostly user home directories). I could move them to a different partition of course, but today we’re going to resize that partition to 100GB and put the rest in the storage partition.
Off-topic note: Do you also hate it when you’re typing in a browser and hit CRTL-w to delete your last word and realize you just closed your tab? I sure as heck do, good thing wordpress saves these drafts every now and then 🙂 (continue reading…)

As I have mentioned a while ago, Steam is coming to Linux. If you cared and filled out the survey back then, you’ve probably already been accepted for the limited beta. In their own words We’ve just expanded the limited public beta by a large amount — in other words, chances are quite big that you’ve been accepted by now. And even if you haven’t, they say you won’t be banned for trying the beta anyway.

However, the beta is obviously for Pokemon OS only right now. But that doesn’t mean we can’t try to get it running under our beloved Slackware Linux, right? 🙂
One catch right now however: you’ll need to have a 32 bit slackware installation lying around. I still have my old one that I can chroot into that I also use for running 32 bit games under wine. If you don’t I’m sure you can do a quick

root@machine:/# mkdir /slackware32
root@machine:/# cd /mnt/slackware-current/slackware/
root@machine:/mnt/slackware-current/slackware# for PKG in `egrep ADD\|REC {a,ap,k,l,n,x,xap}/tagfile | cut -f1,2 -d':' | sed -e 's/tagfile://'` ; do
installpkg -root /slackware32 -infobox $PKG-*.t?z
done
# Takes a while installing packages to your new chroot, after that you can:
root@machine:/mnt/slackware-current/slacware# chroot /slackware32
root@machine:/# echo Now I just need to fix the rest of the configuration of this chroot... like adding a user.

Mind you, you’ll also need your nvidia drivers installed in your 32 bit chroot! “But BenV, I have an ATI/AMD GPU” … yes, you probably have herpes too, go away.
Anyway, since nvidia sucks, the nvidia driver installer will barf because you it detects your 64 bit kernel and you’ll have to install it the manual way:

# This is still in the chroot
root@machine:/# cd /usr/src
root@machine:/usr/src# mkdir nvidia
root@machine:/usr/src# cd nvidia
# Make sure to match your installed version from your 64 bit environment, this one is 310.19
root@machine:/usr/src/nvidia# wget ftp://download.nvidia.com/XFree86/Linux-x86/310.19/NVIDIA-Linux-x86-310.19.run
# Takes a while depending on your connection
root@machine:/usr/src/nvidia# bash NVIDIA-Linux-x86-310.19.run -x
# Extracts to a dir called NVIDIA-Linux-x86-310.19
root@machine:/usr/src/nvidia# cd NVIDIA-Linux-x86-310.19
root@machine:/usr/src/nvidia/NVIDIA-Linux-x86-310.19# ../benv-installer.sh
Old version(s) detected, based on files:
-----
12583708 5160 -rwxr-xr-x 1 root root 5283056 Dec 4 15:57 /usr/lib/libglx.so.310.14
22152181 440 -rwxr-xr-x 1 root root 446636 Aug 23 21:29 /usr/lib/xorg/modules/extensions/libglx.so.org
------
Removing version 310.14....
Found old files, /usr/lib/libvdpau_nvidia.so.310.14
[...]
Remove them? (y/n)
y
Installing new version 310.19...
root@machine:/usr/src/nvidia/NVIDIA-Linux-x86-310.19# ldconfig

What’s that benv-installer.sh? A little script that removes the old libraries, copies the new ones in place and checks the libglx symlink.
You can get it here:
[Download not found]

Anyway, now that the major preparations are done, let’s go fire up the Steam for Linux beta! (I’m sure you can handle the rest of the missing garbage in the Slackware32 chroot that I didn’t mention, like adding a user etc).

# Yes, this is still the slackware32 chroot :)
root@machine:/usr/src/# mkdir steamlinux
root@machine:/usr/src/# cd steamlinux
root@machine:/usr/src/steamlinux# wget http://media.steampowered.com/client/installer/steam.deb
# We don't handle .deb! Let's make it more managable :)
root@machine:/usr/src/steamlinux# ar x steam.deb
# Oh look, a control.tar.gz with nonsense files and a data.tar.gz with stuff we need
root@machine:/usr/src/steamlinux# mkdir pkg
root@machine:/usr/src/steamlinux# cd pkg
root@machine:/usr/src/steamlinux/pkg# tar axf ../data.tar.gz
root@machine:/usr/src/steamlinux# makepkg /usr/src/packages/steam-1.0.0.16-i686-1.txz # This version comes from the control.tar.gz->control file ;)
# Hit enter a few times
root@machine:/usr/src/steamlinux# installpkg /usr/src/packages/steam-1.0.0.16-i686-1.txz

Easy enough. Let’s see what it does! 🙂
Note that you shouldn’t run the steam executable as root. Not that I need to tell you that, right? 😉

# Yes, still the slackware32 chroot
benv@machine:~$ steam
Setting up Steam content in /home/benv/.local/share/Steam
which: no gksudo in (/home/benv/bin:/sbin:/usr/sbin:/usr/lcoal/sbin:/usr/local/bin:/usr/bin:/bin:/usr/games:/usr/lib/java/bin:/usr/lib/kde4/libexec:/usr/lib/qt/bin:.)
which: no kdesudo in (/home/benv/bin:/sbin:/usr/sbin:/usr/lcoal/sbin:/usr/local/bin:/usr/bin:/bin:/usr/games:/usr/lib/java/bin:/usr/lib/kde4/libexec:/usr/lib/qt/bin:.)
xterm: Error 32, errno 2: No such file or directory
Reason: get_pty: not enough ptys
ILocalize::AddFile() failed to load file "public/steambootstrapper_english.txt".
Installing breakpad exception handler for appid(steam)/version(0_client)
Installing breakpad exception handler for appid(steam)/version(1.0_client)
Installing breakpad exception handler for appid(steam)/version(1.0_client)
Installing breakpad exception handler for appid(steam)/version(1.0_client)
SteamUpdater: Error: Failed to unzip item package/tmp/steam/drivercheck/590/dxsupport.cfg (1275, 1024)

SteamUpdater: Error: Failed to unzip package (/home/benv/.local/share/Steam/package/public_all.zip.1ea35c0dd4a580af99814d50c996080d1d0b3f70)

Not only did it start with the above output, it gave the following graphical display:

After which it errored with the following one:

Not that I’m surprised by an error at this point, I never expect things to work from the start 🙂
Taking a look at the console output you can see that xterm isn’t able to start. I guess they need it to run some scripts in or something, so we better make sure it can start properly. The reason is simple: this slackware chroot doesn’t have a proper /dev and especially /dev/pts (and later: /dev/shm) in place. Normally these get mounted a boot, but since you don’t really boot a chroot we have to fix these entries manually. I suggest you make a chroot script for it 😉

# Still in the chroot, as root this time
root@machine:/# mount -n -o mode=0620,gid=5 -t devpts devpts /dev/pts
root@machine:/# mount -t tmpfs tmpfs /dev/shm

There, you should be able to start xterm without errors now. If you didn’t fix the /dev/shm you’ll get another error that looks like this one:

[1207/113507:ERROR:shared_memory_posix.cc(167)] Creating shared memory in /dev/shm/org.chromium.Chromium.shmem.libcef_8194274913974519198 failed: Permission denied
[1207/113507:ERROR:shared_memory_posix.cc(170)] Unable to access(W_OK|X_OK) /dev/shm: Permission denied
[1207/113507:FATAL:shared_memory_posix.cc(172)] This is frequently caused by incorrect permissions on /dev/shm. Try 'sudo chmod 1777 /dev/shm' to fix.

Anyhow, we fixed it, so let’s try the steam beta again! 🙂

# Yes yes, still the Slackware 32 bit chroot environment ;)
benv@machine:~$ steam
/home/benv/.local/share/Steam/steam.sh: line 238: pidof: command not found
Installing breakpad exception handler for appid(steam)/version(1354745237_client)
Looks like steam didn't shutdown cleanly, scheduling immediate update check
Installing breakpad exception handler for appid(steam)/version(1354745237_client)
Installing breakpad exception handler for appid(steam)/version(1354745237_client)
unlinked 0 orphaned pipes
removing stale semaphore last operated on by process 4022 with name 0eBlobRegistryMutex_ECD12E799B7F2C7C5974C84ABE8C7520
removing stale semaphore last operated on by process 4022 with name 0eBlobRegistrySignal_ECD12E799B7F2C7C5974C84ABE8C7520
removing stale semaphore last operated on by process 4022 with name 0emSteamEngineInstance
removing stale semaphore last operated on by process 4022 with name 0eSteamEngineLock
Installing breakpad exception handler for appid(steam)/version(1354745237_client)
[1207/113620:ERROR:bus.cc(261)] Failed to connect to the bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused
[1207/113620:ERROR:bus.cc(261)] Failed to connect to the bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused
[1207/113620:WARNING:proxy_service.cc(646)] PAC support disabled because there is no system implementation
Installing breakpad exception handler for appid(steam)/version(1354745237_client)
Installing breakpad exception handler for appid(steam)/version(1354745237_client)
Installing breakpad exception handler for appid(steam)/version(1354745237_client)
Installing breakpad exception handler for appid(steam)/version(1354745237_client)
PulseAudio connect failed (used only for Mic Volume Control) with error: Connection refused
Generating new string page texture 12: 48x256, total string texture memory is 49.15 KB
# and more new string page textures
Installing breakpad exception handler for appid(steam)/version(1354745237_client)
# and more new string page textures
Process 4149 created /ValveIPCSharedObjects3
Installing breakpad exception handler for appid(steam)/version(1354745237_client)
Installing breakpad exception handler for appid(steam)/version(1354745237_client)
Installing breakpad exception handler for appid(steam)/version(1354745237_client)
Installing breakpad exception handler for appid(steam)/version(1354745237_client)
Installing breakpad exception handler for appid(steam)/version(1354745237_client)
Adding license for package 4314
Adding license for package 6134
# and a ton more licenses
local (potentially out of sync) copy of roaming config loaded - 0 bytes.
Installing breakpad exception handler for appid(steam)/version(1354745237_client)
SteamUpdater: Error: Download failed: http error 0
System startup time: 9737.35 seconds
Installing breakpad exception handler for appid(steam)/version(1354745237_client)
ExecCommandLine: "/home/benv/.local/share/Steam/ubuntu12_32/steam"
# and another ton of new string page textures

Meanwhile, what do you know – we’re greeted with a login screen!


W00t. After logging in and entering the s3cr3t c0d3 because this is a ‘new computer’ according to SteamGuard or whatever it’s called, we look upon our game library. Looks like they added a ‘Linux Games’ entry that’s selected by default.

Well, that’s cool. Let’s see if it works. I ask steam to install Dungeons of Dredmor, hit next a few times, wait a minute orso, and it looks like it’s installed 🙂
The only things that hints we’re not on windows is the weird resolution Dredmor offers (possibly related to me running Fluxbox), but this works great 🙂

Things to note:
* I have a Pulseaudio installation on my slackware32 chroot — sound worked fine for me, but if you’re having trouble it might help to install it.
* Valve seems to have put Team Fortress 2 Beta in my Linux Games list — I’ll have to see how that runs under linux, but it’s 12.2GB so takes a while to leech.
* Carefully read the console output when things don’t work, there may be helpful hints like Steam error: SteamProcessCall(WaitForAppReadyToLaunch)(0xab427c,0xfff3d100,0xfff3cee8) failed with error 17: Cache Write Failure, errno 28 “No space left on device” when your disk is full when trying to install TF2 😉

Anyway, looks like Valve is making great progress in getting Steam to work under linux. Soon things will be running smooth for Pokemon OS and hopefully that’ll open up even more games to linux 🙂

Now that Xen has deprecated the xm command and xend daemon, libxl is the way to go. However, libxl didn’t support external scripts for your block devices (like block-drbd) before version 4.2.0. Seems like that issue has been resolved, or at least as far as I care for now. However, with these changes I found that the block-drbd script (at least up until DRBD 8.4.2) still doesn’t work properly.

To save you some time debugging this shit, the problem is that the new xl stack forces the device type to be ‘phy‘ when a script is used. In the older versions xm/xend would report ‘drbd‘ to the block-drbd script as device type. Knowing this the fix for now is simple:

--- block-drbd.org 2012-11-21 12:35:08.338180920 +0100
+++ block-drbd 2012-11-21 12:35:33.278642801 +0100
@@ -248,6 +248,8 @@
fi

case $t in
+ phy)
+ ;&
drbd)
drbd_resource=$p
drbd_role="$(/sbin/drbdadm role $drbd_resource)"
@@ -276,6 +278,8 @@

remove)
case $t in
+ phy)
+ ;&
drbd)
p=$(xenstore_read "$XENBUS_PATH/params")
drbd_resource=$p


Yay a new Xen version. Well, it’s not that new, but I’m upgrading to it today. And while we’re at it, Jeremy got his pvops kernel almost to version 3.1.0 (it’s at rc9 today, good enough for me atm).
So what’s new in this latest Xen version? First of all it has finally ditched the xm command for good. Well, it’s still there, but it’s really deprecated now because it has been replaced by xl. For a nice overview of what has been improved since Xen 4.0, they have a nice list over here.
One cool thing in the later Xen releases (that is: 4.0 and up) is the integration of Remus. We’ll test that out later. (continue reading…)

Before today I was still working behind an old 20″ 2006 Acer (al2016W) as primary screen and an even older 17″ secondary screen.
They started to bug me a bit, and after looking around a bit for new screens I ordered 4 new instances of the BenQ GW2450HM.
After reading a very positive review at TFTCentral on the BenQ GW2450HM and
also a forum that was a lot more negative (people who died because of ghosting issues etc) I decided to buy them anyway because they couldn’t possibly
be worse than my current screen.

Today they arrived, so after unpacking them and figuring out how the heck I was going to make space for them on my desk I finally connected them to my PC.
I had windows up and running, which immediately noticed the BenQ that was connected through HDMI. The BenQ happily told me “No Cable Connected” however, but that
was solved by hitting the enter button twice to make it use the HDMI as source instead of the ancient DSUB. They should really stop supplying those connectors.

After unpacking and installing the second screen and connecting it to DVI I noticed a difference.
Both had the same background, but the DVI screen had deeper blacks than the HDMI one!
Nope, it’s not caused by the brightness or any of those knobs, they were identical (factory default) on both screens.

The reason for this is simply: NVIDIA sucks. Hm, that’s a nice trademark that they should register 😉
Yeah, those incompetent assholes again. NVIDIA (sucks) doesn’t care if your left screen looks a bit brighter than your right screen. They only care about getting your money, which is strange because actions like these make it less likely that they’ll receive my money in the future.

Some background on the issue:
When you connect a HDMI device to a NVIDIA (sucks) graphics card, the NVIDIA (sucks) assumes that the device is crippled and can only handle RGB values between 16-235.
Obviously PC monitors can handle the full range of 0-255, which is the default on VGA and DVI. (this is the reason my DVI screen was darker).
This mismatch in communication will fuck up the black colors for starters, but for a real impression check out this forum: http://www.neogaf.com/forum/showthread.php?t=471695
Mind you that the control panel settings that they discuss in that thread didn’t work for me.

Fortunately there’s a solution that does work for me.
This guy over here at metaclassofnil.com wrote a tiny tool to fix your registry and tell the driver to use the full range.
After a reboot everything looks great on BOTH screens 🙂