Seit Upgrade auf 10.1 und 10.2: loader.conf wird ignoriert

C

cabriofahrer

Well-Known Member
Seit einem Upgrade von 9.3 auf 10.1 bzw. 10.2 auf zwei verschiedenen Systemen wird anscheinend loader.conf einfach ignoriert. Auf dem System mt 10.2 hat dies zur Folge, dass der Nvidia-Treiber nicht automatisch beim Booten geladen wird und ich diesen immer manuell per kldload laden muss. Auch andere Einträge wie z.B. ein autoboot delay von drei Sekunden sind wirkungslos, deswegen die Vermutung, dass loader.conf einfach ignoriert wird.
 
Ohne Genaueres zu wissen, sind berüchtigte Ursachen für solche Fehler Syntax-Errors in der Datei und dazu zähle ich auch ungültig gewordene Einträge.
Wie man das im Einzelnen am Schlauesten prüfen kann, weiß ich nicht. Ich würde es manuell Punkt für Punkt durchgehen und sehen, was der manuelle Aufruf ergibt, bzw mal mit der /boot/defaults/loader.conf vergleichen.
 
auge schrieb:
was steht denn bei dir in '/boot/loader.rc' ?
Zum Vergrößern anklicken....

Code: 
$ more /boot/loader.rc
\ Loader.rc
\ $FreeBSD: releng/10.2/sys/boot/i386/loader/loader.rc 262704 2014-03-03 07:31:55Z dteske $
\
\ Includes additional commands
include /boot/loader.4th
try-include /boot/loader.rc.local

\ Reads and processes loader.conf variables
initialize

\ Tests for password -- executes autoboot first if a password was defined
check-password

\ Load in the boot menu
include /boot/beastie.4th

\ Start the boot menu
beastie-start
$

Im Übrigen habe ich zum Testen eine neue loader.conf erstellt mit dem einzigen Eintrag nvidia_load="YES", aber das Nvidia-Modul wird trotzdem nicht automatisch geladen.
 
Code: 
$ grep loader.conf /boot/loader.4th
\       Initializes support.4th global variables, sets loader_conf_files,
  s" /boot/defaults/loader.conf" initialize
  s" /boot/defaults/loader.conf" initialize
  include_conf_files \ Will recurse on new loader_conf_files definitions
$ grep loader.conf /boot/defaults/loader.conf
# This is loader.conf - a file full of useful variables that you can
# loader_conf_files instead and you will be able to update these
# $FreeBSD: releng/10.2/sys/boot/forth/loader.conf 283971 2015-06-03 22:24:57Z dteske $
exec=".( Loading /boot/defaults/loader.conf ) cr"
loader_conf_files="/boot/device.hints /boot/loader.conf /boot/loader.conf.local"
$
 
Hmm, ich seh da jetzt keinen Unterschied zu einem System bei uns hier.
Heißt deine Datei wirklich /boot/loader.conf?
Versuche doch mal, ein tuneable zu setzen:

kern.geom.part.check_integrity=0

Und schau dir nach einem Reboot dessen Wert an.

Rob
 
OK, Problem gelöst, es lag an einer fehlerhaften device.hints: Beim Upgrade wurde ich dummerweise aufgefordert, mit vi die device.hints zu editieren. Da ich vi nicht beherrsche, hatte ich es nur irgendwie geschafft, da rauszukommen und den Prozess zu Ende zu bringen. Letztendlich habe ich mich daran erinnert und mal die device.hints überprüft, die folgendermaßen aussah und die ich hier zu Euer Info poste. Vielen Dank für Eure Hilfe!

Code: 
# $FreeBSD: releng/10.2/sys/amd64/conf/GENERIC.hints 276986 2015-01-11 17:10:07Z nwhitehorn $
hint.fdc.0.at="isa"
hint.fdc.0.port="0x3F0"
hint.fdc.0.irq="6"
hint.fdc.0.drq="2"
hint.fd.0.at="fdc0"
hint.fd.0.drive="0"
hint.fd.1.at="fdc0"
hint.fd.1.drive="1"
hint.atkbdc.0.at="isa"
hint.atkbdc.0.port="0x060"
hint.atkbd.0.at="atkbdc"
hint.atkbd.0.irq="1"
hint.psm.0.at="atkbdc"
hint.psm.0.irq="12"
hint.sc.0.at="isa"
hint.sc.0.flags="0x100"
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.ppc.0.at="isa"
hint.ppc.0.irq="7"
hint.atrtc.0.at="isa"
hint.atrtc.0.port="0x70"
hint.atrtc.0.irq="8"
hint.attimer.0.at="isa"
hint.attimer.0.port="0x40"
hint.attimer.0.irq="0"
hint.wbwd.0.at="isa"
<<<<<<< current version
hint.hdac.0.cad0.nid22.config="as=1 seq=2"
hint.hdac.0.cad0.nid37.config="as=1 seq=4"
=======
hint.acpi_throttle.0.disabled="1"
hint.p4tcc.0.disabled="1"
>>>>>>> 10.2-RELEASE
 
Das ist ja behindert, dass sich Fehler in dieser Datei auf das Laden der loader.conf auswirken.
In meinen Augen ein Bug.

Rob
 
Ich glaube sogar, dass ich kürzlich einen vergleichbaren Fehler hatte und ein Syntax-Error in der device.hints irgendwas beim Booten blockierte. Ob das mit der loader.conf zusammen hing, weiß ich nicht mehr. mein Fehler war mir sofort klar und schnell behoben, so dass ich mir nicht weiter darüber Gedanken machte.

Was ich anfügen wollte: die Änderungen mit vi werden dann verlangt, wenn vi dein Standard-Editor ist. Es ist natürlich nicht sinnvoll, einen Editor als Standard zu benutzen, den man nicht bedienen kann. Deshalb habe ich da auch auf ee umgestellt, was wesentlich einfacher für derartige Aufgaben und ungeübte Anwender ist. Das solltest du auch erwägen, denn freebsd-update verlangt häufiger manuelle Eingriffe.
Weil ich trotz ee da immer noch gelegentlich Fehler mache, habe ich mir auch schon eine komplette Liste mit allen manuell bearbeiteten Dateien notiert und dann unmittelbar nach meinen Änderungen diese Dateien nochmals überprüft. Mein Problem ist dabei, dass mir das grundlegende Verständnis für das mergen fehlt, das habe ich nie richtig erlernt und verstehe die Ausgabe der diffs nur sinngemäß, aber nicht wirklich. Deshalb ist es mir lieber, die Datei nach den Änderungen nochmals anzusehen und auf Fehler zu achten. Das kann man ja auf zwei unterschiedlichen Konsolen durchführen und hin und her schalten, also kein allzu großer Aufwand.
 
Seh ich das richtig, dass das Update einem ein Diff der Dateien (alt und neu) mit dem Namen der neuen Datei in den Editor kippt, und wenn man dann einfach speichert, schreibt man quasi in die Datei das Diff rein, was dann natürlich zu Syntaxfehlern führt?

Syntaxfehler haben natürlich zu Fehlern zu führen, was denn sonst? Einfach ignorieren? Da würde ich eher behindert nennen, dass der Fehler entweder nicht angezeigt wird oder von dem tollen Vollbild-Menü weggespült wird, was ich sowieso für die Krätze schlechthin halte. Dieses DOS-hafte Malen von Vollbild-Oberflächen (s. auch Ports-Config) hat in einem UNIX IMHO nichts zu suchen.

/rant

Edit: Die device.hints ist ja nichts weiter als eine von mehreren Config-Dateien, s. /boot/defaults/loader.conf:

Code: 
loader_conf_files="/boot/device.hints /boot/loader.conf /boot/loader.conf.local"
 
Schon sollte es zu einer Fehlermeldung führen, wie du sagst, aber nicht die Bearbeitung der weiteren Dateien in loader_conf_files terminieren. Offenbar ist das genau der Fall.

Rob
 
@TCM
nicht ganz. Das freebsd-update Script geht schon etwas raffinierter vor, aber genau damit habe ich dann auch gelegentlich Probleme.
Da wird mergemaster(8) benutzt ohne zuvor /etc komplett zu sichern. Mergemaster habe ich mir nicht angesehen, aber es kann diese diffs automatisch mergen und so die neuen Dateien erzeugen. freebsd-update erklärt einem das während des Laufs. Nur manchmal, bei einigen Dateien, da geht das aus irgendeinem Grund nicht und da gibt es zwei Möglichkeiten: man bekommt eine Vorgabe und kann sagen, dass die OK ist oder man muss manuell Hand anlegen, was aber meist bedeutet, dass man es getrost der Automatik vorwerfen kann, weil die geratenen Änderungen in der Regel gut sind. Man kann aber auch die Änderungen manuell vornehmen und die Datei geändert abspeichern. Dabei übersieht man leicht irgendwelchen Ballast, der nicht in die Datei gehört oder man ändert etwas aus Versehen falsch, so dass es nun gar nicht gemerged wird. Was genau meine Fehler dabei immer so waren, kann ich nicht sagen, aber ich musste schon einige Male nachträgliche Korrekturen vornehmen. Immer nur bei manuell geänderten Dateien und vermutlich eben, weil ich diesen Prozess nie richtig durchblickt habe und mir auch nicht wirklich Mühe damit machte. Die Korrektur ist trivial und schnell und durchaus nicht bei jedem Lauf von freebsd-update nötig.
 
pit234a schrieb:
Was ich anfügen wollte: die Änderungen mit vi werden dann verlangt, wenn vi dein Standard-Editor ist. Es ist natürlich nicht sinnvoll, einen Editor als Standard zu benutzen, den man nicht bedienen kann. Deshalb habe ich da auch auf ee umgestellt, was wesentlich einfacher für derartige Aufgaben und ungeübte Anwender ist. Das solltest du auch erwägen, denn freebsd-update verlangt häufiger manuelle Eingriffe.
Zum Vergrößern anklicken....

Nichts lieber als das! Und wie lege ich ee als Standardeditor fest?
 
TCM schrieb:
Seh ich das richtig, dass das Update einem ein Diff der Dateien (alt und neu) mit dem Namen der neuen Datei in den Editor kippt, und wenn man dann einfach speichert, schreibt man quasi in die Datei das Diff rein, was dann natürlich zu Syntaxfehlern führt?
Zum Vergrößern anklicken....

Nicht ganz, mergemaster führt (vermutlich) einen 3-way merge aus, indem es eine Basisversion (vermutlich von der originalen Installation) mit der aktuellen Version und der neuen Version vergleicht. Versionsverwaltungssysteme mergen dann neue Änderungen automatisch, sofern es keine Konflikte mit der aktuellen Version gibt, mergemaster fragt nach.
Zumindest ist die
<<<
aktuelle Änderungen
===
neue Änderungen
>>>
Syntax typisch dafür.
Bei normalen diffs ohne Konflikten wird einfach nur gefragt, ob man die neue oder die alte Version haben möchte (und kann optional noch selbst editieren).

Übrigens:
mergemaster(8) schrieb:
It is HIGHLY recommended that you back up your /etc directory before beginning this process.
Zum Vergrößern anklicken....
Und im Handbuch steht das auch.

Aber eine Syntaxüberprüfung wäre natürlich hilfreich (vi lernen aber auch! ;))
 
Mergemaster ist ein dummes Tool. Ohne weitere Optionen aufgerufen, macht es einen normalen Diff zwischen installierter und neuer Datei. Wenn er nicht leer ist, legt es dem Nutzer die Datei vor. Gibt man -U mit, wird mittel mtree getestet, ob der Nutzer die Datei verändert hat. Wenn nicht, wird die neue Version stumpf kopiert. -F prüft, ob sich nur der $FreeBSD$-Tag geändert hat. Wenn ja, wird die Datei ebenfalls stumpf kopiert. Weil die Verfahren dämlich und fehleranfällig ist, wurde mergemaster mit FreeBSD 10.0 durch etcupdate ersetzt. Das führt einen echten 3-Way-Merge (alt, installiert, neu) durch, merged automatisch und legt dem Nutzer nur echte Mergekonflikte vor. Der Fall in diesem Thread wäre beispielsweise von etcupdate vollautomatisch behandelt worden und es hätte nie ein Problem geben. Eigentlich hätte man das alte mergemaster gleich rauswerfen sollen, aber...
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben