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)
Sunday, April 22, 2007
Saturday, April 7, 2007
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.
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.
Thursday, April 5, 2007
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.
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.
Wednesday, March 7, 2007
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.
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.
Thursday, February 8, 2007
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
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.
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 U8I 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).
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).
Monday, January 29, 2007
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.
Subscribe to:
Posts (Atom)