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.
- 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! - 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.
Eric
For the last problem, please drop your comment on this page: https://bugs.kde.org/show_bug.cgi?id=221408
😉
Hi Grissiom – thanks for the tip. Done.
Eric
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!
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!
Eric
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.
Cheers
Greg
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?
Eric
@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.
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 😀
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 (http://slackware.osuosl.org/slackware64-current/source/a/mkinitrd/lukskey_configs/ 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.
Eric
Thanks, Eric. I will give that a try.
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.