Hallo Community,
ich betreue ehrenamtlich einen Server in einer sozialen Beratungsstelle –
bald brauche ich die auch für meine Nerven.
Ich habe dort auf Basis von Debian testing (Etch) einen Server mit verschiedenen Diensten aufgebaut
(DNS,DHCP,eGroupware,Samba). Der Server hat einen Dual-Core-Proz von Intel, einen 3Ware-Controller mit 2 Sata
Platten, die im Raid 1 laufen (also gespiegelt).
Die Installation (netinstall) ist vollständig über die offiziellen Debian-Server erfolgt und es sind keine
selbstgebauten Kernel eingerichtet worden. Das Dateisystem ist JFS.
Nach verschieden Stromausfällen haben wir eine USV (APC 820) angeschafft: Der Server wird bei Stromausfall, nach einer
bestimmter Zeit kontrolliert herunter und wenn der Strom wieder da ist, automatisch hinauf gefahren.
Der Server ist seit Start problemlos gelaufen (Dank Debian), die Uptime war 54 Tage.
Die Updates wurden immer remote mit ‘aptitude update’ und ‘aptitude dist-upgrade’ gemacht – allerdings
kein reboot nach update….
Jetzt hatten wir wieder einen Stromausfall: Der Server fährt runter, bootet nach einschalten des Stroms
und endet mit der Fehlermeldung:
VFS: Cannot open root device “sda4” or unknown-block(0,0)
Please append a correct “root=” boot option
Kernel panic – not syncing: VFS: Unable to mount root fs on unknown-block(hd0,0)
Überprüft habe ich die fstab (sda4 ist korrekt), menu.lst (also Grub als Bootloader, auch korrekte einträge),
das Dateisystem mit fsck.jfs (CLEAN-Ergebnis), die logfiles (keine Einträge), Festplattenplatz (df).
Die eingetragenen Kernelversionen kann ich nicht punktgenau nennen, da ich gerade nicht vor der Maschine sitze:
Es müßte 2.6.17-686 (auch recovery), 2.6.16-686 (auch recovery) und 2.6.16-486 (auch recovery) im Grub-Menü sein.
Wenn ich mit den höheren Kernelversionen im Recovery-Modus boote, kommt die Kernelpanic – nur eine KVersion
erlaubt mir wenigsten in den Recovery-Modus mit einer root-Anmeldung zu arbeiten.
Leider weiß ich jetzt nicht welche. Ich glaube es war die “mittlere” Version. Das ich von einer CD booten kann
und dann in den rescue-mode wechseln kann, weiß ich und habe ich auch getan.
Die Partitionen (sda1-4) können dann ohne probleme gemountet werden. Einen Hardware-Schaden möchte ich ausschliessen.
Also kein verbasteltes System, alles vorher 3mal getestet und keine sebstgestrickten Pakete – eben
ein produktives System.
Aber genau das irritiert mich: ich habe einiges gegoogelt und hier gelesen – der Fehler wird immer/meistens mit
selbstgebauten Kernel genannt. Eine grundsätzliche Lösung ist für mich nicht erkennbar (natürlich durch die
Verschiedenartigkeit der Systeme und Distributionen).
Also:
Für mich sieht das nach einen sauberen Schnitt durch einen gedrehten Parameter in einer config
durch das online-update aus.
Meine Fragen:
1. Gibt es ein logfile unter Debian, in dem ich speziell nur die online-updates
der letzten XX Tage auslesen könnte?
2. Kann jemand einen Link nennen, der den Befehl mkinitrd erläutert (wenn möglich an einen Beispiel)? Ich habe
diesen Befehl immer wieder in Verbindung mit der obengenannten Fehlermeldung – allerdings meistens mit
selbstgebauten 2.4-Kernel – gelesen.
3. Kann es sein, dass nach einen online-update etwas im System neu generiert werden muss? Ich mache die updates
nicht automatisiert und belasse bei Nachfrage normalerweise die vorliegende config (also die selbstkonfigurierte)
und schaue mir die Unterschiede an. (Debian-User wissen wohl was ich meine.)
Status im Moment: Kein Mail, Keine Daten, kein Internet – Hurrah.
Dank für jede Hilfe.
Mathias
Hallo Mathias,
Der Kernel findet deine Festplatten/Partitionen nicht.
Im Debiankernel sind keinerlei Treiber für Festplattencontroller integriert.
Die Treiber liegen als Module in der Initial Ramdisk und werden nach starten
des Kernels geladen.
Nun ist wahrscheinlich dein Problem, dass die in der jeweiligen Sektion
von /boot/grub/menu.lst angegebenen initrds nicht mit dem zu bootenden Kernel
übereinstimmen.
Die Images für die Ramdisks liegen in /boot und tragen normalerweise die
Version des Kernels im Namen.
Scheinbar ist beim Kernelupdate die zugehörige Initrd nicht korrekt erstellt
worden oder eine falsche wurde dem Kernel zugeordnet.
Du könntest versuchen, die Einträge in menu.lst manuell hinzubiegen, den
Kernel neu zu installieren oder mit “mkinitrd -o Dateiname Kernelversion” eine
neue initrd anzulegen und diese in menu.lst dem Kernel zuzuordnen.
mf
Rico
Ich hatte auf Testing auch schon mal dieses Phänomen.
Die Ursache war ein Kernelupdate. Mit diesem Update hat sich die Numerierung meiner S-ATA Laufwerke geändert. Die Laufwerke des PCI SATA-RAID Controller waren plötlich vor den Onboard Komponenten. (sda war sdc, sdb -> sda und sdc -> sdb)
Klingt Verwirrend, und war es auch.
Ich habe den Verdacht das du diesem Verhalten auch zum Opfer gefallen bist.
In dem Fall kannst du mit root=/dev/irgendwas in den Rescuemode starten die /etc/mtab anpassen. mit sync die Änderungen auf die Festplatte schreiben und dann sollte nach einem neustart der neue Kernel auch wieder laufen.
Ja, ich muss den beiden anderen Recht geben. Auch ich hatte genau an der Stelle Probleme das die initrd nicht richtig erstellt wurde nach einem Upgrade bzw. einem Netinstall/dbootstrap. Und zwar im Zusammenhang mit aktueller Doppelprozessor Hardware und SATA.
Auch die zweite Vermutung das die Reihenfolge der SCSI Festplatten nicht mehr stimmen kann ist richtig. Auch dies hatte ich schon. Es reicht ein zufällig sitzender USB-Stick und schon war es das.
Ich hoffe Du kannst das Problem jetzt lösen. Wenn nicht antworte halt noch mal mit ein wenig Debug-Text.
Gruss, Ecaroh
Hallo Commnunity,
ich habe die Lösung gefunden – allerdings etwas ganz anderes als erwartet.
Die Fakten:
a. die gültige initrd war umbenannt.
b. eine initrd war mit 0 KB vorhanden.
c. der Apache Webserver zeigte auf der localhost-adresse im Browser eine Webseite mit “It works!”
Nach dem umbenennen der initrd in den ursprünglichen Namen, dem löschen der 0 KB-initrd und dem hinzufügen eines kleinen Kommentars zur Webseite bootete der Server ohne Probleme – äh, kann das sein, dass unser Server “liebevoll” gehackt wurde?
Falls ja, habe ich den Wink verstanden und werde mich nochmal gezielter mit dem Thema Sicherheit auseinander setzen.
Wenn nein, war wohl das online-update nicht ganz sauber, was aber bestimmt mehreren Nutzern in der Gemeinde schon aufgefallen wäre.
Tja, man lernt nie aus. Ich vermute momentan, dass unser ssh-pw zu schwach war…
Trotzdem vielen Dank für die möglichen Lösungsansätze.
Wieder Nerven.
m.
Zu meinen gestellten Fragen will ich hier noch einige Antworten geben:
a. Der Eintrag “It Works!” ist also lt. Auskunft eines Kollegen die neuere Testseite der Apache Group – die kannte ich so nicht.
b. Die erfolgten Online-updates können in /var/log/aptitude nachgelesen werden – die Datei eignet sich auch ganz gut, um bei Server-SLA’s die updates nachzuweisen. Fehler bei update werden nicht vermerkt.
c. Die User-Anmeldungen sind in /var/log/auth.log zu finden – dort werden auch vom System erkannte (mögliche) Eindringversuche vermerkt (BREAK-IN-Eintrag).
d. Die/Das USV, die/das wir einsetzen, ist eine APC CS650 (usb) und arbeitet hervorragend mit dem apcupsd-Dienst in Debian zusammen.
Also: Eindringversuch war es scheinbar doch nicht: das online-update hatte scheinbar, die alte Datei .bak gemacht und die neue nur mit 0 KB angelegt.
Mathias