According to Debians Upgrade instruction and it’s “How to recover” section, the problem can be caused by new naming conventions for IDE disks.

This problem can occur when the upgrade of the kernel introduces the use of the new generation of IDE drivers. The IDE disk naming convention for the old drivers was hda, hdb, hdc, hdd. The new drivers will name the same disks respectively sda, sdb, sdc, sdd. The problem appears when the upgrade does not generate a new /boot/grub/menu.lst file to take the new naming convention into account. During the boot, Grub will pass a system root partition to the kernel that the kernel doesn’t find.

This seems like to be very common reason for these “Waiting for root file system” troubles that many faces now when upgrading to Lenny. But in my case I allready had the new sda* names in the grub/menu.lst and /etc/fstab. The “solution to recover” did not work.

The virtual lenny server with the new kernel images that fails to boot was hosted by VMWare Server 1.0.3. For a nearly the same upgrade process (etch to lenny) hosted on FMWare fusion 2.0.2, I did not have these problems.

Solution: My VMWare Server 1.0.3 was out of date and had a known vmware bug that caused this error. Upgrading to the latest version (now 1.0.8) solved the problem.

You can prevent /dev/rtc from being used. This will generally cause clocks to run slow
in any virtual machines you have that need the additional interrupts, but that may be
acceptable to you, depending on your application. To do so, add the following setting to
each virtual machine’s .vmx configuration file, or add the setting globally to the host’s
configuration file (/etc/vmware/config):

host.useFastClock = FALSE

Wenn man diese Zeile im /etc/vmware/config einträgt und vmware neu startet (/etc/init.d/vmware restart), ist man die Einträge im Syslog los.

Nachdem ich dann also über den Apt-Get-Wet für die Installation der nvidia-Treiber nicht weitergekommen bin, habe ich den nvidia Treiber vom der Homepage downgeloaded und in etwa wie folgt installiert:

Download des aktuellen Treiber

apt-get install linux-headers-2.6.18-3-686
apt-get install pkg-config
apt-get install xserver-xorg-dev –purge

apt-get –purge install nvidia-glx
(rm /etc/init.d/nvidia-glx)

frei nach:

http://www.linuxquestions.org/linux/answers/Applications_GUI_Multimedia/HOWTO_Installing_nVidia_Grapics_Drivers_on_Debian_Etch

apt-get install linux-source-2.6.18
cd /usr/src
tar -jxvf linux-source-2.6.18
ln -s linux-source-2.6.18 linux

sh NVIDIA-Linux-x86-1.0-9746-pkg1.run

Damit liefen dann auch OpenGL super flott. Ich hoffe, mein Vorgehen korrekt rekonstruiert zu haben. Nachteil dieser Methode ist natürlich, dass ich die Nvidia Treiber nicht über das Debian-Paket-System installiert habe sondern über den Nvidia Installer, der generisch gehalten ist und für alle Distros funktionieren soll; aber nicht in das Debian-Universum eingebunden ist.
Der Installer muss auch die Kernel-Module compilieren, so dass ich bei einem Kernel-Image Update neu kompilieren muss und ich den Apt-Get Vorteil verloren habe.

Sollte der Nvidia Treiber wieder über Apt-Get Installierbar bzw. vielmehr nutzbar sein, so wäre ich dankbar für einen Hinweis

Die erste Hürde: Das Asus P5WDB2 WS PRO MoBo bootet die Debian Etch PreRelease mit Stand vom 02.01.2007 nicht sondern bleibt sehr früh hängen. Erst nachdem ich im BIOS bei den Advanced-Einstellungen den Marvell SATA Controller für den zweiten sog. zweiten onboard Raid-Controller deaktiviert habe, kommt der Debian Etch-Installer überhaupt weiter.

Allgemeine Hintergrund-Info zu RAID im allgemeinen und auch Hardware-RAID vs. Software-RAID gibt es hier.
SATA RAID (oft auch als FakeRAID bezeichnet) unter Linux ist offenbar ein Thema was in letzter Zeit immer mehr nachgefragt wird, weil nahezu alle aktuellen MoBos RAID für SATA versprechen, die aber bei genauerem Hinschauen dann oft doch nur Software-RAID-Lösungen im Bios sind, die dazu noch einen Treiber benötigen, den es oft für Linux noch nicht gibt..
Diese Lösungen sind also für Windows entwickelt und greifen auf Treiber zurück, die es für Linux i.d.R. noch nicht gibt.
Ich denke, man sollte generell diese FakeRAID Lösungen für Linux meiden und die RAID-Unterstützung im BIOS deaktivieren und statt dessen auf das gut erprobte Linux Software-Raid dmraid zurückgreifen. Da FakeRaid kein echtes Hardware-RAID ist, bringt es auch keine Vorteile gegenüber dem Linux-Softwareware-RAID. Im Gegenteil: Man greift auf herstellerspezifische Lösungen zurück, die an diese Produktversionen binden (vergleich auch den berits oben verlinkten Wikipedia Artikel über Hardware-RAID).

