options MSDOSFS_LARGE in Free-BSD 6.3? Ersatz?

pit234a

pit234a

Well-Known Member
Bisher brachte ich meine externe 300GB FAT Platte durch diese Option im Kernel dazu, auch von HAL in KDE sauber eingebunden werden zu können.
Nun scheint es diese Option nicht mehr zu geben und ich bekomme in /var/log/messages erklärt, die Platte sei zu groß und ich soll die mount Option -o large benutzen.

Aber, wie sage ich dem HAL dieses, so daß er das dauerhaft behält?
 
Das geht relativ einfach, indem Du für den HAL eine policy-Datei anlegst.

z.B. habe ich /usr/share/hal/fdi/policy/20thirdparty/90-storage-raid.fdi

Code: 
<deviceinfo version="0.2">
  <device>
    <match key="block.is_volume" bool="true">
      <match key="volume.fsusage" string="filesystem">
<!-- Raid Platte -->
        <match key="volume.uuid" string="9a6b6997-3544-4fe7-9969-c831c2ea1bc6">
          <merge key="org.freedesktop.Hal.Device.Volume.method_execpaths" type="strlist">hal-storage-mount</merge>
          <append key="org.freedesktop.Hal.Device.Volume.method_execpaths" type="strlist">hal-raid-unmount</append>
        </match>
      </match>
    </match>
  </device>
</deviceinfo>

Damit werden die mount/umount Kommandos für mein Software-RAID ersetzt.

Unter http://freedesktop.org/wiki/Software/hal findest Du ein Manual, in dem die möglichen Optionen erläutert sind.

So long...

Der Indy
 
Code: 
udi = '/org/freedesktop/Hal/devices/storage_serial__'
  block.storage_device = '/org/freedesktop/Hal/devices/storage_serial__'  (string)
  info.udi = '/org/freedesktop/Hal/devices/storage_serial__'  (string)
  block.is_volume = false  (bool)
  storage.serial = ''  (string)
  block.freebsd.cam_path = '6,0,0'  (string)
  storage.lun = 0  (0x0)  (int)
  storage.firmware_revision = '08.0'  (string)
  info.product = '00JB-00KFA0'  (string)
  info.vendor = 'WDC WD30'  (string)
  storage.vendor = 'WDC WD30'  (string)
  storage.model = '00JB-00KFA0'  (string)
  storage.physical_device = '/org/freedesktop/Hal/devices/usb_device_4cf_8818_100_if0'  (string)
  storage.no_partitions_hint = false  (bool)
  storage.automount_enabled_hint = true  (bool)
  storage.media_check_enabled = false  (bool)
  storage.hotpluggable = true  (bool)
  storage.requires_eject = false  (bool)
  storage.removable = false  (bool)
  storage.drive_type = 'disk'  (string)
  storage.bus = 'usb'  (string)
  block.minor = 123  (0x7b)  (int)
  block.major = 0  (0x0)  (int)
  block.device = '/dev/da0'  (string)
  info.category = 'storage'  (string)
  info.bus = 'block'  (string)
  info.capabilities = {'block', 'storage'} (string list)
  freebsd.unit = 0  (0x0)  (int)
  freebsd.driver = 'da'  (string)
  info.parent = '/org/freedesktop/Hal/devices/usb_device_4cf_8818_100_if0_scsi_host_scsi_device_lun0'  (string)

udi = '/org/freedesktop/Hal/devices/volume_part1_size_300066407424'
  volume.mount.valid_options = {'ro', 'noexec', 'noatime', 'longnames', 'shortnames', 'nowin95', '-u=', '-g=', '-m=', '-M=', '-L=', '-D='} (string list)
  org.freedesktop.Hal.Device.Volume.method_execpaths = {'hal-storage-mount', 'hal-system-storage-unmount', 'hal-system-storage-eject'} (string list)
  org.freedesktop.Hal.Device.Volume.method_signatures = {'ssas', 'as', 'as'} (string list)
  org.freedesktop.Hal.Device.Volume.method_names = {'Mount', 'Unmount', 'Eject'} (string list)
  info.interfaces = {'org.freedesktop.Hal.Device.Volume'} (string list)
  block.storage_device = '/org/freedesktop/Hal/devices/storage_serial__'  (string)
  info.product = 'Volume (vfat)'  (string)
  info.udi = '/org/freedesktop/Hal/devices/volume_part1_size_300066407424'  (string)
  block.is_volume = true  (bool)
  volume.mount_point = ''  (string)
  volume.is_mounted_read_only = false  (bool)
  volume.is_mounted = false  (bool)
  volume.num_blocks = 586067202  (0x22eead02)  (uint64)
  volume.size = 300066407424  (0x45dd5a0400)  (uint64)
  volume.block_size = 512  (0x200)  (uint64)
  volume.uuid = ''  (string)
  volume.label = ''  (string)
  volume.fsversion = 'FAT32'  (string)
  volume.fstype = 'vfat'  (string)
  volume.fsusage = 'filesystem'  (string)
  volume.ignore = false  (bool)
  volume.is_partition = true  (bool)
  volume.is_disc = false  (bool)
  volume.partition.start = 32256  (0x7e00)  (uint64)
  volume.partition.media_size = 300066407424  (0x45dd5a0400)  (uint64)
  volume.partition.type = '0x83'  (string)
  volume.partition.scheme = 'mbr'  (string)
  volume.partition.number = 1  (0x1)  (int)
  block.minor = 124  (0x7c)  (int)
  block.major = 0  (0x0)  (int)
  block.device = '/dev/da0s1'  (string)
  info.category = 'volume'  (string)
  info.bus = 'block'  (string)
  info.capabilities = {'block', 'volume'} (string list)
  info.parent = '/org/freedesktop/Hal/devices/storage_serial__'  (string)
ich glaube, dazu brauche ich noch ein wenig Hilfe.
Was ich wahrscheinlich verstanden habe, das ist, wie ich genau diese Platte nun trotzdem einbinden könnte (wenn die Option -o large es überhaupt tut, getestet habe ich das nämlich noch nicht). Was ich aber brauche, das ist die Funktion, daß beliebige FAT32 formatierte Platten eingebunden werden, also auch, wenn diese (oder Partitionen) größer als die maximalen 128GB sind.
Dazu gab es diesen "Workaround" durch die Kernel-Variable.

Wie ich dies nun in die HAL Konfiguration mit einbringe, das sehe ich noch nicht. Da müßte ich dann ja irgendeine if, then einbauen? Oder könnte in einer Konfiguration die Option -o large als feste Option eingebaut werden?

Ich beziehe mich da auf diesen Teil:
Code: 
udi = '/org/freedesktop/Hal/devices/volume_part1_size_300066407424'
  volume.mount.valid_options = {'ro', 'noexec', 'noatime', 'longnames', 'shortnames', 'nowin95', '-u=', '-g=', '-m=', '-M=', '-L=', '-D='} (string list)
  org.freedesktop.Hal.Device.Volume.method_execpaths = {'hal-storage-mount', 'hal-system-storage-unmount', 'hal-system-storage-eject'} (string list)
und behaupte nicht, den zu verstehen, aber da scheinen mir verschiedene Mount-Optionen gelistet zu sein (wobei ich das ro nicht verstehen kann, es wird im allgemeinen doch rw eingebunden). Wenn da irgendwie der Wert für das volume.mount.valid_options verändert und die -o large dazugenommen werden könnte, wäre das nicht, was ich da brauche?
 
Was Du brauchst ist ein match auf volume.fstype = 'vfat'.
Anschließend _ersetzt_ Du dafür den mount-Befehl durch ein eigenes Shell-Script.
Da drin kannst Du mount ausführen, wie Du lustig bist.

<deviceinfo version="0.2">
<device>
<match key="block.is_volume" bool="true">
<match key="volume.fstype" string="vfat">
<!-- Raid Platte -->
<merge key="org.freedesktop.Hal.Device.Volume.method_execpaths" type="strlist">mein-hal-fat-mount-script</merge>
<append key="org.freedesktop.Hal.Device.Volume.method_execpaths" type="strlist">hal-storage-unmount</append>
</match>
</match>
</device>
</deviceinfo>

