Tag Archives: kernel

Slackware 13.37 Release Candidate 2

We have progressed to the second release candidate for the upcoming release of Slackware stable (version 13.37 no less). There is probably not going to be a lot of other updates before final release; the TODO list should be quite short now. The only one to know for sure is Pat Volkerding… I am only speculating of course.

Noticable is that the Slackware -current’s kernel has again been updated – this time to 2.6.37.4. And again, as part of a Slackware kernel update, the glibc packages were rebuilt against the new kernel’s header files.

If you have enhanced your 64bit Slackware-current with multilib capabilities, you can upgrade to the new multilib glibc packages that I compiled for you.

Get the glibc packages for your multilib Slackware64-current at http://slackware.com/~alien/multilib/current/ as usual (or visit my mirror at http://taper.alienbase.nl/mirrors/people/alien/multilib/current/).

I also updated the content of the slackware64-compat32 directory. In there you will find a copy of all the packages which are created by running the massconvert32.sh script. Install these packages on top of your multilib Slackware64-current in order to make your computer fully support 32bit applications (or use “upgradepkg –install-new” if you already installed a previous set of these packages).

No idea what I have been talking about?

If you want to know about 64bit Slackware Linux (which is a pure 64bit OS) and how to “upgrade” to a multilib system (supporting 32bit as well as 64bit applications), you should definitelty read http://alien.slackbook.org/dokuwiki/doku.php?id=slackware:multilib

Eric

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.

Eric

Compiling a new kernel module for VirtualBox

I had installed VirtualBox a while ago on my laptop running my Slackware64 test environment, so I could experiment with the program a bit. Then I forgot all about it.

Today, I upgraded to the latest set of slackware64-current packages, including the new 2.6.32.7 kernel and when I rebooted to that new kernel, I saw an error message scrolling by stating that “the vboxdrv kernel modules failed to load”. Of course… a new kernel needs all external modules to be recompiled.

When installing VirtualBox, I had already noticed that the installer is Slackware friendly; it installed a nice “/etc/rc.d/rc.vboxdrv” boot script and updated the “rc.local” script so that it runs “rc.vboxdrv” on boot. Well done!

It is easy to rebuild the missing VirtualBox kernel modules using that rc script: you just need to run it once with the “setup” parameter.

root@alienteepee:~# /etc/rc.d/rc.vboxdrv setup
Stopping VirtualBox kernel module ...done.
Recompiling VirtualBox kernel module ...done.
Starting VirtualBox kernel module ...done.
root@alienteepee:~#

That’s all there is to it!

Cheers, Eric

Robby’s libata switchover howto

The new kernels in Slackware (post 13.0) have one important change compared to previous kernels. This change will affect anyone with Slackware installed on an IDE disk (like /dev/hda) who wants to upgrade to the latest state of affairs.

The new kernels exclusively use “libata”. The last bits of the old IDE/ATA subsystem have finally been removed.

This means, that your IDE disk will be recognized as a “SCSI disk”. The device name “/dev/hda” will change to “/dev/sda” when you boot the new kernel. As a result, your computer will refuse to boot because the bootloader (grub or lilo) can not find the root device.

Robby Workman has written a HOWTO for anyone who wants to do this upgrade. The article was published as http://rlworkman.net/howtos/libata-switchover. By following the HOWTO you will not have any issues in upgrading to the new kernel.

I will print Robby’s HOWTO in full below to give it some more coverage:

libata_switchover
20100110
rworkman

/*
Thanks to David Somero, Old_Fogie, gegechris99, and GazL for valuable
feedback and enhancements to this document.
*/

This is written to provide one of several ways to retain a working system after upgrading from Slackware 13.0’s kernel to the newer kernel in -current (which removes support for the “old” ide subsytem, thereby causing all /dev/hd* devices to have /dev/sd* names.

1. Upgrade the kernel and kernel-modules packages normally.

2. Edit /etc/fstab to reflect the change from hd* to sd*.

If you have multiple SATA devices, and especially if you have some of
both hd* and sd* devices present already, then you’re basically going
to be playing a guessing game right now, and you probably want to
consider using some of the persistent symlinks in /dev/disk/by-*/
instead of raw device nodes.

* If you are using one of the generic kernels (requiring an initrd),
then use the sd* name for the root device when creating the image
(edit /boot/initrd-tree/rootdev and then re-run “mkinitrd”).

* You will almost surely want to remove the udev rules file for cdrom
devices (it will be regenerated on the next boot with correct
information reflecting the new libata stuff):
# rm -f /etc/udev/rules.d/70-persistent-cd.rules

* Speaking of optical devices, if you have multiple disk drives and an
optical drive using the old ide subsystem, then be aware that the
optical drive will get a /dev/sr* name instead of /dev/sd* — this is
relevant because you might see something like this (if your optical
drive is currently /dev/hdb):

Old Name –> New Name
/dev/hda /dev/sda
/dev/hdb /dev/sr0
/dev/hdc /dev/sdb

3. Run lilo. Note that you have made no edits at all to it yet, unless
you needed to edit it for the new kernel. Specifically, do not make
any changes with respect to hd* –> sd*.

4. Reboot. At the lilo prompt, press <TAB> and add an append for the
real root device (which will no longer be /dev/hd*). For example, if
the old root device was /dev/hda1, and it will now be /dev/sda1, and
the name of your kernel image is “Linux” then you would type this:

Linux root=/dev/sda1

5. Once the system comes back up, then fix /etc/lilo.conf, run lilo, and
reboot again to be sure everything is correct.

Good luck! Eric

PS: I have refreshed the copy of Robby’s text so that it reflects the updates he made to the original after feedback from several people.

Bleeding at the edges again?

… Ok, ok, it is not so bad actually! Au contraire!

Slackware Linux development made a big leap today, when Pat Volkerding updated the distro’s “vital organs” of kernel, glibc and gcc. The “dull” phase of the slackware-current development cycle is over hopefully, and it’s back to the bleeding edge.

To be fair, gcc 4.4.2 has been sitting in “testing” area for quite a while now, and we think it is time to promote it into the core. With glibc 2.11.1 we are pushing it, as this is the most recent stable release, and the 2.6.32.2 kernel was much-anticipated by those who run -current on their computers.

Note that the new kernel has full support for EFI (the Extensible Firmware Interface which is going to be the replacement for the ageing BIOS on modern computers). This means that there is also support for GPT partitions. GUID Partition Table is a standard for the layout of the partition table on a physical hard disk (part of the EFI specification and meant to overcome the 2 TB size limitation of MBR partitions). We still have to look into updating the Slackware installer for automatic GPT partition recognition, but you will be able to use GPT partitions if you do some footwork yourself before running “setup”.

With this update to Slackware’s vitals, the stage is set for further tweaks of the core, but I think that for now, you will have plenty to play with.

And as promised to those running the 64-bit version of Slackware-current, I have made available multilib versions of the new gcc and glibc packages! Thanks to Pat Volkerding who allowed me sufficient time to build and rebuild these packages on my old computer until they were just perfect (I hope) and could be released along with the Slackware originals.

You can get them here: http://slackware.com/~alien/multilib/13.1/ (I took the liberty of assuming that 13.1 will be the version of the next Slackware release, mainly because I needed to give that directory a name).

For detailed instructions about what multilib means to the 64-bit Slackware and how you can add it, read this wiki article: http://alien.slackbook.org/dokuwiki/doku.php?id=slackware:multilib

Have fun! Eric