Hugh Perkins's tech blog

Ok, so I searched evveeerryyywhere yesterday to figure out how to toggle the bluetooth on my debian eeepc 901.

And failed.

And then I tried installing eee-control this morning from eee-control, and found the solution

The bluetooth is controlled by rfkill1, ie you just toggle:

/sys/class/rfkill/rfkill1/state

Easy once you know…

Moving on.. eee-control installed really easily for me, though I feel it’s good to remove the dkms module, which is installed in /usr/src by default.

I did the following:

• Downloaded eee-control source from eee-control tarballs, selecting the latest version 0.9.4
• untarred it
• ran ‘sudo checkinstall –exclude /usr/src python setup.py install –prefix=/usr’

To run it, do:

• sudo eee-control-daemon -V &
• eee-control-tray &

Awesome!

Control of toggles works. Fan-control works. FSB control doesn’t seem to work, but it’s not a huge deal for me, though it would be nice if it did work. Camera and bluetooth control are the main things.

This is like the earlier qemu version, only better Basically, on my machine, an eeepc, virtualbox seems to be much snappier than qemu. kvm doesn’t run for me because my processor is not virtualization-compatible.

There were a few issues to surmount for me to get VirtualBox working with a raw disk partition that I’d already installed using the raw base machine:

1. mount a raw partition in virtualbox
2. get grub to boot from a whole-disk partition

To get virtualbox to work with a raw partition, there is a ‘secret’ internal command one can use:

sudo VBoxManage internalcommands createrawvmdk -filename /data/virt/centosraw.vmdk -rawdisk /dev/vg0/centos
sudo chown user:user /data/virt/centosraw.vmdk

The .vmdk is a tiny text file that can be read with ‘vi’ or ‘cat’ or similar, and describes where to find the raw partition, for VirtualBox.

To run the vm, we need to run virtualbox as root, otherwise it doesn’t have access to the device. So, to run it we can do:

sudo virtualbox

Then, we can create a new virtualmachine, using the .vmdk from earlier.

Next up, grub. I tried attaching a grub1 floppy to the virtualmachine. I couldn’t find a way to get it to read from (hd0). It insisted it wasn’t an appropriate format.

grub2 sounded promising. How to make a grub2 bootable floppy? It turns out we can make a bootable grub2 cd image very easily:

grub-mkrescue grubfloppypc.img

… then we can mount this as a cdrom drive on the virtual machine.

If we turn the virtual machine on, we should boot into grub!

Then we can start the os by doing something like:

ls (hd0)
ls (hd0)/boot
root (hd0)
linux (hd0)/boot/vmlinuz-myfavoritekernelversion -root /dev/hda
initrd (hd0)/boot/initrd-myfavoritekernelversion
boot

For your own os, if it is linux, the only thing to change would be the kernel version. The drive name should be the same. Note that the root to be passed to the kernel is ‘/dev/hda’ and not ‘/dev/hda1′ since we have mounted the partition as a whole disk.

Quick screenshot of grub:

… and then from there the os should boot normally:

qemu virtual machine on its own: needs various hard-disk images etc. Kind of a pain…

lvm: works like a SAN: create partitions of any size, up to the entire available size of all assigned hard drives, move them around, resize, delete, at will.

qemu can run off lvm partitions! Like this:

sudo qemu -hda /dev/mapper/vg0-centos -kernel /sda1/bootother/centos/vmlinuz-2.6.18-164.el5 -append 'root=/dev/hda' -initrd /sda1/bootother/centos/initrd-2.6.18-164.el5.img

It needs to run as sudo, otherwise qemu can’t access the device.

Doesnt even need grub or anything! Simply copy the vmlinuz and initrd to somewhere accessible when the device is not mounted, and refer to them on the commandline like above!

Now its easy to create a ton of vms, by creating an lvm partition for each, running qemu on it, and just removing or resizing the partitions once one is done.

Easy life…

Note that it’s not super super easy to dual-boot qemu vs rebooting the actual raw machine using that partition as rootfs because you’ll need to modify /etc/fstab when you switch between qemu vs raw machine, but that seems like a fairly small price to pay?

Couple of pictures:

By default, ext2/ext3 et al reserve 5% of the disk for. .. nothing.. sneakily, without telling you. It’s done to help reduce fragmentation and to prevent the system dieing completely and suddenly if the available disk space displayed drops to zero.

