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.

Error: Could not stat() command file ‘/var/lib/nagios3/rw/nagios.cmd’!

In “/etc/nagios3/nagios.cfg” the “check_external_commands=1″ was already set. So there was something more required to make it run on Debian…

Deep in my memory I know that there was a debian way to solve this user right related problem. This time I’ll write it down here – perhaps I’ll find it more easily when I upgrade to Debian GNU/Linux 6.0 (codenamed squeeze) and/or Nagios4.

/etc/init.d/nagios3 stop
dpkg-statoverride –update –add nagios www-data 2710 /var/lib/nagios3/rw
dpkg-statoverride –update –add nagios nagios 751 /var/lib/nagios3
/etc/init.d/nagios3 start

Vulnerable host keys will be regenerated

Some of the OpenSSH server host keys on this system were generated with a version of OpenSSL that had a broken random number generator. As a result, these host keys are from a well-known set, are subject to brute-force attacks, and must be regenerated.
…

Mehr Details dazu unter: http://lists.debian.org/debian-security-announce/2008/msg00152.html

Das ist wirklich schlimm, denn anders als bei den meisten üblichen Sicherheitslücken, die durch einen Patch sofort mehr oder weniger zuverlässig geschlossen werden (hoffentlich ohne neue Sicherheitslücken aufzureissen), ist dieser Fehler eher wie eine Art Bandwurm. Das fehlerhafte Debian Paket OpenSSL hat Schlüssel erzeugt, die nicht so zufällig waren wie sie hätten sein sollen. Daher sind diese Schlüssel vorhersagbar und nicht sicher.

Etliche sicher geglaubte Keys sind längst im Umlauf (das Problem besteht seit dem 17.09.2006) und müssen nun rasch durch neue, sichere Schlüssel ersetzt werden, bevor die schwachen Schlüssel, die ja auch zur Authentifizierung genutzt werden, geknackt werden.

Wenn solche schwachen Schlüssel für vermeintlich sichere Verbindungen genutzt wurden, könnten die übertragenen Daten sogar im Nachhinein entschlüsselt werden, wenn der Traffic mitgeschnitten wurde. Womöglich lassen sich daraus sicherheitsrelevante Daten gewinnen.

Das Patchen verhindert zunächst nur, dass nicht weitere schwache Schlüssel erzeugt werden – aber die bereits in Verwendung befindlichen schwachen Schlüssel sind zunächst ja weiterhin im Umlauf. Das macht diesen Fehler so dramatisch. Der Aufwand für die Admins ist jetzt irre gross: Alles betroffenen Schlüssel müssen ermittelt und ausgetauscht werden – in allen Anwendungen und auf allen Servern wo sie eingesetzt werden. Viel Angriffsfläche wie man auch dem Debian Key-Rollover Dokument entnehmen kann.

Der Fehler zieht also weite Kreise über Debian Grenzen hinaus und stiftet grosses Chaos – auch Heise berichtete schon darüber und bietet einen einfachen deutsprachigen Leitfaden an.

Das installieren des Patches aktiviert eine Blacklist für “schwache” Schlüssel, so dass Debian Admins Gefahr laufen, sich auszuschliessen, wenn sie bisher nur mit schwachen Schlüssen einloggen konnten und versäumen neue “harte” Schlüssel anzulegen und einzutragen.

Der Schaden für das Ansehen von Debian ist gross – auch wenn heise mit einem guten Kommentar versucht die Wogen etwas zu glätten. Wie konnte ein einzelner Paket-Maintainer (Kurt R.) einen solchen dummen und unnötigen Bug einbauen ohne dass eine Qualitätssicherung greift oder jemand von der Mailingliste darüber stolpert. Wieso gab es keine Kommunikation mit den Autoren des OpenSSL Quellcodes. Konnte sich der Fehler einschleichen und so lange unentdeckt bleiben, weil Debian ja neuerdings versucht aktueller zu sein und somit den Zeitdruck auf die Maintainer erhöht? Gergely Riskó stellt in seinem Artikel die Hintergründe des Supergau zusammen.

