[abgebrochen] Kernel-Panic,ich auch !

[josef-wien]

mkinitrd hat sich über das fehlende root-Laufwerk beschwert, fdisk hat merkwürdigerweise garnichts gesagt und die Platte ließ sich nicht einfach einbinden - mount konnte die Platte nicht finden.

Diese Symptome lassen vermuten, daß mount --bind /dev /mnt/dev vor chroot /mnt gefehlt hat, und ein danach erfolgreiches /etc/init.d/boot scheint von der jeweiligen Systemkonstellation (oder einer Portion Glück?) abhängig zu sein.

 

[lostinspace]

Habe jetzt folgendes gemacht:

mount -t ext4 /dev/sdb2/ /mnt/sdb2 # betreffende root-Partition
cd /mnt
mount /dev/sdb2 /mnt # hatte erwartet,sdb2(den Inhalt) auch in /mnt vorzufinden,
war aber nicht!Habe ich jetzt /mnt/sdb2 über-
schrieben?
mount --bind /dev /mnt/dev
chroot /mnt # hätte ich hier vielleicht chroot /mnt/sdb2 nehmen sollen?
mount /sys
mount /usr
mount /proc
mkinitrd # ergab folgendes:mount: /dev/sdb5 already mounted or /usr busy
mount: according to mtab, /dev/sdb5 is already mounted on /usr
/usr/bin/ldd not available and mount /usr failed. mkinitrd does
not work without it.(sdb5 ist das andere /usr)
Hätte ich mir vielleicht das erste mount sparen können(sollen)?
Jetzt traue ich mich nicht,weiter 'rumzuprobieren,nacher überschreibe ich noch
die initrd vom laufenden System,und habe den nächsten Pflegefall an der Backe!
Werde jetzt erstmal Rebooten,sicherheitshalber.

 

[spoensche]

Wenn das Problem für dich gelöst ist, dann setzte den Thread bitte noch auf gelöst. Dazu ersten Beitrag editieren und ein [gelöst] im Titel einfügen.

 

[lostinspace]

Nein,garnichts ist gelöst!
Ich bin ja schon nahe dran(?),aber ich krieg noch nicht so richtig die Kurve(s.o.).
Hatte mich bloß erstmal mit 'nem Reboot aus dem chroot gerettet.

 

[josef-wien]

mount -t ext4 /dev/sdb2/ /mnt/sdb2
...
mount /dev/sdb2 /mnt

Was soll dieser Unfug? Wozu hängst Du dieselbe Partition zweimal ein, und dann noch das zweite Mal "über" das erste Mal?

hätte ich hier vielleicht chroot /mnt/sdb2 nehmen sollen?

Nicht nur hier!

mount /dev/sdb2 /mnt/sdb2
mount --bind /dev /mnt/sdb2/dev
chroot /mnt/sdb2

/dev/sdb5 already mounted or /usr busy

Schau vor chroot mit mount nach, ob die Partition eingehängt ist, und hänge sie gegebenenfalls aus.

 

[lostinspace]

Nachsicht,Nachsicht!Ich hab' mich mit dem chroot-jail noch nicht näher be-
faßt,keine Ahnung z.B.,wo ich nach "chroot" überhaupt bin.
Ich hab' halt nur gedacht,ich muß erstmal die Partition einhängen,um da
irgendwas mit zu machen.Mit dem "mount /dev/sdb2 /mnt"-Befehl dachte ich,
die Partition wird (nochmal) direkt in /mnt eingehängt.
Habe also :

mount /dev/sdb2 /mnt/sdb2
mount --bind /dev /mnt/sdb2/dev
chroot /mnt/sdb2
mount /proc
mount /sys
mount /usr
mkinitrd

versucht,nach /dev/sdb5(usr) already mounted or /usr busy,ausgehängt,und
dann lief "mkinitrd",aber nur mit 95% "Kommando nicht gefunden"-Meldungen.
Wie muß ich denn die mount /proc,sys,usr-Sequenz genau gestalten?
Ich habe vor "chroot" geschaut,kein /usr eingehängt,außer das vom aktuellen
System.
Und wie komme ich aus dem chroot-jail wieder 'raus?

 

