beastie menü boot optionen: doku?

pit234a

pit234a

Well-Known Member
Ich finde mal wieder nicht, was andere vermutlich einfach wissen.
Die Beschreibung, was eigentlich die Boot-Optionen im Beastie menü bedeuten und wo die eingestellt sind (evtl verändert werden können).

Was es bedeutet, normal oder im Single-User Modus zu booten, ist vielleicht noch intuitiv erfassbar, aber was ist der sichere Modus?
Ich habe den auch noch nie gebraucht, habe nun aber einen Bekannten, der mir erklärte, sein BSD bootet nur noch in diesem Modus regelrecht, ansonsten hängt es immer.
Deshalb wollte ich mal kurz nachlesen, aber Ebbe....
 
Eine Moeglichkeit waere es direkt in /boot/beastie.4th nachzusehen. Das mag jetzt vielleicht nicht gerade das ein, was man sich im Allgemeinen unter 'Doku' vorstellt, aber man kann erkennen, was dort mit welcher Option wie gesetzt wird.
Ist meinerseits auch nur ein Schuss aus der Huefte, aber vielleicht wirst du dort ja fuendig.
 
/boot/beastie.4th

Code: 
: beastie-start
        s" beastie_disable" getenv
        dup -1 <> if
                s" YES" compare-insensitive 0= if
                        exit
                then
        else
                drop
        then
        beastie-menu
        s" autoboot_delay" getenv
        dup -1 = if
                drop
                10
        else
                0 0 2swap >number drop drop drop
        then
        begin
                dup tkey
                0 25 at-xy
                dup 32 = if nip 0 swap then
                dup -1 = if 0 boot then
                dup 13 = if 0 boot then
                dup bootkey @ = if 0 boot then
                dup bootacpikey @ = if
                        acpienabled? if
                                s" acpi_load" unsetenv
                                s" 1" s" hint.acpi.0.disabled" setenv
                                s" 1" s" loader.acpi_disabled_by_user" setenv
                        else
                                s" YES" s" acpi_load" setenv
                                s" 0" s" hint.acpi.0.disabled" setenv
                        then
                        0 boot
                then
                dup bootsafekey @ = if
                        s" arch-i386" environment? if
                                drop
                                s" acpi_load" unsetenv
                                s" 1" s" hint.acpi.0.disabled" setenv
                                s" 1" s" loader.acpi_disabled_by_user" setenv
                                s" 1" s" hint.apic.0.disabled" setenv
                        then
                        s" 0" s" hw.ata.ata_dma" setenv
                        s" 0" s" hw.ata.atapi_dma" setenv
                        s" 0" s" hw.ata.wc" setenv
                        s" 0" s" hw.eisa_slots" setenv
                        s" 1" s" hint.kbdmux.0.disabled" setenv
                        0 boot
                then
                dup bootverbosekey @ = if
                        s" YES" s" boot_verbose" setenv
                        0 boot
                then
                dup bootsinglekey @ = if
                        s" YES" s" boot_single" setenv
                        0 boot
                then
                dup escapekey @ = if
                        2drop
                        s" NO" s" autoboot_delay" setenv
                        exit
                then
                rebootkey @ = if 0 reboot then
        again
;

previous
und es wäre gelogen, wenn ich behaupte, damit sei mir alles klar.
Bevor ich wusste, daß es eine entsprechende Option in /boot/loader.conf möglich macht, hatte ich hier meine Delay-Zeit und das gewünschte Bild gesetzt, also, ich hatte da schon mal rein gesehen.

die nun für mich besonders interessante Option mit dem sicheren Modus ist wohl dies:
Code: 
                dup bootsafekey @ = if
                        s" arch-i386" environment? if
                                drop
                                s" acpi_load" unsetenv
                                s" 1" s" hint.acpi.0.disabled" setenv
                                s" 1" s" loader.acpi_disabled_by_user" setenv
                                s" 1" s" hint.apic.0.disabled" setenv
                        then
                        s" 0" s" hw.ata.ata_dma" setenv
                        s" 0" s" hw.ata.atapi_dma" setenv
                        s" 0" s" hw.ata.wc" setenv
                        s" 0" s" hw.eisa_slots" setenv
                        s" 1" s" hint.kbdmux.0.disabled" setenv
                        0 boot
und wenn ich das verstehe, dann macht der da einige Optionen zu ata und atapi DMA und zu ata.wc, was mir noch nichts sagt und auch zu eisa-slots. Bei diesen Angaben steht jeweils eine "0", weshalb ich denke, daß die ausgeschaltet werden.
Interessant ist dann der nächste Eintrag bei mir: der Bekannte bekam das Problem, seit er eine neue Maus verwendet hat (leider ist die Zuordnung nicht ganz so eindeutig, wie ich das nun schreibe, aber es scheint mir doch ein "hint") und da wird etwas disabled, also etwas nicht eingeschaltet, was normalerweise eingeschaltet ist und das etwas mit kbdmux zu tun hat und da steckt kbd und mux drin.

Ich denke, das hört sich für mich schon mal gar nicht soo schlecht an und für die anderen Optionen stehen hier in ähnlicher Weise ja auch die jeweiligen Parameter geschrieben. Das hilft jedenfalls weiter.

Ich hatte mir vorgestellt, daß über init diverse rc-Stadien aufgerufen werden und darüber dann die Optionen bestimmt sind. Hier werden offenbar "nur" sysctl-Variablen gesetzt.

Mal sehen, zunächst jedenfalls Dank, das hilft schon was...
 
Code: 
pit@syo ~:-> sysctl -d hw.ata.ata_dma
hw.ata.ata_dma: ATA disk DMA mode control
pit@syo ~:-> sysctl -d hw.ata.atapi_dma
hw.ata.atapi_dma: ATAPI device DMA mode control
pit@syo ~:-> sysctl -d hw.ata.wc
hw.ata.wc: ATA disk write caching
pit@syo ~:-> sysctl -d hw.eisa_slots
sysctl: unknown oid 'hw.eisa_slots'
pit@syo ~:-> sysctl -d hint.kbdmux.0.disabled
sysctl: unknown oid 'hint.kbdmux.0.disabled'
heidernei!
wäre auch zu einfach gewesen!

Sind das nun keine sysctl Variablen?
Die ersten kamen mich ja bekannt vor, weshalb ich da nachgesehen habe, aber die beiden letzten sind wohl unbekannt.
Nun bin ich ja schnell wieder gestrandet, aber doch ein wenig weiter, als zuvor.
 
hint.kbdmux.0.disabled

ist mir da am verdächtigsten und mit hint fangen ja Einträge in /boot/device.hints an und so vermute ich mal, daß es hier darum geht?

Jedenfalls werde ich da mal nachsehen und weitermachen.

Nochmal Dank bisher.


Doku ist das irgendwie wirklich nicht.

Ist das Wert, ins Wiki zu kommen? Sollen wir (das ist schön gesagt, gell?) da was machen?
 
Ein alleinstehender Device Resource Hint ist sicherlich keine Doku, aber kbdmux(4) hat ja auch eine man-page in der man nachlesen kann, was der Keyboard Multiplexer ist.
Mit /boot/device.hints bist du doch schon nah dran. Der naechste Schritt waere nun wieder in der man-page (device.hints(5)) nachzulesen. Dokumentation ist also vorhanden. Zumindest, um etwas Hintergrundwissen zu vermittlen.

Ob das Wert is ins Wiki aufgenommen zu werden kannst du, wenn du mit deinen Nachforschungen fertig und zufrieden bist und wenn man sich streng an die Wiki-definition haelt, theoretisch selber entscheiden (enable anyone who accesses it to contribute [...] content). In diesem konkretem Fall wird es allerdings kein "wir" geben, sorry.
 
Wenn Du/Ihr etwas herausfindet, sollte das unbedingt ins Wiki!

Ich kann mich erinnern, genau die gleichen Fragen auch schon gehabt zu haben und nach mehreren, ähnlichen Versuchen, aufgegeben zu haben - ich weiß bis heute nicht, wie das Menü gesteuert wird. Eigentlich erstaunlich, wo sonst alles so exzellent dokumentiert ist.... irgendwie glaube ich ja immer noch, dass es irgendwo eine echte Doku dazu geben muss...

Schöne Grüße
SolarCatcher
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben