FreeBSD fährt nicht mehr hoch

Amorphus

Amorphus

Ich bin der Neue
Hallo liebe Leute,

mir ist etwas passiert, was mir doch ehr Angst macht:

Ich wollte meine Software updaten, habe cvsup -g ... cd /usr/ports ... make fetchindex ... portsdb -u ...pkgdb -F ...portupgrade -ar gemacht.

Nach c.a. 5 Stunden portupgrade -ar unter KDE (ich weiß, macht man nicht *schäm*) macht es auf einmal *knack* und der Rechner bootet neu. Ich mache heute, 5 Tage später, auf der Console nochmal von vorne. Als ich bei pkgdb -F bin und er mir Stale Dependencies angibt, gehe ich auf die nächste Console und gebe ein portinstall für das Programm nach dem Pfeil ein. Dieses Programm war der nvidia-driver-irgendeineZahl. Auf einmal will der Rechner wieder neu booten, es stand irgendwas mit Kernel blah auf der Console.

Tja, da habe ich mir ein Herz gefasst und gleich wieder hochgefahren. Was soll ich sagen: der Bootvorgang wurde nach einer Sekunde uptime abgebrochen mit einer panic und ich sitze vor dem Rechner und gucke ungefähr so:eek:

Ich wollte schon einmal diese Vorgeschichte posten, bitte sagt mir, ob ihr sowas schonmal erlebt habt, wie ihr das verkraftet habt und mit wem ihr darüber reden konntet. Sagt mir, was ihr für Infos braucht, was es genau sein könnte...

Ich weiss, ich hatte schon immer ein paar Probleme mit der nVidia TNT2 Vanta aber sowas mit Kernel und so...ich möchte;'(


Amorphus
 
Offensichtlich stimmt mit Deinem nvidia-Kernel-Modul etwas nicht. Das kann z.B. daran liegen, dass der Port nicht richtig/vollständig installiert wurde, oder das das Modul nicht richtig zum Kernel paßt.

Du hast mehrere Möglichkeiten, z.B. mit einem Rescue-System (z.B. FreesBIE, o.ä.) starten, mounten und aus /boot/loader.conf die Zeile nvidia_load="YES" entfernen. Oder beim Bootvorgang gleich abbrechen und das Modul manuell vom Ladevorgang ausschließen.
 
Ist schon erschreckend, wenn's passiert. Augen zu und durch.
Halte den Bootvorgang an beim Fenster mit dem Daemon, drücke die 4, was Dich in den sogenannten Singele User Boot Modus bringt. Danach bestätigen (er will den Pfad zur sh haben), und erst mal mit /sbin/fsck -p zu reparieren versuchen. Läuft das nicht durch, dann /sbin/fsck -fy (Achtung! Englische Tastatur). fsck ist zwar nicht die tolle Lösung und er kann Dir einiges zerrödeln, aber er hilft (hoffentlich) erst mal.
Nach dem fsck mit reboot neu starten, mach ein pkgdb -fu und ein portsdb -fu, denn mit Sicherheit ist was in /var/... zerrödelt, so baust Du die Datenbanken für die Ports wieder auf. Und deinstalliere den NVidia-Treiber und baue ihn neu. Scheinbar ist durch den Absturz die Kommunikation zwischen dem Treiber und dem Kernel durcheinander geraten.
 
@ i18n
Entweder, ich bin auf dem Holzweg oder Du hast nicht richtig gelesen. Kann man ein fälschlich geladenes Modul durch den Single-User-Mode umgehen? Mein letztes nvidia-Modul-Problem liess sich nichtmal durch den "safe mode" umgehen.
 
meine lösung wäre ein freesbie einwerfen und dann wie Steve sagte das nvidia modul aus der loader.conf werfen und neustarten und dann die sachen von i18n machen. das müsste es dann eigentlich gewesen sein :)

EDIT:
ok vergesst es. das hat er auch geschrieben. nicht richitg gelesen.
ignoriert mich :)
 