[josef-wien]

Und wie komme ich aus dem chroot-jail wieder 'raus?

exit

nach /dev/sdb5(usr) already mounted or /usr busy,ausgehängt,und dann lief "mkinitrd",aber nur mit 95% "Kommando nicht gefunden"-Meldungen.

Nachdem ich noch nie auf die Idee gekommen bin, für /usr eine eigene Partition anzulegen, kann ich Dir hier nicht weiterhelfen. Aber vielleicht solltest Du doch das Rettungssystem verwenden.

 

[spoensche]

Die / und /usr Partition, zwecks chroot, zu mounten macht nur Sinn, wenn du z.B. von einer Live-CD bootest. Also entweder von einer Live-CD booten und folgendes ausführen:

mount /dev/sdb2 /mnt
mount /dev/sdb5 /mnt/usr

chroot /mnt /bin/bash

und dann die initrd erzeugen oder per Install-DVD in den Reperaturmodus booten

 

[lostinspace]

Hallo,und frohe Ostern !

Ja,also,so richtig komme ich hier nicht weiter.Wenn,dann brauche ich die komplette
Vorgehensweise,egal,ob in Reparaturkonsole,Chroot,oder mit Live-CD.
Diese ganze "chroot"- und "bind"-Materie,z.B.,habe ich durchaus auf meiner schier
endlosen Linux?-Liste,aber wenn man da als Notfall mit konfrontiert wird,ist das
kein so richtiger Einstieg.
Deshalb werde ich das Thema hier erstmal auf Halde legen,wenn noch jemand weiter-
helfen kann,immer zu,das System existiert noch.
Vielen Dank bis hier !

Grüße !

lostinspace

 

[spoensche]

1. Von einer Live-CD booten
2. Konsole öffnen

3. mount /dev/sdb2 /mnt
4. mount /dev/sdb5 /mnt/usr
5. chroot /mnt /bin/bash
6. mkinitrd -k /boot/vmlinuz-.... -i /boot/initrd.....
7. exit
8. reboot

 

[Anonymous]

Diese ganze "chroot"- und "bind"-Materie,z.B.,habe ich durchaus auf meiner schier
endlosen Linux?-Liste,aber wenn man da als Notfall mit konfrontiert wird,ist das
kein so richtiger Einstieg.

Das liegt nur daran weil dir noch nicht klar ist was da passiert und zu was du das brauchst.

