Linux LVM2 and md arrays

For some time now, I've been running a debian server with several disks in a RAID5 md array with LVM2 layered over the top. At the time this seemed like the usual path that people were taking; ie. Use the md tools to create your redundant drive array, and use LVM2 over the top to get a flexible volume management system. Coming from a Veritas Volume Manager background, this always seemed a bit dodgy (Veritas manages the redundancy and the logical volumes). However, this setup has proved reliable and straight forward to work on. Admitedly I haven't had a drive failure, but I've never had a situation where the LVM2 or md information needs some form of repair.

I still don't mirror my root filesystem ... but thats a personal choice.

At the time I setup this disk array, there were some notes indicating that the Linux device-mapper stuff (which effectively implements the core of LVM2) would implement mirroring. It looks like that is the case now, though it's not exactly mentioned in many places on the net. The main resource seems to be redhat who I think maintain the LVM2 stuff.

Anyway, you can now do mirroring without an underlying md array. It's really quite simple. If you have another drive you need to pvcreate at least a partition on it and then vgextend and finally lvconvert to do the actual mirroring. Here's an example from an LVM'd debian setup

pvcreate /dev/hdd1
vgextend debian /dev/hdd1
lvconvert --corelog -m1 /dev/debian/usr

Not too sure what the corelog does. I kept on getting an insufficient extents error until I added it. You can do a 'lvs' to see the progress of the mirror. It works pretty well. Like most LVM operations you don't need to umount anything while they're running.

