Am 07.12.2009 um 20:59 schrieb Bernd Walter:
> On Mon, Dec 07, 2009 at 08:29:17PM +0100, Christoph Sold wrote:
>>
>> Am 07.12.2009 um 13:33 schrieb Bernd Walter:
>>> "Bad system call" legt die Vermutung nahe, dass du den alten Kernel
>>> laufen hast, aber schon neue binaries benutzen willst.
>>> Das kann gut gehen, muss aber nicht, weil neuere Binaries auch
>>> neue Features erwarten können, was bei einem Schritt von 7 zu 8
>>> durchaus zu erwarten ist.
>>
>> Stimmt. Meist geht's ja gut, diesmal nicht. Ideen?
>
> Du musst den neuen Kernel booten, sonst kommst du nicht weiter.
Der Meinung war ich auch.
> Oder irgendwie alte Binaries aufspielen - falls dafür noch genug Befehle
> laufen - dann kannst du den Teil-Update evtl rückgängig machen.
Das hatte ich nicht vor -- im Notfall neues System und Daten vom Backup [1].
> Es kann gutgehen, dass der mit dem jetzigen System multiuser bootet, vor
> allem weil du schon die neuen Binaries drauf hast.
> Aber ein Risiko ist das denoch und dann brauchst du Konsolenzugriff.
Das kostet dann halt wieder ein paar Extra-Euronen fürs anschließen -- im Gegensatz zu der Erfahrung, die man beim reparieren sammelt, die kostet nur (Frei-) Zeit.
> Wirf vor dem reboot auch noch mal einen Blick auf die device.hints,
> da hat sich von 7 auf 8 wichtiges geändert.
Guter Hinweis.
Weggefallen sind:
hint.adv.0.at="isa"
hint.adv.0.disabled="1"
hint.bt.0.at="isa"
hint.bt.0.disabled="1"
hint.aha.0.at="isa"
hint.aha.0.disabled="1"
hint.aic.0.at="isa"
hint.aic.0.disabled="1"
hint.vga.0.at="isa"
hint.vt.0.at="isa"
hint.vt.0.disabled="1"
hint.sio.0.at="isa"
hint.sio.0.port="0x3F8"
hint.sio.0.flags="0x10"
hint.sio.0.irq="4"
hint.sio.1.at="isa"
hint.sio.1.port="0x2F8"
hint.sio.1.irq="3"
hint.sio.2.at="isa"
hint.sio.2.disabled="1"
hint.sio.2.port="0x3E8"
hint.sio.2.irq="5"
hint.sio.3.at="isa"
hint.sio.3.disabled="1"
hint.sio.3.port="0x2E8"
hint.sio.3.irq="9"
Neu sind:
hint.uart.0.at="isa"
hint.uart.0.port="0x3F8"
hint.uart.0.flags="0x10"
hint.uart.0.irq="4"
hint.uart.1.at="isa"
hint.uart.1.port="0x2F8"
hint.uart.1.irq="3"
hint.atrtc.0.at="isa"
hint.atrtc.0.port="0x70"
hint.atrtc.0.irq="8"
Ja, ich verwende einen angepassten Kernel. SMP ist für einen alten Athlon Overkill, und 256 MB RAM sind nicht üppig: jedes Byte zählt ;)
Ich vermute, dass sio() duch uart ersetzt wurde. atrtc() scheint neu zu sein.
Die hint.*.disabled-zeilen verweisen auf nicht konfigurierte Device-Treiber, richtig?
Also ersetze ich hint.sio.[0-3].* durch hint.uart.[0,1].*, und füge atrtc.* hinzu. Die *.disabled="1"-zeilen und deren Treiber kann ich vorerst ignorieren.
Treiber ohne device.hints-Eintrag werfen höchstens eine Fehlermeldung, richtig?
Danke für die Tips
-Christoph
[1] "Nobody needs a backup. All you need in case of emergency is a working restore procedure."
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Mon 07 Dec 2009 - 21:55:07 CET