mkinitrd soll eine neue initrd für dein System erstellen. Dazu benötigt es die genaue Kernelversion die installiert ist, und die Module die zu dieser Kernelversion gehören und je nach dem noch eine Menge Informationen aus deinem System mehr, zB wie hießt das Rootdevice, an welchem Treiber hängt diese Platte, wird dazu noch ein RAID oder LV-Treiber oder ähnliches benötigt, wo befindet sich genau das /boot Verzeichnis, ein paar Konfigurationsdateien aus dem System werden oft auch noch verwendet (zB für Raid, LV, Crypt , bestimmte Kernelmodule usw. und vieles mehr.

mkinitrd ist ein Script das die Informationen aus deinem System zusammensuchen kann und aus Scripten und Vorlagen die extra dafür in einem bestimmten Verzeichnis passend zur mkinitrd vorhanden sind, dann die initrd für dich richtig zusammenbauen. Dazu muss aber das Script das System genau so vor sich haben, damit es alles genau erkennen kann und auch die richtigen Vorlagen passend zur mkinitrd Version hat und vor allem den richtigen Kernel mit den richtigen Kernelmodulen auch findet. Also am besten das System läuft gerade wenn du mkinitrd ausführst. Geht aber nicht, denn ohne oder mit defekter initrd kannst du es ja gar nicht starten.

Bootest du von einer CD dann bootest du einen ganz anderen Kernel hast ein anderes Rootdevice andere Mountpoints und andere aktuelle Konfigurationsdateien, andere Programmversionen, alle ist vollkommen anders, damit kann mkinitrd nicht das finden was es braucht um eine initrd zu bauen die ein ganz anderes System starten soll, du willst ja keine initrd erstellen die dann von CD bootet und die CD als Rootdevice einbindet.

Dazu gibt es den chroot Befehl. Mit diesem Befehl kannst du Befehle ausführen und für die Laufzeit dieses Befehls das Rootverzeichnis für diesen Befehl ändern.

und genau das wird gemacht. Von CD hast du gebootet nun mountest du dein Rootfilesystem von Platte nach /mnt. Gibst du jetzt

chroot /mnt

ein, dann wird dort eine neue Shell gestartet und zwar die von /mnt/bin/bash und diese hat dann als Rootfilesystem das Filesystem das unter /mnt gemountet ist. Diese Shell kann gar nicht in dein orginal CD Rootfilesystem reinschauen, denn für diese Shell ist "/" genau das was in deinem normal gestarteten CD-System /mnt ist. Damit werden jetzt von dieser Shell aus also nur Kommandos ausgeführt und Dateien gefunden die auf dem gemounteten Filesystem sind, nicht das was auf der CD ist. Du bist damit in einer Chrootumgebung gefangen bis du diese Shell mit exit oder Tastenkombination beendest.

Damit aber noch nicht genug. Es werden für viele Befehle das /proc /sys und /dev Verzeichnis benötigt. ZB um Platten anzusprechen. Das sind spezielle Systemfilesyteme die physikalisch nicht existieren sondern nur im Speicher oder im laufendem Kernel. Damit du diese in deiner Chrootumgebung auch hast, müssten diese innerhalb deiner Chrootumgebung erst komplett neu aufgebaut werden, dazu müssten eine Menge Scripte dort gestartet werden, braucht man aber nicht.
Dein laufender Kernel von CD der hat ja diese Filesysteme alle schon gestartet und gemountet. Soweit die CD jetzt einigermaßen kompatibel zu deinem System auf Platte ist hast du die Möglichkeite diese jetzt nur noch ein 2. Mal einzuhängen und zwar unterhalb von /mnt und zwar nachdem du das Rootfilesystem von Platte gemountet hast aber noch bevor du chroot startest.
Dieses macht die Option "-o bind" beim Mountbefehl

mount -o bind /proc /mnt/proc

zB. bindet das Filesystem was unter /proc ist noch ein 2. Mal in das Verzeichnis /mnt/proc ein. Die Dateien sind dann 2 Mal zu sehen einmal unterhalb von /proc und einmal unterhalb von /mnt/proc.
Das also mit den 3 Filesystemen gemacht und du hast dann dort in der Chrootumgebung auch den vollen Zugriff auf /sys /proc und /dev und kannst eben auch zB Platten mounten oder Netzwerkgeräte ansprechen.

Damit immer noch nicht genug. Wenn dein Plattensystem neben dem Rootfilesystem auch noch ein separates /boot /usr /var /tmp /opt dann muss dieses auch noch gemountet werden. Und zwar entweder bevor du den chroot Befehl absetzt nach /mnt/boot /mnt/usr /mnt/var .....
oder nachdem du den chroot Befehl ausgeführt hast dann nach /boot /usr /var ..... Und Vorsicht, innerhalb der chroot-Umgebung lügt der mount-Befehl. Dieser nutzt die Datei /etc/mtab um anzuzeigen was für Filesysteme gemountet sind. Innerhalb der Chroot-Umgebung wird der Befehl dir anzeigen was gemoutet war als das System das letzte mal gelaufen ist, da diese Datei erst beim Systemstart neu angelegt wird, und das System innerhalb der chrootumgebung wurde ja nicht gestartet, sondern nur zusammengebaut und dann quer reingesprungen.

Alles richtig gemacht, dann hast du dann das komplette System so wie es wirklich im Normalfall aussieht nach /mnt gebastelt und bist dann mit chroot dort reingesprungen. Das Chrootsystem verhält sich jetzt bis auf wenige Ausnahmen genau so als wenn es selbst gestartet wurde. Eine Ausnahme sind zB Kernelmodule. Der Kernel wurde von der CD gestartet und du kannst keine Module nachladen, da du die Module auf der CD innerhalb der chrootumgebung nicht sehen kannst. Ein paar Kleinigkeiten noch mehr da in dem System ja keine eigenen Dienste und Daemons gestarte wurden, aber das stören erstmal nicht für die Reperaturarbeiten die du jetzt dort machen kannst.

Wenn du jetzt mkinitrd ausführst, dann führtst du das mkinitrd Script aus, was auf deiner original Platte ist und es findet die originalen Filesysteme und Konfiguration und die originalen Dateien als wenn das System dort wirklich laufen würde. Dieses mkinitrd Kommando ist aber überall etwas anders. Suse benötigt zB keine Optionen und für jeden Kernel der unterhalb von /boot gefunden wird, wird auch eine neue initrd erstellt. Bei anderen Distributionen musst du die Kernelversion immer mit angeben (fedora zB) für die eine neue initrd erstellt werden soll. Du musst dir also auf dem System jetzt eventuell die Manpage anschauen, was dort zu mkinitrd genau gesagt wird.

Diese Vorgehensweise mit chroot kann ebenfalls benutzt werden für eine Grub Reperatur oder für das Installieren von Programmen in einem defektem System das nicht startet, zB weil ein defekter Kernel installiert worden ist. Reparaturkonsolen arbeiten zT auch so.


Jetzt ließ das in Ruhe durch, verstehe es, probiere es aus und versuche es mal richtig zu machen.

robi

 

[Rainer Juhser]

Robi, den Beitrag könnte man fast unverändert ins Wiki stellen!

 

[lostinspace]

Erstmal vielen Dank für Eure grundlegenden Hilfestellungen.

spoensche : Jetzt,wo ich die Sequenz komplett sehe,verstehe ich auch,
was und wo.Klar,wenn das root gemounted ist,muß ich nicht /proc und /sys,wohl
aber /usr (in meinem Fall) mounten.
Und mit der mkinitrd-Option wird der jeweilige Kernel ausgewählt :
Z.B.:mkinitrd -k /boot/vmlinuz-desktop -i /boot/initrd desktop ?
Und nicht von Live-CD,sondern vom Nachbarsystem aus,exakt das gleiche?

Grrr,apropos Kernel-Auswahl.Jetzt sehe ich gerade,auf einem frisch aufgesetzten
11.3 + Upgrade + KDE-Update,daß im /boot nur ein Desktop-Kernel vorhanden ist!
Was ist das denn jetzt?
Beim Upgrade hat er mir den Xen-Kernel geladen,obwohl ich den extra nicht installiert
hatte.
Hab alle drei Kernel-Archive im /boot(Default,Desktop und Xen),aber,wie gesagt,
nur vmlinuz-desktop und initrd-desktop.
Hab' mich schon über das kurze Grub-Menue gewundert.Das hatte ich auch noch nie.
Ist das jetzt ein neues Feature aus dem Update-Repo?

robi : Da kann ich Rainer Juhser nur recht geben !
Bei so grundsätzlichem Informationsbedarf hättest Du es Dir mit ein paar guten
Literaturhinweisen leichter machen können...
Aber mir erspart Deine konzentrierte Darlegung einiges an Recherche und Studium.
Echt super !

Aber jetzt kommt der Hammer! Wahrscheinlich ist unser aller Einsatz hier für die Katz!
Wie ich am Anfang dieses Themas schon beschrieben hatte,ist eine ehemals
funktionierende initrd aus mysteriösen Gründen in eine 0-Byte-Datei mutiert,aber
vorhanden.Daß der Default-Kernel mit seiner ursprünglichen initrd auch in Panik
gerät,steht wohl auf einem anderen Blatt...
Aber jetzt habe ich beim 'rummounten entdeckt,daß nahezu die gesamte /usr-Partition
leer ist,bis auf das /lib64-Verzeichnis,in dem sich nur ein aspell-Verzeichnis
befindet!
Das wars ja wohl!Und auch hier keine Vorstellung,wie das passiert sein könnte.

Grüße !

lostinspace

 

[Anonymous]

robi : Da kann ich Rainer Juhser nur recht geben !
Bei so grundsätzlichem Informationsbedarf hättest Du es Dir mit ein paar guten
Literaturhinweisen leichter machen können...
Aber mir erspart Deine konzentrierte Darlegung einiges an Recherche und Studium.
Echt super !

Danke, aber mit den "ein paar guten Literaturhinweisen" ist das so eine Sache, meint ihr ich würde mir die Mühe machen das selbst zu schreiben wenn es so etwas gäbe und ich wüsste wo ? Im Internet findet man allen Mist, jede Menge Halbwahrheiten, Doktorarbeiten über alles mögliche,( nur muss man da mindestens Professor sein, um die halbwegs zu verstehen) aber oftmals für so einfache Sachen keine umfassend brauchbaren Texte in denen wirklich umfassende und langwierige Erfahrungen so eingearbeitet sind, dass sich jemand mit wenig Vorwissen schnell einarbeiten kann und alles auf 2 Seiten hat was er wirklich wissen muss. In Deutsch schon gleich 2 mal nicht. Da bleibt eben nur selbst schreiben.
Wenn ich alles zusammenfassen würde was ich so schon im Internet hinterlassen habe, könnte man da ein schönes dickes Buch daraus binden.
Und wenn ich sehe, das es wirklich was bringt und auch genutzt und von anderen verlinkt wird, dann mache ich mir auch gerne die Mühe.

robi

 

[spoensche]

Aber jetzt habe ich beim 'rummounten entdeckt,daß nahezu die gesamte /usr-Partition
leer ist,bis auf das /lib64-Verzeichnis,in dem sich nur ein aspell-Verzeichnis
befindet!
Das wars ja wohl!Und auch hier keine Vorstellung,wie das passiert sein könnte.

Wenn du noch an die Logfiles dran kommst, könnte man mal nachforschen.

egrep -i "(error|fail|segfault|trace|warn|fatal)" /var/log/{messages,warn,faillog,mail.err}

@robi:
Ich weiss ja nicht, wie es zeitlich bei dir aussieht, aber es wäre mal eine Überlegung wert, einen Blog ins Leben zu rufen oder wie siehst du das?

 

[lostinspace]

robi : Ja-ah,gute,alte Analog-Zeit!Da gab es wirklich noch für fast jedes Anliegen
richtig gute Fachbücher,man mußte diese nur erkennen.Ich bin guter Autodidakt,
ich muß keinen 1000-Seitenwälzer durchlesen,bevor ich weiß,ob er was taugt.Nur
schnell 5 Minuten ein bißchen durchblättern,schon die Spreu vom Weizen getrennt.
Und gerade bei EDV-Literatur machen sich viele,denen eigentlich die Hände abgehackt gehören,damit sie ja kein Wort niederschreiben, die natürliche Abneigung der Leute
gegen Nullen und Einsen zu nutze,um ihren Reibach zu machen.
Echt gut,wenn so ein Statement mal aus berufenen Munde ertönt,ich bekomme
immer einen Hals,wenn ich auf irgendwelche Suchmaschinen verwiesen werde.
Und sollte ich dann vielleicht solche Kritik wagen,heißt das nachher noch,"erst zu blöd,
den Computer zu bedienen,und dann noch zu faul,zu suchen!".

Aber zum Thema :
spoensche : Du wolltest es ja so haben,hier mal die Auszüge der Logfiles:

< http://pastebin.com/65rxNFkP >

Vielleicht erzeugen sie ja bei Dir noch etwas anderes als Übelkeit...

Das seltsame Verhalten bei der Installation (Default fehlt) werde ich mal in ein Extrathema
überführen.Wobei sich mir wiedermal die Frage stellt,in welches Forum,in
"Paketmanager...",oder besser in "Update..."?

Grüße !

lostinspace

 

[spoensche]

Wenn es um Installation geht, dann ist beim Update.. besser aufgehoben.

Ich habe mir gerade mal die Ausgabe angesehen und auch fündig geworden. Der Kernel versucht einen Coredump vom RAM zu erstellen was aber nicht möglich ist, weil der RAM defekt ist. Deshalb u.a. auch die Meldungen über fehlende Werte in Dateien unter /proc. /proc wird im RAM verwaltet, der bei dir wohl defekt zu sein scheint und somit gehen die Werte ständig verloren.
Das die DIMM Tabelle über DMI (Desktop Management Interface) nicht abgefragt und gefüllt werden können deutet auch auf einen defekten RAM.

Nimm dir mal eine Live-CD und führe Memtest aus. Memtest überprüft deinen Arbeitspeicher.

 

[lostinspace]

Schöner Schreck in der Abendstund',würde mir ja noch fehlen.Wollte eigentlich denSpeicher für'n halben Preis in Zahlung geben,und auf 4GB aufrüsten.
Ich hab' den Memtest aus dem /boot genommen,hat mir glücklicherweise
0 Fehler angezeigt.Ist das aussagekräftig?
Und weiter hast Du da nichts bedenkliches entdeckt?

Das mit dem fehlenden Default-Kernel war wohl auf meine sparsame Installation zurückzuführen,dachte aber,selbst bei einer Minimal-Installation sind beide
Kernel dabei.

Könntest Du vielleicht noch,der Vollständigkeit halber,für die chroot-Sequenz hier...

1. Von einer Live-CD booten
2. Konsole öffnen

3. mount /dev/sdb2 /mnt
4. mount /dev/sdb5 /mnt/usr
5. chroot /mnt /bin/bash
6. mkinitrd -k /boot/vmlinuz-.... -i /boot/initrd.....
7. exit
8. reboot

...die evtl. Abwandlungen für die Aktion auf dem Nachbarsystem posten?

Besten Dank erstmal!

Grüße !

lostinspace

 

[spoensche]

at mir glücklicherweise
0 Fehler angezeigt.Ist das aussagekräftig?
Und weiter hast Du da nichts bedenkliches entdeckt?

Wieviele Tesläufe hast du durchgeführt, min. 10? (dauert ca. 4-5 Std)
Wenn nicht, ist es nicht wirklich aussagekräftig.

Wenn die fehlgeschlagenen Anmeldeversuche der User rabe,emu,root,chef von, dir nicht bekannten, dann nimm deinen Rechner mal schleunigst vom Netz.

Das mit dem fehlenden Default-Kernel war wohl auf meine sparsame Installation zurückzuführen,dachte aber,selbst bei einer Minimal-Installation sind beide
Kernel dabei.

Was verstehst du unter sparsamer Installation? Eine Minimalinstallation ist das nicht, sonst wäre unter anderem kein xscreensaver installiert.

Könntest Du vielleicht noch,der Vollständigkeit halber,für die chroot-Sequenz hier...

Das schaffst du auch. Eigeninitiative und ein bisschen nachdenken, was für Mountvorgänge getätigt und was gemountent worden sind bevor du in die chroot Umgebung gewechselt bist.

 

[lostinspace]

Hallo !

Wieviele Tesläufe hast du durchgeführt, min. 10?...

Naja,nur 2,mach ich dennn nochmal,und länger.

... die fehlgeschlagenen Anmeldeversuche der User ...

User sind alle von mir,müßten erfolglose Versuche sein, mit dem defekten
System zu starten.

Was verstehst du unter sparsamer Installation?

Schon ca. die halbe DVD...
Bootet aber schon spürbar schneller.

Das schaffst du auch.

Ja,ja,schon gut! Sollte aber auch keine Faulheit sein,sondern mehr eine gewisse
Vorsicht.
Wenn schon Dateiinhalte und ganze Partitionen verschwinden,wenn ich nichts mache,
was passiert denn erst,wenn ich etwas (falsch) mache.
Aber hab ja' jetzt etwas "Stoff",um ein bißchen 'rumzuprobieren.
Kann ich nicht einfach,nur zu Übungszwecken,eine andere Usr-Partition 'rüberkopieren?
Das kaputte System bietet sich ja an,um da irgendwelche Experimente zu veranstalten.

Grüße !

lostinspace