A Gentoo diary part 1
Switch from Lilo to GrubFor 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:
After the Grub command line has booted, which is right after the BIOS, I can now type:
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 AudaciousA 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
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:
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:
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 GentooAlmost 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
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 workSo, 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 CardMy 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 18.104.22.168 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!
|Subject||Topic Starter||Replies||Views||Last Post|
|Failed to load microcode..||techiem2||6||2,728||Jul 21, 2006 9:04 AM|
|USE Flags||carpenike||1||2,493||Jul 21, 2006 8:00 AM|
|WindowMaker and Grub||Inhibit||1||2,236||Jul 20, 2006 11:43 AM|
You cannot post until you login.