HardwareErkennung
Version 27 (mj0, 12/10/2009 02:47 pm)
| 1 | 27 | mj0 | h1. Hardware |
|---|---|---|---|
| 2 | 27 | mj0 | |
| 3 | 1 | dsuchod | h2. Hardware-Erkennung auf SLX-Clients |
| 4 | 1 | dsuchod | |
| 5 | 27 | mj0 | Zentrale Komponente der automatischen Konfiguration ist eine Hardware-Erkennung. Diese übernimmt die weitgehende Einrichtung des Systems. Das passiert im Stage3 hauptsächlich durch @hwautocfg@. Die Einrichtung der Basishardware (Systeme ohne X) erfolgt ebenfalls durch dieses Skript, die Einrichtung von Xorg durch das [[XorgPlugin]], für einige generelle Fragen hierzu siehe auch [[XorgServer]]. |
| 6 | 1 | dsuchod | |
| 7 | 27 | mj0 | Im Hintergrund kommt @hwinfo@ (SuSE-Projekt) zum Einsatz. Entscheidend ist eine passende Zuordnung von Kernelversion zur Version der HW-Info-Datenbank. Deshalb sind die Versionen 13.11, 14.19, 15.3 und 15.21 verfügbar. |
| 8 | 1 | dsuchod | |
| 9 | 22 | dvs | h3. Ergänzung der hwinfo Datenbank |
| 10 | 22 | dvs | |
| 11 | 27 | mj0 | Die primäre, fest einkompilierte Datenbank (@libhd.so@) von @hwinfo@ kann durch Einträge in Dateien unterhalb von @/var/lib/hardware/ids@ (Stage3) extern ergänzt werden. Letztere kann man nehmen, um die Hardware-Erkennung anzupassen (die Einträge hier überschreiben die Einträge in der Hauptdatenbank). |
| 12 | 27 | mj0 | Die "externe Datenbank" befindet sich unter @/opt/openslx/share/ramfstools/hwinfo/db/hwinfo.db.tgz@ und wird bei jedem Boot im Stage3 entpackt. |
| 13 | 1 | dsuchod | |
| 14 | 26 | dvs | Vorgehen: |
| 15 | 1 | dsuchod | # @tar xzfv /opt/openslx/share/ramfstools/hwinfo/db/hwinfo.db.tgz -C /tmp@ |
| 16 | 26 | dvs | # @cd /tmp/var/lib/hardware@ |
| 17 | 27 | mj0 | # @vi hd.ids ids/20.xorg-x11-driver-video@ # In den beiden Dateien die Einträge modifizieren bzw. hinzufügen. Syntax schaut man sich einfach an den anderen Einträgen ab. |
| 18 | 27 | mj0 | # Wieder packen und nach @/opt/openslx/share/ramfstools/hwinfo/db@ kopieren. *ACHTUNG:* Nach einem @make install@ im Repository wird dieser Ordner wieder überschreiben. Deshalb kann die Datei auch nach @./initramfs/tools/hwinfo/db/hwinfo.db.tgz@ im Repository kopiert werden. Diese Datei bei Updates von uns bitte entsprechend wieder anpassen, falls notwendig. |
| 19 | 27 | mj0 | # @slxconfig-demuxer@ durchlaufen lassen und dann sollte er eigentlich was anderes erkennen. |
| 20 | 26 | dvs | # Dann im Stage 3 (debug=3) @hwinfo --gfxcard@ |
| 21 | 26 | dvs | |
| 22 | 27 | mj0 | Für direkte Tests bietet sich im Stage3 das Ändern in @/var/lib/hardware/...@ an. |
| 23 | 5 | dsuchod | |
| 24 | 16 | dvs | h2. Device-Zugriff |
| 25 | 16 | dvs | |
| 26 | 16 | dvs | |
| 27 | 9 | dsuchod | Nur zum Teil ist Hardware fest mit der Maschine verbunden: Mittels USB, Firewire, SCSI, ... lassen sich Geräte auch nachträglich anschliessen oder wieder abklemmen. Unabhängig davon sollte dem Benutzer des Desktops (GUI die sich direkt auf die Maschine bezieht an der er sitzt - sonst gibts noch ganz andere Probleme) Zugriffsrecht auf die Hardware erhalten (und andere bspw. remote angemeldete Benutzer nicht). |
| 28 | 1 | dsuchod | |
| 29 | 6 | dsuchod | Das Einbinden der Hardware regelt inzwischen "udev", die später möglichen Zugriffe werden von verschiedenen Diensten verwaltet. |
| 30 | 6 | dsuchod | |
| 31 | 6 | dsuchod | |
| 32 | 17 | dvs | h3. SuSE10.2 |
| 33 | 16 | dvs | |
| 34 | 6 | dsuchod | http://forgeftp.novell.com/resmgr/web/ ist die Homepage vom "resmgrd". Dort hat der Maintainer auch ein Bild der Zusammenhänge gezeichnet [http://forgeftp.novell.com/resmgr/web/#id2484325] |
| 35 | 7 | dsuchod | |
| 36 | 16 | dvs | Wie gleich im ersten Satz klargestellt wird, ist *resmgr* heute keine Resource Manager mehr. Diese Aufgaben werden von Skripten erfüllt, die der *resmgr* beim Login des Nutzers aufruft. |
| 37 | 12 | dvs | |
| 38 | 16 | dvs | So sorgt _/etc/resmgr.conf.d/99-desktop.conf_ zum Beispiel dafür, dass alle Nutzer mit "tty=:*" der Resmgr-Klasse (!= UNIX-Gruppe) "desktop" (definiert in _/etc/resmgr.conf_) hinzugefügt werden. |
| 39 | 1 | dsuchod | |
| 40 | 20 | schmelzs | _/etc/resmgr.conf.d/90-desktop-console.conf_ realisiert die Anbindung an PolicyKit. Der Datei ist direkt entnehmbar, welche _/usr/bin/polkit-resmgr-*_ Skripte bei der An- oder Abmeldung ausgeführt werden. |
| 41 | 12 | dvs | |
| 42 | 1 | dsuchod | Ebenso verhält es sich mit _/etc/resmgr.conf.d/91-hal-resmgr.conf_ ... |
| 43 | 19 | dvs | |
| 44 | 19 | dvs | h3. PolicyKit |
| 45 | 19 | dvs | |
| 46 | 19 | dvs | Spielt bei neueren Distros eine Rolle ... |
| 47 | 23 | dvs | |
| 48 | 23 | dvs | h2. Einbinden von Platten-Partitionen |
| 49 | 23 | dvs | |
| 50 | 25 | dvs | Generell kann über die globale Variable "hw_local_disk" festgelegt werden, ob die lokale Festplatte überhaupt berücksichtigt werden soll oder nicht. Das kann gerade in Multiboot-Umgebungen sinnvoll sein, um den Zugriff auf das komplette Device explizit auszuschliessen. Diese Platten-IDs werden nachfolgend von *hwsetup* behandelt: |
| 51 | 23 | dvs | |
| 52 | 24 | dvs | * ID44 - _/tmp_ Mount wird immer neu angelegt |
| 53 | 25 | dvs | * ID45 - permanentes Filesystem - Mount nach _/var/scratch_ |
| 54 | 1 | dsuchod | * ID46 - spezielles OpenSLX Teil mit a) boot, b) Home c) ConfTGZ (nicht implementiert) |
| 55 | 23 | dvs | * ID82 - Einbindung von SWAP (erfolgt) |
| 56 | 24 | dvs | * ID83 - Passiver Eintrag in _/etc/fstab_ |