Debian Squeeze: Nouveau runs with 2.6.32-5

To run Nvidia display hardware on Debian GNU/Linux – really not a minor issue even for the end user – always was quite inconvenient: the proprietary driver is full-featured and mature but unavailable in the first install pack nor in the repository naturally due to license conflicts and furthermore must be reinstalled after each kernel update. Nvidia has provided also a limited free version of their Linux driver which was included into Debian (nvidia-glx), but a couple of months ago the company announced that they are not going to maintain it any longer (see here). After that the end user has to look out for another solution if he has used this driver so far. If able to give up acceleration and 3D support for Google Earth etc. the simple VESA driver (xserver-xorg-video-nv) is a reliable alternative, but users which are employing Nvidia should really take a look at times the new Nouveau driver. Nouveau was created through reverse engineering and is going to be a full fledged free driver for Nvidia hardware. There was some struggle about including Nouveau, but Linus Thorvalds finally accepted it for the experimental 2.6.33 kernel (see here). The X server driver (xserver-xorg-video-nouveau) became available a couple of days before for Testing and since the latest update to kernel 2.6.32-5 also the corresponding kernel module (/etc/X11/xorg.conf must contain Driver “nouveau” instead of nv or nvidia). So now Debian Squeeze (which is 6.0 and is planned to get frozen in August, see here) has finally caught up to Ubuntu which made Nouveau available already for Karmic Koala (see here). The driver is still marked as experimental but seems to work already pretty fine.

Debian: transfered Grub can’t find /dev/md0

Problem (recent Debian testing, Kernel 2.6.30-1 – might not play a role, Grub 1.97~beta3-1): I’ve bought a new set of harddisks and assembled them to a brand new software raid1 chain from a Linux live system on CD  the usual way with Mdadm and formatted it with ext3. After that I’ve copied my filesystem to that which I tarballed before to an external harddisks from my old set of harddisks – no secret involved so far. I’ve executed chroot to reach the mounted filesystem and did update-grub and grub-install “(md0)” to reinstall the bootloader – it executed without errors. After reboot Grub started from the MBR of the first harddisk like planned but the raid chain wasn’t been found and so the boot precedure hung after Grub’s boot menu – not very amusing. On the net I’ve found several tips for people having the same problem, it was been told that Grub can’t handle all of the superblock versions which could have been created by different livesystems, a guy said that the problem typically occurs if the order of harddisks was manipulated on the bios level (both wasn’t the problem), and finally there were several suggestions concerning the fact that the Initramfs has to be updated regarding the new created filesystem, too. I did this (update-initramfs -u, before that the livesystem’s /dev and /proc have to be linked with mount -o bind /dev /mnt/dev and mount -t proc /proc /mnt/proc [or similar] before changing to the mounted filesystem with chroot, I don’t know if it’s critical but I’ve found an commented option raid1 in /etc/initramfs-tools/modules which I restored before) but without no response, still hung.

The solution (simple but hard to come to if you aren’t a Linux booting procedure insider): when the boot procedure hangs after several minutes it breaks and the Initramfs jumps into its shell (prompt: (initramfs) – I became very desperate to find out!). Just assemble the raid chain manually: mdadm –assemble /dev/md0 /dev/sda1 /dev/sdb1 (or similar) and jump back to the procedure tying exit. It boots. Then, after update-initramfs, update-grub and grub-install have been executed from their booted native system it works again! I haven’t found out what has been the problem up to the present day but I’ve seen that /boot/grub/grub.cfg contains the UUID of the raid where was just /dev/md0 when update-grub was executed in the chroot environment. But it seems that in general there is a  problem when you are using a live system with a different architecture.