Ein Beispiel Shell-Script für umount unter Linux kann ich liefern:

Code: 
#!/bin/sh

LOGGER=/bin/logger
LOGGEROPTIONS=-"p local0.notice"

function log()
{
        message=$1
        ${LOGGER} ${LOGGEROPTIONS} ${message}
}

log "Unmount ${HAL_PROP_VOLUME_MOUNT_POINT}"

/bin/umount ${HAL_PROP_VOLUME_MOUNT_POINT}

log "Shutdown ${HAL_PROP_BLOCK_DEVICE}"

/sbin/mdadm -S ${HAL_PROP_BLOCK_DEVICE}

Wie man sieht, kann man in den Scripten machen, was man will.
HAL stellt die benötigten Informationen als Umgebungsvariablen zur Verfügung.

Gruss...

Der Indy
 
Danke dir für diese Hilfe.
Ich habe mich inzwischen ein wenig weiter belesen und verstehe vermutlich schon was. Auch dein Vorschlag leuchtet mir schon ein. Vermutlich muß ich dann im vorgeschlagenen script die dmesg Ausgabe auswerten und sehen, ob ich large verwenden muß und dieses dann zurückgeben.
Im Laufe der Woche, will ich mir das mal ansehen, fürchte aber, daß ich damit doch etwas überfordert sein werde. Probieren will ich es, denn das Problem taucht bei dem PC eines Bekannten auf, dem ich noch nicht mit manuellem Mount kommen kann.
Es wundert mich, daß scheinbar dieses Problem unbehandelt bleibt. Also, daß ich keine Beiträge im WWW finde. Das müßte doch schon aufgefallen sein und meist gibt es dann ja auch Lösungen von Leuten, die das auch können. Oder zeigt das nun, daß nur ich das Problem bin? Manchmal denke ich das schon.
Wir werden sehen.
 
pit234a schrieb:
ich bekomme in /var/log/messages erklärt, die Platte sei zu groß und ich soll die mount Option -o large benutzen.
Zum Vergrößern anklicken....
Warum kann mount das nicht gleich selbst machen, wenn es schon so schlau daherquatscht? Das hat ungefähr die Qualität eines mount_cd9660: »Kann nicht rw mounten, weil ISO9660 iss nicht beschreibbar, bitte nochmal mit -o ro aufrufen.«
 
jtsn schrieb:
Warum kann mount das nicht gleich selbst machen, wenn es schon so schlau daherquatscht? Das hat ungefähr die Qualität eines mount_cd9660: »Kann nicht rw mounten, weil ISO9660 iss nicht beschreibbar, bitte nochmal mit -o ro aufrufen.«
Zum Vergrößern anklicken....

Weil das -o large Feature noch experimentell ist.
msdosfs_vfsops.c schrieb:
/*
* Experimental support for large MS-DOS filesystems.
* WARNING: This uses at least 32 bytes of kernel memory (which is not
* reclaimed until the FS is unmounted) for each file on disk to map
* between the 32-bit inode numbers used by VFS and the 64-bit
* pseudo-inode numbers used internally by msdosfs. This is only
* safe to use in certain controlled situations (e.g. read-only FS
* with less than 1 million files).
* Since the mappings do not persist across unmounts (or reboots), these
* filesystems are not suitable for exporting through NFS, or any other
* application that requires fixed inode numbers.
*/
Zum Vergrößern anklicken....
 
jtsn schrieb:
Warum kann mount das nicht gleich selbst machen, wenn es schon so schlau daherquatscht? Das hat ungefähr die Qualität eines mount_cd9660: »Kann nicht rw mounten, weil ISO9660 iss nicht beschreibbar, bitte nochmal mit -o ro aufrufen.«
Zum Vergrößern anklicken....

