2.6er Kernel, /dev-FS ohne /dev/cdrom und gmplayer - Wie macht man es richtig?
Hi, bisher hatte ich auf allen Maschinen ein /dev/cdrom link zum entsprechenden bevorzugten CD-Laufwerk, also /dev/hdc oder /dev/sr1 oder was auch immer. In .mplayer/gui.conf steht /dev/cdrom. Meine SuSE 10 Workstation hat kein /dev/cdrom, weil /dev/ ja vom Kernel automatisch erstellt wird. Nun meine ich mich zu erinnern, dass man mit trozdem ein /dev/cdrom machen kann, habe aber leider nicht mehr gefunden, wie. Ist das überhaupt der "richtige Weg"? "gmplayer /dev/sr1" oder sowas funktioniert nicht wirklich. Ich habe SuSE 8.2, SusE 9.1 (?) und SuSE 10 mit gleichem $HOME. Die Maschinen sollen möglichst ähnlich sein, weil ich mir nur wenig merken kann und einfach nur mal ein Video gucken möchte. Natürlich könnte ich mir jetzt ein Shellscript "gmplayer" machen, was .mplayer/gui.conf immer je nach `hostname` patcht oder sowas, aber dass kann ja nicht so gedacht sein. Ein ähnliches Problem scheint "esd" zu betreffen. Bei SuSE 8.2 funktioniert das normalerweise "einfach so". Manchmal aber nicht, dann hat es bisher komischerweise meistens geholfen, einfach "esd" in einem xterm laufen zu lassen. Bei meiner SuSE 9.1 Maschine funktionierte mplayer über esd irgendwie nicht, hab da irgendwas anderes genommen (-ao alsa oder so). Bei meiner SuSE 10 hatte ich vorhin gar keinen Sound. K3B hing beim Versuch, einen Sound abzuspielen (wenn ich die Meldungen richtig gedeutet hab), kenn dass Verhalten von neueren esd - was ist das und wie verhindert man das? Wenn ich -ao umschalte, z.B. mit gmplayer und Menü, ist das auf allen Maschinen umgestellt und damit auf mindestens einer falsch. Wenn ich mich recht erinnere, konnte man früher esd entweder immer laufen lassen oder es wird automatisch gestartet, wenn nicht da. Ich hatte mein esd früher via xinit oder so gestartet, bei SuSE 8.0 oder 8.2 oder so dann nicht mehr (lange her, die Details hab ich vergessen, bin mir nicht sicher). Ist das noch so? Sollte ich esd dann immer schon via xinit starten oder kann dies wieder zu anderen Problemen führen? Weiter geht's mit -vo. Mein 8.2 macht -vo xv, so will ich das auch haben. Funktioniert prima, auch mit Vollbild. Bei meiner 9.1 geht das inzwischen auch, wenn ich mich recht erinnere, jedenfalls hatte ich da Vollbild so hinbekommen, dass es brauchbar aussah. Bei meiner 10 fehlt nu komischerweise die xv-Extension. Verstehe ich nicht. Liegt das daran, dass da eine ATI Radeon X700 drin ist und ich wieder ein Spezialtreiber brauche oder so? -vo x11 funktioniert zwar ein bisschen, aber spätenstens das Vollbild ist unbrauchbar. Eigentlich will ich auch keine systemabhängige .mplayer/Konfiguration, sondern eigentlich ja immer xv+esd (oder sollte ich was anderes wollen?). Aber das kriege ich nicht richtig auf den drei genannten Versionen hin. Alle Maschinen auf die gleiche SuSE-Linux-Version zu updaten scheidet leider auch aus, da dies nur die 8.2 sein könnte (die letzte, die für mich noch wirklich funktioniert und damit auf dem Server laufen darf), 2.6er Kernel von der Workstation-Hardware benötigt wird, was mit 8.2 nicht zusammen hinzukriegen war und mein HTPC (mit XPM usw.) aufwändig zu installieren/updaten ist (weil viel Handarbeit). Anscheinend stelle ich mich einfach zu dämlich an. Ich will ja nur ein Video gucken und kriege das nicht vernünftig hin. Was mache ich falsch? oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Hallo, Am Sun, 29 Jan 2006, Steffen Dettmer schrieb:
bisher hatte ich auf allen Maschinen ein /dev/cdrom link zum entsprechenden bevorzugten CD-Laufwerk, also /dev/hdc oder /dev/sr1 oder was auch immer. In .mplayer/gui.conf steht /dev/cdrom. Meine SuSE 10 Workstation hat kein /dev/cdrom, weil /dev/ ja vom Kernel automatisch erstellt wird. Nun meine ich mich zu erinnern, dass man mit trozdem ein /dev/cdrom machen kann, habe aber leider nicht mehr gefunden, wie.
mknod /dev/sr0 b 11 0 ln -s /dev/sr0 /dev/cdrom Du kannst aber auch direkt mknod /dev/cdrom b 11 0 Die minor-Nummer und die Zahl hinter /dev/sr bitte anpassen. verwenden, den Kernel interessieren nur typ, major und minor, nicht der Name des Devices. Nicht mal in /dev/ muss das sein. Und damit die Module ggfs. automatisch geladen werden muss auch die modprobe.conf (bzw. modules.conf) passen. Mehr dazu auf Nachfrage. Bei mir reicht z.B. ein einfaches 'mount /cdrom' um automatisch scsi_mod, cdrom, ide-scsi und sr_mod (in dieser Reihenfolge) zu laden, die LW-Schublade einfahren zu lassen und die CD mounten zu lassen. Wenn das udev stoert sollte es meckern. Also mal ein tail -f /v/l/m zum Testen mitlaufen lassen.
Ich habe SuSE 8.2, SusE 9.1 (?) und SuSE 10 mit gleichem $HOME. Die Maschinen sollen möglichst ähnlich sein, weil ich mir nur wenig merken kann und einfach nur mal ein Video gucken möchte.
Das ist generell schwierig, v.a. bei verschiedenen KDE Versionen etc.
Natürlich könnte ich mir jetzt ein Shellscript "gmplayer" machen, was .mplayer/gui.conf immer je nach `hostname` patcht oder sowas, aber dass kann ja nicht so gedacht sein.
Mach's so wie ich beim Testen eines neuen WindowMakers: Benamse die relevanten Unterverzeichnisse (~/.kde, ~/.mplayer usw.) jeweils mit Versionen/hostnamen. Also z.B.: ~/.mplayer-1.0pre7-foo ~/.mplayer-1.0pre7-bar ~/.mplayer-1.0-baz Und genau, dann nimmst du ein (Wrapper-)Script in die ~/.xinitrc und/oder ~/.xsessionrc (Bei meiner SuSE liest ~/.xsession die ~/.xinitrc) das je nach Hostname und mplayer Version einen symlink ~/.mplayer/ anlegt / umbiegt: ==== Schema ==== #!/bin/sh host="`hostname`" mplayerver="`mplayer --version 2>&1 | sed -n '1s/Mplayer \([^ ]\+\) .*/\1/ip'` rm -f ~/.mplayer ln -sf ~/.mplayer-${mplayerver}-${host} ~/.mplayer rm -f ~/.kde ln -sf ~/.kde-${host} ~/.kde ... ==== Die ganze Umbiegerei wuerde ich "gesammelt" in einem script in ~/bin/ ablegen und das dann aus der ~/.xinitrc | ~/.xsessionrc oder aus der ~/.profile ausfuehren.
Ein ähnliches Problem scheint "esd" zu betreffen. Bei SuSE 8.2 funktioniert das normalerweise "einfach so". Manchmal aber nicht, dann hat es bisher komischerweise meistens geholfen, einfach "esd" in einem xterm laufen zu lassen. Bei meiner SuSE 9.1 Maschine funktionierte mplayer über esd irgendwie nicht, hab da irgendwas anderes genommen (-ao alsa oder so). Bei meiner SuSE 10 hatte ich vorhin gar keinen Sound. K3B hing beim Versuch, einen Sound abzuspielen (wenn ich die Meldungen richtig gedeutet hab), kenn dass Verhalten von neueren esd
Das deutet darauf hin, dass da noch ein andere "multiplexer" laeuft, z.B. artsd von KDE.
- was ist das und wie verhindert man das?
esd ist das GNOME Aequivalent von artsd. Lass' nur einen Laufen. Oder gar keinen, wenn du alsa verwendest, denn Alsa kann auch selber "multiplexen" (d.h. mehrere Sounds auf einem Kanal zusammenmischen). Du solltest dich IMHO auf eine Variante (die auf allen 3 Rechnern laeuft, also vermutlich sogar esd) festlegen.
Wenn ich -ao umschalte, z.B. mit gmplayer und Menü, ist das auf allen Maschinen umgestellt und damit auf mindestens einer falsch.
Wuerde sich auch durch ein ~/.mplayer/ (s.o.) umgehen lassen.
Wenn ich mich recht erinnere, konnte man früher esd entweder immer laufen lassen oder es wird automatisch gestartet, wenn nicht da.
Jep.
Ich hatte mein esd früher via xinit oder so gestartet, bei SuSE 8.0 oder 8.2 oder so dann nicht mehr (lange her, die Details hab ich vergessen, bin mir nicht sicher). Ist das noch so? Sollte ich esd dann immer schon via xinit starten oder kann dies wieder zu anderen Problemen führen?
s.o. Und ja, kannst du starten, nur gehen dann Anwendungen, die ein Device nur direkt benutzen wollen evtl. nicht mehr. Aber die sollten inzwischen die Ausnahme sein.
Weiter geht's mit -vo. Mein 8.2 macht -vo xv, so will ich das auch haben. Funktioniert prima, auch mit Vollbild. Bei meiner 9.1 geht das inzwischen auch, wenn ich mich recht erinnere, jedenfalls hatte ich da Vollbild so hinbekommen, dass es brauchbar aussah. Bei meiner 10 fehlt nu komischerweise die xv-Extension. Verstehe ich nicht.
Hm. XVideo sollte aber klappen, das geht ja sogar bei mir mit nem XFree86 3.3.6, das ich im April 2000 installiert habe... Hm. Evtl. fe lt da was in der 'Section "Module"' deiner XF86Config/xorg.conf. Frag mich aber nicht was, mit XFree 4.x hatte ich bisher nur testhalber und dabei erfolglos, mit XOrg gar keinen Kontakt.
Liegt das daran, dass da eine ATI Radeon X700 drin ist und ich wieder ein Spezialtreiber brauche oder so?
Moeglich.
Eigentlich will ich auch keine systemabhängige .mplayer/Konfiguration, sondern eigentlich ja immer xv+esd (oder sollte ich was anderes wollen?). Aber das kriege ich nicht richtig auf den drei genannten Versionen hin.
s.o. Es haengt halt auch an den Anwendungen ob diese esd verwenden koennen. Wenn du alsa verwendest: das koennen alle, denn alsa kann ja auch OSS emulieren. Wie zum "multiplexen" die Config sein muss weiss ich nicht, das ist aber dokumentiert (habe ich irgendwo schon mal gelesen), ich selber verwende Alsa nicht (hab's mit meiner Karte[1] nicht zum laufen bekommen, obwohl die von Alsa angeblich unterstuetzt wird). HTH, -dnh [1] von '95 IIRC, die fuer isapnp unsichtbar ist, aber tadellos funktioniert. Ist ne ISA "Mozart" mit OTI 60[15][A-E]-Chip... -- "The most exciting phrase to hear in science, the one that heralds new discoveries, is not 'Eureka!' (I found it!) but 'That's funny ...'" -- Isaac Asimov
* David Haller wrote on Mon, Jan 30, 2006 at 02:39 +0100:
ln -s /dev/sr0 /dev/cdrom
ja, sowas. Das geht und ist der "Richtige Weg (TM)" bei diesem neumodischem /dev-Krams? Schreibt man sich einfach in boot.local oder so rein? mmm... Aus'm Bauch fühlt sich das irgendwie nach Hack an?
Du kannst aber auch direkt
mknod /dev/cdrom b 11 0
ln -s ist prima, falls ich vergesse, wo mein CD denn auf Maschine X nu gerade hängt :)
verwenden, den Kernel interessieren nur typ, major und minor, nicht der Name des Devices. Nicht mal in /dev/ muss das sein.
Ja, hatte ich auch schon überlegt, ein /SteffensDevices/ anzulegen, da ist dann Ordnung drin, dann können SuSE und der Kernel in /dev rumwursten, wie sie Lust haben, aber das kann ja nicht so gedacht sein, oder?!
Und damit die Module ggfs. automatisch geladen werden muss auch die modprobe.conf (bzw. modules.conf) passen.
Yup, geht wie früher, oder? Das passt wohl auch alles, weil ein mount /dev/hdc /mnt (oder was auch immer) ja funktioniert.
Wenn das udev stoert sollte es meckern. Also mal ein tail -f /v/l/m zum Testen mitlaufen lassen.
(Meckern? Optimist! :))
Ich habe SuSE 8.2, SusE 9.1 (?) und SuSE 10 mit gleichem $HOME. Die Maschinen sollen möglichst ähnlich sein, weil ich mir nur wenig merken kann und einfach nur mal ein Video gucken möchte.
Das ist generell schwierig, v.a. bei verschiedenen KDE Versionen etc.
KDE? Das mit dem Klinux? Das verwende ich nicht :) SCNR. Nee, mal im Ernst, werden heute keine NFS-Homes mehr unterstützt? Hat mich schon bei minicom damals genervt, dass die Dial-No-Liste in verschiedenen Formaten aber gleichem Dateinamen abgelegt wurden, und heute ist das normal? Kann doch nicht sein, werde ja wohl nicht der einzige mit NFS-Home sein? Und Enlightenment zwischen SuSE 7.0 und 9.1 (oder was auch immer ich im Wohnzimmer nu genau hab) ging auch immer.
Und genau, dann nimmst du ein (Wrapper-)Script in die ~/.xinitrc und/oder ~/.xsessionrc
NEIN, das wird doch bloss beim Anmelden ausgeführt! Nee, muss schon ~/bin sein oder so. Sonst geht's ja am Server nie, weil sich da ja "nie" jemand anmeldet :)
ln -sf ~/.mplayer-${mplayerver}-${host} ~/.mplayer
Aber stimmt, es gibt zwar "conf=<file>" für input.conf, aber nix für gui.conf (laut manpage). Schade eigentlich. Wäre sonst auch zu einfach, könnte man ja einen alias nehmen lol
Die ganze Umbiegerei wuerde ich "gesammelt" in einem script in ~/bin/ ablegen und das dann aus der ~/.xinitrc | ~/.xsessionrc oder aus der ~/.profile ausfuehren.
Früher hatte ich was in der Art, um passende Binaries zu finden, also ein ~/bin/perl was dann (je nach Platform etc) /usr/etc/local/sbin/dochbin/perl (oder wie die komischen Pfade bei IRIX oder so waren) gesucht hat, dann legt man sich ~/bin vorn in den Pfad und kann alles schön überschreiben. Hatte auch compiler-Wrapper, die gewissen Output filterten und sowas. Aber kann doch nicht sein, dass ich sowas in einem Linux-Only-Netz auspacken muss, oder? [...esd hängt...]
Das deutet darauf hin, dass da noch ein andere "multiplexer" laeuft, z.B. artsd von KDE.
Ich werde mal rumgucken und artsd deinstallieren oder chmod 0'n. Wird sowas irgendwo default benutzt? Wäre ja ein Hammer, wenn wieder mal das KDE was KKKaput macht :)
- was ist das und wie verhindert man das?
esd ist das GNOME Aequivalent von artsd. Lass' nur einen Laufen. Oder gar keinen, wenn du alsa verwendest, denn Alsa kann auch selber "multiplexen" (d.h. mehrere Sounds auf einem Kanal zusammenmischen).
Auch bei SuSE 8.2? Muss man da was machen? gmplayer startet hier meist esd (der scheinbar kein chdir(/) macht und daher vor'm unmounten gekillt werden muss, unglaublich) und man hört dann jedenfalls sound. [quoting reordered]
s.o. Und ja, kannst du starten, nur gehen dann Anwendungen, die ein Device nur direkt benutzen wollen evtl. nicht mehr. Aber die sollten inzwischen die Ausnahme sein.
Na, Skype ist das Problem, meine ich mich zu erinnern, jetzt, wo Du's sagst... Ich glaub, damals hatte ich esd aus boot genommen, weil Skype sonst nicht ging, eigentlich als Test, alles eine Fummelei. Skype kann nu wohl wieder kein esd. Echt nervig, es geht immer nur "fast", irgendwo klemmts dann wieder :(
Du solltest dich IMHO auf eine Variante (die auf allen 3 Rechnern laeuft, also vermutlich sogar esd) festlegen.
Ja, falls es ein Arzt-D gibt, war das sicherlich nicht gewollt, muss ich mal gucken, danke für den Tipp.
Weiter geht's mit -vo. Mein 8.2 macht -vo xv, so will ich das auch haben. Funktioniert prima, auch mit Vollbild. Bei meiner 9.1 geht das inzwischen auch, wenn ich mich recht erinnere, jedenfalls hatte ich da Vollbild so hinbekommen, dass es brauchbar aussah. Bei meiner 10 fehlt nu komischerweise die xv-Extension. Verstehe ich nicht.
Hm. XVideo sollte aber klappen, das geht ja sogar bei mir mit nem XFree86 3.3.6, das ich im April 2000 installiert habe...
Ja, früher ging's, bei 8.2 geht's und überall geht's. Ausser auf meiner AMD-3000-keineAhnung-DualCore 3D-Grafik-Hardwareschlacht 1GB RAM Workstation. Sollte ich RAM aufrüsten? LOL SCNR. Nee, denke, dass muss wieder so'n Treiberding sein, ging bei meiner Matrox P650 zwischendurch auch mal nicht. Vielleicht sollte ich noch ne "dumme" zweite GraKa zum Videogucken einbauen SCNR.
Hm. Evtl. fe lt da was in der 'Section "Module"' deiner XF86Config/xorg.conf. Frag mich aber nicht was, mit XFree 4.x hatte ich bisher nur testhalber und dabei erfolglos, mit XOrg gar keinen Kontakt.
ja, die Extensions müssen geladen werden, sollte aber default sein, gerade xv, aber gucke ich mal (Büchse nur gerade aus).
s.o. Es haengt halt auch an den Anwendungen ob diese esd verwenden koennen. Wenn du alsa verwendest: das koennen alle, denn alsa kann ja auch OSS emulieren. Wie zum "multiplexen" die Config sein muss weiss ich nicht, das ist aber dokumentiert (habe ich irgendwo schon mal gelesen),
Klingt nach einer guten Idee. Da würde ich dann sowas wie ein /dev/dsp1 machen, da kann sich skype dann austoben und /dev/dsp0 macht über esd den Rest, klingt erstmal nach einem Weg. Stimmt, hatte schon mal irgendwo gelesen, dass und was man bei ALSA bis zum Abwinken konfigurieren kann (FALLS man denn alle 6 Kanäle einer 5.1 Karte nutzen kann ;)). Danke für die Tips!! oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
David Haller wrote:
[...] Mehr dazu auf Nachfrage. Bei mir reicht z.B. ein einfaches 'mount /cdrom' um automatisch scsi_mod, cdrom, ide-scsi und sr_mod (in dieser Reihenfolge) zu laden, die LW-Schublade einfahren zu lassen und die CD mounten zu lassen.
Das ist "Hallerlix" - moderne *huestel* Linux-Distributionen kommen mit Kernel 2.6 daher und da ist ide-scsi pfui, pfui, pfui... ;-) Was spricht denn dagegen, einfach einen Link /dev/cdrom anzulegen auch bei einer SuSE 10? Der Link zeigt halt ins Leere, solange das eigentliche Device des Laufwerks von udev noch nicht generiert wurde, aber sobald es da ist, ist auch der Link gueltig. Es koennte natuerlich sein, dass udev keine Eingriffe von Dritten in /dev duldet und den von Hand angelegten Link wieder entfernt - kann ich mir aber kaum vorstellen... Cheers, Th.
Hallo, Am Mon, 30 Jan 2006, Thomas Hertweck schrieb:
David Haller wrote:
[...] Mehr dazu auf Nachfrage. Bei mir reicht z.B. ein einfaches 'mount /cdrom' um automatisch scsi_mod, cdrom, ide-scsi und sr_mod (in dieser Reihenfolge) zu laden, die LW-Schublade einfahren zu lassen und die CD mounten zu lassen.
Das ist "Hallerlix" - moderne *huestel* Linux-Distributionen kommen mit Kernel 2.6 daher und da ist ide-scsi pfui, pfui, pfui... ;-)
Dann eben ide-core/ide-generic, cdrom und ide-cd. Und ISTR, dass das Brennen ohne ide-scsi nicht immer klappt.
Was spricht denn dagegen, einfach einen Link /dev/cdrom anzulegen auch bei einer SuSE 10? Der Link zeigt halt ins Leere, solange das eigentliche Device des Laufwerks von udev noch nicht generiert wurde, aber sobald es da ist, ist auch der Link gueltig. Es koennte natuerlich sein, dass udev keine Eingriffe von Dritten in /dev duldet und den von Hand angelegten Link wieder entfernt - kann ich mir aber kaum vorstellen...
Ich auch, deswegen sollte es udev auch nicht stoeren, wenn ein device per Hand angelegt wird. Aber ich kenne udev eben nicht. In 'man udev' hab ich nix gefunden. Und da ich kein udev habe (und will) kann ich's auch nicht ausprobieren. Was mich aber bei udev wundert ist: ==== man udev [von SuSE 9.1] ==== As part of the hotplug subsystem, udev is executed if a kernel device is added or removed from the system. ==== So, wie kann aber nun der Kernel merken, dass ein Device "dazukommt" wenn kein Modul fuer so ein Device da ist? Reicht ein Zugriff auf ein "nicht-existentes"(!) Device, z.B. /dev/sg1 um das Device zu erstellen, die noetigen Module z.B. fuer meinen Scanner g_NCR5380 und sg zu laden? Denn bis g_NCR5380 geladen ist weiss mein Kernel genau nix ueber SCSI-Devices: # ls /proc/scsi ls: /proc/scsi: No such file or directory # modprobe sg # ls /proc/scsi . .. g_NCR5380 ide-scsi scsi sg Und wenn der Kernel nix weiss... Fuer mich liest sich das wie ein Henne-Ei Problem. Folgerung: man muss zwingend beim booten z.B. die USB-Module (-ehci/-uhci usw.) laden, sonst bekommt der Kernel ja nix von mit, wenn ich einen USB-Stick einstoepsel. Ich glaube ich versteh' jetzt auch, warum die modprobe.conf nur noch eine extrem simple Syntax hat. Denn das meiste muss man sowieso beim booten laden. Und der Rest wird ueber den hotplug Krempel "quasi-manuell" geladen (da nur (vom Distributor) verscriptet). Yippie-ah-yea-ah, Schweinebacke, also DAS nennt ich Fortschritt. *Boerks* -dnh, muss man hier Sarkasmus eigentlich markieren? --
This needs quotes: use lib "/path/to/perl/modules"; Single or double quotes? Yes. -- Tad McClellan in comp.lang.perl.misc
Hallo, Am Mon, 30 Jan 2006, Steffen Dettmer schrieb:
* David Haller wrote on Mon, Jan 30, 2006 at 02:39 +0100:
ln -s /dev/sr0 /dev/cdrom
ja, sowas. Das geht und ist der "Richtige Weg (TM)" bei diesem neumodischem /dev-Krams?
Keine Ahnung. Probier's aus. :)
Schreibt man sich einfach in boot.local oder so rein? mmm... Aus'm Bauch fühlt sich das irgendwie nach Hack an?
Noe. Einmal machen. Loeschen sollte udev den symlink ja nicht. Aber kann man natuerlich in /boot.local einbauen, falls noetig. Und wuerde ich auch machen. Wenn mir so ein Automatismus was kaputt macht kenne ich keine Gnade was die Wahl der Mittel angeht, den Automatismus zu umgehen / auszutricksen. Und in der manpage von udev steht auch nix, das einen hindern wuerde "manuell" mit mknod die (noetigen) /dev/sr* anzulegen und ggfs. zu versymlinken.
Du kannst aber auch direkt
mknod /dev/cdrom b 11 0
ln -s ist prima, falls ich vergesse, wo mein CD denn auf Maschine X nu gerade hängt :)
Jep.
verwenden, den Kernel interessieren nur typ, major und minor, nicht der Name des Devices. Nicht mal in /dev/ muss das sein.
Ja, hatte ich auch schon überlegt, ein /SteffensDevices/ anzulegen, da ist dann Ordnung drin, dann können SuSE und der Kernel in /dev rumwursten, wie sie Lust haben, aber das kann ja nicht so gedacht sein, oder?!
Na und? Wenn's nicht wie vorgeschlagen klappt, warum nicht? S.o. bzw. Wahl der Mittel.
Und damit die Module ggfs. automatisch geladen werden muss auch die modprobe.conf (bzw. modules.conf) passen.
Yup, geht wie früher, oder?
Leider nicht. Die Syntax der modprobe.conf ist kastriert worden.
Das passt wohl auch alles, weil ein mount /dev/hdc /mnt (oder was auch immer) ja funktioniert.
Auch bei 'mount /dev/sr0' (oder wie auch immer, halt ein sr-Device)? Achso: ich hab ein awk-script, das mir aus einfachen 'above' und 'below' Zeilen wie in der modules.conf modprobe geeignetes generiert. $ echo 'below sr_mod ide-scsi' | ~/src/modprobe_gen/modprobe_gen ### below sr_mod ide-scsi install sr_mod {\ /sbin/modprobe ide-scsi;\ }; /sbin/modprobe --ignore-install sr_mod remove sr_mod /sbin/modprobe --ignore-remove --remove sr_mod && {\ /sbin/modprobe --remove ide-scsi;\ } Sowas will man sich nicht wirklich merken und per Hand eingeben, odr?
Wenn das udev stoert sollte es meckern. Also mal ein tail -f /v/l/m zum Testen mitlaufen lassen.
(Meckern? Optimist! :))
man euphemism
Ich habe SuSE 8.2, SusE 9.1 (?) und SuSE 10 mit gleichem $HOME. Die Maschinen sollen möglichst ähnlich sein, weil ich mir nur wenig merken kann und einfach nur mal ein Video gucken möchte.
Das ist generell schwierig, v.a. bei verschiedenen KDE Versionen etc.
KDE? Das mit dem Klinux? Das verwende ich nicht :) SCNR.
Ah :) Ich schon. Z.B. habe ich noch keinen besseren Mixer als das kmix aus KDE-1.1.2 gefunden. Kleine und einstellbare UI, aber dennoch gut bedienbar. Andere Mixer sind entweder viel Platzfressender oder zu klein um noch bedienbar zu sein (wie wmmixer z.B.)...
Nee, mal im Ernst, werden heute keine NFS-Homes mehr unterstützt? Hat mich schon bei minicom damals genervt, dass die Dial-No-Liste in verschiedenen Formaten aber gleichem Dateinamen abgelegt wurden, und heute ist das normal?
Bei den ueblichen Verdaechtigen wohl schon. Es gab AFAIK recht haeufig gravierende Probleme bei KDE X.Y.Z und X.Y.(Z + 1) eine Konfig-Datei weiterzuverwenden -- geschweige denn mit beiden Versionen zu nutzen. Und ob sowas dokumentiert wurde?
Kann doch nicht sein, werde ja wohl nicht der einzige mit NFS-Home sein? Und Enlightenment zwischen SuSE 7.0 und 9.1 (oder was auch immer ich im Wohnzimmer nu genau hab) ging auch immer.
Das spricht fuer Enlightenment (der mir aber zu fett ist ;). Und ja, ~/.kde (teilweise gab/gibt es auch .kde2 .kde3) war immer ein "Quell des Spasses" *hurhuar* Das musst du also wohl "trennen". Besonders geil daran: Anscheinend legt KMail inzwischen per default die Mailboxen unter ~/.kde/share/irgend/was/ ab. "Froide!"... Alles Gruende, warum ich kein Interesse habe, mir KDE3 anzuschauen.
Und genau, dann nimmst du ein (Wrapper-)Script in die ~/.xinitrc und/oder ~/.xsessionrc
NEIN, das wird doch bloss beim Anmelden ausgeführt! Nee, muss schon ~/bin sein oder so. Sonst geht's ja am Server nie, weil sich da ja "nie" jemand anmeldet :)
Ich meinte dort wo du dich anmeldest. Bzw. was der XServer eben liest, wenn du ihn startest. Das script kann natuerlich dazu in ~/bin/ liegen, so dass du's ggfs. auch per Hand bequem (nochmal) aufrufen kannst. Was meinst du, was ich alles in ~/bin/ habe ;) $ ls ~/bin | wc -l; du -hs ~/bin 724 11M /home/dh/bin Sind aber auch ein paar Dinge dabei, die da eigentlich nicht unbedingt reingehoeren ;) Und einiges an *~ Dateien.
ln -sf ~/.mplayer-${mplayerver}-${host} ~/.mplayer
Aber stimmt, es gibt zwar "conf=<file>" für input.conf, aber nix für gui.conf (laut manpage). Schade eigentlich. Wäre sonst auch zu einfach, könnte man ja einen alias nehmen lol
Aber zumindest 'vo=' und 'ao=' koenntest du ueber eine /etc/mplayer.conf pro Host vorgeben und den Rest in ~/.mplayer/config. Aus der sample-Datei (steht auch in der manpage): ## If both exist, the ~/.mplayer/config's settings override the ## /etc/mplayer.conf ones. Aber die nur in /etc/mplayer.conf gesetzten und nicht in ~/.mplayer/config ueberschriebenen sollten gelten, so wie sich das ja auch gehoert :)
Die ganze Umbiegerei wuerde ich "gesammelt" in einem script in ~/bin/ ablegen und das dann aus der ~/.xinitrc | ~/.xsessionrc oder aus der ~/.profile ausfuehren.
Früher hatte ich was in der Art, um passende Binaries zu finden, also ein ~/bin/perl was dann (je nach Platform etc) /usr/etc/local/sbin/dochbin/perl (oder wie die komischen Pfade bei IRIX oder so waren) gesucht hat, dann legt man sich ~/bin vorn in den Pfad und kann alles schön überschreiben. Hatte auch compiler-Wrapper, die gewissen Output filterten und sowas. Aber kann doch nicht sein, dass ich sowas in einem Linux-Only-Netz auspacken muss, oder?
Wenn's hilft, warum nicht.
[...esd hängt...]
Das deutet darauf hin, dass da noch ein andere "multiplexer" laeuft, z.B. artsd von KDE.
Ich werde mal rumgucken und artsd deinstallieren oder chmod 0'n. Wird sowas irgendwo default benutzt? Wäre ja ein Hammer, wenn wieder mal das KDE was KKKaput macht :)
Der KDE-KKram nutzt das, einige andere Sachen auch, z.B. die libSDL wenn so eingestellt/kompiliert. Auch xmms u.a. kann artsd verwenden. Schau also mal mit 'ps' ob artsd laeuft und ggfs. welche der laufenden Apps bei nem 'ldd' ein libarts*.so enthalten.
- was ist das und wie verhindert man das?
esd ist das GNOME Aequivalent von artsd. Lass' nur einen Laufen. Oder gar keinen, wenn du alsa verwendest, denn Alsa kann auch selber "multiplexen" (d.h. mehrere Sounds auf einem Kanal zusammenmischen).
Auch bei SuSE 8.2?
Kommt auf die Alsa-Version an. Und die laesst sich ja unabhaengig von der Distri aktualisieren.
Muss man da was machen? gmplayer startet hier meist esd (der scheinbar kein chdir(/) macht und daher vor'm unmounten gekillt werden muss, unglaublich)
*oerks*
und man hört dann jedenfalls sound.
MPlayer kann AFAIK eigentlich alles zur Ausgabe verwenden. Schau dir mal 'mplayer -ao help' an. [..]
s.o. Es haengt halt auch an den Anwendungen ob diese esd verwenden koennen. Wenn du alsa verwendest: das koennen alle, denn alsa kann ja auch OSS emulieren. Wie zum "multiplexen" die Config sein muss weiss ich nicht, das ist aber dokumentiert (habe ich irgendwo schon mal gelesen),
Klingt nach einer guten Idee. Da würde ich dann sowas wie ein /dev/dsp1 machen, da kann sich skype dann austoben und /dev/dsp0 macht über esd den Rest, klingt erstmal nach einem Weg. Stimmt, hatte schon mal irgendwo gelesen, dass und was man bei ALSA bis zum Abwinken konfigurieren kann (FALLS man denn alle 6 Kanäle einer 5.1 Karte nutzen kann ;)).
Wenn du Alsa als Treiber verwendest und das ueberhaupt geht, dann geht das auch direkt ohne artsd/esd. Mein 'esd' kann auch nur das anbieten, was der OSS-Treiber meiner Soundkarte kann. -dnh -- Wenn Ihr irgendwas Zischen und Krachen höhrt, keine Angst. das ist nur mein Kopf, bei der Produktion von wognaturen. [WoKo in dag°]
Am Montag, 30. Januar 2006 20:51 schrieb Steffen Dettmer:
* David Haller wrote on Mon, Jan 30, 2006 at 02:39 +0100:
ln -s /dev/sr0 /dev/cdrom
ja, sowas. Das geht und ist der "Richtige Weg (TM)" bei diesem neumodischem /dev-Krams? Schreibt man sich einfach in boot.local oder so rein? mmm... Aus'm Bauch fühlt sich das irgendwie nach Hack an? Also der korrekte Weg wäre, glaube ich, unter /etc/udev/rules.d eine neue Datei anzulegen (bei mir 60-local.rules). Die Nummer zeigt die Reihenfolge des Abarbeitens an, da hat sich in letzter Zeit einiges geändert, im Zweifelsfall verschiedene Ziffern ausprobieren.
In die Datei muß dann die Regel zum Erstellen des Symlinks hinein, z.B. KERNEL=="hdc", SYMLINK="cdrom" führt zu einem Symlink von cdrom auf hdc. MfG Klaus
Hallo. * Dienstag, 31. Januar 2006 um 02:06 (+0100) schrieb David Haller:
Ich auch, deswegen sollte es udev auch nicht stoeren, wenn ein device per Hand angelegt wird.
"Das kommt drauf an..." -- Wenn 'udev' einen gleichnamigen Device-Node oder Symlink anlegt/anlegen würde, dann löscht es i.a. den Node oder Symlink auch beim Entfernen des Devices oder beim Reboot.
Aber ich kenne udev eben nicht. In 'man udev' hab ich nix gefunden. Und da ich kein udev habe (und will) kann ich's auch nicht ausprobieren. Was mich aber bei udev wundert ist:
==== man udev [von SuSE 9.1] ==== As part of the hotplug subsystem, udev is executed if a kernel device is added or removed from the system. ====
So, wie kann aber nun der Kernel merken, dass ein Device "dazukommt" wenn kein Modul fuer so ein Device da ist? Reicht ein Zugriff auf ein "nicht-existentes"(!) Device, z.B. /dev/sg1 um das Device zu erstellen, die noetigen Module z.B. fuer meinen Scanner g_NCR5380 und sg zu laden?
AFAIK "scannt" der Kernel (2.6.X) während des Bootens alle Geräte bzw. Busse, lädt ggfs. die passenden Module und schreibt die Daten der gefundenen Geräte ins sysfs. Diese Daten werden auch an das Hotplug-Subsystem gesendet, womit sie von 'udev(d)' empfangen werden und 'udev' dann aus den Daten u.a. Device-Nodes und falls gewünscht Symlinks o.ä. anlegt. Oder anders ausgedrückt (aus http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ): "[...] Q: But udev will not automatically load a driver if a /dev node is opened when it is not present like devfs will do. A: Right, but Linux is supposed to load a module when a device is discovered not to load a module when it's accessed. [...]"
Denn bis g_NCR5380 geladen ist weiss mein Kernel genau nix ueber SCSI-Devices:
# ls /proc/scsi ls: /proc/scsi: No such file or directory # modprobe sg # ls /proc/scsi . .. g_NCR5380 ide-scsi scsi sg
Das ist aber entweder ein antiker oder kastrierter Kernel ;-)
Und wenn der Kernel nix weiss... Fuer mich liest sich das wie ein Henne-Ei Problem. Folgerung: man muss zwingend beim booten z.B. die USB-Module (-ehci/-uhci usw.) laden, sonst bekommt der Kernel ja nix von mit, wenn ich einen USB-Stick einstoepsel.
Nein, der Kernel lädt die Module (automagisch), sobald er die Geräte erkennt.
Yippie-ah-yea-ah, Schweinebacke, also DAS nennt ich Fortschritt.
Ich breche hier mal eine Lanze für 'udev' -- IMHO ist das wirklich Fortschritt. Schliesse doch mal einen 2. Scanner an deine SCSI-Karte an und sieh dir an, wie die /dev/sg* den beiden Scannern zugeordnet werden, abhängig davon welcher Scanner eingeschaltet. (Noch schöner ist das mit einem externen SCSI-CD-Brenner, der auch über /dev/sg* angesprochen werden muss...) Und nun stell dir das Chaos bei den USB-Massenspeicher-Device-Nodes vor, wenn du ein paar USB-Sticks, einige USB-Festplatten und einen 16fach-Speicherkarten-Leser anschliesst (oder eben nicht alle anschliesst). Nee, da lob' ich mir dann doch 'udev'... Gruß Andreas (Back in town) -- XMMS spielt gerade "The Who - I Can See For Miles"... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
Hallo, Am Tue, 31 Jan 2006, Andreas Koenecke schrieb:
* Dienstag, 31. Januar 2006 um 02:06 (+0100) schrieb David Haller: [..] A: Right, but Linux is supposed to load a module when a device is discovered not to load a module when it's accessed. [...]"
Genau letzteres will ich aber nicht. [..]
# ls /proc/scsi . .. g_NCR5380 ide-scsi scsi sg
Das ist aber entweder ein antiker oder kastrierter Kernel ;-)
Weder noch. [..]
Ich breche hier mal eine Lanze für 'udev' -- IMHO ist das wirklich Fortschritt. Schliesse doch mal einen 2. Scanner an deine SCSI-Karte an und sieh dir an, wie die /dev/sg* den beiden Scannern zugeordnet werden, abhängig davon welcher Scanner eingeschaltet. (Noch schöner ist das mit einem externen SCSI-CD-Brenner, der auch über /dev/sg* angesprochen werden muss...)
Das ist hier kein Problem (Scanner extern an SCSI, Brenner intern via ide-scsi).
Und nun stell dir das Chaos bei den USB-Massenspeicher-Device-Nodes vor, wenn du ein paar USB-Sticks, einige USB-Festplatten und einen 16fach-Speicherkarten-Leser anschliesst (oder eben nicht alle anschliesst).
Ok, bei USB...
XMMS spielt gerade "The Who - I Can See For Miles"...
Ah, guter Geschmack. -dnh -- Get your acts together, guys. Stop blathering and frothing at the mouth. -- Linus Torvalds
Andreas Koenecke wrote:
[...]
Ich breche hier mal eine Lanze für 'udev' -- IMHO ist das wirklich Fortschritt. Schliesse doch mal einen 2. Scanner an deine SCSI-Karte an und sieh dir an, wie die /dev/sg* den beiden Scannern zugeordnet werden, abhängig davon welcher Scanner eingeschaltet. (Noch schöner ist das mit einem externen SCSI-CD-Brenner, der auch über /dev/sg* angesprochen werden muss...) Und nun stell dir das Chaos bei den USB-Massenspeicher-Device-Nodes vor, wenn du ein paar USB-Sticks, einige USB-Festplatten und einen 16fach-Speicherkarten-Leser anschliesst (oder eben nicht alle anschliesst).
Nee, da lob' ich mir dann doch 'udev'...
udev hat seine Vorteile, das steht ausser Frage. Diese Vorteile beziehen sich aber hpts. auf Geraete, die zur Laufzeit eines Linux-System dynamisch an- oder abgemeldet werden koennen (wie eben u.a. USB-Sticks). Was aber bringt es mir, den Device-Knoten fuer meine Root-Partition auf einer IDE-Festplatte dynamisch zu erzeugen? Ich aendere doch nicht laufend meine Festplatten und/oder Root-Partitionen usw. - also muss der Device-Knoten doch eh bei jedem Booten identisch neu erzeugt werden. Das ist sicher kein Performance-Problem, ich sehe lediglich keinen Sinn darin. Und Dinge ohne Sinn sind mir immer suspekt. Wenn es mit udev in der initrd nicht stimmt, dann kannst Du nicht mal Dein System mehr booten, es kommt zu einem Kernel-Panic, weil der Device-Knoten fuer die Root-Partition fehlt. IMO eine voellig unnoetige Sache. Dass es ohne initrd heute schon gar nicht mehr geht, scheint jeder einfach so hinzunehmen... CU, Th.
Hallo. * Dienstag, 31. Januar 2006 um 18:40 (+0100) schrieb David Haller:
Hallo,
Am Tue, 31 Jan 2006, Andreas Koenecke schrieb:
[..]
A: Right, but Linux is supposed to load a module when a device is discovered not to load a module when it's accessed. [...]"
Genau letzteres will ich aber nicht.
Aber unter "/dev" nur die Device-Nodes für tatsächlich im System vorhandene Geräte statt ca. 7500 ungenutzte Nodes wäre doch eine feine Sache, oder? (SUSE 10.0 macht das aber auch noch nicht...)
Das ist aber entweder ein antiker oder kastrierter Kernel ;-)
Weder noch.
Na gut: "Ein langjährig bewährter Kernel, der sich in der Maintenance-Phase befindet?";-)
Schliesse doch mal einen 2. Scanner an deine SCSI-Karte an und sieh dir an, wie die /dev/sg* den beiden Scannern zugeordnet werden, abhängig davon welcher Scanner eingeschaltet. (Noch schöner ist das mit einem externen SCSI-CD-Brenner, der auch über /dev/sg* angesprochen werden muss...)
Das ist hier kein Problem (Scanner extern an SCSI, Brenner intern via ide-scsi).
Aber doch nur solange du penibel darauf achtest, in welcher Reihenfolge "ide-scsi" und "g_NCR5380" geladen werden, oder?
Und nun stell dir das Chaos bei den USB-Massenspeicher-Device-Nodes vor, wenn du ein paar USB-Sticks, einige USB-Festplatten und einen 16fach-Speicherkarten-Leser anschliesst (oder eben nicht alle anschliesst).
Ok, bei USB...
Ja, da fällt das Problem schnell auf, aber auch SCSI hat grundsätzlich das Problem: Jede zusätzliche Platte muss eine höhere ID als die vorhandenen Platten haben (am gleichen Bus natürlich), sonst wird "neu gemischt"... Gruß Andreas -- XMMS spielt gerade "Pink Floyd - Pigs (Three Different Ones)"... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
Hallo. * Dienstag, 31. Januar 2006 um 19:19 (+0000) schrieb Thomas Hertweck:
Andreas Koenecke wrote:
[...]
Nee, da lob' ich mir dann doch 'udev'...
udev hat seine Vorteile, das steht ausser Frage. Diese Vorteile beziehen sich aber hpts. auf Geraete, die zur Laufzeit eines Linux-System dynamisch an- oder abgemeldet werden koennen (wie eben u.a. USB-Sticks). Was aber bringt es mir, den Device-Knoten fuer meine Root-Partition auf einer IDE-Festplatte dynamisch zu erzeugen? Ich aendere doch nicht laufend meine Festplatten und/oder Root-Partitionen usw. - also muss der Device-Knoten doch eh bei jedem Booten identisch neu erzeugt werden. Das ist sicher kein Performance-Problem, ich sehe lediglich keinen Sinn darin. Und Dinge ohne Sinn sind mir immer suspekt.
Ein Ziel von 'udev' ist z.B., dass unterhalb von "/dev" nur noch die Device-Nodes für tatsächlich vorhandene Geräte aufgeführt werden. Das ist zwar nur Kosmetik, aber IMHO durchaus sinnvoll. Und man ändert die Festplatten zwar nicht laufend, aber vielleicht doch mal im Laufe eines Computer-Lebens: Ein zusätzlicher (baugleicher) SCSI- oder RAID-Controller und du musst dir ohne 'udev' Gedanken machen, in welcher Reihenfolge der PCI-Bus "geprobed" wird...
Wenn es mit udev in der initrd nicht stimmt, dann kannst Du nicht mal Dein System mehr booten, es kommt zu einem Kernel-Panic, weil der Device-Knoten fuer die Root-Partition fehlt.
Das ist aber eher ein Problem der initrd statt von 'udev'. Wenn *irgend etwas* in der initrd nicht funktioniert, dann kannst du mit großer Wahrscheinlichkeit nicht mehr booten.
IMO eine voellig unnoetige Sache.
OK, bei initrd oder 'udev' in der initrd stimme ich zu.
Dass es ohne initrd heute schon gar nicht mehr geht, scheint jeder einfach so hinzunehmen...
Doch, noch geht SUSE ohne initrd. Ich habe noch nie eine initrd gebraucht. Gruß Andreas -- XMMS spielt gerade "Pink Floyd - Sheep"... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
Andreas Koenecke wrote:
[...]
Ein Ziel von 'udev' ist z.B., dass unterhalb von "/dev" nur noch die Device-Nodes für tatsächlich vorhandene Geräte aufgeführt werden. Das ist zwar nur Kosmetik, aber IMHO durchaus sinnvoll.
Der Device-Knoten meines Laufwerks mit der Root-Partition wird *immer* kreiert werden muessen und daher immer in /dev vorhanden sein - dazu brauche ich kein udev ;-)
Und man ändert die Festplatten zwar nicht laufend, aber vielleicht doch mal im Laufe eines Computer-Lebens: Ein zusätzlicher (baugleicher) SCSI- oder RAID-Controller und du musst dir ohne 'udev' Gedanken machen, in welcher Reihenfolge der PCI-Bus "geprobed" wird...
Wenn sich meine Festplatten aendern, dann werde ich Linux nicht booten koennen, solange SuSE etwas wie "kernel /boot/vmlinuz root=/dev/hda7" in meine /boot/grub/menu.lst schreibt (Beispiel aus SuSE 10) - es wird naemlich dann schlicht die Root-Partition nicht mehr gefunden werden. Und hd? ist nun einmal eindeutig festgelegt fuer die Master/Slave an den primaeren IDE-Controllern. Aus die Maus, da hilft auch udev nicht. IMO. Oder ich habe es eben nicht ganz verstanden. Aber bei dem Durcheinander mit udev, HAL, subfs und Konsorten waere das auch kein Wunder! Ferner brauche ich auch keine Komplexitaet im Alltag in meinem Linux System, die mir vielleicht einmal in Laufe des Computer-Lebens von Vorteil ist, wenn ich doch tatsaechlich mal etwas umbauen sollte. Das waere doch ein wenig overkill, deswegen auf udev zu bauen ;-)
[...] Das ist aber eher ein Problem der initrd statt von 'udev'. Wenn *irgend etwas* in der initrd nicht funktioniert, dann kannst du mit großer Wahrscheinlichkeit nicht mehr booten.
udev fuer eine Root-Partition ist IMO unnoetig und erhoeht nur die Komplexitaet und damit Anfaelligkeit. Oder warum glaubst Du, dass es immer wieder zu Fehlermeldungen der Art "waiting for device ... to appear" kommt mit anschliessendem Kernel Panic beim Booten? Ich kann es Dir sagen: meistens ist der Grund, dass udev nicht mehr zum Kernel passt (sysfs API-Aenderung?) oder es Probleme mit udev beim Bau der initrd gab.
Doch, noch geht SUSE ohne initrd. Ich habe noch nie eine initrd gebraucht.
Und wenn alle Device-Knoten ueber udev geregelt werden (wohgemerkt ein Programm, das auf der Root-Partition in /sbin liegt, die erst gemountet werden kann, wenn logischerweise das Device verfuegbar ist), wie bitte kannst Du dann ohne initrd einen Device-Knoten fuer Deine Root-Partition erzeugen? Das leuchtet mir gerade nicht ein... Cheers, Th. PS: Nochmal zur Klaerung - ich sehe durchaus einen Sinn in udev, aber eben nicht fuer alles...
Hallo, Am Tue, 31 Jan 2006, Andreas Koenecke schrieb:
* Dienstag, 31. Januar 2006 um 18:40 (+0100) schrieb David Haller:
Am Tue, 31 Jan 2006, Andreas Koenecke schrieb: [..]
A: Right, but Linux is supposed to load a module when a device is discovered not to load a module when it's accessed. [...]"
Genau letzteres will ich aber nicht.
Aber unter "/dev" nur die Device-Nodes für tatsächlich im System vorhandene Geräte statt ca. 7500 ungenutzte Nodes wäre doch eine feine Sache, oder? (SUSE 10.0 macht das aber auch noch nicht...)
# ls /dev | wc -l 1865 Das sind tatsaechlich ein paar mehr als noetig, allerdings habe ich damals hat das 'devs'-rpm installiert und habe es nicht fuer noetig gehalten da gross aufzuraeumen. Andererseits hatte ich auch nie Platzprobleme in / obwohl die Partition teilweise nur 200 MB gross (mit entsprechend wenigen Inodes) war. Inodes hatte ich nie zuwenig: Filesystem Inodes IUsed IFree IUse% Mounted on /dev/hdc5 2562240 360109 2202131 14% / So sah das eigentlich immer aus.
Das ist aber entweder ein antiker oder kastrierter Kernel ;-)
Weder noch.
Na gut: "Ein langjährig bewährter Kernel, der sich in der Maintenance-Phase befindet?";-)
# ls -l /boot/bzImage-`uname -r` [..] 1199328 Apr 23 2004 /boot/bzImage-2.4.25-1l Ich will mir demnaechst aber mal die Changelogs bis 2.4.3x anschauen. Uebrigens: ich das meiste fest im Kernel. # lsmod | wc -l 19 [ohne sg/sr_mod/ide-scsi/scsi_mod] Die meisten Module habe ich deswegen als solche, um ohne rebooten die Optionen aendern zu koennen. Speziell der Soundtreiber ist etwas eigenwillig. [..]
Das ist hier kein Problem (Scanner extern an SCSI, Brenner intern via ide-scsi).
Aber doch nur solange du penibel darauf achtest, in welcher Reihenfolge "ide-scsi" und "g_NCR5380" geladen werden, oder?
Noe ;) below sr_mod ide-scsi below sg ide-scsi g_NCR5380 # ls -l /lib/modules/`uname -r`/kernel/drivers/scsi/ 23140 Apr 18 2004 g_NCR5380.o 13768 Apr 18 2004 ide-scsi.o 14708 Apr 18 2004 ppa.o 135332 Apr 18 2004 scsi_mod.o 17724 Apr 18 2004 sd_mod.o 41444 Apr 18 2004 sg.o 19852 Apr 18 2004 sr_mod.o V.a. im Vergleich zu scsi_mod ist das unnoetige mitladen von ide-scsi oder g_NCR5380 unerheblich. [..]
Ja, da fällt das Problem schnell auf, aber auch SCSI hat grundsätzlich das Problem: Jede zusätzliche Platte muss eine höhere ID als die vorhandenen Platten haben (am gleichen Bus natürlich), sonst wird "neu gemischt"...
Und wie oft kommt das vor? Wer heutzutage SCSI-Festplatten verwendet weiss das mit den IDs wohl, oder? Und wie gesagt, das mit dem root-device per udev finde ich, aehm, fragwuerdig. -dnh --
The Mother of Parliaments has actually done something. Amazing! Actually, _England_ is the Mother of Parliaments, but never mind. Iceland has finally exploded, then? They renamed the Allþing to 'Noþing', and it ceased to exist. Fnord.
Hallo. * Dienstag, 31. Januar 2006 um 22:00 (+0000) schrieb Thomas Hertweck:
Andreas Koenecke wrote:
Ein Ziel von 'udev' ist z.B., dass unterhalb von "/dev" nur noch die Device-Nodes für tatsächlich vorhandene Geräte aufgeführt werden. Das ist zwar nur Kosmetik, aber IMHO durchaus sinnvoll.
Der Device-Knoten meines Laufwerks mit der Root-Partition wird *immer* kreiert werden muessen und daher immer in /dev vorhanden sein - dazu brauche ich kein udev ;-)
OK, die Root-Partition ist natürlich problematisch.
Wenn sich meine Festplatten aendern, dann werde ich Linux nicht booten koennen, solange SuSE etwas wie "kernel /boot/vmlinuz root=/dev/hda7" in meine /boot/grub/menu.lst schreibt (Beispiel aus SuSE 10) - es wird naemlich dann schlicht die Root-Partition nicht mehr gefunden werden. Und hd? ist nun einmal eindeutig festgelegt fuer die Master/Slave an den primaeren IDE-Controllern. Aus die Maus, da hilft auch udev nicht.
Doch. Theoretisch. Mit der richtigen udev-Regel kannst du einen Device-Node "Meine_Root_Partition" anlegen lassen, die du dann dem Kernel als root-Option in der Grub-Zeile übergeben kannst. Allerdings dann wohl nur mit einer initrd. (Nein, ich probiere es nicht aus, soooo viel Freizeit habe ich nicht...;-))
IMO. Oder ich habe es eben nicht ganz verstanden. Aber bei dem Durcheinander mit udev, HAL, subfs und Konsorten waere das auch kein Wunder! Ferner brauche ich auch keine Komplexitaet im Alltag in meinem Linux System, die mir vielleicht einmal in Laufe des Computer-Lebens von Vorteil ist, wenn ich doch tatsaechlich mal etwas umbauen sollte. Das waere doch ein wenig overkill, deswegen auf udev zu bauen ;-)
Du brauchst ja udev sowieso für die USB-Massenspeicher. Wenn es jetzt verschiedene Hot-/Coldplug-Mechanismen für USB, Firewire, SATA, SCSI, Cardbus usw. gibt, wäre das IMO auch nicht weniger komplex.
udev fuer eine Root-Partition ist IMO unnoetig und erhoeht nur die Komplexitaet und damit Anfaelligkeit.
Grundsätzlich stimme ich mit dir in diesem Punkt aber völlig überein.
Oder warum glaubst Du, dass es immer wieder zu Fehlermeldungen der Art "waiting for device ... to appear" kommt mit anschliessendem Kernel Panic beim Booten? Ich kann es Dir sagen: meistens ist der Grund, dass udev nicht mehr zum Kernel passt (sysfs API-Aenderung?) oder es Probleme mit udev beim Bau der initrd gab.
Naja, das liegt dann aber am Kernel- und/oder initrd-Bauer...
Doch, noch geht SUSE ohne initrd. Ich habe noch nie eine initrd gebraucht.
Und wenn alle Device-Knoten ueber udev geregelt werden (wohgemerkt ein Programm, das auf der Root-Partition in /sbin liegt, die erst gemountet werden kann, wenn logischerweise das Device verfuegbar ist), wie bitte kannst Du dann ohne initrd einen Device-Knoten fuer Deine Root-Partition erzeugen? Das leuchtet mir gerade nicht ein...
Ach so, jetzt verstehe ich erst deinen Einwand... Klar, wenn du auch eigene Device-Node-Namen für das Root-Device brauchst bzw. wenn du mit einem leeren /dev/ bootest, dann kommst du wohl nicht um eine initrd herum. Das ist aber bei der SUSE 10.0 (noch) nicht nötig, da es dort ja noch ein prall gefülltes /dev/ gibt. Gruß Andreas -- XMMS spielt gerade "Genesis - After The Ordeal"... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
Hallo. * Dienstag, 31. Januar 2006 um 23:24 (+0100) schrieb David Haller:
Am Tue, 31 Jan 2006, Andreas Koenecke schrieb:
Aber unter "/dev" nur die Device-Nodes für tatsächlich im System vorhandene Geräte statt ca. 7500 ungenutzte Nodes wäre doch eine feine Sache, oder? (SUSE 10.0 macht das aber auch noch nicht...)
# ls /dev | wc -l 1865
Das sind tatsaechlich ein paar mehr als noetig, allerdings habe ich damals hat das 'devs'-rpm installiert und habe es nicht fuer noetig gehalten da gross aufzuraeumen.
Das ist bei dir doch noch übersichtlich, hier (SUSE 10.0): kocom:~ # ls /dev | wc -l 7556 aber das reicht noch nicht: kocom:~ # ls -R /dev | wc -l 14859
Andererseits hatte ich auch nie Platzprobleme in / obwohl die Partition teilweise nur 200 MB gross (mit entsprechend wenigen Inodes) war.
Ich denke, es geht dabei weniger um den Platzbedarf als um die Übersichtlichkeit in /dev/.
Aber doch nur solange du penibel darauf achtest, in welcher Reihenfolge "ide-scsi" und "g_NCR5380" geladen werden, oder?
Noe ;)
below sr_mod ide-scsi below sg ide-scsi g_NCR5380
Na gut, dann doch das Beispiel mit 2. Scanner oder externem SCSI-CD-Brenner am SCSI-Bus... ;-)
[..]
Ja, da fällt das Problem schnell auf, aber auch SCSI hat grundsätzlich das Problem: Jede zusätzliche Platte muss eine höhere ID als die vorhandenen Platten haben (am gleichen Bus natürlich), sonst wird "neu gemischt"...
Und wie oft kommt das vor? Wer heutzutage SCSI-Festplatten verwendet weiss das mit den IDs wohl, oder?
Meinst du? Optimist. ;-) Aber OK, das Beispiel ist vielleicht sehr konstruiert. Hm, wie wäre es mit dem User-tauglichen "Ich habe mir eine weitere Netzwerkkarte (mit gleichem Chipsatz) für meinen DSL-Rechner eingebaut, um dem Rechner meiner Frau den Internetzugang zu ermöglichen und jetzt geht gar kein Internet mehr." (Das kommt aber häufig vor...)
Und wie gesagt, das mit dem root-device per udev finde ich, aehm, fragwuerdig.
Ja, OK, OK... Gruß Andreas -- XMMS spielt gerade "Genesis - Seven Stones"... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
Hallo, Am Wed, 01 Feb 2006, Andreas Koenecke schrieb:
* Dienstag, 31. Januar 2006 um 23:24 (+0100) schrieb David Haller:
Am Tue, 31 Jan 2006, Andreas Koenecke schrieb:
Aber unter "/dev" nur die Device-Nodes für tatsächlich im System vorhandene Geräte statt ca. 7500 ungenutzte Nodes wäre doch eine feine Sache, oder? (SUSE 10.0 macht das aber auch noch nicht...)
# ls /dev | wc -l 1865
Das sind tatsaechlich ein paar mehr als noetig, allerdings habe ich damals hat das 'devs'-rpm installiert und habe es nicht fuer noetig gehalten da gross aufzuraeumen.
Das ist bei dir doch noch übersichtlich, hier (SUSE 10.0):
kocom:~ # ls /dev | wc -l 7556
aber das reicht noch nicht:
kocom:~ # ls -R /dev | wc -l 14859
*UARGS* Das ist uebel! Was zum Geier muellt dir dein /dev/ so zu? # ls -R /dev | wc -l 2347 # find /dev/ -type d -maxdepth 1 /dev/ /dev/inet /dev/ida /dev/pts /dev/rd /dev/shm /dev/input /dev/cpu /dev/ide /dev/net HAEEE??? WO KOMMT DER /dev/ide/ KRAM HER?!???!? Und dann auch nur: # find /dev/ide -not -type d /dev/ide/host0/bus0/target0/lun0/part2 *WAAAHHHHHHHH* # ls -l /dev/ide/host0/bus0/target0/lun0/part2 3, 2 Apr 8 2002 /dev/ide/host0/bus0/target0/lun0/part Uaerks, das stammt wohl noch von nem devfs anschauen. *ARGS* root@slarty[0]:~ (0)# rm /dev/ide/host0/bus0/target0/lun0/part2 root@slarty[0]:~ (0)# rmdir /dev/ide/host0/bus0/target0/lun0 root@slarty[0]:~ (0)# rmdir /dev/ide/host0/bus0/target0 root@slarty[0]:~ (0)# rmdir /dev/ide/host0/bus0/ root@slarty[0]:~ (0)# rmdir /dev/ide/host0/ root@slarty[0]:~ (0)# rmdir /dev/ide/ Ja, mit Absicht kein 'rm -rf /dev/ide/'! Das haette nicht so befriedigt... So! Jetzt geht's mir schon gleich besser! *g* Und schwuppdiwupp bekomme ich beim ls -R | wc -l nur noch 2321. Achso, ein 'find -not -type d' ist wohl sinnvoller als ls -R. # find /dev/ -not -type d | wc -l 2268
Andererseits hatte ich auch nie Platzprobleme in / obwohl die Partition teilweise nur 200 MB gross (mit entsprechend wenigen Inodes) war.
Ich denke, es geht dabei weniger um den Platzbedarf als um die Übersichtlichkeit in /dev/.
Das wurde ja schon durch die Unterverzeichnisse gehandhabt, vgl. /dev/usb/ und /dev/pts/ z.B. und das ganz ohne devfs/udev. In proc geht's doch auch. find /proc/ -not -type d | wc -l 2154 Und ist /proc/ unuebersichtlich? # ls /proc/ . 222 296 33 41 7730 8244 execdomains locks sys .. 223 3 34 413 7912 8293 fb meminfo sysrq-trigger 1 224 300 35 42 7913 84 filesystems misc sysvipc 140 226 301 352 424 7914 90 fs modules tty 146 228 303 354 426 7915 94 ide mounts uptime 167 229 31 36 481 7916 apm interrupts mtrr version 188 230 32 363 484 7917 bus iomem net video 193 248 320 365 5 7918 cmdline ioports partitions 2 268 322 37 6 7919 cpuinfo irq pci 208 273 323 38 7 7934 crypto kcore self 209 285 324 39 7622 7935 devices kmsg slabinfo 220 286 325 4 7632 8 dma ksyms stat 221 295 328 40 7633 8227 driver loadavg swaps Ich glaube nicht. Ok, das mit den PIDs direkt in /proc ist nicht ideal, stoert aber nicht weiter, IMHO. Selbst wenn deutlich mehr Prozesse laufen, denn die reinen "^[0-9]+$" kann man ja leicht ausblenden: # cd /proc; ls -d ./[^0-9]* ./apm ./driver ./iomem ./locks ./partitions ./sysrq-trigger ./bus ./execdomains ./ioports ./meminfo ./pci ./sysvipc ./cmdline ./fb ./irq ./misc ./self ./tty ./cpuinfo ./filesystems ./kcore ./modules ./slabinfo ./uptime ./crypto ./fs ./kmsg ./mounts ./stat ./version ./devices ./ide ./ksyms ./mtrr ./swaps ./video ./dma ./interrupts ./loadavg ./net ./sys Mein ~ sieht da viel(!) schlimmer aus... $ ls -la ~ | wc -l 2166 $ find ~ -type d -maxdepth 1 | wc -l 311
Aber doch nur solange du penibel darauf achtest, in welcher Reihenfolge "ide-scsi" und "g_NCR5380" geladen werden, oder?
Noe ;)
below sr_mod ide-scsi below sg ide-scsi g_NCR5380
Na gut, dann doch das Beispiel mit 2. Scanner oder externem SCSI-CD-Brenner am SCSI-Bus... ;-)
Wird nach SCSI BUS-ID-LUN einsortiert. Odr?[0] Ich hab hier zuwenig SCSI Kram. Und ansonsten hilft ein kl. shell-script mit z.B. 'sgcheck', 'awk' und 'ln -s /dev/sgX /dev/scanner/MODEL'. Ja, ist nicht so elegant wie udev, loest das Problem aber ebenfalls und das _ohne_ Aenderungen am Kernel. Zum Beispiel liesse sich als "post-install" von 'sg' folgendes fuer meinen Brenner ausfuehren: sgcheck | awk '/^\/.*DVDRAM/{print "ln -sf "$1" /dev/BRENNER/"$NF;}' ln -sf /dev/sg0 /dev/BRENNER/GSA-4163B Oder auch schlicht: `sgcheck | awk '/^\/.*DVDRAM/{print "ln -sf "$1" /dev/dvdram";}'` Also z.B. (eine Zeile in der {modules,modprobe}.conf): post-install sg /bin/sh -c "`/usr/sbin/sgcheck | awk '/^\/.*DVDRAM/{print "ln -sf "$1" /dev/dvdram";}'`" Das ist auch nicht schwerer als das, was diese bloede kastrierte Syntax der modprobe.conf fuer 'above' und 'below' erzwingt. Denk mal drueber nach. Und wenn das der User/Distributor machen muss, warum nicht sowas wie obiges? Ebent[tm]. Ich seh bei solch einfachen Loesungen einfach keine Notwendigkeit gross am Kernel rumzuschrauben. Und obiges post-install laesst sich fuer mehrere devices bequem in ein shell-script verpacken. *GRUMPF* Versteh' mich nicht falsch, fuer USB und so Zeugs mag das ja gut sein, aber dafuer reicht sowas wie hotplug/usbdevfs. Da muss man nicht gleich das ganze /dev/ umkrempeln.
[..]
Ja, da fällt das Problem schnell auf, aber auch SCSI hat grundsätzlich das Problem: Jede zusätzliche Platte muss eine höhere ID als die vorhandenen Platten haben (am gleichen Bus natürlich), sonst wird "neu gemischt"...
Und wie oft kommt das vor? Wer heutzutage SCSI-Festplatten verwendet weiss das mit den IDs wohl, oder?
Meinst du? Optimist. ;-)
*hurhur* Justiere mal deinen Zynismusdetektor. Das Fragezeichen oben expandiert zu: " hat es nicht anders verdient. *MUAHAHAHAHA*"
Aber OK, das Beispiel ist vielleicht sehr konstruiert.
Ja.
Hm, wie wäre es mit dem User-tauglichen "Ich habe mir eine weitere Netzwerkkarte (mit gleichem Chipsatz) für meinen DSL-Rechner eingebaut, um dem Rechner meiner Frau den Internetzugang zu ermöglichen und jetzt geht gar kein Internet mehr." (Das kommt aber häufig vor...)
Da hilft die MAC zusammen mit PERSISTENT_NAME in /etc/sysconfig/network/ifcfg-eth-id* -- oder so, IIRC. Und BTW: # ls -l /dev/eth* ls: /dev/eth*: No such file or directory Auch das Beispiel passt also nicht. Da musst du schon in der {modules,modprobe}.conf suchen: # grep eth /etc/modules.conf-`uname -r` alias eth0 8139too *tuedelüüt* -dn'*SCRNR*'h [0] diesmal nix versteckt ;) -- "What, you don't think "insmod emacs" is a good idea?" -- Joe Moore
Hallo, Am Wed, 01 Feb 2006, Andreas Koenecke schrieb:
* Dienstag, 31. Januar 2006 um 22:00 (+0000) schrieb Thomas Hertweck:
Andreas Koenecke wrote:
Ein Ziel von 'udev' ist z.B., dass unterhalb von "/dev" nur noch die Device-Nodes für tatsächlich vorhandene Geräte aufgeführt werden. Das ist zwar nur Kosmetik, aber IMHO durchaus sinnvoll.
Der Device-Knoten meines Laufwerks mit der Root-Partition wird *immer* kreiert werden muessen und daher immer in /dev vorhanden sein - dazu brauche ich kein udev ;-)
OK, die Root-Partition ist natürlich problematisch.
Nicht nur die. Denk an /dev/null. Das gibt auch einen feinen Fehler beim booten... Oder /dev/zero. Oder /dev/u?random.
Wenn sich meine Festplatten aendern, dann werde ich Linux nicht booten koennen, solange SuSE etwas wie "kernel /boot/vmlinuz root=/dev/hda7" in meine /boot/grub/menu.lst schreibt (Beispiel aus SuSE 10) - es wird naemlich dann schlicht die Root-Partition nicht mehr gefunden werden. Und hd? ist nun einmal eindeutig festgelegt fuer die Master/Slave an den primaeren IDE-Controllern. Aus die Maus, da hilft auch udev nicht.
Doch. Theoretisch. ^^^^^^^^^^^ *OINK* *OINK*
Mit der richtigen udev-Regel kannst du einen Device-Node "Meine_Root_Partition" anlegen lassen, die du dann dem Kernel als root-Option in der Grub-Zeile übergeben kannst. Allerdings dann wohl nur mit einer initrd. (Nein, ich probiere es nicht aus, soooo viel Freizeit habe ich nicht...;-))
DAS waere IMHO einfach nur krank. Da kannst du auch gleich Windumm nehmen. Eine initrd halte ich ja sowieso ausser fuer Distri-Kernel fuer sinnfrei (wobei ich Ausnahmen nicht ausschliesse). BTW: wer einen eigenen Kernel fuer eine Kiste so baut, dass eine initrd noetig ist, macht sich's IMO nur schwer, denn das, was in die initrd muss laesst sich auch fest einbauen. Die Schwierigkeit besteht AFAIK/IMHO nur darin, einen Modulnamen aus (bei SuSE, und (nur?) da) /etc/sysconfig/kernel -> INITRD_MODULES auf die passende von 'm' auf 'y' zu aendernde Kerneloption zu finden. Aber da kann man ja auch mal etwas Doku lesen, oder jemanden fragen, der sich damit auskennt, also z.B. hier und bei 'jbd' oder 'ext3' oder 'reiserfs' usw. werden sicher nicht nur Thomson oder ich antworten koennen... Und eben das ist auch nicht schwerer, als bei der Erstellung der initrd alles richtig zu machen...
IMO. Oder ich habe es eben nicht ganz verstanden. Aber bei dem Durcheinander mit udev, HAL, subfs und Konsorten waere das auch kein Wunder! Ferner brauche ich auch keine Komplexitaet im Alltag in meinem Linux System, die mir vielleicht einmal in Laufe des Computer-Lebens von Vorteil ist, wenn ich doch tatsaechlich mal etwas umbauen sollte. Das waere doch ein wenig overkill, deswegen auf udev zu bauen ;-)
Du brauchst ja udev sowieso für die USB-Massenspeicher.
Sicher? Wieso funktionieren die dann auch unter Kernel 2.4.x? Ohne udev und devfs?
Wenn es jetzt verschiedene Hot-/Coldplug-Mechanismen für USB, Firewire, SATA, SCSI, Cardbus usw. gibt, wäre das IMO auch nicht weniger komplex.
Was meinst du, warum ich mich von sowas fernhalte... [..]
Das ist aber bei der SUSE 10.0 (noch) nicht nötig, da es dort ja noch ein prall gefülltes /dev/ gibt.
Trotz udev? Ja, wozu dann udev, wenn /dev/ trotzdem voll ist? Wenn's nur als Ersatz fuer devfs und evtl. Teilen des hotplug-Krams dienen soll, dann bitte. Aber dann bitte auch nur dafuer. Aber doch nicht auch fuer die /-Partition... -dnh PS: nix persoenlich gemeint. -- Ich hasse das, wenn die Realität den Zynismus überholt. -- Ulrich Schwarz
Hallo. * Mittwoch, 01. Februar 2006 um 05:16 (+0100) schrieb David Haller:
Am Wed, 01 Feb 2006, Andreas Koenecke schrieb:
Das ist bei dir doch noch übersichtlich, hier (SUSE 10.0):
kocom:~ # ls /dev | wc -l 7556
aber das reicht noch nicht:
kocom:~ # ls -R /dev | wc -l 14859
*UARGS* Das ist uebel! Was zum Geier muellt dir dein /dev/ so zu?
Allein 20 "hd?" mit je 64 möglichen Partitionen sind schon 1280 Einträge und so geht das munter weiter...
Ich denke, es geht dabei weniger um den Platzbedarf als um die Übersichtlichkeit in /dev/.
Das wurde ja schon durch die Unterverzeichnisse gehandhabt, vgl. /dev/usb/ und /dev/pts/ z.B. und das ganz ohne devfs/udev.
Aber ein konsequenter Einsatz von Unterverzeichnissen in /dev/ müsste von allen Programmen unterstützt werden. Das kann dauern. Und in der "Übergangszeit" müssen dann doch Symlinks von /dev/ nach /dev/Unterverzeichnis/ angelegt werden.
In proc geht's doch auch.
IMHO hat /proc/ aber auch eine andere Historie: /proc/ war schon immer hierarchisch organisiert, /dev/ nicht.
Na gut, dann doch das Beispiel mit 2. Scanner oder externem SCSI-CD-Brenner am SCSI-Bus... ;-)
Wird nach SCSI BUS-ID-LUN einsortiert. Odr?[0] Ich hab hier zuwenig SCSI Kram.
Ja, aber es kommt halt darauf an, welches der externen Geräte eingeschaltet ist und in welcher Reihenfolge die Busse gescannt werden. Ein Grund, warum ich einem Mechanismus wie udev positiv gegenüberstehe, ist, dass ich ein "gebranntes Kind" bin: Ich hatte hier mal ein reines (gewachsenes) SCSI-System: in der letzten Ausbaustufe 2 SCSI-Controller, 4 Festplatten, 2 interne CD-Roms, 1 externe CD-Brenner und 1 Scanner. Ein Problem war, dass ich mir um die Vergabe nicht ausreichend Gedanken gemacht habe (Ja, ich weiss: Selbst schuld!), so dass ich bei jedem Booten darauf achten musste, dass sowohl Scanner als auch externer CD-Brenner eingeschaltet sein mussten, sonst gerieten die "cdrom?"-Symlinks auf scd? und der "scanner"-Symlink auf sg? völlig durcheinander. Ein weiteres Problem waren die Treiber-Module: Beide Controller waren NCR/Symbios Logic-Karten, 1x FAST-SCSI und 1x UW-SCSI. Im Laufe ihres Lebens wurden sie von verschiedenen Treibern bedient: Mal jede Karte ein eigener Treiber, mal ein gemeinsamer Treiber und dann mal wieder 2 eigene Treiber usw. Die Treiber waren fest im Kernel und eine Kernel-Version hat zuerst den FAST-SCSI-Karte und die andere Kernel-Version zuerst den UW-SCSI-Karte erkannt. Oder der gemeinsame Treiber hat je nach Version gerne mal die eine Karte "nach vorne" gebracht, mal die andere... Ging alles, aber so richtig schön war das nicht...
Und ansonsten hilft ein kl. shell-script mit z.B. 'sgcheck', 'awk' und 'ln -s /dev/sgX /dev/scanner/MODEL'. Ja, ist nicht so elegant wie udev, loest das Problem aber ebenfalls und das _ohne_ Aenderungen am Kernel.
Warte mal, was ändert denn udev am Kernel?
Zum Beispiel liesse sich als "post-install" von 'sg' folgendes fuer meinen Brenner ausfuehren:
sgcheck | awk '/^\/.*DVDRAM/{print "ln -sf "$1" /dev/BRENNER/"$NF;}' ln -sf /dev/sg0 /dev/BRENNER/GSA-4163B
Ist das wirklich anschaulicher/weniger komplex/übersichtlicher als eine udev-Regel wie z.B. SUBSYSTEM=="block", ENV{ID_MODEL}=="*DVDRAM*", SYMLINK+="dvdram cdrecorder \ dvdrecorder"
Ich seh bei solch einfachen Loesungen einfach keine Notwendigkeit gross am Kernel rumzuschrauben.
?
Versteh' mich nicht falsch, fuer USB und so Zeugs mag das ja gut sein, aber dafuer reicht sowas wie hotplug/usbdevfs.
Naja, die "alten" hotplug-Agents und -Skripte waren ja noch unübersichtlicher und komlexer als udev. Da ist udev IMO wesentlich übersichtlicher und stringenter.
Da muss man nicht gleich das ganze /dev/ umkrempeln.
IIRC hätte man /dev/ mittelfristig sowieso "umgekrempelt": Entweder devfs oder eben ein Userspace-Lösung wie udev.
*hurhur* Justiere mal deinen Zynismusdetektor. Das Fragezeichen oben expandiert zu: " hat es nicht anders verdient. *MUAHAHAHAHA*"
:-)
Aber OK, das Beispiel ist vielleicht sehr konstruiert.
Ja.
Aber siehe meine "Leidensgeschichte" oben...
Hm, wie wäre es mit dem User-tauglichen "Ich habe mir eine weitere Netzwerkkarte (mit gleichem Chipsatz) für meinen DSL-Rechner eingebaut, um dem Rechner meiner Frau den Internetzugang zu ermöglichen und jetzt geht gar kein Internet mehr." (Das kommt aber häufig vor...)
Da hilft die MAC zusammen mit PERSISTENT_NAME in /etc/sysconfig/network/ifcfg-eth-id* -- oder so, IIRC.
Wobei das aber AFAIK mit udev realisiert wird. Gruß Andreas -- XMMS spielt gerade nichts... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
Hallo. * Mittwoch, 01. Februar 2006 um 05:36 (+0100) schrieb David Haller:
Am Wed, 01 Feb 2006, Andreas Koenecke schrieb:
* Dienstag, 31. Januar 2006 um 22:00 (+0000) schrieb Thomas Hertweck:
Nicht nur die. Denk an /dev/null. Das gibt auch einen feinen Fehler beim booten... Oder /dev/zero. Oder /dev/u?random.
Ja, ja, ja -- Also: Wenn /dev/ leer und/oder auf tempfs, dann geht es wohl nur mit initrd.
Mit der richtigen udev-Regel kannst du einen Device-Node "Meine_Root_Partition" anlegen lassen, die du dann dem Kernel als root-Option in der Grub-Zeile übergeben kannst. Allerdings dann wohl nur mit einer initrd. (Nein, ich probiere es nicht aus, soooo viel Freizeit habe ich nicht...;-))
DAS waere IMHO einfach nur krank. Da kannst du auch gleich Windumm nehmen. Eine initrd halte ich ja sowieso ausser fuer Distri-Kernel fuer sinnfrei (wobei ich Ausnahmen nicht ausschliesse). BTW: wer einen eigenen Kernel fuer eine Kiste so baut, dass eine initrd noetig ist, macht sich's IMO nur schwer, denn das, was in die initrd muss laesst sich auch fest einbauen. Die Schwierigkeit besteht AFAIK/IMHO nur darin, einen Modulnamen aus (bei SuSE, und (nur?) da) /etc/sysconfig/kernel -> INITRD_MODULES auf die passende von 'm' auf 'y' zu aendernde Kerneloption zu finden. Aber da kann man ja auch mal etwas Doku lesen, oder jemanden fragen, der sich damit auskennt, also z.B. hier und bei 'jbd' oder 'ext3' oder 'reiserfs' usw. werden sicher nicht nur Thomson oder ich antworten koennen...
Und eben das ist auch nicht schwerer, als bei der Erstellung der initrd alles richtig zu machen...
Du rennst bei mir (mal wieder) offene Türen ein: Eine meine ersten Handlung nach jeder Installation ist der Bau eines Kernels ohne initrd. Es ging mir bei obigem Beispiel auch nur um die (theoretische!) Möglichkeit von udev...
Du brauchst ja udev sowieso für die USB-Massenspeicher.
Sicher? Wieso funktionieren die dann auch unter Kernel 2.4.x? Ohne udev und devfs?
Funktionieren ja, aber wie ist es denn unter 2.4 mit dem Gerätezugriff auf USB-Massenspeicher? Gibt es persistete Symlinks für die Geräte, so dass ein 'mount /dev/usbstick /media/usbstick' meinen USB-Stick mountet und nicht den CF-Kartenleser, den ich vergessen hatte, vorher abzuziehen? Gruß Andreas -- XMMS spielt gerade nichts... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
participants (5)
-
Andreas Koenecke -
David Haller -
Klaus Hartmann -
Steffen Dettmer -
Thomas Hertweck