A Gentoo diary part 1

LXer Feature: 19-July-06 It's been a while since I promised to write about my Gentoo desktops. In the intro, I gave some general information about Gentoo, and explained my setup. The reason I didn't write a bit earlier is, amongst others, not that much interesting happened the last few weeks. Anyway, let's talk about what did happen: I set up an old 300 mHz server with Gentoo, tried to make distributed compiling work, learned a bit more about Windowmaker, tried to get a Broadcom Wireless card working on a laptop, switched to Grub, and finally got rid of Xmms. Uhhm, the latter kind of unnoticeable.

Switch from Lilo to Grub

"Then why on earth would somebody switch?" I hear you think. It started when I read 'yet another' article on why Grub is the way to go. I was tired of having to rerun and rerun Lilo every time I compiled a new kernel - although the kernel name didn't change, which is rather often, at least one time per month. I always end up forgetting to run Lilo, so I should reboot the old kernel, rerun Lilo, and start over.

Wanting to get rid of this trouble, I read the article about Grub. It also explained the stage 1.5, which gives Grub kind of access to the file system even before the kernel is loaded , and about the command line you can get when booting. So, I finally made up my mind and decided to migrate my two boxes to Grub.

Migrating was easier than I thought. It required only a few steps:

• #emerge -av grub
• Start the Grub commandline: #grub
• At the prompt, do grub> root (hd0)
• At the prompt, do grub> setup (hd0,0)

After the Grub command line has booted, which is right after the BIOS, I can now type:

grub>kernel (hd0,0)/boot/2.6.15-gentoo-r9

It tells Grub to look for the kernel on the first partition of the first harddrive, which is sda1 or hda1 in Lilo-terms. After that, you can boot by simply typing

grub>boot

and Grub boots the requested kernel. Of course, this can be automated via a menu file. The menu file is normally located at /boot/grub/menu.lst, and can be very simple. On Gentoo, The file is empty by default. To start a new configuration file using Gentoo, the best way is to do

# zcat /usr/share/doc/grub-0.96-r2/grub.conf.sample.gz > ~/menu.lst

Of course, replace 0.96-r2 with your version. From there on, one can easily create a working menu file, and also chainload Windows XP without any problem. As I'm told, it's also easy to chainload any of the BSD's. This is interesting, since I wasn't able to make a dual boot between OpenBSD and WinXP, as far as I can remember.

Switch from Xmms to Audacious

Obviously, the code was also chaotic to more trained eyes, because the beep-media-player people finally decided to start almost from the ground up making a whole new media player. The new media player, now called bmpx, used the gstreamer libraries and was incompatible with the old xmms-plugins. The beep-media-player people wanted to rename bmpx back to beep-media-player as soon as bmpx became stable.

Because bmpx was shiny and new, and used the new gstreamer libraries, I thought I should give it a try. Looking back, it was a waste of time. I needed lots and lots of gstreamer stuff, after which my alsamixer didn't work anymore. Finally, beep-media-player worked, uhhm, it started I mean. But the alsa plugin didn't play any sound, after which I spend some time debugging. I found a Gentoo debugging guide on gstreamer, which I followed line by line, and learned gstreamer installation and configuration isn't that easy on Gentoo, and also it isn't user friendly at all at this time. I did post a bug at the Gentoo Bugzilla , but a short while after that, I thought it was my own fault, though I still doubt. Therefore, I decided to let bmpx go, and switch to another media player.

So, I found myself asking: "Which media players are available to me?" If I were using Windows I would have to search the web for this, but on Linux, there is an easier way to find this out. All you have to do is look in your package repository what packages are available! This is the Gentoo 'implementaiton' of this process:

$ sudo emerge -av xmms, which gives:

[ebuild R ] media-sound/xmms-1.2.10-r15

The media-sound part tells me which category xmms is in. Now its time to check which other packages are in that category:

$ cd /usr/portage/media-sound
$ ls

I started to check out the things available to me, by alphabet. Amarok was an option, but I found it was too big. That's when I found audacious. I found out it isn't audacity (the great wave editor, these two names confuse me sometimes), but a fork of... beep-media-player. Ok, hang on folks, this is the last fork. Audacious was forked from beep-media-player before beep-media-player forked (was from the ground rewritten) to bmpx - if I'm right here; things are confusing for me too. This means, audacious is compatible with xmms. It can use xmms skins, but also Winamp (2) classic skins, and can use most of the xmms plugins. That's when I decided it was time to switch to audacious. Migration went very smooth. Emerging audacious went without a problem, and the sound immediately worked. Moreover, when typing

#free

at the prompt, I could check it didn't eat up all my memory. Thereby, this was officially my new-to-use media player, and I started rewriting my initialization script. Here is the old:

#!/bin/sh
cp -f /home/kwint/.xmms/my_config /home/kwint/.xmms/config
cp -f /home/kwint/.xmms/my_playlist /home/kwint/.xmms/xmms.m3u xmms -pf

It copies my 'standard' configuration file to the current config, and copies my 'standard' playlist to the current playlist. After that, it starts xmms, and puts it forward one song in the playlist. Without the -f switch, it always start to play the same 'random' song if I remember correct. Now, audacious file naming is a tiny bit different, but easy to find out. I copied over my playlist from ~/.xmms to ~/.audacious, and the new initiation script became:

#!/bin/sh
cp -f /home/kwint/.audacious/my_playlist /home/kwint/.audacious/playlist.m3u
audacious -pf

Strangely, audacious didn't make a config file by default, so I stripped that out. After that, I copied my skins;

$ cp .xmms/Skins/* .audacious/Skins/

After that, audacious used my old xmms skin, and after starting audacious with my old xmms-keybinding right_win_key+B (the B is the QWERTY equivalent of the dvorak X, the first letter of the command xmms_init. Logic, eh?) it was almost impossible to note the difference between xmms and audacious. The only difference was, my computer didn't lock up, and all songs played as should. Another successful migration!

Setup an old 300 mHz server with Gentoo

So we ended up having a diskless desktop. Still interesting anyway, and we started making some wild plans. Since my friend owns a Windows box, we wanted to make the 300mHz 'server' boot over SMB, booting the server from a Gentoo LiveCD. Therefore, we edited and edited a LiveCD, but we couldn't make it mount a SMB drive that well without rebuilding a rather big part from the LiveCD. Because of this, I decided it was time to learn NFS, Sun's ancient network filesystem. That was because, the 50MB Gentoo LiveCD did include NFS support. Using my LPIC 1 book, configuration was easier than I thought. I first set up the NFS server on my own Gentoo box (the 3000+), after which we even managed to get an NFS server working on my friend's Windows XP box. Nonetheless, my friend kept whining over the NFS-server window being required to be left open. Because the Windows XP box was rather unstable, and my friend didn't want a DOS-window running the NFS server open the whole day, we finally decided we needed a new hard disk.

And that was not the only problem we came across. The server was rather slow in booting the LiveCD! I acquainted myself with the Gentoo LiveCD setup, after which I was able to change the LiveCD environment in such a way that

• SSHD started automatically, to make sure we didn't need to switch monitors and keyboards,
• The password was customized, because the LiveCD password is scrambled (randomized) by default,
• A lot of unnecessary support was stripped out the boot process. This was done by editing the LiveCD's boot-parameter configuration file (TIP!)
• The network parameters were hardcoded on the LiveCD, because we didn't use DHCP.
• The fstab file was customized to mount the right partitions.

With new motivation, we mounted the new harddrive, and because my friend saw me working with Gentoo and knew I could give Gentoo support, he asked me to put Gentoo on it. Compiling was kind of disastrous on that 300mHz box, after which I remembered distcc, the distributed compiler. In that way, my AMD 3000+ box could help compile for the 300mHz box. At least, I hoped back then.

Trying to get distributed compiling to work

Nonetheless, I kept getting error messages about incorrect hash-sums. After this happened more than five times, we decided it was probably a defect 13-euros harddrive (again!). Since this brought us in an unworkable situation, we gave up until after our holiday. New, faster hardware is coming our way maybe!

Broadcom Wireless Card

Of course, I first tried to get the newest kernel for OpenSuse 10.1, but somehow 2.6.16.4 was the newest kernel for it. I downloaded the 2.6.17 source from a Gentoo mirror, after which I discovered OpenSuse didn't have a compiling-environment by default (the horror!), after which my friend asked if I could do it with Gentoo. Nothing new to me, so in a matter of two hours or so I put Gentoo on it. On Gentoo, the 2.6.17 kernel was also masked by keyword (as unstable), but unmasking is easy in Gentoo: Just put the package name in /etc/portage/packages.keywords. Lazy as I was, I chose a quicker way:

# cd /usr/portage/sys-kernel/2.6.17/gentoo-sources # ebuild gentoo-sources-2.6.17.ebuild merge

This is a 'manual' kind of emerging which disregards if packages are stable or not. Finding the Broadcom in the kernel modules was rather easy - though it needed some extra modules, after which we recompiled our stuff, and booted our new 2.6.17 kernel. Then, we tried to load and use the BCM43xx module, but it failed. Via #dmesg we found out their was an error which told Failed to load microcode. This looks indeed like a hardware problem, so it was out of my reach to fix it, and I gave up.

Windowmaker 'secrets'

Nonetheless, someone used to Windows won't find this easy to work with. Therefore, I started making some icons on my workspaces. Amsn has its icon, Audacious has its icon which I changed, but I couldn't get an icon for Firefox. I searched the web for it, but found nothing. Obviously, no one else had the 'error' Firefox wouldn't display an icon in Windowmaker. This kept me wondering for weeks!

However, once I accidentally double-clicked on the paperclip, after which the Amsn icon magically disappeared. "Hey" I wondered, "double-clicking again might make the icon re-appear!" And indeed, it worked this way: Icons in Windowmaker can be hidden by double-clicking on the paperclip. Knowing this, I went to my Firefox-workspace, doubleclicked on the paperclip, and finally, there was my icon! This wasn't a bug of Firefox or Windowmaker, just a feature I hadn't discovered yet.

So, that's it for now. Stay tuned, more will follow!