Auch für Open Source könnte damit Schaden entstanden sein. Was üblicherweise eine Stärke von Open Source ist, könnte sich nun als Nachteil erweisen, denn bei einem Closed-Source System würden wohl nicht so rasch die Details über die Schwachstelle zu ermitteln sein, die es “den Bösen” erleichtern das Sicherheitsloch rasch auszunutzen. Derzeit kann wohl noch keiner einschätzen, wie groß der Schaden sein wird, der durch die Entschlüsselung von mitgeschnittenen Daten über vermeintlich sichere Verbindungen entsteht.

Sun Java 2 ist in der “non-free” Sektion der Debian Repositories verfügbar. Damit auf diese Sektion zugegriffen werden kann, muss das non-free repository in der apt sources Datei verfügbar gemacht werden. Die Datei /etc/apt/sources.list sollte wie folgt ausschauen – wichtige Passage ist hervorgehoben:

deb http://ftp.de.debian.org/debian/ etch main non-free contrib

Nun apt updaten mit:

sudo apt-get update

Nun die Java Debian Pakete installieren:

sudo apt-get install sun-java5-jre

Oder wenn das JDK ( das Java SDK ) installiert werden soll:

sudo apt-get install sun-java5-jdk

Alternativen: GNU Compiler für Java

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.

Bereits im Frühjahr 2005 hat Debian's geistiger Vater Ian Murdock in seinem Blog angemahnt das Paketsystem von Debian und seinen Töchtern kompatibel zu halten, damit es nicht zu einem Fork kommt und man die gleichen Probleme wie bei RPM basierten Distributionen bekommt.

Ian's Ubuntu vs. Debian Betrachtungen gewinnen heute unter dem zunehmenden Erfolg von Ubuntu mMn. immer mehr Bedeutung. Seine Mahnung "we all win if and only if Ubuntu remains a good son" scheint aber von Mark Shuttleworth ungehört zu bleiben. Heute.de berichtete jüngst über "das beste Linux, das es je gab" und meint damit das für den Dezember angekündigte Debian GNU/Linux 4 mit dem Codenamen "Etch". Martin "Joey" Schulze gibt im Inverview die Bedenken vieler Debian-Entwickler wieder:

"Normalerweise freuen wir uns, wenn sich andere Projekte Debian als Basis aussuchen", erläutert Schulze. "Ein bisschen anders" sei das bei Ubuntu, der Linux-Distribution, die Mark Shuttleworth gegründet hat, südafrikanischer Millionär und erster Weltraumtourist. Ubuntus Popularität gehe mehr und mehr auf Debians Kosten: "Seine Firma hat Debian-Entwickler eingestellt und zieht einiges an Entwicklungszeit und Anwenderschaft von Debian ab."

Schulze befürchtet darum eine Spaltung, einen "Fork", wie das in Linux-Kreisen heißt: "Es sieht derzeit so aus, dass Ubuntu mehr oder weniger ein 'Fork' von Debian ist. Viele Entwickler haben damit ein Problem." Sollte Ubuntu dauerhaft an Debians Stelle treten, beende das auch die basisdemokratische Organisation: "Ubuntu hat ein anderes Leitungsmodell, hierarchische Strukturen - und der Projektleiter ist erheblich autoritärer."

Debian auf dem Desktop war bisher aufgrund dieser "basisdemokratische Organisation" alles andere als "Cutting Edge", so dass dieses Segment von Ubuntu im Sturm eingenommen werden konnte. Aber auch für den Einsatz auf dem Server ist der Entwicklungszyklus der community driven Distribution Debian oftmals ein Problem, so dass die Server-Version von Ubuntu zunehmend mehr Anhänger findet.

Natürlich ist es nicht fair den Output der Debian Community und seinen "pro bono maintainern" mit dem einer Distribution zu vergleichen, die sich zum einen die Errungenschaften eben dieser Community zunutze macht und zum anderen auf bezahlte Entwickler zurückgreifen kann - aber danach fragt in dem Moment kaum keiner, wenn ein Problem gelöst werden muss. Also bleibt die Ubuntu-Versuchung groß. Aber wenn die Beziehung zwischen Debian und Ubuntu entgegen Ubuntus "relationship declaration" zur Einbahnstrasse wird, so wird Ubuntus Erfolg Debian mehr schaden als nutzen. Und Martin "Joey" Schulzes Aussagen im Interview wollen dabei so gar nicht mit Ubuntus "wir haben uns alle lieb" Erklärung zusammenpassen... Also behält am Ende Ian Murdock Recht: "Mark, this doesn’t end well."