@ Steve`. Jau, Du warst schneller mit der Beantwortung. Ich denke auch, zunächst das falsche Mudul raus, aber das sollte auch im Single User Modus gelingen. Man muß halt nur die einzelnen Slices mounten:
/sbin/mount -a /
/sbin/mount -a -t ufs
/sbin/swapon -a

Dann kann man auch die /boot/loader.conf editieren.
Aber zuvor fsck.
 
@ i18n
Ich bin mir jetzt nicht mehr ganz sicher (was durchaus erstaunlich ist, ist gerade erst zwei Tage her), aber ich meine, es gab übers Beastie-Menü keine Möglichkeit, über das kaputte Modul hinwegzubooten. Es gibt jedoch den Weg, das Modul vor dem Bootvorgang zu disablen und dann zu booten. Das erfordert aber manuellen Eingriff und singleUser-Mode wars AFAIR nicht.
 
Steve` schrieb:
@ i18n
Ich bin mir jetzt nicht mehr ganz sicher (was durchaus erstaunlich ist, ist gerade erst zwei Tage her), aber ich meine, es gab übers Beastie-Menü keine Möglichkeit, über das kaputte Modul hinwegzubooten. Es gibt jedoch den Weg, das Modul vor dem Bootvorgang zu disablen und dann zu booten. Das erfordert aber manuellen Eingriff und singleUser-Mode wars AFAIR nicht.
Zum Vergrößern anklicken....
Ja, je nach Bootmanager kannst du direkt den kernel starten ohne den loader von FreeBSD zu bemühen. Was man dabei beachten muß weiß ich jetzt nicht, aber so verhinderst du jedenfalls, daß das nvidia-modul geladen wird. Wenn die loader.conf leer ist bootet der loader ja auch einfach nur den kernel...

Gruß

edit: eventuell gibt es sogar noch eine Möglichkeit den loader so zu starten, daß er die loader.conf ignoriert. Aber das ist nur eine Spekulation.
 
Zuletzt bearbeitet:
.mp schrieb:
Ja, je nach Bootmanager kannst du direkt den kernel starten ohne den loader von FreeBSD zu bemühen. Was man dabei beachten muß weiß ich jetzt nicht, aber so verhinderst du jedenfalls, daß das nvidia-modul geladen wird. Wenn die loader.conf leer ist bootet der loader ja auch einfach nur den kernel...

Gruß

edit: eventuell gibt es sogar noch eine Möglichkeit den loader so zu starten, daß er die loader.conf ignoriert. Aber das ist nur eine Spekulation.
Zum Vergrößern anklicken....
ja diese möglichkeit gibt es auch noch und zwar heisst der befehl "unload". damit schmeißt der alle module raus, die von ihm aus der laoder.conf geladen wurden. allerdings kann ich nicht sagen ob das funktioniert, weil ich das bis jetzt noch nie gebraucht habe.
die man page hilft aber bestimmt weiter ;)
 
Mit "unload" geht es.

Am Boot-Prompt:
Code: 
unload
load /boot/kernel/kernel
boot

Dann nicht vergessen aus der Datei /boot/loader.conf herzukommentieren.

So hab ich immer ein kaputtes Modul beseitigt.
 
Bei meinem letzten nvidia-Modul-Problem (vgl. aktuelle Threads in der -CURRENT-Mailingliste) hat unload nicht geholfen. Dort ging wirklich nur der Weg über disable. Ich bin allerdings mit beiden Methoden nicht so fit, dass ich jeglichen Fehler meinerseits ausschließen würde.
 
Ich wollt auch grad anmerken: wenn das Modul fehlerhaft ist und die Kiste in dem Moment stehen bleibt, in dem das Modul geladen wird, dann kommt man nicht mehr dazu es mit "unload" wieder zu entladen. Der Singleusermode ist dann auch unnütz. Deswegen schrieb ich auch "vllt gibt es eine Möglichkeit den Loader anzuweisen die loader.conf zu ignorieren." Aber der google weiß das bestimmt.. ;)