But you still need to use md if you want RAID5. I don't think the device mapper implements RAID5 yet. One thing that is good about current (post kernel 2.6.16) md setups is that you can add a disk to a RAID5 array and dynamically expand it (google for mdadm raid5 reshaping). If you understand how RAID5 works, you'll realise that adding a disk is a complicated process involving restriping data across all the disks in the array. When I set up my array this reshaping feature was not available so I deliberately split each drive up into about 5 or 6 partitions to create multiple RAID5 instances .... which suffice to say allows me to add another drive and reshape it myself (it's a long process, but doable)

Compiling kernel 2.6.20 for a Core Duo

Am just trying out the latest 2.6.20.6 kernel on Debian Sarge, and the first problem I hit was having the 'make bzImage' fail very early on with an error similar to:

cc1: error: invalid option `tune=i686'
make[1]: *** [arch/i386/kernel/asm-offsets.s] Error 1
make: *** [prepare0] Error 2

It turns out you need to use gcc 3.4 or higher if you choose Core Duo as the processor type. There are gcc-3.4 debs in the normal repositories for Debian Sarge.

ADSL speeds

Just a quick note about ADSLv1 speeds. Here in NZ, ADSL2 and ADSL2+ are really just wishful thinking, so we're stuck with ADSLv1 at the moment. Its not too awful. Its essentially; up to 8Mbps down and up to 800kbps up depending on distance to the exchange and bunch of other factors. And actual throughput beyond your exchange is highly variable depending on how congested your exchange is.

For 4 or 5 years I've used an Alcatel Speedtouch USB modem attached to some form of linux box (more recently to an OPENWRT box). It has served me well, but has never managed download speeds higher than 2.3Mbps. Having had a few problems with my ADSL connection lately, I tried using a Dynalink RTA1025W ADSL2+ capable modem on the line, and the speed difference is staggering. This new ADSL router will max out at around 6Mbps ... which is rather fine and dandy.

The Dynalink is an interesting device. It seems to run some form of Montavista linux, and you can even enable SSH access via the web interface. Its a typical little busybox/uclibc type of setup. The only problem with the command line access is I can't work out how you save anything. This would be nice so you could add your own iptables rules and other stuff. One thing that I would like to work out is how to configure and save changes to the 4 port switch. It looks very similar to the one in the WRT54G devices whereby you can configure it to effectively look like multiple interfaces and hence have a true DMZ. The web interface kind of hints at the fact that you can do this but doesn't really tell you how.

icewm sloppy focus

If I'm not using beryl and some other window manager, I'm often using icewm. It's simple and it works. Most of the config is done by editing files in ~/.icewm (or a global location like /usr/share/icewm). I usually like sloppy focus rather than click to focus, so there are a couple of settings in the 'preferences' file you need to change to get sloppy focus going.

However, in the latest icewm (v1.2.30), they seemed to have changed how you configure the focus model. There is a menu item on the main start menu that allows you to set the focus model to 'Click to Focus', 'Sloppy Focus' or 'Custom'. I tried 'Sloppy Focus' and it mostly did what I wanted, except that in order to raise a window I needed to click on the window border rather than anywhere on the window, so I thought I'd try changing those 'preferences' settings to what I thought should work. I tried setting 'ClickToFocus=0' and 'RaiseOnFocus=0' but making those changes and restarting icewm didn't seem to do much. Then I finally tried changing that start menu item from 'Sloppy Focus' to 'Custom' ... and now my type of sloppy focus worked (ie. moving the mouse over a window activates it but won't raise it, and clicking anywhere in it raises it). It looks like you have to set it to 'Custom' for all the old focus settings in the preferences file to be recognised.

There's actually a new config file for that focus mode start menu item called 'focus_mode'. (eg. ~/.icewm/focus_mode ). If that file has 'FocusMode=0' in it then its set to 'Custom' mode.

Using lirc with audio_alsa

There are some pages on the lirc site
that show you how to connect an IR receiver diode to the Microphone port of your sound card. You need to get +5V from somewhere and there is a suggestion to wire a 0.6V diode across the output to limit the voltage swing. I did all that, but had a lot of trouble working out how to get it to go. Most of the examples on this page did not work. I'm using the internal sound card of a T40 laptop (well its the base of a T40). I tried

arecord -D hw:# -c1 -r8000 -f U8

I could not seem to find a hw:# or hw:#,# number that would work at all. If I left off the -D hw:# entirely it would work. Since I couldn't seem to work out the hardware number, attempting the next bit:

irrecord -d hw:1,0 file

was futile. After a lot of going round in circles, I discovered that plughw:0,0 would work as a device name:

irrecord -d plughw:0,0 file

But there was still something else wrong, and I ended up applying this patch that makes sampling take place in 16 bit mode rather than 8 bit mode. The only mention of it is here. The patch as it is on that web page would not apply cleanly to the current hw_audi_alsa.c file, so I ended up working out the changes by hand.

Now I had versions of irrecord and lircd that actually seemed to work. Initially I left off the 0.6V diode across the IR diode output, but I had a lot better results with it connected. Still there are certain brands of remotes that are virtually impossible to learn from.

One big thing I learned is that if you use lirc with the audio_alsa (ie. Microphone input) you don't need any special kernel modules ... as are mentioned in the instructions for other IR adapters. lircd will create that /dev/lircd socket and then other programs communicate through it.... such as irw.

I also played around with different sample rates:

lircd -d plughw:0,0@48000 /etc/lircd.conf

lircd -d plughw:0,0@11024 /etc/lircd.conf

48000 probably works better. But trying to work out the ideal capture volume is difficult (NB: I found that the Mic volume control in alsamixer didn't actually do much. Had to press Tab to get to the capture volume and control that). And also, certain remotes seemed to work better. Sony remotes were definately more understandable. The xbox remote was one of the hardest.

So far, I'm still experimenting with this as it doesn't seem to work very reliably.

Speedtouch USB modem on OpenWRT RC6

I've been happily using an Alcatel Speedtouch USB modem connected to an ASUS WL-HDD running OpenWRT RC4 as my 'ADSL router'. This has worked great. I can't remember whether there were official packages for the speedtouch in RC4, but somehow I got them and had it working (I think I had to trawl the forums a bit). Anyway, RC6 has some nice QoS stuff in it, so I thought I'd upgrade. However, it doesn't look like anyone has redone the speedtouch package for RC6. I ended up backing up my RC4 install , installing RC6 and then manually copying some of the old files from RC4 in order to get it to work.

One nice thing is that when you do an 'upgrade' by reflashing, all your nvram settings stay. I did a 'micro' install this time


RC6 ipkg packages to install:

kmod-usb-core
kmod-usb-ohci
ppp
libgcc
libpthread


Files you need from RC4

/sbin/ifup.speedtouch
/etc/init.d/S30speedtouch
/lib/modules/2.4.30/n_hdlc.o
/lib/modules/2.4.30/ppp_synctty.o
/usr/lib/speedtouch/firmware/mgmt.o.gz
/usr/sbin/pppoa3
/usr/sbin/modem_run

I had to edit /etc/init.d/S05nvram and added this to the end:

nvram set wan_ifname=ppp0

Also take a good look at the /etc/init.d/S35firewall script. It initially opened up access pretty wide by virtue of the ppp0 interface not being recognised as the outward facing interface.

I think thats pretty much it. If you're troubleshooting, the S30speedtouch does the modem_run bit that loads the firmware from the mgmt.o.gz file into the Speedtouch. The actual ppp link is brought up via the S40network script. The speedtouch is the wan interface effectively. That hack to the wan_ifname nvram setting is because it tends to get overridden by the S05nvram script during the boot. So the S40network script ends up doing a "ifup wan" and then that will call /sbin/ifup.speedtouch (because wan_proto=speedtouch) which kicks off pppd with the args required to bring up the pppoatm link (this is for PPP over ATM style ADSL).

Beryl stopped working

I am running xfce4 and beryl 0.2.0 SVN on Archlinux (on my T42). Beryl is quite buggy at the best of times. The latest problem I had was berly not starting at all. I seemed to be stuck in xfce4. A quick look at the arch forums and someone suggested making sure the 'Window Decorations' plugin is selected (It's under 'Visual Effects'). It was on my setup, but I tried deselected it and selecting it again, and magically it's all working again. Weird.

Thinkpad 600x 2.6.19 kernel

I thought I'd try the 2.6.19.2 Archlinux kernel on my 600X. There seems to be lots of big changes in the kernel recently. Makes me far more hesitant to upgrade. For the 600X, I had been using apm suspend to RAM for quite some time on it with older kernels. It seemed to 'just work'. It stopped working with 2.6.19. I had to edit the /etc/apmd_proxy to do a pccardctl eject prior to suspend and then a pccardctl insert after it woke up. I have a realtek 8139 pcmcia card in the machine.

I have actually almost had ACPI work on this machine too. So far I can get it to suspend and wake up once. But the 2nd time it never wakes up.

h264 encoding

Having played with divx encoding and tv recording on linux, I thought I'd try out this h.264 encoding. The vague features that I had read about were:

• Smaller file sizes
  
• Better quality
  
• I think the ipod video uses it
  
• Quicktime uses it
  

Having read a good article in Linux journal about using h.264 encoding I set about trying it myself.

Tools
I use Debian Sarge stable (this is my main server ... and I'm happy to keep Debian on it) so chances are I have to compile everything from scratch:

• MPlayer 1.0pre8
  
• faac 1.25
  
• MP4Box (part of gpac 0.4.2)
  
• x264 0.53.583 (I think is was the latest daily snapshot)
  

FAAC was a prick to compile as all the source files seem to have CR.LF at the end of every line (obviously from a Windows box). Make sure you read the Wiki for FAAC and there is a tiny bit of shell code (see here) to simplify stripping out the carriage returns. I ran the configure step for faac as :

'./configure --with-mp4v2'.

I can't remember the specifics of compiling x264 or gpac. You might have to do a bit of trawling to find the answers to get them compiled.

The technique from that Linux Journal article for converting video was the following:

• Dump the audio out as raw PCM audio
  
• Convert the PCM audio to AAC audio using FAAC B
  
• Use mencoder to dump out the source video in YUV 4:2:0 and using a fifo pipe that into x264 to convert the video part of the file to h.264
  
• Use MP4Box to combine the h.264 video and AAC audio into an MP4 container
  

A simple example is:

# dump pcm audio
mencoder -ao pcm -vc null -vo null source.mpg

# convert to AAC
faac --mpeg-version 4 audiodump.wav

# Convert the video to h264
mkfifo /tmp/myfifo
mencoder -vf format=i420 -nosound -ovc raw -of rawvideo \
-ofps 25 -o /tmp/myfifo source.mpg >/dev/null 2>&1 &
x264 -o source.h264 --fps 25 --crf 26 --progress \
/tmp/myfifo 720x576
rm /tmp/myfifo

# Encapsulate in MP4 container
MP4Box -add source.h264 -add audiodump.aac -ftps 25 source.mp4

In my case the source.mpg was a 720x576 PAL MPEG2 capture from a Hauppage PVR card. You'd obviously need to change the resolution settings and fps settings depending on your source material.

That crf setting appears to be very clever. It stands for Constant Rate Factor and it seems good at maintaining a set level of quality in a video regardless of whether there are low motion or high motion scenes throughout. There is a bitrate setting that you can use with x264, but I find that this is ignored when you start using the crf setting. The Linux Journal article suggests using a crf setting of between 18 and 26. With lower values producing better quality but with consequently larged file sizes.

With any kind of video encoding, there are often a bunch of bizarrely named parameters that you can tweak on your way to finding a good compromise between file size and quality. x264 has heaps of them. The example above used a single pass encode, but you can also do two pass or three pass (and possibly more passes) encodes to improve quality. In writing this article, I have only played around with a few of these settings. Some of my observations so far:

• I've somehow been able to convert a 23 minute show (typical half hour show minus commercials) into an 80MB mp4 file. While the quality wasn't marvellous it was a lot better than a divx of that file size.
• You need a lot of CPU power for h264 encoding. I've recently upgraded to a Core 2 Duo CPU ... and you need it ... unless you like waiting. x264 has a '--threads' option which is great for taking advantage of multi-core CPUs. Even with this CPU grunt, x264 tends to plod along at between 17fps and 32fps depending on my settings and the type of source material.
• Quicktime seems to very fickle about what kinds of h264 encoded stuff you throw at it. I rarely use Windows these days, and mplayer and XBMC seem to be happy playing back what I've encoded. One thing I did notice early on was that a 720x576 H264 video won't play back very well on XBMC, giving me the impression that the XBox does not have enough CPU power. Since then I have downscaled the video while I convert it and XBMC is fine (so long as there isn't lots of onscreen motion)

There seems to be a reasonably active community of windows users using these tools... albeit with some GUI frontend to disguise it. Check out the Doom 9 forums for MPEG-4 Encoder GUIs especially the ones that relate to MeGUI. MeGUI seems to have a bunch of 'profiles' which are just XML files that describe the settings to use with x264. I haven't quite worked out how to convert one of these XML profiles to x264 parameters ... as the parameter naming is slightly different but they are definately a good start once you get the hang of it.

Encoding examples

NB: I have no idea how well these will fair if you try to play them back in Windows.... especially using Quicktime. You could try using the Windows ports of mplayer or even VLC as a better option than quicktime.

I also soon discovered that the MP4Box command appends to an mp4 file if it already exists, so make sure the mp4 file is deleted before MP4Box runs. Another useful hint is to t use the '-tmp' option with MP4Box as the default behaviiour of MP4Box is to create rather large temp files un /tmp. If you're running short on disk space, MP4Box will screw up ... and most likely not tell you.

In all the examples, I have previously encoded the sound like:

# You always get a 'your computer is too slow' message. Don't
# worry about it.
mplayer -ao pcm:fast:file=source.wav -vc null -vo null source.mpg
# Create source.aac
faac --mpeg-vers 4 source.wav

Resize 720x576 source to 720x304. Convert in one pass

FIFO=/tmp/myfifo
mkfifo $FIFO
mencoder -vf scale=720:304,format=i420 -nosound -ovc raw -of rawvideo -ofps 25 -o $FIFO source.mpg 2>&1 >/dev/null &
## Found a note somehwere that file output here needs to end in .264 or .h264
x264 -o source.h264 --crf 23 --sar 281:500 --threads 2 --fps 25 \
--bframes 1 --b-rdo --bime --weightb --direct auto --subme 6 \
--trellis 1 --analyse p8x8,b8x8,i4x4,p4x4 --me umh --progress \
--no-psnr $FIFO 720x304

MP4Box -tmp /somedir -add source.h264:par=281:500 -add source.aac -fps 25 source.mp4

The sar/par params above require some explanation. The video source is 720x576 PAL in 4:3 aspect ratio. Since the video is downscaled to 720x304 some aspect ratio info needs to go back into the video so that the player knows how to play it back (I think Quicktime ignores these settings). The calculation looks like:

DAR (Display aspect ratio) = 4/3 = 1.3333

the SAR and PAR = 1.3333 * 304 / 720 = 0.562 = 562/1000 = 281 / 500

So the SAR/PAR = 281:500
ie. Lowest fraction
For a 16x9 source video you could try a SAR/PAR of 3:4

Resize 720x576 source to 512:416. Convert in one pass . Less quality

FIFO=/tmp/myfifo
mkfifo $FIFO
mencoder -vf scale=512:416,format=i420 -nosound -ovc raw -of rawvideo -ofps 25 -o $FIFO source.mpg 2>&1 >/dev/null &
## Found a note somehwere that file output here needs to end in .264 or .h264
x264 -o source.h264 --crf 26 --sar 541:500 --threads 2 --fps 25 \
--bframes 1 --b-rdo --bime --weightb --direct auto --subme 6 \
--trellis 1 --analyse p8x8,b8x8,i4x4,p4x4 --me umh \
--progress --no-psnr $FIFO 512x416

MP4Box -tmp /somedir -add source.h264:par=541:500 -add source.aac -fps 25 source.mp4

NB: The scaling factor here 512x416 was specifically chosen as a size that approximates 4:3 aspect ratio so that it would hopefully work with Quicktime ... but I don't think it plays smoothly on quicktime this way.


Resize 720x576 source to 512:416. Convert in two passes. Low quaility, but small file

FIFO=/tmp/myfifo
mkfifo $FIFO
mencoder -vf scale=512:416,format=i420 -nosound -ovc raw \
-of rawvideo -ofps 25 -o $FIFO source.mpg 2>&1 >/dev/null &
## Found a note somehwere that file output here needs to end in .264 or .h264
x264 --bitrate 300 --crf 26 -o /dev/null --pass 1 --stats test.stats \
--sar 541:500 --threads 2 --fps 25 --bframes 2 --subme 6 --progress \
--analyse p8x8,b8x8,i4x4,p4x4 --no-psnr $FIFO 512x416
# 2nd pass
mencoder -vf scale=512:416,format=i420 -nosound -ovc raw \
-of rawvideo -ofps 25 -o $FIFO source.mpg 2>&1 >/dev/null &
## Found a note somehwere that file output here needs to end in .264 or .h264
x264 --bitrate 300 -o source.h264 --pass 2 --stats test.stats \
--sar 541:500 --threads 2 --fps 25 --bframes 2 --subme 6 \
--progress --analyse p8x8,b8x8,i4x4,p4x4 --no-psnr $FIFO 512x416

MP4Box -add source.h264:par=541:500 -add source.aac.aac \
-fps 25 source.mp4

More Archlinux

Well I've been using Arch on an old Thinkpad 600X and a newer T42 for about a month or so now.

In the past I've used slackware on these systems. I occasionally try other distros ... to see what I'm supposedly missing out on. But I generally keep coming back to slackware. Generally, I like that slackware starts up quickly and doesn't start a bunch of stuff that you don't really want. I also like that it's aimed at experienced Unix users. It's generally been a good setup for compiling programs as well.

However, it's 2007 now and more and more Open Source stuff seems to have a huge array of dependencies ... that make compiling from scratch very time consuming and prone to failure.

Now, there is one other distro I have used for quite some time; Debian. I run it on a server here and use the stable branch (Sarge at the moment). I like debian because apt-get pretty much 'just works' and it's not a 'latest and greatest' type of distro ... which is generally what you want for a stable server. Having said that, none of the new 'cool stuff' for linux is available on Sarge. By this I mean the XGL/AIGLX/Compiz/Beryl stuff.

I wanted to try AIGLX plus Beryl on my Thinkpad T42. Sure, flashy desktops are not really my thing, but I wanted to at least try it out. AIGLX generally means using Xorg 7.1 or newer. Sarge still uses Xfree86 4.3. Slackware 11.0 uses Xorg 6.9. Sure there are notes and packages for putting Xorg 7.1 into Slackware (on the net), but it doesn't look pretty.

So I tried Debian Etch. I actually put this on my Thinkpad 600X (P3 500MHz, 576MB ram) first. I know, I know it'll never run Beryl ... but I just wanted to see how Etch installed and ran before I put it on my T42. The most noticeable thing was how slow it felt. The 600X had been running Slackware 10.2 and 11 for quite sometime and generally felt quite responsive. With Etch it just felt laggy. Some research led me to various posts that Slackware is compiled for i486 and optimised for i686 ... whereas I assume Debian Etch is not. This is all with a custom kernel (ie. compiled by me with specific support for the P3) and a lightweight window manager (icewm)

Archlinux
As per the previous post, I now have this installed on a 600X and a T42. All going reasonably well. Being laptops it often takes an eternity to get ACPI or APM working 'just right', and the fact that Arch seems to upgrade kernels to the latest and greatest all the time was annoying, hence my preference to set 'IgnorePkg = kernel26' in the /etc/pacman.conf file and then compile my own kernel.

Speedwise Arch is as fast or faster than Slackware (in terms of general responsiveness)

AIGLX and beryl
Setting up AIGLX and Beryl was one of the main aims of installing Arch in the first place. Anyway, there are some very nice short and to the point entries in the Archlinux wiki about how to setup aiglx and beryl. I ended up getting it running on top of XFCE4. It wasn't too hard. My graphics chip in the T42 (ATI radeon 7500) is too old for the fglrx driver, so I have to use the open source one in Xorg (which actually works pretty well).

So now I could do my rotating cube mumbo jumbo, Expose effect etc. Now, I'm not too interested in wobbly windows etc, but I am interested in the speed with which I can do stuff in linux. I use linux for work, and in the past I've been annoyed with how (even with lightweight wm's) linux can be slow in switching between apps ... especially when you compare it to windows running on the same machine. Sometimes this is just the lagginess of screen redrawing or the delay of alt-tab'ing. When you have multiple apps open including mutliple xterms, the speed with which you can 'find an app' is quite important. So I was pleasantly surprised that AIGLX + beryl + xfce4 was really really responsive and fast. All that hardware rendering is very fast and you can flip around apps quite quickly. In my opinion you can probably 'navigate' faster than when using a desktop in regular 2D mode. And this is on an older 3D chip.

However, one thing that doesn't work well is multiple monitors. I have a 17 inch 1280x1024 monitor plugged into the VGA port of my T42. In the past I've used the MergedFB2 setup (google for it) to make one very wide desktop which can handle the different screen resolutions together (the T42 just has a 1024x768 screen). That works fine without Beryl. With Beryl the screen is all screwed up. The only way I can get the two monitors to mostly work is to have the 17" monitor running at 1024x768. The closest I got to it all working was to set a 'Virtual 2048 768' in the Screen section of my xorg.conf, but that kind of gives you a mangled 2048 pixel wide screen. Supposedly there is some kind of 2048 pixel wide limit.... but I'm not too sure.

Good things about Arch linux 

• The wiki is good
  
• The startup mechanism is simple, and not much is started by default
• There are enormous numbers of precompiled packages available in the various repositories. Its very easy to build the packages yourself. For example, I wanted to try the Linuxant hsfmodem driver. If I googled for 'archlinux hsfmodem' I see there is a package for it in the Arch AUR repository. Howerver, thats for a proper arch kernel, not my own one. So I just downloaded the tar.gz files for hsfmodem.tar.gz (and eventually hsfmodem-utils.tar.gz), extracted them, then ran 'makepkg' in each directory, and then I had a hsfmodem-utils hsfmodem package compiled for my kernel which I could then install with pacman -U
• The fonts seem reasonable (once you add a few ttf fonts)
• Everything is compiled for i686 (at least a Pentium II)
• You don't have to use Gnome or KDE

Archlinux annoyances

• It is a 'latest and greatest' type of distro. Its meant to be some kind of rolling distro without major releases (eg. My 0.7.2 install magically became a 0.8 setup during a pacman package update). So far in the month or two I've been running Arch, this has led to two annoying bugs creeping in. All these appeared after doing a pacman distro update. First, thunderbird decided that drag n drop should not work, and second, Beryl decided to paint large sections of the screen white. In each case I had to trawl through the Archlinux forums to find other people had the problem and the suggested fix. In each case I had to downgrade a package that had recently been updated. Arch keeps all the packages it installs under /var somewhere so it was simply a case of finding the correct one and running pacman -U against it (for reference, I had to downgrade to gtk2-2.10.6-1 and libgl-dri-6.5.1-3 ). The fix was easy once I found out what to do ... but it was annoying that such bugs could creep in.

Arch Linux notes (Dec 2006)

I am a long term Slackware user, but thought I'd try out this Archlinux distro. Supposedly Arch is a bit like slackware but with a package manager similar to more mainstream distros. Notes below relate to my install on an old Thinkpad 600X (and also a T42)

I downloaded the 0.7.2 base CD (about 150MB iso) and the larger 550MB+ iso
I actually just did a base install in all cases so the bigger CD is probably a
waste.

That base install gives you a 500MB root fs that has a 2.6.16 kernel and
gcc but no Xorg. I mainly used the guide here:

http://wiki.archlinux.org/index.php/Gavins_quickguide_for_dummies_like_me

Key things during the install:

• The Thinkpad 600x required me to do a 'modprobe yenta_socket' and 'modprobe 8139too' to get the lan card recognised (I have some Belkin rtl8139 based lan card). The t42 just required a 'modprobe e1000'


• I didn't create a filesystem in swap


• I just used ext3 for root

I just chose the base bundle and preselected everything in it
/etc/rc.conf changes involved setting hostname, ip address etc, and removing the exclamation in front of gateway

Now that guide suggested doing a pacman -Syu straight after install. That does
a full update of all packages including the kernel. I made sure I added the following
to /etc/pacman.conf:

IgnorePkg = kernel26

That means it won't autoupdate your kernel when you eventually do upgrade (NB: I have since tried to use the latest and greatest 2.6 kernels that Arch provides ... 
but generally things break since I'm using it on two laptops. My preference is to compile my
own kernels and sort out the power management issues).

Once it was up I added xorg

pacman -S xorg

Then added the module for the video card:

tp600x : xf86-video-neomagic
t42: xf86-video-ati

Then ran xorgconfig

Then added twm in and xterm

I could never work out what the xclock package was.

I added icewm in later and set up my .xinitrc to run it.

Some other stuff I've added

alsa-lib alsa-utils
mesa
gconf
xmms
xfce4
ttf-dejavu ttf-bitstream-vera
openssh
mrxvt
opera
mozilla-firefox
mozilla-thunderbird
tightvnc
iptables
mplayer
laptop-mode-tools
libstdc++
skype
remind
portmap (for NFS mounts)
beryl (T42)
beryl-plugins-svn (T42)
wpa_supplicant (T42)

I waited until I was ready to download 100MB and then did the pacman -Syu
It asks some questions about mkinitcpio etc. I think its best to say Yes to these.

Some of the ones above are part of other repositiories (see pacman.conf). I had to enabl
e the unstable one (for beryl) and the community one (skype and remind)

There is a good page on setting up beryl here:

http://wiki.archlinux.org/index.php/Beryl

I tried the 'without a window manager' way but ended up using xfce4 and got it
all going.

NB: the ipw2200 wireless stuff on the t42 requires the firmware files in /lib/firmware

I measured the LCD screen on teh T42 and put in the dimensions (in mm) into xorg.conf
and that improved the fonts on thunderbird

Putting in a different kernel

(NB: This is not the right way to do it in Arch) 
There are some notes about using something called ABS. No idea what that is.
I just made backups of /boot/vmlinuz26 and /boot/initrd26.img, then extracted
linux-2.6.17 under /usr/src. Created the symlink for /usr/src/linux. Copied the .config
in the old source directory (and yep its a cut down source .. the old one that is).

cd /usr/sr/linux (ie. my new one)
make oldconfig and answer questions
make menuconfig
make bzImage
make modules
make modules_install

Now do a mkinitrd kernel_version=2.6.17-ARCH
Copy the bzimage into /boot/vmlinuz26. The new initrd will be called
/boot/initrd-2.6.17-ARCH.img

NB: You can play with /etc/mkinitrd.conf to leave out the SATA and SCSI modules in the
initrd.

I also think mkinitcpio is used from kernel 2.6.18 or 19

Put something like this in /boot/grub/menu.lst

title Arch Linux - New
root (hd0,6)
kernel /boot/vmlinuz26 root=/dev/hda7 ro acpi_sleep=s3_bios video=radeonfb radeon_force
_sleep=1
initrd /boot/initrd-2.6.17-ARCH.img

NB: I also patched the ibm_acpi module to allow level control. I'll need
to patch the radeonfb module as well.

HAL

hal is some weird hw abstraction thingy that looks like its used by lots of
desktops (gnome/kde) for better detection of devices when you plug them
in.

You have to add it to the DAEMONS list in /etc/rc.conf. It should go before 'network':

DAEMONS=(syslog-ng !hotplug !pcmcia hal network netfs crond acpid alsa laptop-mode sshd
paul)