Probieren will ich es, denn das Problem taucht bei dem PC eines Bekannten auf, dem ich noch nicht mit manuellem Mount kommen kann.
Zum Vergrößern anklicken....
Dieser PC gehört einem Bekannten, der weit weit weg zieht und dorthin gerne einen PC mit zuverlässigem Betriebssystem mitnehmen möchte. Er fragte mich, ob ich ihm dabei behilflich sein könnte und ich wollte das, allerdings nicht mit einer der verklebten GNU/Linux Versionen, die mir keinen Spaß bei der Installation bringen und wo diese Dinge alle wie von selbst gehen. Das Problem hatte ich auch in vorhergehenden BSD-Versionen angetroffen und mit der experimentellen Kernel Option lösen können, die sehr zuverlässig funktionierte und den HALD bediente. Nun bin ich überfordert. Deshalb frage ich.
Daß du dies als schlaues Dahergequatsche empfindest, trift mich etwas. Besser kann ich es halt nicht und du solltest mir das nicht vorwerfen. Im Übrigen gebe ich zwar sehr gerne und bereitwillig Auskunft, warum ich etwas bestimmtes will, doch diese Auskünfte sollen in der Regel helfen, die Probleme zu lösen. Dazu hilft dein Beitrag allerdings in keinster Weise.

edit: ich hatte deinen Satz falsch gelesen, du sagtest ja gar nicht, daß ich so daherquatsche, sondern mount. Tschuldigung.
 
Zuletzt bearbeitet:
daran bin ich gerade am spielen.
Ich glaube, daß sich das Ausgangsproblem eigentlich einfach lösen könnte, wenn nämlich die Datei /usr/local/share/hal/fdi/policy/10osvendor/20-storage-methods.fdi geändert wird. Ich weiß, dies ist eine mitgelieferte und keine 3rd-party Datei, doch obwohl ich da nicht viel Ahnung von alledem habe, scheint mir die Konstruktion doch deutlich zu sein:
Code: 
      <!-- allow these mount options for vfat -->
      <match key="volume.fstype" string="vfat">
	<match key="/org/freedesktop/Hal/devices/computer:system.kernel.name" string="Linux">
	  <append key="volume.mount.valid_options" type="strlist">utf8</append>
	  <append key="volume.mount.valid_options" type="strlist">shortname=</append>
	  <append key="volume.mount.valid_options" type="strlist">codepage=</append>
	  <append key="volume.mount.valid_options" type="strlist">iocharset=</append>
	  <append key="volume.mount.valid_options" type="strlist">umask=</append>
	  <append key="volume.mount.valid_options" type="strlist">dmask=</append>
	  <append key="volume.mount.valid_options" type="strlist">fmask=</append>
	  <append key="volume.mount.valid_options" type="strlist">uid=</append>
	</match>
	<match key="/org/freedesktop/Hal/devices/computer:system.kernel.name" string="FreeBSD">
	  <append key="volume.mount.valid_options" type="strlist">longnames</append>
	  <append key="volume.mount.valid_options" type="strlist">shortnames</append>
	  <append key="volume.mount.valid_options" type="strlist">nowin95</append>
	  <append key="volume.mount.valid_options" type="strlist">large</append>
	  <append key="volume.mount.valid_options" type="strlist">-u=</append>
	  <append key="volume.mount.valid_options" type="strlist">-g=</append>
	  <append key="volume.mount.valid_options" type="strlist">-m=</append>
	  <append key="volume.mount.valid_options" type="strlist">-M=</append>
	  <append key="volume.mount.valid_options" type="strlist">-L=</append>
	  <append key="volume.mount.valid_options" type="strlist">-D=</append>
	</match>
      </match>
dies habe ich mal mit meiner Änderung eingefügt.
In dieser Datei werden ja mountoptionen gelistet und hier (an anderen Stellen auch) wird zwischen Linux und FreeBSD unterschieden und dann unterschiedliche Optionen vermerkt. Hier habe ich die Option "large" eingefügt, die es nun bei FreeBSD gibt (die ich in der man page noch nicht gesehen hatte) und die dann ganz global zur Verfügung stehen könnte.