Gruß

edit: Die Manpages von boot(8), loader(8) und ähnliches erklären wie es geht. Man darf den loader nicht mit Grub starten, sondern muß den Bootmanager von FreeBSD (per chainloading zum Beispiel) benutzen. Dem kann man dann einige Befehle geben, unter anderem welche Configs er den Loader laden lassen soll. So kann man tatsächlich verhindern, daß die loader.conf abgearbeitet wird und somit umgeht man das maliziöse Modul.
 
Zuletzt bearbeitet:
.mp schrieb:
Ich wollt auch grad anmerken: wenn das Modul fehlerhaft ist und die Kiste in dem Moment stehen bleibt, in dem das Modul geladen wird, dann kommt man nicht mehr dazu es mit "unload" wieder zu entladen. Der Singleusermode ist dann auch unnütz. Deswegen schrieb ich auch "vllt gibt es eine Möglichkeit den Loader anzuweisen die loader.conf zu ignorieren." Aber der google weiß das bestimmt.. ;)
Zum Vergrößern anklicken....

Ich glaube, dass wir uns missverstehen. "unload" ist ein Befehl im Boot-Prompt, der den zu startenden Kernel (und Module) entfernt. nvidia.ko lädt erst nach dem Boot-Prompt, soweit ich mich erinnere.

Als letzte Möglichkeit bleibt noch das Live-System auf der FreeBSD-Installations-CD. Damit kriegt man (fast) alles wieder grade.

edit: Die Manpages von boot(8), loader(8) und ähnliches erklären wie es geht. Man darf den loader nicht mit Grub starten, sondern muß den Bootmanager von FreeBSD (per chainloading zum Beispiel) benutzen. Dem kann man dann einige Befehle geben, unter anderem welche Configs er den Loader laden lassen soll. So kann man tatsächlich verhindern, daß die loader.conf abgearbeitet wird und somit umgeht man das maliziöse Modul.
Zum Vergrößern anklicken....

Ich würde /boot/loader starten anstatt den Kernel direkt. Ich habe auch den FreeBSD-Bootmanager im MBR und nicht GRUB. Meiner Meinung nach verhält sich der FreeBSD-Bootmanager am besten, wenn es um korrektes Verhalten bei der Auswahl von Betriebssystemen geht.
 
Zuletzt bearbeitet:
Bei mir (5.4-RELEASE) werden einige Module, wie nvidia.ko, vor dem loader geladen und einige, acpi.ko, hinterher. Man kann das bestimmt auch irgendwie steuern, fragt mich aber nicht wie.
 
Kurz nach dem BIOS POST oder dem jeweiligen Bootmanager erscheint beim FreeBSD Boot für 1 - 2 Sekunden eine Pipe (oben links) Wenn man jetzt eine Taste drückt (ESC beispielsweise) kommt man zum Bootprompt. Wenn nicht dann werden die Module geladen. Anschliessend kommt der Loader mit dem Menu oder dem Loader Prompt, wenn man will. hier wählt man Optionen für den Kernel aus.

also zuerst:

1) Boot Prompt; Autostart in 1-2 Sekunden
(1.5) Kernel wird vorgeladen (da bin ich mir nicht sicher)
2) Module werden vorgeladen. (Aber ned verwendet, noch ist kein Kernel dafür vorhanden)
3) Loader Menu; Autostart (default) 10 Sekunden
4) kernel wird exekutiert

Jedenfalls gibt es zwei Prompts. Bei irgendeinem der Beiden gibt es definitiv ein Unload.

So: Ganz einfach mal man page fragen:
zum loader: http://www.freebsd.org/cgi/man.cgi?...ath=FreeBSD+5.4-RELEASE+and+Ports&format=html
Und der Loader kennt den Befehl unload