You can ‘reclaim’ this space by doing ‘tune2fs -m 2′ to reduce it to 2%, or even ‘tune2fs -m 0′ to remove this reservation altogether. Use at your own risk of course… It seems it might be useful to reduce it slightly, maybe to 2% on root filesystems, and maybe down to 1 or 0 on home drives that you manage yourself.

For production systems, the default of 5% is probably not a bad idea. I’d even be tempted to bump that up a little in some circumstances perhaps.

I started to look at lvm yesterday, and today I’ve moved my entire second hard-drive to lvm, and so far it seems pretty cool!

lvm lets you take a hard drive or two or three, or a bit of one, and create partitions that you can move around, shrink, grow, without needing to back everything up, copy somewhere else, delete the old partitions and create new ones.

I’m using an EEEPC, with a 4GB SSD and a 16 GB SSD. The 16GB SSD used to have 4 partitions of 4GB so I could move things around sort of, by shuffling things around.

Now there are still 4 partitions of 4GB on the second SSD, but they are all part of a single lvm volume group, and then re-allocated to: 3GB for Debian Squeeze, 2GB for CentOS, and about 7GB for data. There’s some space left over which can be shuffled around.

Both CentOS and Debian can boot from the lvm! At least: grub itself, and the grub.cfg are on the first SSD, which is still a bog-standard normal ext4 partition, but the kernel and the initrd image are in the lvm volumes! And that seems to work just fine!

I had a little bit of hassle to get the first OS that I migrated – CentOS – booting at all once it was in the lvm. The solution was to recreate the initrd image, which I figured out pretty quickly, but the missing bit that took me a while is to first, before recreating the initrd image chroot into the OS from, well, I have Ubuntu on my first SSD, and do:

sudo pvscan
sudo vgchange -ay

… at this point all the logical volumes should be registered with the os, and activated, ie the /dev/ directory will have been created and so on.

It also seems to be important to configure the /etc/fstab first, before creating the initrd, but I did that anyway, and it still didn’t work Not without doing the vgchange -ay first.

Great summary of lvm::

IBM – Logical Volume Management

One thing I like about linux is that it’s very easy to script things from the command-line.

And it really is, I feel.

That said, there is a limitation to this I feel, and that is: all the stuff that’s integrated into Gnome or KDE, rather than implemented at the command-line level and wrapped in a gui.

Here’s a good example of something I think is done well in this respect: ufw, vs gufw.

ufw works just great from the commandline, and if I want I can give the graphical version – gufw – to my girlfriend to use, not that she does, since she doesn’t need to configure the firewall really, but she could. It’s simple, it’s graphical, I feel it’s fine.

Then at the other extreme we have usb key auto-mounting, and networking, which as you can see from my recent posts doesn’t really work by default from the commandline without a fair amount of prodding and pushing. You cannot easily use gnome’s network manager and at the same time control the network from the commandline. They are totally incompatible. Each interface can either be controlled from the commandline, or from Gnome, and not both. I think that this basically sucks!

Another example: disk auto-mounting: Gnome will handle this with some combination of gvfs or gnome-volume-manager. It is possible to create a command-line automounter for usb keys (see previous post), but again, totally incompatible with the gnome ones.

I suppose that what happens is that when someone in the Gnome team writes something, they just naturally integrate it (read: lock it into) Gnome since that will encourage people to use Gnome. Which makes sense I suppose. And it would take more effort to abstract it. But I don’t like it. And suddenly Windows seems to me to be actually quite integrated. Sure in Windows it’s a total PITA to script networking stuff, but it’s possible, and it doesn’t involve disabling all access to networking configuration from the gui!

The ‘mild’ pro-Windows bias in this post may be because I have a windows admin interview on Friday so I have to think about getting myself back into a Windows admin mindset perhaps

By default, debian et al rely on gnome or kde to automatically mount usb storage devices.

There is a package ‘usbmount’, but it mounts keys to /media/usb0 , rather than to a more meaningful /media/<disk label> , which is what I’m used to from gnome.

So, what I did was write my own script, and slot that into the udev rules file that usbmount uses.

Here is the script, simply create a script called /usr/sbin/usbmounter.sh with the following content:

#!/bin/bash
# Copyright Hugh Perkins 2009
# hughperkins@gmail.com http://hughperkins.com
#
# This program is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by the
# Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
# or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
#  more details.
#
# You should have received a copy of the GNU General Public License along
# with this program in the file licence.txt; if not, write to the
# Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-
# 1307 USA
# You can find the licence also on the web at:
# http://www.opensource.org/licenses/gpl-license.php
#

# This aims to mount a usb storage device using its disk label name.
#
# It can run in a non-gui environment, without needing kde, gnome etc

MOUNTOPTIONS='-o noatime'
MOUNTBASEDIR=/media
MOUNTRUN=/var/run/usbmount

# logger "from my usbmount script: $DEVNAME"
# env | logger

mkdir -p ${MOUNTRUN} # use this to link to created directories, simply
                           # as an easy record of what we mounted, so we can
                           # remove that mountpoint directory later on

logger -t usbmount "running, $DEVNAME $ACTION"
if [[ $ACTION == add ]]; then {
   if ! mount | awk '{print $1;}' | grep $DEVNAME; then { # if not already mounted
      # check in blkid, ie has valid filesystem etc
      if /sbin/blkid $DEVNAME -s TYPE -o value | egrep '[ext|fat]'; then {
         DISKLABEL=$(/sbin/blkid $DEVNAME -s LABEL -o value)
         if [[ x${DISKLABEL} != x ]]; then {
            MOUNTPOINT=$DISKLABEL
            # get a mount point that's not already used
            while mount | awk '{print $3;}'|grep "${MOUNTBASEDIR}/${MOUNTPOINT}"; do {
               MOUNTPOINT="${MOUNTPOINT}_"
		logger -t usbmount "trying new mountpoint: ${MOUNTPOINT}"
            } done
            if [[ ! -d ${MOUNTBASEDIR}/${MOUNTPOINT} ]]; then {
               mkdir -m 000 ${MOUNTBASEDIR}/${MOUNTPOINT}
               ln -s $MOUNTBASEDIR/${MOUNTPOINT} $MOUNTRUN
            } fi
            mkdir -p ${MOUNTPOINT}
            logger -t "usbmount[$$]" "mounting $DEVNAME on ${MOUNTPOINT}"
            mount $MOUNTOPTIONS $DEVNAME ${MOUNTBASEDIR}/${MOUNTPOINT}
         } fi
      } fi
   } fi
} else {
   # simply remove any directory linked from $MOUNTRUN that doesn't exist in mount table any more
   for LINKPOINT in $(ls $MOUNTRUN); do {
      TARGETDIR=$(readlink $MOUNTRUN/$LINKPOINT)
      if [[ x${TARGETDIR} != x && -d ${TARGETDIR} ]]; then {
         if ! mount | awk '{print $3;}'|grep ${TARGETDIR}; then {
            logger -t "usbmount[$$]" "Cleaning up mount directory ${TARGETDIR}"
            rmdir ${TARGETDIR}
            rm ${MOUNTRUN}/${LINKPOINT}
         } fi
      } fi
   } done
} fi

And a file /etc/udev/rules.d/usbmounter.rules with the following content:

KERNEL=="sd*", DRIVERS=="sbp2",		ACTION=="add",	RUN+="/usr/sbin/usbmounter.sh add"
KERNEL=="sd*", SUBSYSTEMS=="usb",	ACTION=="add",	RUN+="/usr/sbin/usbmounter.sh add"
KERNEL=="ub*", SUBSYSTEMS=="usb",	ACTION=="add",	RUN+="/usr/sbin/usbmounter.sh add"
KERNEL=="sd*",				ACTION=="remove",	RUN+="/usr/sbin/usbmounter.sh remove"
KERNEL=="ub*",				ACTION=="remove",	RUN+="/usr/sbin/usbmounter.sh remove"

… then add your usb key and check /media to see it mounted.

When you’re done with your key, ‘sudo eject <devicename>’ to clean up the mount points.

Make sure that the gnome gvfs is not running at the same time!

I spent the last few days installing a few different distros, well mostly Centos 5 and Debian Testing.

I’m fairly happy with Debian Testing at the moment. It feels ‘clean’, or rather, using CentOS makes me feel ‘unclean’ because it gives me the feeling that it’s ripping off RedHat. I mean, I’m not saying it is ripping off RedHat, but it seems to spend so much time saying that it isn’t that, well you get the picture?

CentOS is really incredibly slow to boot. Maybe because it’s a really old system? Maybe something to do with selinux being activated by default?

The repositories by default of CentOS, those that are essentially a copy of the RHEL repositories, are fairly limited in terms of multimedia and stuff, which is reasonable I suppose, since it is mostly targeting server environments I guess (it’s the reason CentOS/RHEL was one of the two main distros I tried playing with), but still, it makes it not that acceptable to me as a desktop OS.

Redhat/CentOS seemed to me surprisingly similar to both Ubuntu and Debian once Gnome Desktop Environment was installed. It seems that the distributions all have basically the same software – not too surprisingly in retrospect really – just the distribution methods are different, yum vs apt-get and so on, the versions of products are different, and different packages are included or not in the repositories. There are some differences in high-level scripts and admin utilities, but the actual end-user applications seems to basically work the same I feel.

I figured out how to run wpa_supplicant directly by hand. It was the only way I could get pppoe over wifi working with redhat. Actually, it was the only way I could get wifi over wpa working with redhat/centos at all.

Strangely, this morning, I briefly booted into Ubuntu, to find out how to configure redhat wifi, and whilst Ubuntu couldn’t seem to connect to the wep access point, using wpa_supplicant worked just fine! It’s odd since presumably Ubuntu uses wpa_supplicant underneath? Or, maybe not for wep, maybe just for wpa connections?

What I feel Debian is missing really to make installation easy is a usb key installation that doesn’t need a network, so I could install a base system, and then boot up and install a couple of networking driver packages.

By default I think that Debian consists of either cds or a network boot usb key image. I think it’s probably possible to hack the cd onto a usb key, but there are no obvious easy procedural instructions to follow as part of the official debian installation I think. The network boot usb key needs an easy to configure working ethernet connection, which is not so easy when one’s connection is fundamentally pppoe

I just found that there is no AppArmor in Debian. I will need to play with selinux if I want to feel comfortable browsing stuff; or at least: after browsing with apparmor I feel a little naked without it

I finally took the plunge and installed debian testing on my eeepc yesterday.

I definitely would not recommend it for beginners. I feel Ubuntu is vastly more polished. Still, it seems to do pretty much most things that Ubuntu Karmic does for me.

I feel that most applications are roughly the same version as Karmic, with exactly the same bugs: latency in vlc for flv files even when using alsa; and I haven’t tested, but I saw someone say that if you don’t shut down wifi connection,s before turning off the wifi hardware it will kernel panic, just like in Karmic.

My memory usage is vastly reduced compared to Ubuntu, since I hardly installed anything.

I installed it eventually using debootstrap, from Ubuntu, using the instructions at Installing Debian GNU/Linux from a Unix/Linux System. This may be why my user experience was a little sub-optimal compared to Ubuntu I’m studying for LPIC though, so I felt it would be good to do things the hard way for a bit, using the command-line and so on.

Getting networking working – wifi over rt2860, + pppoe – was surprisingly easy. Once debootstrap has run, you can chroot into the new partition and use apt-get normally, from within the old ubuntu system, so it’s dead easy to install the appropriate rt2860 and pppoeconf packages, I found.

Configuring the networking for wpa was fairly easy I felt, considering it is commandline stuff: just install wpasupplicant, and add a couple of lines to the /etc/network/interfaces file.

X was kind of a pain to get working. In the end, I apt-get’d ‘gnome-core’ and ‘gdm’ and did ‘/etc/init.d/gdm start’, and magically it started, but just running ‘X’ or ‘startx’ did nothing. I suppose what I mean is: starting x without knowing what I was doing and not using a standard way of doing it like gnome is kind of a pain

gnome-core was fairly ugly on my system, but changing the font sizes helped a lot for that. I suppose if I installed the full gnome standard install it might be prettier, but I didn’t want to have to go through aptitude deselecting pretty much every office and cups package being installed by the standard gnome installation.

Even gnome-core brought in brasero for some reason, temporarily, until it was purged by me

I’ve been using the new debian all morning so far. I haven’t felt a desire to jump into Ubuntu for anything yet. Anything I want is just an apt-get away…

Oh, and I uninstalled network-manager to save a bit of memory and attempt to be l33t