Leider funktioniert es bei mir nicht, ich kann es nicht testen.
Bei meiner Sucherei nach Lösungen, ist mir aufgefallen, daß der HALD dann mounten kann, wenn er das Label des Gerätes ordentlich erkennt. Diese Erkenntnis ist für mich vollkommen neu, ich wunderte mich nur manchmal, daß einige Geräte nicht wollen aber manuell einfach eingebunden werden können. Ein solches Gerät, das aber keine große FAT-Partition hat, habe ich mir heute näher betrachtet.
dmesg gibt dafür aus:
GEOM_LABEL: Label for provider da0s1 is msdosfs/FLASH DISK.
HALD sagt dann, dieses ist kein gültiges Block-Device.
Wenn ich mit glabel einen Label "flash" zuweise, wird dies zusätzlich ausgegeben: GEOM_LABEL: Label for provider da0s1 is label/flash. Und beim nächsten Stecken dieses Sticks wird er automatisch eingebunden, in HAL wird ein weiterer Eintrag hinzugefügt, der nun unter /dev/label/flash die passenden Einträge führt, allerdings dem Gerät einen mountpoint so zuweist:
dev/label/flash on /media/FLASH DISK (msdosfs, local, noexec, nosuid). Das ist schon mal interessant und läßt sich auch wiederholen. Weiter ist interessant, daß dieses Gerät nicht über den HAL entfernt werden kann, es muß manuell und mit Option -f umountet werden.
All dies ist bei einem ähnlichen Stick nicht nötig, der den Eintrag UDISK als Label trägt. Hier funktioniert alles problemlos, wie vorgesehen. Unter dem Eintrag /dev/msdosfs/UDISK werden alle nötigen Positionen aufgeführt und ein mountpoint /media/UDISK geschaffen und genutzt, übrigens immer dieser bei dem Gerät, obwohl HAL nicht mit "fixed mountpoints" gebaut wurde. Dies ist auch ein Unterschied zu den Geräten, denen ich nun Probeweise einen glabel setzte, denn hier wird jedesmal ein Mountpoint mit Index -1 ... -2 und weiter neu angelegt.
Meine 300GB FAT-Platte hat leider gar keinen Label im MBR und so gelingt es auch nicht, sie zu mounten, wenn ich ihr mit glabel einen neuen Punkt setze. Jedenfalls vermute ich das mal, vielleicht wirkt aber der Eintrag der Option "large" gar nicht so, wie ich das will. Ich weiß nun nicht mehr, wie die Fehlersuche geht, um nachzusehen, welche Optionen HAL tatsächlich an mount übergibt, da muß ich erst weiter lesen, doch ich dachte, vielleicht kann mir jemand helfen und auf die schnelle eine Möglichkeit nennen, den Volume-Label im MBR (also nicht den Eintrag durch glabel) auf FAT-Partitionen zu ändern. tunefs will keinen FAT.
Ich vermute deshalb, daß HAL ohne einen gültigen Label nicht zu Recht kommt, obwohl er auch hier einen mountpoint Namens disk in /media anlegt, weil volume.label leer bleibt und volume.mount_point ebenfalls und das war identisch mit dem Stick, der FLASH DISK heißt und der hat kein großes Dateisystem und braucht deshalb die Option "large" gar nicht.

Wäre schön, wenn es da eine Möglichkeit gibt, den Label im MBR zu ändern (evtl kann ich auch einen Windows Rechner organisieren, wenn es damit dann geht, nur weiß ich nicht, ob die überhaupt große FAT-Partitionen können).
 
pit234a schrieb:
Wäre schön, wenn es da eine Möglichkeit gibt, den Label im MBR zu ändern (evtl kann ich auch einen Windows Rechner organisieren, wenn es damit dann geht, nur weiß ich nicht, ob die überhaupt große FAT-Partitionen können).
Zum Vergrößern anklicken....

Meinst du das?
newfs_msdos(8) schrieb:
-L label
Volume label (up to 11 characters). The label should consist of
only those characters permitted in regular DOS (8+3) filenames.
Zum Vergrößern anklicken....
 
Das Problem ist, dass dann der Slice neu formatiert wird. Was fehlt ist hier ein tunefs_msdos mit dem das auch nachträglich gemacht werden kann.
 
ahja, genau das wollte ich gerade erklären, denn ich hatte zwischendurch einen Termin und wollte schnell zuvor noch den Label ändern, was auch gelungen ist, doch merkwürdigerweise dauerte das recht lange, ich meine, die paar Bit...
STRG+C brachte mich zwar raus, doch scheinbar ist das Dateisystem zerstört. Nun habe ich mir bei der Gelegenheit meinen Firmenlaptop mitgebracht, der XP drauf hat und versuche mal, zu reparieren.
Den Label des Sticks konnte ich ändern und das wirkte tatsächlich schon mal.
Aushängen gelingt leider nicht immer, da behauptet ein gam-server, daß er den Stick noch braucht, doch im großen und ganzen war das für mich ein wichtiger Hinweis, denn diesen Volume-Labels schenkte ich bisher keine Beachtung.
An diesem PC hier fällt auch auf, daß gelegentlich einfach alles hängen bleibt und einfriert, wenn ich am USB-Bus und mit HAL was versuche. Ich kann noch nicht eindeutig sagen, ob das nur der Fall ist, wenn ich mit "schwieriegen" Geräten arbeite oder ob das ab und zu mal passiert. Doch das ist ein anderes Thema.
 
Leider ist die Lösung meines Problems denn doch nicht so einfach.
Das large in dieser fdi wirkt zwar, es wird angezeigt, aber nicht angewendet. Eine Platte auch mit passendem Label wird nicht gemountet (ich habe mir dann noch eine zusammengebaut mit 160GB). Ohne passendes Label aber erst recht nicht, das ist also sehr wichtig.
Leider ist es auch genausowenig einfach, eine ntfs Partition rw durch den Hal mounten zu lassen, jedenfalls stehe ich da auf dem Schlauch. Das habe ich denn nämlich gleich als nächstes probiert mit der 160GB Platte und sobald die einen akzeptablen Label hatte, wurde sie sehr schön automatisch eingebunden und konnte wieder entfernt werden, nur leider immer ro. Manuell konnte root sie auch rw einbinden, mehr habe ich damit noch nicht gespielt.
 
Nächster Versuch.
Heute gab es eine erste Antort auf meine Anfrage bei hal@lists.freedesktop.org wegen dieses Problems, Joe Marcus Clarke <marcus@freebsd.org> schrieb dazu:
This is part of what you need to do. But it's not hald's job to
auto-mount volumes. You would need something like gnome-volume-manager to actually tell hald to mount the volume. It also needs to be taught
what mount options are needed.
Zum Vergrößern anklicken....
Natürlich fragte ich ihn auch, was da bei mir mit meinem KDE gemacht werden könnte. Da ich die Anwendungen mittels portinstall -P installierte, kann es sein, daß ich einen solchen Volume-Manager drauf habe, ohne ihn zu kennen. Jedenfalls finde ich mal nichts, mit whereis gvm.
Vielleicht kann mir hier schon mal jemand weiterhelfen?
Die Grundidee scheint ja nicht ganz abwegig, eine solche Änderung in die ....fdi zu schreiben, wie oben gezeigt, das macht mich zuversichtlich.
 
ja, in der Tat.
Michael Nottebrock <lofi@freebsd.org>
vom Free-BSD KDE-Team hat sich auch eingeschaltet und es gelingt nun, daß eine große FAT-Partition automatisch gemountet wird, aber leider entsteht dabei auch noch ein zweiter mountpoint in /media und der will nachher wieder umounted werden, was natürlich mißlingt. Es ist also noch keine reife Lösung, aber den Schritt, die momentane Testphase, will ich mal veröffentlichen:
Die /usr/local/share/hal/fdi/policy/10osvendor/20-storage-methods.fdi bekommt im Bereich für vfat zusätlich die Option "large". Das hat Joe Marcus Clarke <marcus@freebsd.org> wohl auch offiziel veranlaßt, denkt aber, daß es erst in der übernächsten Version des Hal auch veröffentlich wird. Bis dahin kannst du die Änderung manuell vornehmen und mußt bedenken, daß die immer wieder wegfällt, wenn du Hal neu baust.
Die Änderung habe ich oben schon beschrieben:
Code: 
	<match key="/org/freedesktop/Hal/devices/computer:system.kernel.name" string="FreeBSD">
	  <append key="volume.mount.valid_options" type="strlist">longnames</append>
	  <append key="volume.mount.valid_options" type="strlist">shortnames</append>
	  <append key="volume.mount.valid_options" type="strlist">nowin95</append>
	  <append key="volume.mount.valid_options" type="strlist">large</append>
	  <append key="volume.mount.valid_options" type="strlist">-u=</append>
	  <append key="volume.mount.valid_options" type="strlist">-g=</append>
	  <append key="volume.mount.valid_options" type="strlist">-m=</append>
	  <append key="volume.mount.valid_options" type="strlist">-M=</append>
	  <append key="volume.mount.valid_options" type="strlist">-L=</append>
	  <append key="volume.mount.valid_options" type="strlist">-D=</append>
	</match>
dies sind bei mir nun die Zeilen zu vfat, 142-153 und die mit dem large Eintrag ist dabei neu.
Weiter habe ich eine /usr/local/etc/hal/fdi/policy/preferences.fdi erstellt, die diesen Inhalt hat:
Code: 
<?xml version="1.0" encoding="UTF-8"?> 
<deviceinfo version="0.2">

<device> 
 <match key="volume.fstype" string="vfat">
  <match key="volume.size" compare_ge="128000000000">
    <merge key="volume.policy.mount_option.large" type="bool">true</merge>
  </match>
 </match>
</device>

</deviceinfo>
Wie gesagt, damit funktioniert es schon ein wenig, aber irgendwas haut den zweiten mountpoint noch rein und es hat wohl mit dieser policy zu tun.

Den Vorschlag von indy weiter oben, den mount mit einem Script zu machen, habe ich nicht hingekriegt. Ich finde nicht die passenden Variablen aus Hal, also, auch dann, wenn ich glaube dort was sinnvolles gemacht zu haben, bleiben meine Variablen leer und damit ist nicht gut arbeiten. Vermutlich habe ich es nicht verstanden.

edit: das Problem scheint auch mit KDE zusammen zu hängen, die beiden denken, daß es mit GNOME und der Änderung des /usr/local/share/hal/fdi/policy/10osvendor/20-storage-methods.fdi sowie des Gnome Volume Managers, damit der die neue Option auch kennt, funktionieren würde. Nur KDE hat keinen einfach zugänglichen Volume-Manager und es müßte der Code angepaßt werden. Das will wohl derzeit niemand machen.
 
> dahin kannst du die Änderung manuell vornehmen und mußt bedenken, daß die immer wieder wegfällt, wenn du Hal neu baust.
Das is so nicht richtig. Man kann es nämlich in eine andere Datei (im 20thirdparty-Verzeichnis) schreiben, die bei einer Neuinstallation nicht überschrieben wird.

Gibts eigentlich ein Äquivalent zu udev in FreeBSD?
Ich hab damit jetzt bei einigen Linux-Systemen bissl was gebaut und muss sagen, das fetzt. Gerade in diesem Fall wäre das sogar der bessere Weg.

So long...

Der Indy
 
udev empfinden die Free-BSDler als eine Art Sündenfall, ich glaube nicht, daß es etwas in der Art gibt.

Well: the thing is working, when:

also, mit folgendem Workaround kann vielleicht gelebt werden: warten.

erstmal machte ich /media leer, wie das auch sein sollte. Übrige mountpoints waren hier geblieben, weil ich zuvor mit fehlerhaftem Mount zu oft probiert und manuell umount gemacht hatte.
Dann ist das Rezept einfach: warten. Es dauerte bei mir etwa eine Minute, bis das Gerät eingebunden war. Es ist wichtig, erst dann das angebotene Systemfenster zu öffnen, sonst misslingt es und es wird ein zweiter mountpoint angelegt.

Ich will den Vorgang deshalb detailliert beschreiben:
In kcontrol bei dem gezeigten screenshot out1.png bewirke ich, daß für ein erkanntes Gerät ein Icon am Desktop angezeigt wird, also ein Icon für ein nicht gemountetes und eines für ein eingebundenes Gerät.
Wenn nun ein Gerät eingesteckt wird, erscheint etwa gleichzeitig ein Fenster, wie in out2.png. Normalerweise ist nun der mount schon erfolgt und so kann getrost eine Aktion gewählt werden, vorzugsweise das Fenster mit dem mountpoint geöffnet werden. DIesmal nicht! Der mountvorgang mit großen Partitionen ist dann noch nicht beendet und es entsteht dadurch der Fehler mit dem zweiten mountpoint. Also warten.
Erst, wenn das kleine Dreieck, wie in meinem out3.png gezeigt als grünes Dreieck unten rechts in dem Icon erscheint, ist der Mountvorgang beendet und das Gerät auf dem richtigen mountpoint eingebunden. Wird nun der Ordner des mountpoints geöffnet oder der Dialog aus out2.png bestätigt, funktioniert alles, wie geplant.
Bei mir erscheint out2.png nach etwa 30sec, wie gesagt, zusammen mit dem Icon auf dem Desktop. Der Mountvorgang dauerte bei der ~300GB Platte etwa 60 sec. Da heißt es warten und Geduld beweisen, doch dann wird es auch gut.

Wie indy sagt, kann es besser sein und einfacher, ein thirdparty policity zu nutzen. Ich habe dies gmacht:
Code: 
<?xml version="1.0" encoding="UTF-8"?> <!-- -*- SGML -*- --> 

<deviceinfo version="0.2">
  <device>
      <match key="volume.fstype" string="vfat">
	  <append key="volume.mount.valid_options" type="strlist">large</append>
      </match>
  </device>
</deviceinfo>
und einfach als /usr/local/share/hal/fdi/policy/20thirdparty/large_fat.fdi gespeichert. Das scheint zu funktionieren. Nun muß eventuel darauf geachtet werden, wann das dann in der osvendor fdi eingebaut ist, damit dann die thirdparty gelöscht werden kann.
 

Anhänge

  • out1.png
    out1.png
    66,3 KB · Aufrufe: 337
  • out2.png
    out2.png
    19 KB · Aufrufe: 326
  • out3.png
    out3.png
    4,3 KB · Aufrufe: 675
Die neue Version der DesktopBSD Tools im Portstree hat für den dbsd-traymounter jetzt automatisch die Option large für große FAT-Partitionen gesetzt.
Das funktioniert bei mir bei ner 200 GB Partition gut, braucht aber auch einige Sekunden, bis sie gemountet ist. Das ist also normal.
 
Am Wochende habe ich in einem Update auch ein neues Hal und KDEbase bekommen.
Die Option large ist nun in der /usr/local/share/hal/fdi/policy/10osvendor/20-storage-methods.fdi enthalten, es braucht also keine zusätzliche policy, wie etwa oben gezeigt in /usr/local/share/hal/fdi/policy/20thirdparty/large_fat.fdi, doch es braucht weiterhin die /usr/local/etc/hal/fdi/policy/preferences.fdi um die Unterscheidung für große Partitionen zu treffen.
Dann wollte mit dieser neuen Version auch kein kleiner Stick mehr mounten und es gab eine Fehlermeldung "org.freedesktop.hal.storage.mount-removable no <-- (action, result)".
Mit einem Eintrag in die /usr/local/etc/PolicyKit/PolicyKit.conf konnte ich das ändern. Weil ich die vorhandenen Einträge dort sowieso nicht mochte, habe ich das rausgenommen und so sieht diese Datei nun also bei mir aus:
<?xml version="1.0" encoding="UTF-8"?> <!-- -*- XML -*- -->

<!DOCTYPE pkconfig PUBLIC "-//freedesktop//DTD PolicyKit Configuration 1.0//EN"
"http://hal.freedesktop.org/releases/PolicyKit/1.0/config.dtd">

<!-- See the manual page PolicyKit.conf(5) for file format -->

<config version="0.1">
<match action="org.freedesktop.hal.storage.mount-removable">
<return result="yes"/>
</match>
</config>
Zum Vergrößern anklicken....
Der Rest funktionierte dann, eben langsam, wie beschrieben.
 
Unter PC-BSD wird übrigends das Workaround von Oben in der Version 1.5.1 als Patch angeboten (Online Updater), ansonsten ja hoffentich ab Version 7 (nächste) nicht von Nöten ;)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben