Automounter erkennt falsches fs?!

carbuncle

Rainbow Six
Moin,

hab hier auf meinem Laptop automounter eingerichtet. Das System ist ein 8.1REL, also nix besonderes.

Jetzt zum eigentlichen Problem: Automounter mounted zwar die Platten/Sticks, aber im log kommen seltsame Dinge wie das:

Code:
Oct  2 11:00:36 tobias-ibm kernel: ext2fs: da0s1: wrong magic number 0x11d (expected 0xef53)

Mit diesen Meldungen wird der Lock vollgeschmiert wenn eine Platte dran hängt. Jetzt ist das ganze nicht verwunderlich, denn auf der Platte ist tatsächlich kein ext2 Dateisystem. Ich frag mich warum der Kernel da meckert.

Automounter ist, nachdem eine Platte dran hängt, ständig gelockt. Da kann man sich keine Infos mehr holen.

Hier mal der devfs.rules eintrag:

Code:
add path 'msdosfs/*'	mode 0660 group operator
add path 'ntfs/*'	mode 0660 group operator

und hier automounter.conf:
Code:
#
# This file contains examples for configuring automounter(8). Read the
# automounter.conf(5) manual page to learn all the possibilities.
#
# - Dominic Fandrey <kamikaze@bsdforen.de>
#

###
# Enable geli key polling and auto attaching.
#

#geli=1

###
# The automounter aquires a lock to prevent simultaneous calls of the script
# from interfering with each other. Aquiring the lock can timeout. The default
# is 10 seconds, set this to 0 to skip if the lock cannot be aquired
# immediately.
#

#timeout=10

###
# The automounter uses amd(8) to actually mount the identified mounts.
# By default automounter tunes the cache and wait time of amd aggressively
# towards early unmounting. Increase these values to be less aggressive.
#

#c=4
#w=2

###
# You can change the directory that is populated with mountpoints, e.g. to
# avoid clashes with HAL-based solutions.
#

linkdir="/mediaAMD"

###
# The following line reduces the probability of data corruption when removing
# mounted media by activating synced I/O. Due to the extreme performance
# punishment this is and will not be the default.
#

#mount_options=$mount_options,sync

### 
# Uncomment the following to use the fusefs ntfs implemention of the NTFS file
# system with root:operater 0775 access for directories and 0664 for files,
# synchronous unmount (important to be sure that you can unplug ntfs formatted
# media) and UTF-8 encoded file names.
#

ntfs_options=rw,noatime,mountprog=/usr/local/bin/ntfs-3g,sync_unmount
ntfs_options=$ntfs_options,gid=5,umask=113,dmask=002,locale=en_GB.UTF-8

# The following lines do similar on FreeBSD versions without the mountprog
# option.

#ntfs=ntfs-3g
#ntfs_options=rw,noatime,sync_unmount
#ntfs_options=$ntfs_options,gid=5,umask=113,dmask=002,locale=en_GB.UTF-8

###
# Uncomment the following line to activate a very evil bug workaround for
# fuse based mounts (e.g. ntfs-3g). If more than one fuse file system
# is mounted at a time, this will lead to unexpected results.
#
# With this workaround in place any fuse based file system will only be
# unmounted if ALL fuse based file systems are free for unmounting.
#
# Without this workaround all files in a fuse based file system will be closed
# whenever amd tries to unmount. With the default settings that means
# every 2 seconds.
#

evil_fuse=1

###
# The following options cause msdosfs mounts to be treated as UTF-8 encoded
# and make sure that files do not get the executable bit, while directories
# keep it.
#

msdosfs_options=$mount_options,-L=en_GB.UTF-8,-m660,-M770

###
# Blacklist certain devices or nodes, separated by ','.
# This is useful to except nodes that are already handled elsewhere,
# e.g. in the static amd map or in the fstab(5) file.
#
# These are shell patterns. Don't forget to quote or escape stuff.
#

blacklist_devs="ad*,acd*"
blacklist_nodes="ufs/*"

Hat jemand schonmal sowas gehabt? Wenn das Tool geht, ists schon geil ;) Endlich dieses krüppelige HAL über Bord werfen.
 
Wenn Partitionen nicht gelabelt sind probiert automounter aus was das für Partitionen sind. Die Fehlermeldung ist also nicht weiter problematisch.

Aber bei manchen Partitionen (nicht bei allen) scheint der Kernel nach so einem Versuch der Meinung zu sein, er müsse über devd ein Update des devfs Subsystems propagieren (obwohl sich nichts geändert hat), was zu einer Art race condition führt, denn das wird automounter dann dazu veranlassen nach Änderungen zu forschen und die Sache wieder auslösen.

Versuche mal in der automounter.conf
Code:
probe_types=ufs,msdosfs,iso9660,ntfs
zu setzen. Vielleicht verschweindet dann ja das Problem.

Ich wollte schon länger eine race-Detection einbauen, aber bisher bin ich noch nicht dazu gekommen.
 
Hm jetzt ist zwar die Message weg, aber irgendwie ist da was faul. Er schreibt dauernd was auf die Platte. Ich glaube in irgendein Logfile, aber ich weiss nicht in welches. Die Festplatte ist dauernd am schreiben wenn ein usb stick angesteckt/abgezogen wird.

Hat automounter seine eigene Log Datei?

Edit:
Bei meiner ntfs Platte sagt er Operation timed out, wenn ich in das Verzeichnis ntfs/LABEL gehen will....

Bei msdosfs FS funktioniert es.

Edit:
Wenn er die ganze Zeit auf die interne Platte schreibt und ich automounter list aufrufen will, gibt er "Locked" zurück.
 
Zur Not kannst du das Probing abschalten. detect_probe=0 in die Konfiguration, dann ist hoffentlich Schluss mit dem Ärger.
 
Hm, also wenn ich detect_probe ausschalte, passiert mal garnichts mehr.

Im Moment wird der Lock vollgeschrieben mit:

Code:
Oct  2 17:47:10 tobias kernel: GEOM: da1: partition 1 does not start on a track boundary.
Oct  2 17:47:10 tobias kernel: GEOM: da1: partition 1 does not end on a track boundary.
Oct  2 17:47:10 tobias kernel: GEOM: da1: partition 1 does not start on a track boundary.
Oct  2 17:47:10 tobias kernel: GEOM: da1: partition 1 does not end on a track boundary.
Oct  2 17:47:11 tobias kernel: GEOM: da1: partition 1 does not start on a track boundary.
Oct  2 17:47:11 tobias kernel: GEOM: da1: partition 1 does not end on a track boundary.

Anscheinend liegt da wirklich eine Race Condition vor. Er versucht anscheinend dauernd die Platte neu zu erkennen.

Will ich in ein Verzeichnis gehen in /mediaAMD/msdosfs/LABEL, dann meldet er mir Operation Timed out

Also wenn der Automounter geht ist es ein richtig geiles Tool ;). Brauch ich für 8.1 vielleicht noch irgendein Patch?
 
Hmm, ich kann das so nicht reproduzieren.

Ich kenne das von ein paar vorformatierten USB-Sticks, wenn ich einmal auf die Partition zugreife ist aber eigentlich Ruhe bis ich den Stick abziehe und erneut einstecke.

Kommt das Race auch ohne automounter?
 
Nachdem ich letztens mal wieder automounter ausprobiert habe, hatte ich die gleichen Fehler. War aber zu faul nachzuschauen, woran es liegt und mounte weiterhin von Hand.
 
Bei mir tritt es auf zwei verschiedenen Rechnern auf, beide auf 8.1REL.

Ne das Race kommt nur mit Automounter, also ein mount_ntfs /dev/da0s1 /mnt/MeinNTFS funktioniert tadellos.
 
Das Race war ja auch an da1. Du musst das schon mit dem kaputten Device ausprobieren.

Was ich von dir will ist, dass du die kaputte partition mountest, unmountest und schaust ob die Fehlermeldung mit den track boundaries noch mal gekommen ist.

Wenn nicht, versuch's mal mit etwas zu mounten, das nicht passt.
 
Hi,

ich bin mir nicht sicher ob die Meldung mit den Track Boundaries relevant ist. Sowas hatte ich auch schon vor automounter Zeiten.
 
Vor ein paar Tagen hat jemand im Bugtracker einen patch eingestellt, der das wahre Problem offenbart.

Und zwar folgendes, wenn eine Partition z.B. da0s1 heißt wird zuerst auf da0 zugegriffen, wobei da0s1 kurzfristig zerstört wird. Das erzeugt destroy und create Ereignisse. Das Race ist also ganz klar meine Schuld. Ich denke der Fix geht heute noch raus.
 
Den devd solltest du nicht automatisch bei der Portinstallation von automounter neu starten. Das wird dir so niemand committen.
Lass das lieber den Benutzer selber machen und sag es ihm mit einer pkg-message.
 
Ich kann Erfolg vermelden. Der devd wird bei mir komischerweise nicht richtig neu gestartet, aber der Patch funktioniert einwandfrei. Danke dafür! Ich hoffe der Patch wird schnellstmöglich in den neuen Ports Tree aufgenommen.
 
@laemodost
Wenn das nicht in Ordnung ist sollen die das sagen.

@carbuncle
Wie hat sich das denn geäußert? /etc/rc.d/devd restart geht leider sehr oft schief, aber nacheinander stop und start aufrufen hat bei mir bisher immer funktioniert.
 
Ich kann dir leider nicht genau sagen was da schief lief. Er wollte das nicht neu starten weil PID xyz noch "running" war.

Kann aber sein dass es an meiner Freebsd Installation liegt. Das ist nämlich ein 8.1er Kenrnel mit einem 8.0 Userland. Make installworld funktioniert leider nicht mehr
 
Back
Top