• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Migration /etc/fstab zu hald

Als old-schooler habe ich lange gebraucht bevor ich mich mit der Umstellung von statischen Mountpoints (via /etc/fstab) auf dynamische (via hald) angefreundet habe.

Unter openSUSE 10.2 läuft das Ganze auf einem Testrechner fast (siehe http://www.linux-club.de/viewtopic.php?t=76322) so wie ich es will und für ein Desktop System auch wünschenswert ist:
USB Stick/iPod/SD Karte ... rein und los gehts: wird erkannt, gemountet und los gehts.

Also wollte ich das Ganze auch auf einem 2. Rechner entsprechend umstellen: weg mit den /etc/fstab Einträgen, Neustart (da ich mit den Abhängigkeiten der Services udev/dbus/hald nicht ganz durchblicke).
Aber leider keine Reaktion wie auf dem Testrechner auf hotplugging neuer Getäte.

Nur:
- Beide Rechner laufen auf _identischer_ HW (MB, CPU, USB relevante Peripherie) (Deshalb ist das hier kein Posting unter HW)
- Auf beiden Rechnern läuft openSUSE 10.2 (vorher: 10.1, Upgrade)
- Die entsprechenden Daemeons laufen, lsusb erkennt die neue HW, wird aber auf dem 2. Rechner nicht automatisch gemountd

Wo liegt das Problem? Bei KDE? Oder fehlt irgendein Eintrag bei irgendeinem Service bzw. dessen Konfiguration? Ich habe schon alles mögliche verglichen (/etc/sysconfig/*) ohne etwas zu finden.
 
wenn die HW eh identisch ist.. zieh doch ein image von dem rechner, auf dem es funktioniert. und spiel es auf dem anderen ein ;)

ansonsten.. dmesg, lshal usw sind deine freunde.
 
Gimpel schrieb:
wenn die HW eh identisch ist.. zieh doch ein image von dem rechner, auf dem es funktioniert. und spiel es auf dem anderen ein ;)

Nicht praktikabel.
1. dienen die Rechner unterschiedlichen Zwecken und sind entsprechend unterschiedlich konfiguriert
2. möchte ich verstehen welche Komponenten wie konfiguriert werden müssen

Gimpel schrieb:
ansonsten.. dmesg, lshal usw sind deine freunde.

dmesg beim ein- und ausstöpseln eines USB Sticks:
Code:
usb 5-6: new high speed USB device using ehci_hcd and address 6
usb 5-6: new device found, idVendor=04e8, idProduct=1a23
usb 5-6: new device strings: Mfr=1, Product=2, SerialNumber=3
usb 5-6: Product: Mighty Drive
usb 5-6: Manufacturer: Samsung
usb 5-6: SerialNumber: 076B08890BEA
usb 5-6: configuration #1 chosen from 1 choice
scsi4 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 6
usb-storage: waiting for device to settle before scanning
  Vendor: Samsung   Model: Mighty Drive      Rev: PMAP
  Type:   Direct-Access                      ANSI SCSI revision: 00
SCSI device sdf: 4029440 512-byte hdwr sectors (2063 MB)
sdf: Write Protect is off
sdf: Mode Sense: 23 00 00 00
sdf: assuming drive cache: write through
SCSI device sdf: 4029440 512-byte hdwr sectors (2063 MB)
sdf: Write Protect is off
sdf: Mode Sense: 23 00 00 00
sdf: assuming drive cache: write through
 sdf: sdf1
sd 4:0:0:0: Attached scsi removable disk sdf
sd 4:0:0:0: Attached scsi generic sg5 type 0
usb-storage: device scan complete
st: Version 20050830, fixed bufsize 32768, s/g segs 256
usb 5-6: USB disconnect, address 6

lshal ist mir ein Rätsel und hat keine manpage :(
 
Das Problem besteht immer noch.

Der ganze udev Kram läuft erfolgreich durch, der Stick wird erkannt und die entsprechenden Symlinks auf die sysfs Device in /dev angelegt.

Welche Komponente sollte denn jetzt für das mounten des erkannten USB Sticks sorgen?
 
jengelh schrieb:
Normalerweise die Automountteile von KDE/Gnome, oder sonst das unabhängige ivman z.B.

KDE würde genügen.
Ich bekomme auf den 3 Rechnern bei denen es funktioniert dieselben Einstellungen angezeigt wie für die 2 bei denen es nicht funktioniert:

Peripherals -> Storage Media -> Advanced
X Enable HAL Backend
X Enable CD polling

(Die beiden Eintrage sind checked aber auch disabled)

Trotzdem bleiben Änderungen bei Notifications ohne Ergebnis auf den 2 Rechnern...

Fehlt vielleicht ein rpm?
Bzgl. der kde Pakete habe ich keinen Unterschied zwischen den Rechnern, auf denen es läuft und den anderen feststellen können.
ivman ist auch nicht installiert.
 
Ich habe nochmal weiter geforscht und folgendes herausgefunden:

Der Grund liegt wohl daran dass policykitd den Usern nicht das Recht hal-storage-removable-mount zugesteht.

Dies scheint damit zusammenzuhängen das bei den Rechnern auf denen es nicht funktioniert die Gruppenzugehörigkeiten per NIS importiert werden. id zeigt jedoch weitgehend identische Zugehörigkeiten, deshalb vermute ich eher ein Problem mit pam.

Muss man bzgl. PolicyKit was besonders einstellen wenn die Gruppen von NIS geliefert werden?
 
Ich führe den Monolog mal weiter :roll:

Ich habe unter http://www.kde-forum.org/thread.php?threadid=14443 einen Hinweis gefunden, bei laufender KDE Session:
Code:
# /etc/init.d/dbus restart
Stopping Hardware abstraction layer: hald.
Stopping system message bus: dbus.
Starting system message bus: dbus.
Starting Hardware abstraction layer: hald.
$ killall -w kded
$ kded

und siehe da: es geht! Danach werden USB Geräte wie Memsticks oder iPod erkannt und gemountet.

Ist natürlich keine befiredigende Lösung, denn bei der nächsten KDE Sitzung ist wieder dasselbe nötig, und nicht jeder kommt damit zurecht. Scheint also ein Problem der kded Konfig zu sein, aber definitiv keine benutzerspezifische (bei den Rechnern auf denen es läuft geht das für alle Accounts, auf den anderen für alle nicht, einschl. neue User mit leerem ~/.kde).
 
Nach weiteren Versuchen habe ich den Übeltäter gefunden: D-Bus.

Obwohl dieser korrekt startet (keine Fehlermeldung, der Prozess mit PID aus /var/run/dbus/pid existiert, abhängige Services wie hald melden auch kein Problem) bekommt der kded das nicht mit.

Da ein manueller Neustart vor Beginn der KDE Sitzung das Problem beseitigt hat habe ich in /etc/init.d/xdm für "start" eingetragen:
Code:
/etc/init.d/dbus restart
und dieser Workaround funktioniert auf den beiden Problemrechnern.

Warum ist mir weiterhin ein Rätsel, zumal (wie erwähnt) dies bei 2 Rechnern mit identischer HW auf einem nötig ist, auf dem anderen nicht.

Mit beutzerspezifischen Einstellungen hat es definitiv nichts zu tun.
 
Oben