Main menu:


Please consider a small donation:



Or you can donate bitcoin:


Thanks to TekLinks in Birmingham, AL, for providing colocation and bandwidth.

Page Rank


FOSS Force Best Blog--2013 Award

Recent posts

Recent comments

About this blog

I am Eric Hameleers, and this is where I think out loud.
More about me.


Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 425 other subscribers

My Favourites



April 2019
« Mar    

RSS Alien's Slackware packages

RSS Alien's unofficial KDE Slackware packages

RSS Alien's multilib packages

RSS Slackware64-current



Upgrading the eeepc to 2.6.33

Last week I finally took the time to upgrade my Asus Eeepc 1000H to the latest Slackware-current.

I had two issues after the upgrade, which were related to the new 2.6.33 kernel.

  1. My WPA-secured wireless connections would not last longer than a few seconds. After days of despair, I finally found out that the 2.6.33 kernel has a new driver for my wireless card, the “rt2800pci”. This driver is being loaded by default now. Slackware’s kernel also ships the “rt2860sta” driver which is part of the Linux “staging area” i.e. not considered fully stable. This is the driver which would be used with Slackware kernels before 2.6.33. It is in fact a very stable driver which never failed me before.
    By coincidence I saw that both modules were mentioned as supporting the Eeepc’s wireless card in the output of “lspci -v”. After I added the line “blacklist rt2800pci” to the file “/etc/modprobe.d/blacklist.conf” and rebooted the Eeepc, I had fully functional and stable wireless connectivity again, now using the “rt2860sta” driver!
  2. My sound was gone, or at least working at a very very low volume… I could hear the KDE logout sound if I put my ear to the keyboard but that was about it. Getting normal sound output levels through my headphones was no problem at all, however.
    The ALSA troubleshooting guide for HDA Intel audio hardware pointed me in the right direction: not getting sound through the built-in speakers while the headphone output works well is quite common, and often caused by not raising the correct channel’s volume.
    It turned out that after the upgrade to the 2.6.33 kernel, I need to set the “speaker” channel’s output level to anything non-zero or else there would be no sound…

I have to mention one other piece of strangeness I experienced on my netbook:

It is an issue not related to Slackware-current but rather to my use of the new “netbook” interface of KDE 4.4’s plasma workspace manager. I toyed with the netbook interface a bit, because it lets you use the small screen more efficiently – by removing unnecessary stuff like window elements and task bars. One typical treat is that every application window in the plasma-netbook workspace runs full-screen exclusively – there is no “minimize” button but instead you have to use the application switcher in order to access other running applications’ windows. Unfortunately, when I switched back to the “normal” plasma workspace, the “minimize” buttons did not re-appear in the title bar!
I had to manually re-add this button through “system settings > appearance > windows > buttons” and drag the “minimize” button into the titlebar preview.

Just so you know.



Comment from Grissiom
Posted: March 19, 2010 at 00:34

For the last problem, please drop your comment on this page:


Comment from alienbob
Posted: March 19, 2010 at 11:30

Hi Grissiom – thanks for the tip. Done.


Comment from escaflown
Posted: March 20, 2010 at 19:19

Hi Eric,

This is completely off topic in regard to your eeepc update but it is something that I have been struggling with for a while.
Following your README_CRYPT, I was able to have LUKS and LVM, working fine on my laptop. At the end of the readme, you said that Slackware does not currently support the usage of USB sticks as unlocking
mechanism. But in one of your posts in LQ, you said that you got that working on your laptop. So I’m guessing it’s possible to do it through some hackery. Could you give some tips about how to proceed? Thanks!

Comment from alienbob
Posted: March 20, 2010 at 22:43

As a matter of fact, support for unlocking LUKS volumes using a USB key was silently sneaked into the mkinitrd package (in the “Mon Mar 1 22:43:53 UTC 2010” update of Slackware-current).

Look for the “-K” parameter in “man mkinitrd”.

Let me know if it works for you!


Comment from ArTourter
Posted: March 21, 2010 at 00:33

Hi Eric,

Regarding the wifi on the 1000H, are you using wicd? I find the wifi doesn’t associate with anything unless it has no security. This is definitely the case on 13.0 and the sta driver. I maybe be doing something wrong but I haven’t been able to associate the wifi even manually if any sort of encryption is required.



Comment from alienbob
Posted: March 21, 2010 at 11:52

I am using wicd on my 1000h indeed. My home network uses WPA2 and I can use that without any problem – provided that linux loads the rt2860sta driver. Other WPA-secured locations also don’t give me issues.

Are you perhaps mixing up passphrases (max 63 characters of ascii text) with the hexadecimal 64-character WPA key?


Comment from escaflown
Posted: March 21, 2010 at 16:21

@eric: I couldn’t find the “-K” option for mkinitrd in the man pages (under -current). However, I noticed the existence of a “LUKSKEY” option in the mkinitrd.conf. Not too sure how to use that.

Comment from tito
Posted: March 21, 2010 at 16:29

Hi Eric,

I just noticed you mentioning the already famous keyfile feature for mkinitrd 😉

From looking at the sources in both Slackware64-current and Slackware-current I see changes in “init”, but neither in the manpage nor in the mkinitrd script itself. From your previous post I suspect that not all changes have made it as intended into the current source tree?

BTW huge thanks for this feature, it will be very handy for my work laptop 😀

Comment from alienbob
Posted: March 21, 2010 at 20:07

Ummm…. I had forgotten that I pulled my updates because I had also been trying some other enhancements and was unable to make it work. The package I have here locally is my own development stuff… no “-K” parameter for you at the moment, sorry. I will clean up my sources and send them to Pat V. as soon as possible.

Having said that, the support for LUKS keyfiles on a USB stick is already present in the -current version of mkinitrd, it just needs some manual tweaking (which will all be automated by that new “-K” switch). Look inside the source directory for mkinitrd on any Slackware mirror, you will find a “lukekey_configs” subdirectory ( for instance). Inside you will find examples for load_kernel_modules, lukskey, and wait-for-root files as they should be in the initrd. The “load_kernel_modules” file shows you what additional kernel modules are required to access the keyfile whose locationis defined in the “lukskey” file.


Comment from escaflown
Posted: March 21, 2010 at 20:42

Thanks, Eric. I will give that a try.

Comment from tito
Posted: March 21, 2010 at 22:41

Thanks for the heads up, I saw the changes in init and the extra file in the source folder too that contains the keyfile info.

Pingback from RaLink RT2760 Wireless
Posted: September 4, 2010 at 09:39

[…] RaLink driver too on my EEE pc – I wrote an artivcle about how I blacklisted the new drivers here:…epc-to-2-6-33/ […]

Pingback from RT2870 wireless problem Slackware
Posted: November 5, 2010 at 21:22

[…] your card use the rt2800usb driver? If so, perhaps the first part of this older post of mine,…epc-to-2-6-33/ also applies to you. Only in your case the staging driver will be the rt2870sta . […]

Pingback from Alien Pastures » Adding an ALSA software pre-amp to fix low sound levels
Posted: January 24, 2013 at 22:42

[…] Apparently a lot of laptop users are confronted with the issue of very low sound levels – not just in Slackware. Note that this is different from the “sound can not be un-muted” issue I experienced and which I wrote about in a previous article. […]

Write a comment