Freeze beim Boot nach MTRR

aspiaspi

New Member
Hallo zusammen,

ich bin neu hier im OpenBSD Forum, und habe ein Problem beim booten meines OpenBSD 4.2. Selbstverständlich habe ich dieses und andere Foren durchsucht, bevor ich hier einen neuen Thread auf mache :-) Leider haben die ganzen Tipps dort nichts gebracht :-(

Zunächst mal das Problem:

Das System bootet bis zur Zeile:
Code:
mtrr: Pentium Pro MTRR support
Danach passiert nichts mehr.

Das System:
- AMD Athlon K7 Prozessor
- 256 MB SDRAM
- 2 Maxtor Platten (20G: wd0: root disk / 120GB: wd1: nur für /home)
- CD Brenner (Samsung: SAMSUNG SC-148P PS02)
- DVD Player (TEAC: DV-516E 2.01)
- Award Modular BIOS v6
- Floppy 1.44MB (No Name)

Die Historie:
Die OpenBSD Kiste hab ich vor 3 Wochen installiert. Alles nach FAQ 4 von openbsd.org
und es lief einwandfrei. Dann habe ich noch Apache mit PHP5 neu kompiliert und Bind an den Start gebracht. Lief alles einwandfrei, auch mit mehreren reboots. Die letzte bewusste Veränderung war ein eintrag in der rc.shutdown:
Code:
powerdown=YES
Damit die Kiste beim
Code:
halt
auch wirklich aus geht.
Ich bin mir nicht mehr sicher ob ich sie danach noch gebootet habe.
Letztes Wochenende dann, wollte ich sie starten und blieb an oben genannter Stelle hängen. So weit...

Vermutungen:
1) Ein Hardware Problem, nur welches?
2) Wirklich was mit MTRR Support, nur warum von jetzt auf gleich?
3) Die Option die nach dem MTRR Support kommt hängt (dkcsum), warum auf einmal?

Ausprobiert habe ich folgendes:
1) bsd.rd Kernel starten, geht einwandfrei, auch die Platten ließen sich manuell mounten
2) bsd.mp starten, hängt wie bsd. (Wobei ich gestehen muss, dass nicht weiß ob die beiden nicht das gleiche sind. Hab zu wenig Erfahrung mit OpenBSD)
3) NVRAM reset (Batterie raus) und das BIOS neu konfiguriert. Wieder sauber, gleicher boot Fehler.
4) Alle Platten vom IDE Bus genommen (Nur die wd0 als root disk am Primary Master gelassen), auch die Optischen Laufwerke vom Secondary Controller gerissen.
5) im UKC Kombinationen von ACPI und APM deaktiviert/aktiviert.
6) im UKC versucht MTRR zu deaktivieren, ist aber ein Pseudo-Device wo das nicht geht
7) Neuinstallation versucht (merhfach mit allen branches: -release, -stable, -current)
-> Weil nicht mal release booten will - es aber schonmal gemacht hatte vor dem Fehler -, gehe ich von einem Problem meiner Hardware aus, das vielleicht "spontan" aufgetreten ist.
8) Mit einer aktuellen Knoppix CD memtest laufen lassen. Nach 10 Durchläufen keine Fehler.

Ein dmesg würde ich gerne anhängen, bekomme es aber nicht von dem Rechner weg ... bekomme mit dem bsd.rd Kernel weder ssh zum laufen, noch bekomme ich es auf irgendein anderes Medium. Wer da Hilfe hat oder sagt es lohnt sich den Mist mal komplett abzutippen, mache ich das :-)

So nun, das ist alles was ich versucht habe und weiß nicht mehr weiter. Ich will eigentlich nicht aufgeben, aber wenn ich die Schüssel nicht zum laufen bekommen, versuche ich wieder Gentoo, mit dem ich schon sehr lange gespielt habe.

Wenn jemand weiß wie ich das Problem lösen kann, Vorschläge hat was ich noch ausprobieren kann, weitere nützliche Tests kennt die helfen, oder Tipps hat wo ich weitere Hinweise bekommen kann: Bitte sagt bescheid :-)

So far ... danke für die Geduld das alles zu lesen!
 
Weitere Hinweise

Hallo,

also habe gesehen das einige meinen Beitrag schon gelesen haben -
was mich freut.
Ich habe derweil ein bisschen weiter in Richtung Plattenfehler getestet.

Wieder mit der Knoppix CD habe ich smartctl -t long ausgeführt.
Für beide Platten hda und hdb. (hda entspricht meiner root disk wd0
und hdb der wd1 für mein /home Verzeichnis).
Das Ergebnis hat nichts aufregendes gebracht, ausser ein paar
Einträge, die durch das abschalten der Platten während des Boot-
Vorgangs, hervorgerufen wurden. (Ja, das solle man eigentlich nicht
machen :-)
Wer sich über den Eintrag "Security Freeze Lock" wundert ... das habe ich schon
abgeklärt und hat mit meinem MTRR Problem nichts zu tun.
Wen das trotzdem interessiert: Es ist ein Befehl aus dem ATA Security Feature Set,
das leider wegen älteren BIOSen (und wer bastelt nicht gerne an alten Kisten rum) zum
Sicherheisproblem werden kann.
Ich mache bei Gelgenheit man einen neuen Thread zu dem Thema auf, falls es ihn nicht
schon gibt. Vorab der Link zu einem interessanten Artikel:
http://www.heise.de/ct/05/08/172/

Die Ergebnisse habe ich für beide Platten angehängt:
1) smartctlhda (für wd0)
2) smartctlhdb (für wd1)

Vielleicht hilft euch das weiter, wenn ihr Vermutungen zu meinem Problem habt :-)

Vielen Dank an die, die es lesen und Kniefall vor denen die ne Idee haben :-)

Aspi
 

Anhänge

  • smartctlhda.txt
    9,7 KB · Aufrufe: 283
  • smartctlhdb.txt
    10,5 KB · Aufrufe: 268
Zuletzt bearbeitet:
Zurück
Oben