zum bootprompt:
http://www.freebsd.org/cgi/man.cgi?...ath=FreeBSD+5.4-RELEASE+and+Ports&format=html
Der Bootprompt kennt den Befehl unload nicht. Aber das scheint eh egal zu sein, weil die Module ja zu dem Zeitpunkt nur geladen, aber nicht eingebunden oder exekutiert werden.
 
Code: 
kernel wird exekutiert
Falsche Zwillinge Jungs... Doch nicht etwa von "to execute"? :D

Die Module werden - wie du schon sagtest - nach dem Bootloader geladen, aber vor dem eigentlichen Loader, welcher das Menü/Prompt mit unload anbietet. Allerdings kann schon das reine Laden eines defekten Moduls zu ernsten Problemen führen, sodass man man das Prompt des Loader gar nicht mehr erreicht.

Aber eigentlich ist das doch eh alles egal, da das da oben zur Diskussion gestellte Problem schon längst gelöst wurde...
 
@ OOZE: Tja, Denglisch treibt manchmal nette Blüten. ;)
Manches "rechnet sich", "erinnern" wird neuerdings nicht mehr reflexiv gebraucht, gewisse Ereignisse finden "in 2005" statt, ...
Warum also sollten Kernel nicht exekutiert werden?
 
Exekutieren wird, zumindest in Österreich, synonym für ausführen verwendet, vor allem dann, wenn dieses ausführen unter Zwang passiert.

Ich habe allerdings auch überlegt exekutieren durch ausführen zu ersetzen. Jedoch wäre dadurch meine für mich normale Sprache beschnitten worden, und dafür sehe ich keinen Grund.

Aber: EOT, weil nicht zum Thema gehörend.

PS: Der Duden (www.duden.de) hat unter http://www.duden.de/deutsche_sprache/deutsche_sprache.html einen Link zum Thema Fremdwörter im Deutschen. Sicher lesenswert für alle, die Anglizismen als den Untergang der deutschen Kultur ansehen.
 
Zuletzt bearbeitet:
Ich liebe bsdforen.de

Oh mann! Bin ich froh, dass es dieses Forum gibt!!!
Ich hab grad ein reibungsloses Buildworld durchgezogen. Und dann bootet die Kiste nicht! Ich hab mir schon die schlimmsten Horroszenarien vorgestellt. Doch dann, flink das Forum gelesen.. unload, load, boot und alles geht wieder *freu* :D
 
Leute, Ihr seid klasse,

ich habe nun endlich die Zeit gefunden :-), das Auszuprobieren, was Ihr gesagt habt. Was soll ich sagen, es klappt *freu*.

Ich bin folgendermaßen vorgegangen:

Rechner an; bootet grub; wähle FreeBSD aus; mit space time rausgenommen; dann die Option boot-Prompt (ich glaube die 7) ausgewählt; eingegeben:

unload
load /boot/kernel/kernel
---> irgenwas passiert danach wieder ein boot-Prompt
boot

Danach unter /boot/loader.conf das NVidia-modul-bla auskommentiert; reboot gemacht.
Tataa: Ich poste gerade unter FreeBSD *entspanntIst*


...

Ich weiss nicht ob ich deshalb ein neuen Thread aufmachen soll?
Wie kann ich weiter vorgehen, um das Ding komplett zu reparieren? Ich meine, cvsup -g... make fetchindex...pkgdb -F usw. oder habe ich noch was zu bedenken?
Ich erkläre mal warum das bei mir so fragil ist: Ich habe nur einen Rechner, auf dem läuft alles. Ich habe da FreeBSD und Ubuntu drauf, ich kann also nicht, wie so viele andere hier im Forum, rumprobieren, da mein "Testrechner" gleichzeitig mit "Produktivsystem" ist. Bis es soweit ist, dass ich einen zweiten Rechner habe, mit dem ich arbeiten kann (inkl. Router usw.) muss ich das hier so durchziehen *seufz*, deshalb liegt der Fall bei mir etwas anders.
Das nur deshalb, damit Ihr versteht, warum mir manchmal so "Sachen" passieren.
Danke für Euer Verständnis

Amorphus
 
Ich habe nur einen Rechner, auf dem läuft alles. Ich habe da FreeBSD und Ubuntu drauf, ich kann also nicht, wie so viele andere hier im Forum, rumprobieren, da mein "Testrechner" gleichzeitig mit "Produktivsystem" ist. Bis es soweit ist, dass ich einen zweiten Rechner habe, mit dem ich arbeiten kann (inkl. Router usw.) muss ich das hier so durchziehen *seufz*, deshalb liegt der Fall bei mir etwas anders.
Zum Vergrößern anklicken....

Backup auf eine Firewire-Wechselfestplatte wäre schon mal ein Fortschritt:

http://wiki.bsdforen.de/index.php/FreeBSD_-_Backup
 
Hallo,

ich habe auch "nur" eine Maschine,
dafür aber Wechselfestplatten.

Das beruhigt die Nerven ungemein. :D
Wechselfestplattengehäuse gibt es schon so um die 15 Euro,
dann muß man die Leergehäuse natürlich noch befüllen. ;)


Gruß Fusselbär
 
Ich habe ein ähnliches Problem.
Zur Vorgeschichte: http://www.bsdforen.de/showthread.php?t=13814&page=3

Ich wollte 3d Beschleunigung zum Laufen bekommen (FreeBSD 6, xorg6.9). Hab dann den Port dri-devel aus dem Portstree installiert, hatte zu diesem Zeitpunkt aber schon den Port dri installiert.
Und leider ist es mir entgangen, vielleicht den dri Port zu deinstallieren, bevor ich neu boote.

Nun bootet er jedenfalls nicht mehr. Problem ist aber, dass ich auch keinen neuen Kernel booten kann.
Wenn ich am prompt "unload" und "boot /boot/kernel.GENERIC" eingebe, dann bootet er genauso mit Fehler und bleibt stehen wie bei kernel.old.

Meine Vermutung ist nun, dass er versucht dieses Modul, dass ich durch die Install. von dri-devel installiert habe, zu laden, dass das aber nicht gescheit geht. Warum auch immer (vermutlich weil zwei DRIs installiert sind!?).

Fehlermeldung (ich habs mal abgetippt, deswegen hab ich unwichtiges weggelassen)
Code: 
AMD Features = <hex-Adresse> ...
real memory = ...
avail memory = ...
mptable_probe: MP Config Table bas bad signature:
ACPI APIC Table <Nvidia AWRDACPI>
ioapic0 <version ...> ..
dazuko: loaded
Fatal trap 12: page fault while in kernel mode
fault virtual adress = 0x4c
fault code = supervisor read, page not present
instruction pointer = <hex-adresse>
stack pointer = <hex-adresse>
frame pointer = <hex-adresse>
code segment = base 0x0 init ...
processorflags = interrupt enabled resume (oder so) IOPC = 0
comet (oder so; kann ich leider nicht mehr richtig lesen) process = 0 (swapper)
trap number = 12
panic: page fault
Uptime: 1s

Das wichtigste sollte da sein.
Die Hex-Adressen der Pointer denke ich sind nicht wirklich wichtig oder? :)
Zwei Sachen konnte ich hier aufm Zettel gerade nicht mehr genau lesen.


Kann damit jemand was anfangen?
Bzw. wie ist das weitere Vorgehen?
Meine Idee (das ist aber alles was ich habe):
mit ner FreesBie booten und versuchen den Kernel so zu ändern, dass er wieder bootet oder kann ich auch von dort aus den dri-devel Port deinstallieren?

Wie wäre da das vorgehen von der BootCD?
booten
Partitionen mounten!?

und!?

Wie kann ich die Partitionen von der CD aus einbinden?

Danke schon mal für die Hilfe!
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben