CURRENT-Kernel kaputt?

Krull

Well-Known Member
Da ich in letzter Zeit nur noch Probleme hatte beim Imstallieren oder Aktualisieren von Ports und mir pkg regelmäßig vorgeworfen hat, ich hätte die falsche OS-Version, wollte ich nun CURRENT auf einen aktuellen Stand bringen.
In anlehnung an diesen Beitrag https://www.bsdforen.de/threads/update-freebsd-12-current-läuft-nicht-rund.34133/
habe ich vorher /usr/{src,obj} komplett geleert und ein neues Checkout gemacht. Bei World hat das Upgrade anscheinend auch funktioniert, aber der neue Kernel startet nicht. Ich lande immer nur in der Debugkonsole.
Das ist also der jetzige Stand:
Code:
uname -KU                                                                                                                      
1200054 1200059
Beim Bauen selbst sehe ich keinerlei Fehlermeldungen. Gemacht habe ich Folgendes:
Code:
make buildworld
make kernel
make installworld
reboot
Ist bei CURRENT im Moment irgendwas grundsätzlich im Eimer? Läuft bei euch alles so wie es soll?
 
Mein 12-CURRENT von vor nen paar Tagen läuft brav aufm T470s.
Das macht mich tatsächlich gerade ein bisschen neidisch. Mann, woran kann das denn liegen, dass der Kram nicht läuft? Der Securelevel steht übrigens die ganze Zeit auf -1. In der make.conf habe ich zurzeit nur das drin:
Code:
KERNCONF=GENERIC
WITH_DEBUG=NO
 
Hast du mal die Panic-Meldung? Die müsste über den Debugger-Prompt stehen.
 
Hallo,

mal eine Frage am Rande - viel helfen kann ich zwar nicht:
Code:
make buildworld
make kernel
make installworld
reboot

Fehlt da vor dem reboot nicht noch was?
Code:
yes | make delete-old delete-old-libs
etcupdate
etcupdate resolve

Viele Grüße,
Holger
 
Das ist aber nur das Mergen der Konfiguration. Wenn es fehlt löst es (hoffentlich) keine Panic aus. :)
 
Hast du mal die Panic-Meldung? Die müsste über den Debugger-Prompt stehen.
Nee, die habe ich leider nicht. Den kaputten Kernel habe ich vor lauter Frust weggeworfen ^^ Und geloggt wurden die Fehler meines Wissens nirgends. Geht ja glaube ich auch nicht so früh beim Start. Ich werde die nächsten Tage wahrscheinlich einen neuen Versuch wagen. Dann notiere ich mir brav alles.

Fehlt da vor dem reboot nicht noch was?
Eigentlich nicht, oder? Nach dem Reboot mache ich normalerweise noch ein mergemaster. Vorausgesetzt der Rechner kommt überhaupt bis dahin ^^
etcupdate habe ich noch nie benutzt. Ist das besser?
 
etcupdate habe ich noch nie benutzt. Ist das besser?

Die Anleitung, System und Kernel ordentlich aus den Sourcen zu bauen habe ich von @Yamagi bzw. @KobRheTilla - mir ist nur aufgefallen, dass Dein Vorgehen von dem abweicht, wie ich es gelernt habe und ich dachte, es wurde etwas übersehen. Und in dieser Sache kann ich Dir auch nur dahin gehend helfen, auf solche Abweichungen aufmerksam zu machen.

Ob etcupdate besser ist, kann Dir sicher einer der Experten hier beantworten. :)
 
Also deine Konfigurationen musst du schon mal mergen. Wenn sich bei kleineren Updates nur der Header der Konfigurationsdateien verändert ist das noch unkritisch, aber hin und wieder sind da schon paar Sachen drin die dir das System verhageln können. Aber wie Yamagi auch sagte, die sollten nicht zu einer Panic führen.
Mit mergemaster kannst du händisch alle Konfigurationsdateien mergen. Das funktioniert ist erprobt, stumpfsinnig und langweilig. Neigt daher zu Leichtsinnsfehlern, weil man irgendwann nicht mehr genau hinsieht.
etcupdate ist da etwas moderner. Du musst es am Anfang einmal durchlaufen lassen, damit er einen Stand hat. Bei jedem späteren Update erkennt er dann was deine Änderungen waren und was automatisch über den Systemupdate kam. Der Prozess wird damit deutlich überschaubarer und man muss sich iA nur mit echten Änderungen befassen und sich z.B. nicht 100 mal einen geänderten Header ansehen.
 
So, hab einen neuen Versuch unternommen und es ist wie gewohnt gescheitert. Unmittelbar vorher habe ich die Quellen aktualisiert mit 'svnlite up /usr/src... Naja, der Kernel startet wieder nicht. Die Fehlermeldung wollte ich nicht von Bildschirm abmalen, deswegen habe ich ein Foto geschossen:
https://transfer.sh/aBSFB/dsWegfR5r.jpg
World funktioniert nun zur Abwechslung übrigens auch nicht mehr. Bei 'installworld' heißt es dann:
Code:
install: /usr/tests/libexec/tftpd/Kyuafile: No such file or directory
*** Error code 71

Stop.
make[6]: stopped in /usr/src/libexec/tftpd/tests
*** Error code 1

Stop.
make[5]: stopped in /usr/src/libexec/tftpd
*** Error code 1

Stop.
make[4]: stopped in /usr/src/libexec
*** Error code 1

Stop.
make[3]: stopped in /usr/src
*** Error code 1

Stop.
make[2]: stopped in /usr/src
*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error code 1

Stop.
[make](make): stopped in /usr/src
 
Das sind ja zwei Probleme. Bei der Panic ist höchstwahrscheinlich das Problem, dass du die VirtualBox-Kernelmodule lädst, sie aber nicht gegen den neuen Kernel gebaut hast. Unter FreeBSD haben Releases und die -STABLE Zweige ja eine stabile Kernel-API. Sprich ein einmal gebautes Kernelmodul sollte auch mit späteren Versionen des jeweiliges Zweigs direkt funktionieren, ein gegen FreeBSD 11.1 gebautes Modul wird also auch mit FreeBSD 11.3 noch laufen. Außerdem ist die API da versioniert, wenn du z.B. ein unter FreeBSD 9.2 gebautes Modul auf einem FreeBSD 11.1 laden willst, sagt er etwas wie "Version missmatch, module not loaded". -CURRENT hat aber keine stabile API und es hat auch keine Versionen. Daher kann der Kernel nicht erkennen, ob ein Modul passt oder nicht. Er lädt es stumpf und wenn es nicht passt fliegt er auf die Fresse...

Du kannst aber in der '/etc/make.conf' Ports angeben, die bei Neubauen des Kernels automagisch mit aktualisiert werden:
Code:
PORTS_MODULES= x11/nvidia-driver sysutils/lsof

Das er hinterher beim nächsten Build abbrach war ein Fehler in den Sourcen. Der ist gestern Abend um 19:07 Uhr korrigiert worden: https://svnweb.freebsd.org/base?view=revision&revision=330742 Das sollte nun also wieder gehen. Sowas kommt immer mal wieder vor. Da ist es das Beste einige Stunden zu warten und es dann noch mal zu probieren.
 
Dass CURRENT die Module einfach blind frisst, was mir noch nicht klar. Danke. Dann werde ich beim nächsten Mal den VBox-Treiber aus der loader.conf rausnehmen und schauen, ob's dann klappt.
 
Ich habe CURRENT jetzt auf 1200060 hochgezogen. Der Kernel startet auch, mit deaktivierten VBox-Modulen, dafür bekomme ich zur Abwechslung diese Fehler angezeigt:
Code:
Mar 18 15:02:22 freebsd console-kit-daemon[70742]: WARNING: Error waiting for native console 2 activation: Inappropriate ioctl for device
Mar 18 15:02:22 freebsd console-kit-daemon[70742]: WARNING: Error waiting for native console 9 activation: Inappropriate ioctl for device
Mar 18 15:02:24 freebsd console-kit-daemon[70742]: WARNING: Error waiting for native console 1 activation: Inappropriate ioctl for device
Mar 18 15:02:24 freebsd console-kit-daemon[70742]: WARNING: Error waiting for native console 9 activation: Inappropriate ioctl for device
Mar 18 15:02:24 freebsd console-kit-daemon[70742]: WARNING: Error waiting for native console 2 activation: Inappropriate ioctl for device
Mar 18 15:02:24 freebsd console-kit-daemon[70742]: WARNING: Error waiting for native console 8 activation: Inappropriate ioctl for device
Mar 18 15:02:38 freebsd kernel: [127] ACPI Error: No pointer back to namespace node in package 0xfffff80003bd9780 (20180313/dsargs-472)
Mar 18 15:02:38 freebsd kernel: [127] ACPI Error: Method parse/execution failed \_SB.AC.ADJP, AE_AML_INTERNAL (20180313/psparse-677)
Mar 18 15:02:38 freebsd kernel: [127] ACPI Error: Method parse/execution failed \_SB.AC._PSR, AE_AML_INTERNAL (20180313/psparse-677)
Außerdem startet X nicht mehr. Ist das wieder so ein API-Ding? Falls ja, kann man irgendwo vorab sehen/lesen, was durch den neuen Kernel erstmal kaputt sein wird?
 
Jetzt bin ich bei Rev. 332475 angekommen. Damit scheinen sich die Probleme offenbar erledigt zu haben. Der Kernel startet wieder normal.
 
Zurück
Oben