AHCI im Bios aktivieren:
Also habe ich im BIOS des Asus P5WDG2 WS PR MoBos die IDE Configuration aus diesen Gründen nicht auf RAID eingestellt. Auch die Einstellung beim Intel ICH7 basierten SATA Controller auf "Standard IDE" wäre nur eine Notlösung, wenn der Kernel nicht das AHCI unterstüzten würde. Mit "Standard IDE" bekommt man zwar auch das gewünschte RAID1 Software-Array unter Linux aufgesetzt, hat dann aber keine Hotplug/Hotswap Funktionalität, weil der ICH7 Chipset im Standard-IDE Modus dieses nicht leistet. Weiterhin wird im Standard-IDE Modus kein NCQ unterstützt. Standard-IDE kommt also ohne die zusätzlichen Features von SATA oder SATA II daher.
NCQ wird aber vom ICH7 Chipset und den WD5000YS Laufwerken unterstützt und sollte daher auch zur Leistungssteigerung aktiviert werden, zumale im aktuellen Kernel von Etch der Version 2.6.18-3 AHCI auch unterstützt wird (laut http://linux-ata.org/driver-status.html#ahci wird AHCI ab Kernel >= 2.6.18-git5 unterstützt). Ich habe also im BIOS auf AHCI gestellt (Full NCQ support, full SATA control including hotplug and PM., AHCI is a nice, open design.) und auch ALPE (Agressive Link Power Management) und ASP (Agressive Slumber/Partial) enabled. Damit wird der SATA Controller in den nativen Modus geschaltet und unterstützt auch Hotplug sowie das Permance-Steigernde NCQ. Wenn später alles installiert ist, kann man nach dem Reboot das dmesg angeschauen um, zu prüfen, dass AHCI und NCQ aktiviert sind:

Es ist nun also alles vorbereitet für das eigentlich Einrichten das RAID1 und die Installation von Linux.

Leider ist die Installation des Software-Raids nicht so leicht. Für Ubuntu ist es offenbar überhaupt nicht vorgesehen, so dass man über einen Trick mit der Live-CD ein Raid einrichten muss und dann in das "on the fly" eingerichtete RAID hineininstalliert. Wer diesen Weg gehen möchte finde hier eine Anleitung: http://www.ubuntu-in.org/wiki/SATA_RAID_Howto.

Fedora soll da mit dem Installer schon weiter sein, aber ich würde gerne Debian oder zumindest Ubuntu einsetzen.

Debian Etch ist zwar immer noch nicht offiziell released worden, aber die Debian Testing gilt immer schon als sehr stabil, so dass ich mich für den aktuellen Build von Etch entscheide. Hierbei orientiere ich mich an "Install Debian Etch on a Software Raid 1 with S-ATA disks":

Eine weiterführende Variante berücksichtigt auch noch die Einrichtung von LVM "Installing root on LVM + RAID with debian-installer": http://dev.jerryweb.org/raid/

Nachdem das RAID1 eingerichtet ist und in das frisch installierte System gebootet wurde, kann via mdadm das Raid geprüft (mdadm --detail /dev/md0) , überwacht und administriert werden. Siehe dazu "man mdadm" oder auch im Software-RAID-HowTO. Dort werden wichtige Kommando zum Entfernen (z.B. mdadm /dev/md0 -r /dev/sdc2) und hinzufügen (z.B. mdadm /dev/md0 -a /dev/sdc2) zum Array erläutert.

Es empfiehlt sich, die SATA Kabel zu beschriften, damit man bei einem Ausfall einer Platte diese später leicht identifizieren kann. Ich habe den Ausfall jeweils eines Laufwerks erfolgeich simmuliert. Der Ausfall im laufenden betrieb wird erkannt und via "mdadm --detail /dev/md0" korrekt ausgewiesen. Die Platte kann dann wieder mit "mdadm /dev/md0 -a /dev/sdxxx" eingehängt werden worauf der rebuild started.
Weiterführende Hilfreiche Infos habe ich hier gefunden: Serial ATA (SATA) chipsets — Linux support status.