Hallo Gemeinde.
Nun brauche ich doch mal wieder eure Hilfe.
Ich habe mir die Multifunktionskiste MFC-215C von Brother gekauft. Ich dachte, mit den Treibern und den Installationshinweisen auf [1] wäre das Installieren auch für mich ein Kinderspiel. Leider bin ich wieder einmal eines besseren belehrt worden. Aber nun zum Problem:
Ich habe gemäß den Anweisungen des Brother Solutions Center die fstab verändert (siehe Zeile 3). Die sieht jetzt so aus:
—snip—
proc /proc proc defaults 0 0
sysfs /sys sysfs noauto 0 0
usbfs /proc/bus/usb usbfs auto,devmode=0666 0 0
devpts /dev/pts devpts mode=0620,gid=5 0 0
/dev/hda3 /data1 auto defaults 0 0
/dev/hdb3 /data2 auto noauto,user 0 0
/dev/hdb4 /data3 auto defaults 0 0
/dev/dvdram /media/dvdram subfs noauto,fs=cdfss,ro,procuid,nosuid,nodev,exec,iocharset=utf8 0 0
—snap—
Nach jedem Neustart des Systems kann sane den Scanner nicht ansprechen. Die mtab sieht dann so aus. Beispiel-1: (siehe letzte Zeile)
—snip—
/dev/hdb1 / reiserfs rw,acl,user_xattr 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
tmpfs /dev/shm tmpfs rw 0 0
devpts /dev/pts devpts rw,mode=0620,gid=5 0 0
/dev/hda3 /data1 reiserfs rw 0 0
/dev/hdb4 /data3 reiserfs rw 0 0
usbfs /proc/bus/usb usbfs rw 0 0
Nachdem ich “umount /proc/bus/usb” und danach direkt “mount /proc/bus/usb” eingebe, kann ich den Scanner sofort ansprechen und benutzen. Die mtab sieht dann so aus. Beispiel-2:
/dev/hdb1 / reiserfs rw,acl,user_xattr 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
tmpfs /dev/shm tmpfs rw 0 0
devpts /dev/pts devpts rw,mode=0620,gid=5 0 0
/dev/hda3 /data1 reiserfs rw 0 0
/dev/hdb4 /data3 reiserfs rw 0 0
usbfs /proc/bus/usb usbfs rw,devmode=0666 0 0
Was muß ich tun, damit sofort nach dem Neustart des Rechners der mountpoint für usbfs so aussieht, wie im Beispiel-2 und damit der Scanner direkt nutzbar ist???
Könnt ihr mir hier helfen?
Ach so, ich benutze Suse 10.0 OSS von EasyLinux.
Danke schon mal.
Thomy
[1] [1] http://solutions.brother.com/linux/sol/printer/linux/sane_drivers.html
Hi,
das sieht mir eventuell danach aus, als würde das USB-Geraffel
auf Deiner Kiste via Kernelmodule abgewickelt.
Als Test ginge Folgendes:
Liste booten
lsmod | sort > lsmodules.1.txt
umount /proc/bus/usb
mount /proc/bus/usb
lsmod | sort > lsmodules.2.txt
diff -uprN lsmodules.1.txt lsmodules.2.txt
Wenn es einen Unterschied gibt, wird er hierdurch angezeigt werden.
Sollte tatsächlich ein Module nachgeladen werden, würde ich dieses
durch Neukompilieren des Kernels in den Kernel einbinden, anstelle es als
Module auszulagern.
Das ist zwar keine “HighTec”-Lösung aber bei den heutigen Hauptspeichergrößen
von eine halben bis einem Gigabyte ist dies eine prakmatische und meiner
Meinung nach akzeptable Möglichkeit.
By the Way:
Deiner fstab fehlt eine Zeile:
shm /dev/shm tmpfs nodev,nosuid,noexec 0 0
Dies wird von den neueren glibc-Versionen benötigt.
Und nochetwas: Automounter — speziell das subfs-Zeugs — hat bei mir
schon beliebig Ärger gemacht.
Ich bin da etwas altmodisch: Ich schreibe mir für jedes tägliche mount/umount
ein kleines Script und erlaube mir entweder über /etc/sudoers oder über
entsprechende fstab-Einträge diese Aktion. Dadurch habe ich “die volle
Kontrolle” (nein, ich habe kein Handy… ;O) und bin zudem schneller,
weil ich nicht minutenweise auf den Automounter warten muss, bis der
beispielsweise gemerkt hat, dass ein USB-Stick steckt.
Zum Schluß: Beim DVD/CD-RW-Brennen, wo eine schon beschriebene (und daher
mountbare) DVD/CDRW überschrieben werden soll, funkt Dir der Automounter
dazwischen, da er brav die DVD/CD-RW mounted und das Brennprogramm an-
schließend die Scheibe nicht brennen kann, weil sie gemountet ist….
Viel Erfolg!
mcc
Hi Meino.
Ich habe die Zeile shm…. in die fstab eingefügt und deinen Test ausprobiert. Der diff… Befehl hat keine Änderung angezeigt.
Die komplette fstab sieht nun so aus:
/dev/hdb1 / reiserfs acl,user_xattr 1 1
/dev/hdb2 swap swap defaults 0 0
/dev/hda3 /data1 auto defaults 0 0
/dev/hdb3 /data2 auto noauto,user 0 0
/dev/hdb4 /data3 auto defaults 0 0
/dev/dvdram /media/dvdram subfs noauto,fs=cdfss,ro,procuid,nosuid,nodev,exec,iocharset=utf8 0 0
/dev/hda1 /Windows vfat noauto,user,umask=0 0 0
shm /dev/shm tmpfs nodev,nosuid,noexec 0 0
proc /proc proc defaults 0 0
sysfs /sys sysfs noauto 0 0
devpts /dev/pts devpts mode=0620,gid=5 0 0
usbfs /proc/bus/usb usbfs auto,devmode=0666 0 0
Nach dem Systemstart habe ich in der Konsole folgendes gemacht:
linux:/home/Familie # mount
/dev/hdb1 on / type reiserfs (rw,acl,user_xattr)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
tmpfs on /dev/shm type tmpfs (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
/dev/hda3 on /data1 type reiserfs (rw)
/dev/hdb4 on /data3 type reiserfs (rw)
shm on /dev/shm type tmpfs (rw,noexec,nosuid,nodev)
usbfs on /proc/bus/usb type usbfs (rw)
linux:/home/Familie # umount /proc/bus/usb
linux:/home/Familie # mount /proc/bus/usb
linux:/home/Familie # mount
/dev/hdb1 on / type reiserfs (rw,acl,user_xattr)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
tmpfs on /dev/shm type tmpfs (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
/dev/hda3 on /data1 type reiserfs (rw)
/dev/hdb4 on /data3 type reiserfs (rw)
shm on /dev/shm type tmpfs (rw,noexec,nosuid,nodev)
usbfs on /proc/bus/usb type usbfs (rw,devmode=0666)
linux:/home/Familie #
Es fällt auf, daß die richtigen Einstellungen für usbfs erst nach dem manuellen umount und mount aus der fstab gelesen werden. Mein Eintrag
“usbfs /proc/bus/usb usbfs auto,devmode=0666 0 0” wird beim booten immer noch ignoriert.
Ich habe mal die /var/log/boot.msg zeigt durchgeschaut und da fällt mir folgender Teil auf, von dem ich glaube, das müßte aus der fstab stammen.
—————–snip——————-
boot logging started on /dev/tty1(/dev/console) at Fri Apr 7 00:35:23 2006
Mounting shared memory FS on /dev/shmdone
Configuring serial ports…
/dev/ttyS0 at 0x03f8 (irq = 4) is a 16550A
Configured serial ports
doneActivating swap-devices in /etc/fstab…
doneActivating device mapper…
Creating /dev/mapper/control character device with major:10 minor:63.
done
Checking file systems…
fsck 1.38 (30-Jun-2005)
doneSetting up kernel module dependencies (if required)done
Mounting local file systems…
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
tmpfs on /dev/shm type tmpfs (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
mount: you didn’t specify a filesystem type for /dev/hda3
I will try type reiserfs
/dev/hda3 on /data1 type reiserfs (rw)
mount: you didn’t specify a filesystem type for /dev/hdb4
I will try type reiserfs
/dev/hdb4 on /data3 type reiserfs (rw)
shm on /dev/shm type tmpfs (rw,noexec,nosuid,nodev)
mount: mount point /proc/bus/usb does not exist
failedSetting up the CMOS clockdone
Setting up hostname ‘linux’done
Setting up loopback interface done
—————–snap——————-
Auffallend ist, daß hier mein fstab-Eintrag “usbfs /proc/bus/usb usbfs auto,devmode=0666” gar nicht auftaucht. Wie kann das sein? Und die Zeile mit “mount: mount point /proc/bus/usb does not exist” macht mich auch stutzig, denn das Verzeichnis ist sehr wohl vorhanden. Nämlich in hdb1.
Irgendwie verstehe ich das ganze nicht.
Gruß
Thomy
Hi,
ändere mal Deine usb-Zeile in fstab in Folgende um:
none /proc/bus/usb usbfs defaults 0 0
Geht es dann ?
Viel Erfolg !
mcc
Hallo Meino.
Deinen Vorschlag habe ich ausprobiert. Leider ohne Erfolg. Linux mountet beim Systemstart auch dann noch so: “usbfs /proc/bus/usb usbfs rw 0 0”. Egal was ich in der fstab vorgebe. Irgendwie werden jegliche anderen Optionen für usbfs in der fstab ignoriert.
Wenn ich als root manuell mit “umount /proc/bus/usb” unmounte und anschließend wieder mit “mount /proc/bus/usb” mounte, klappt es komischerweise. Dann hat er die Optionen akzeptiert. Dann findet Sane auch den Scanner, der daran hängt. Das zeigt mir, daß die usbfs-Zeile an sich keinen Fehler aufweist.
Ich suche mir ‘nen Wolf, aber finde noch nicht einmal einen Lösungsansatz für das Problem.
Aber mal ne andere Frage dazu: Normalerweise kann Normaluser ja nicht unmounten und mounten. Kann ich das evtl. ändern? Dann würde ich nämlich der Einrichtungsdatei auf dem Desktop einfach diese umount- u. mount-Befehlskette vor dem xsane-Aufruf mitgeben. Wenn das geht, wäre das für mich eine prakmatische Lösung, mit der ich leben könnte. Auch wenn damit der eigentliche Fehler nicht ausgemerzt würde.
Gruß
Thomy
Hi Thomy,
…Dein usbfs-Problem ist “faszinierend”… :-/
Bei mir klappt das nämlich genua auf die beschriebene Weise.
Ich mounte erst “alles mögliche” und dann diese hier in genau
dieser Reihenfolge:
shm /dev/shm tmpfs nodev,nosuid,noexec 0 0
proc /proc proc defaults 0 0
sysfs /sys sysfs auto 0 0
devpts /dev/pts devpts gid=4,mode=0622 0 0
none /proc/bus/usb usbfs defaults 0 0
Nur um es gesagt zu haben:
Du bist Dir sicher, dass in den Bootscripten nicht ein Stück Code hängt,
der usbfs wieder /aushängt/ ???
Weiterhin wäre noch denkbar, dass ein dem allgemeinen mount ein Script läuft,
welches eine Vorausbedingung schafft, welches das Mounten des usbfs erst
ermöglicht.
D.h. Das relativ früh ablaufende “mount -a” findet kein /proc/bus/usb
vor, da usb wegen noch nicht geladener Module noch gar nicht im
Kernelspace bekannt ist. Dann wird udev (z.B.) gestartet und die
Module (z.B. für usb) geladen. Aber zu diesem Zeitpunkt ist
das Mount schon gescheitert.
Mach doch mal nach einem Boot als root ein “mount -a” (alles aus fstab
mounten, was noch nichtgemountet ist).
Wenn dann der usb-mount existiert, liegt es evebtuell an den geschilderten
Zusammenhängen. Rettung wäre dann, die betroffenen Module in den
Kernel zu verlagern, bzw. ein “late binding” zu versuchen :O), d.h.
/proc/bus/usb wird in einem Bootscript, was spät genug abläuft,
“nachgemountet”. Dazu kann man dann auch ein eigenes Script basteln, nach
/etc/init.d (o.ä.) kopieren und in die Runlevel einhängen. Ist vielleicht
die etwas saubere Weise.
Falls das nicht funzt:
In der mount-manpage steht Folgendes:
(iii) Normally, only the superuser can mount file systems. However,
when fstab contains the user option on a line, anybody can mount the
corresponding system.
Thus, given a line
/dev/cdrom /cd iso9660 ro,user,noauto,unhide
any user can mount the iso9660 file system found on his CDROM using the
command
mount /dev/cdrom
or
mount /cd
AHABER: Da gerade die usbfs-Zeile Deiner fstab ja “ignoriert” zu werden
scheint, weiss ich nicht, ob dieser Ansatz fruchtet.
Eine andere Möglichkeit ist über sudo bzw /etc/sudoers Dir dieses
Kommando zu erlauben, ohne dass ein root-Passwort abgefragt wird.
Damit bräuchtest Du lediglich allen u/mount-Kommandos in einem
Script ein “sudo” voranzuhängen.
Musst Dir mal die sudo/sudoers-manpage ansehen, wie das genau geht.
Viel Erfolg!
mcc
Hi Meino,
ich habe im Grunde viel zu wenig Ahnung von Linux, um genau zu verstehen, was du beschreibst. Ich werde aber alles nun ausdrucken und Wort für Wort erarbeiten. ;-)
Gestern Nacht habe ich mittels Installations-DVD von Suse 10.0 OSS eine Reparatur laufen lassen. Dabei teilte mir Linux bei der Prüfung der fstab mit, daß genau diese besagte Zeile “ungültig” ist. Ich erahne förmlich, daß das an den Parametern “auto,devmode=0666” liegt. Denn genau diese werden ja ignoriert.
Aber wie schon gesagt, ich werde heute akriebisch der Sache auf den Grund gehen. Mit deinen Hinweisen, die ich hier bekommen habe.
Erst einmal vielen Dank. Ich werde heute Abend/Nacht berichten, wie der aktuelle Stand ist.
Bis später
Thomy
Hi Meino.
also, ich habe nun ein paar Tage gebraucht, aber Ich weiß nach langem Experimentieren nun, daß der Fehler vom resmgr Version 0.9.8_SVNR57-3 herkommt. Da ich immer brav über Susewatcher die Sicherheitspatches einspiele, war das irgendwann mit dabei. Der Fehler fiel mir aber nicht auf, da ich ja einen ganz anderen Scanner hatte. Mit der Vorgängerversion …57-2 läuft der Scanner einwandfrei. Nun habe aber zu wenig Ahnung um den Fehler weiter einzugrenzen. Jedenfalls bleibe ich vorerst bei der Version …57-2.
In der Patch-Beschreibung steht folgendes:
“Dieses Update behebt folgendes Sicherheitsproblem: – resmgrd erlaubte Zugriff auf alle USB Geräte wenn Zugriff auf ein Gerät via “usb:,” Notation erlaubt war. – Klassenspezifische Ausnahmeregeln wurden nicht auf USB Geräte angewandt, die ihre Klassen-ID auf Interface-Ebene setzen. Dieses Update behebt weiterhin folgende nicht sicherheitsrelevante Probleme: – ein Filedeskriptor-Leak – – resmgrd erzeugte oft unnötig ACL Fehlermeldungen – das initscript löschte /var/run/resmgr/classes auch wenn resmgrd schon lief.
Kannst Du damit etwas anfangen? Ich werde das mal an Brother senden. Mal sehen, was die dazu sagen.
Gruß
Thomy