A Gentoo diary part 1

Posted by dcparris on Jul 20, 2006 6:51 AM EDT
LXer.com; By H. Kwint
Mail this story
Print this story

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

For three years now, I've been using Lilo as my boot loader. It had always been sufficient, though I knew Grub was the 'better' boot loader. But here was my problem: Grub is rather, uhhm, elaborate. Yes, very elaborate. Look at "$info grub", surf around a bit, and you will see what I mean. Moreover, naming of the hard drives is a bit complex, it seems to be a bit harder to secure the boot process since there is a sort of shell available when starting, and Lilo worked fine.

"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)
Ok, now that's done, Grub is set up on the boot partition of the first harddisk; hda or sda, that doesn't matter. In the 'setup' step, Grub puts some file-system specific info in a kind of boot stage, called stage 1.5. For how it exactly works, read an article about Grub, but because of this stage, you have access to your root-filesystem after the boot loader is booted. This is rather useful in practice. For example: You may have noticed I didn't supply a kernel name in the example above. "But the boot process stops if the boot loader doesn't know which kernel to boot, doesn't it?" I hear you doubt. Yes, you are right, but because of the Grub command line, I can supply the kernel name as an argument after the boot loader booted. Therefore, if the kernel name changes by accident, I don't have an unbootable computer, and I don't need to rerun Grub; at least as long as the filesystem stays the same.

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


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

A while ago, xmms always hung when playing some songs, and some songs sounded garbled. Xmms is rather old, and as I heard, it is developed by only a few persons, which form a kind of 'elite'. Xmms uses gtk1 as its graphical library, and once, there was someone who wanted xmms to use gtk2. The xmms people didn't give it priority, and therefore, xmms was forked to bmp, an acronym for beep-media-player. However, the name bmp was already taken on sourceforge by another project, so bmp changed its name to beep-media-player. Since the xmms code was a mess, the folks of beep-media-player tried to clean up the xmms code.
Now, I tried to work with the xmms code in my life while trying to make the skins more flexible (xmms used hard-coded skin sizes and positions), and indeed the xmms code looked rather messy to me, though I was only a beginning C programmer at that time. Since I really couldn't code that well (it was only a 'learning project'), I gave up when extruding the sizes of the skin-objects all in one file and in some variables didn't work.

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


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:

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:

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

Almost forgot, but I did some pretty advanced work to make this work. This is what happened: After building a new computer, selling my old computer to my sister and taking her old computer with me, we finally ended up having a 300 mHz spare box. I took my old Western Digital 40G disk with me and my friend put it in the old 300mHz box, after which the hard disk 'burned'. Too bad...

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.
After this was said and finally done, the server could boot rather fast on its own, and we could log in with SSH and our customized password. Then, the NFS share could be mounted manually. It was my friends wish to chroot (or something) into an Ubuntu server environment, but since we didn't have the time and motivation, we let it rest until I bought a 8GB hard disk for 13 euros, which included shipping. Well, shipping, it were only 40 lousy miles, but it's the Netherlands, you know.

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

So, I started reading about distcc. To make things more complex, I also needed a cross-compiling environment, because my AMD 3000 box was set up to compile for i686 and the 300mHz box needed its stuff compiled for i386. So, I emerged distcc on both boxes, emerged some crossdev tools on my 3000+ box, but than stuff halted, because building the crossdev-chain gave errors. Again, I started debugging, but I coulndn't find out what was wrong. After trying and trying, I decided to follow the simple way. And that's how the 300mHz box ended up compiling non-stop for 78 consecutive hours...

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

My friend with the Windows box shares internet with me via a wireless connection. Because the wireless connection appears to be not-so-stable under WindowsXP, he asked if I could make WLAN working on his laptop which is running OpenSuse 10.1 at the moment. The laptop is a few years old Acer Aspire 1350. I tried hard making his Sis163u WLAN (USB) adapter work with the ndiswrapper module - which uses WLAN Windows drivers under Linux - but I couldn't get it to work. Finally, he borrowed that adapter to someone else. The laptop also has a built in mini-PCI Broadcom 43xx card, but we supposed it had a hardware error, because my friend couldn't make it work in Windows either. A few days later, I read Linux 2.6.17 now has built-in support for the BCM43xx series of WLAN adapters! Time to try.

Of course, I first tried to get the newest kernel for OpenSuse 10.1, but somehow 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'

We end this diary with a Windowmaker 'quirk', though it's probably a feature. I have used Windowmaker as my windowmanager since I started using Gentoo. Since a while, a friend of mine is using my desktop to browse the net. I start all my applications using keyboard shortcuts. They are easy to define in Windowmaker, as long as you remember to unset your numlock-key. So, Eterm is WinKey+E, Firefox is WinKey+F, EuroGlot under wine is WinKey+Shift+E and so on. If something doesn't have a keyboard shortcut, I use WinKey+R which brings up Windowmakers Run box, or I start it from the command line. Works for me!

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!

» Read more about: Story Type: Editorial, LXer Features; Groups: Gentoo

« Return to the newswire homepage

Subject Topic Starter Replies Views Last Post
Failed to load microcode.. techiem2 6 2,984 Jul 21, 2006 9:04 AM
USE Flags carpenike 1 2,670 Jul 21, 2006 8:00 AM
WindowMaker and Grub Inhibit 1 2,505 Jul 20, 2006 11:43 AM

You cannot post until you login.