initrd bei meinem Debian/testing Sytsem

Nachdem ich festgestellt habe, dass die meisten Zugriffe auf mein blogg über Suchmaschinen kommen, bei denen nach dem Kernel panic Problem mit der Meldung "/sbin/init: 432: cannot open dev/console: No such file" gesucht wird, habe ich mich entschlossen, mir das Problem doch nochmal genauer anzusehen.
Im Netz liest man häufig, dass das Problem beim Update auf Kernel 2.6 in Zusammenhang mit SATA-Platten auftritt, da der 2.6er Kernel die SATA-Platten als /dev/sdx Devices anspricht, der 2.4er aber noch als /dev/hdx. Daher muss man beim Update die Bezeichnungen u.a. in der /etc/fstab anpassen. Aber all dies konnte bei mir nicht dir Ursache des Problems sein, da ich zum einen nur den 2.4er Kernel verwendete und zum anderen überhaupt keine SATA-Platten einsetze. (Solche High-Tech Geräte besitze ich gar nicht … 😉
Nun gut. Ich hatte das Glück, dass ich noch einen monolothischen Kernel ohne initial Ramdisk vorliegen hatte, mit dem ich das System noch booten konnte, ohne jedesmal die Knoppix-CD bemühen zu müssen.
Also habe ich mir mal die Ramdisk angeschaut.
Mit dem Kommando
mount -t cramfs /initrd.img /mnt -o loop
kann man die Ramdisk nach /mnt mounten und sich den Inhalt anschauen.
Mir ist aufgefallen, dass in der Datei linuxrc.conf  die Zeile IDE_CORE=none
zu finden war, was mich stutzig machte.
Daraufhin habe ich mir das Erzeugen der Ramdisk mit dem Skript
/usr/sbin/mkinitrd angesehen. Dieses Skript sucht unter anderem nach den nötigen Modulen, die zum Booten des Kernel bzw. zum Zugriff auf das root-Filesystem notwendig sind. Es ist schon an den 2.6er Kernel angepasst. Daher sucht es im passenden modules-Verzeichnis nach Dateien, die auf .ko enden und auf den 2.6er Kernel hindeuten. Hat es solche Dateien gefunden, berücksichtigt es nur noch .ko-Module und keine alten .o-Module.
Bei mir haben sich nun — wie auch immer — zwei Dateien mit der Endung .ko eingeschlichen, obwohl ich doch nur einen 2.4er Kernel habe. Ich habe diese beiden Dateien gelöscht und mit
dpkg-reconfigure kernel-image-2.4.27-2-686
eine neue Ramdisk erzeugt. Und siehe da, in der Datei linuxrc.conf fand sich die Zeile:
IDE_CORE=ide-core
Und nach einem Reboot kam das System hoch, wie man es erwartet.
Dies zeigt mal wieder den Vorteil, den ein quelloffenes System hat: Ich kann, wenn ich mir nur die Zeit nehme, tief genug eindringen, um den Fehler zu analysieren und dann auch zu beheben. Auch wenn nicht bei allen, die den obigen Fehler erhalten, der Fehler auf diese falschen Dateien zurückzuführen ist, so zeige ich doch einen Weg auf, mit dem dem Fehler auf die schliche kommen kann.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *