Automount / autofs

[MajorK]

außerdem würden dann so ein paar Probleme beim WOL wegfallen, oder nicht ?

In wiefern?

ich denke mal wenn automount keinen Sinn machen würde hätte mann es nicht erfunden...

Naja, es wurde ja auch schon diverse male ein Rad erfunden, deshalb muss man das aber nicht an die Box schrauben...
Aber davon ab, ich bin auch fuer autofs (wer haette das gedacht?)

Major K.

[essu]

ich denke mal wenn automount keinen Sinn machen würde hätte mann es nicht erfunden...

Naja da könnte ich dir aber die verschiedensten Erfindungen, angefangen bei Betriebssystemen nennen, die unsinnig/unbrauchbar sind...

Aber mal ernst, ich habe nichts dagegen, wenn automount auf der dbox funkt, ein Platzproblem sehe ich wegen single-gui-images momentan nicht, allerdings sehe ich auch keine Platzersparnis wie barf.

Bleibt nur noch die Frage wer machts, auf die Gegenfrage kann ich schon jetzt antworten: Keine Zeit...

[Papst]

@Barf
Weil mount und umount aus der busybox anscheinend nicht funktioniert. Wie auf Seite 1 schon beschrieben kommt damit nämlich folgendes:

Code: Alles auswählen

Jan  5 01:30:04 dbox daemon.info automount[176]: starting automounter version 4.1.4, path = /net, maptype = file, mapname = /etc/auto.net 
Jan  5 01:30:04 dbox daemon.debug automount[176]: >> /bin/mount: invalid option -- - 
Jan  5 01:30:04 dbox daemon.debug automount[176]: >> /bin/mount: invalid option -- b 
Jan  5 01:30:04 dbox daemon.debug automount[176]: >> /bin/mount: invalid option -- i 
Jan  5 01:30:04 dbox daemon.debug automount[176]: >> /bin/mount: invalid option -- d 
Jan  5 01:30:04 dbox daemon.debug automount[176]: >> mount: Mounting /tmp/autoAtORAt on /tmp/autoCwUw8M failed: Block device required 
Jan  5 01:30:04 dbox daemon.debug automount[176]: >> BusyBox v1.01 (2006.01.04-22:52+0000) multi-call binary 
Jan  5 01:30:04 dbox daemon.debug automount[176]: >> Usage: umount [flags] FILESYSTEM|DIRECTORY 
Jan  5 01:30:04 dbox daemon.err automount[176]: find_mntent: setmntent: No such file or directory 
Jan  5 01:30:04 dbox daemon.crit automount[176]: failed to mount autofs path /net 
Jan  5 01:30:04 dbox daemon.crit automount[176]: /net: mount failed! 
Jan  5 01:30:04 dbox daemon.warn automount[176]: failed to remove dir /net: No such file or directory

(u)mount habe ich aus den util-linux-2.12r von kernel.org
Automount habe ich in der aktuellsten Version 4.1.4 ebenfalls von kernel.org.

Allerdings habe ich grade noch ein Problem bemerkt. Der erste Start nach dem Flashen verläuft ganz normal. Wenn man allerings die Box runterfährt und neu startet passiert folgendes:

Code: Alles auswählen

.
.
.
init started:  BusyBox v1.01 (2006.01.04-22:52+0000) multi-call bUsing /lib/modu
les/2.4.32-dbox2/misc/event.o
event: $Id: event.c,v 1.12 2003/09/30 05:45:38 obi Exp $
Using /lib/modules/2.4.32-dbox2/misc/tuxbox.o
Using /lib/modules/2.4.32-dbox2/misc/dvb-core.o
Using /lib/modules/2.4.32-dbox2/misc/dbox2_i2c.o
[i2c-8xx]: mpc 8xx i2c init
[i2c-8xx]: adapter: 0
Using /lib/modules/2.4.32-dbox2/misc/dbox2_fp.o
Using /lib/modules/2.4.32-dbox2/misc/dbox2_fp_input.o
Using /lib/modules/2.4.32-dbox2/misc/avs.o
Using /lib/modules/2.4.32-dbox2/misc/saa7126.o
/proc/bus/tuxbox/vendor: No such file or directory
Using /lib/modules/2.4.32-dbox2/misc/cam.o
$Id: cam.c,v 1.30 2004/01/10 16:36:34 alexw Exp $
/proc/bus/tuxbox/vendor: No such file or directory
/proc/bus/tuxbox/vendor: No such file or directory
/proc/bus/tuxbox/model: No such file or directory
/proc/bus/tuxbox/model: No such file or directory
/proc/bus/tuxbox/submodel: No such file or directory
/proc/bus/tuxbox/submodel: No such file or directory
Detected STB:
  Vendor: Unknown
  Model: Unknown Unknown
.
.
.

Die Box fährt kurz darauf wieder runter mit der Meldung "Hersteller unbekannt"
Es scheint an dem mount zu liegen. Mit dem busybox mount passiert das nicht. Wenn ich die Box nur einmal hochfahre läuft alles tadellos. Man darf nur nicht neu starten
Ideen?

[MajorK]

Hast Du mount von Busybox nochmal probiert, nachdem Du /var/lock angelegt hattest? Evtl. war es ja dasselbe Problem.

[Papst]

Ja, das hat anscheinend nur mit dem automount zu tun

[Npq]

Das procfs ist da vermutlich nicht gemountet.

[Torsten73]

außerdem würden dann so ein paar Probleme beim WOL wegfallen, oder nicht ?

In wiefern?

Wenn die DBox aus dem DeepStby startet und der Rechner nicht schnell genug aufwacht (so ist es bei mir) werden die Verzeichnisse nicht gemountet, ergo funktionieren auch die Aufnahmen nicht, da vor der Aufnahme keine remount ausgeführt wird.
Ich hatte das gelößt, indem in der Start.neutrino ein WOL ausgelößt wird, incl einer Pause von 10s. Das genügt um ordnungsgemäß mounten zu können.

Mein Server läuft deshalb auch wieder 24h*365T.

Cu
Torsten

[mogway]

Ich habs geschafft.

Kannst du mal kurz erklären, wie du autofs compiliert hast. Bei mir fällt er schon beim configure auf die Nase.

Code: Alles auswählen

checking whether gcc -fPIE works... configure: error: cannot run test program while cross compiling
See `config.log' for more details.
make: *** [.deps/autofs] Fehler 1

Gruß
mogway

[Papst]

@npq
Und was kann ich da machen? Ich meine beim ersten Start gehts ja. Schweint irgendwie als wenn mount das Dateisystem zerhaut oder so

@mogway
Ich habe in der Makefile.rules überall wo nötig die powerpc-tuxbox-linux-gnu... eingetragen und nach dem configure in der Makefile.conf noch den Pfad zu den automount libs geändert:
# Directory for autofs modules
autofslibdir = /lib/tuxbox

Mehr wars glaube ich nicht.

[Papst]

Ich habe mir jetzt einen Würgaround gebaut indem ich die (u)mount für den automounter in /var halte und zum Boxstart das normale mount der busybox benutze. Ist Mist aber zum Testen gehts erstmal.
Hier habe ich mal die Binarys abgelegt:
http://s10.yousendit.com/d.aspx?id=1EC2 ... XBG4XZ5W7B

Dieser automount sucht sein mount und umount in /var. Kann man ja per Symlink oder wie auch immer lösen. Der Rest, so wie in den Verzeichnissen im rar.

[Barf]

So, jetzt ist es so weit. Ich habe ein testbares Setup. Eine Halbe ist in CVS eingecheckt (solches die nicht der Unintressierte stört), und die andere Halbe als diff hier. Wobei ich gegen Dateien vom newmake gearbeitet habe. (Nicht als Arroganz, aber weil EIN konsistentes Setup Arbeit genug ist).

Wie mogway observiert hat, ist automount überhaubt nicht für Crosscompilation vorgesehen. Ich habe deswegen den nicht funktionierende configure verschrottet, un mit dem autofs.diff installiere ich einfach include/config.h und Makefile.conf.

Papsts Problem:

Code: Alles auswählen

/proc/bus/tuxbox/vendor: No such file or directory 

kommt irgendwie wenn mann ein anderes mount benutzt. Frage mich nicht warum.

Papsts (andere) Problem war dass der automount-daemon und busybox-s mount einander nicht wirklich vertragen könnte. Wenn mann definiert CONFIG_FEATURE_MTAB_SUPPORT und CONFIG_FEATURE_MTAB_FILENAME="/etc/mtab" schein alles zu funktionieren. Wobei

Code: Alles auswählen

Jan  5 01:30:04 dbox daemon.debug automount[176]: >> /bin/mount: invalid option -- -
Jan  5 01:30:04 dbox daemon.debug automount[176]: >> /bin/mount: invalid option -- b
Jan  5 01:30:04 dbox daemon.debug automount[176]: >> /bin/mount: invalid option -- i
Jan  5 01:30:04 dbox daemon.debug automount[176]: >> /bin/mount: invalid option -- d 

nicht wirklich etwas böses darstellt: automount versucht einfach mit einem experiment herauszufinden, falls der mount die option --bind unterstützt. Der busybox-mount macht es nicht -- aber automount weiss wie er mit nicht-bind-unterstützende mounts umgeht.

Zu meine Implementierung: Erstmals, es fehlt noch die Flashinstallation, z.Z. nur YADD/CDK. Der automount-daemon wird mit /etc/init.d/start_automount gestartet, wobei der Benutzer diese anpassen kann, eventuell mit mehre Maps. /etc/auto.stuff ist als Beispiel gedacht.

Mittelfristig könnte mann vielleicht die Mounteditieroptionen in Neutrino umkrempeln zu einem Warmduschereditor für diese Datei?

Noch etwas zum Geschichte von dem Automounter. Der war eingentlich erfunden in Zusammenhang mit grosse Workstationinstallationen, mit einem grossen Anzahl von sowohl Benutzer als auch Workstations, sowie Servers wo die Benutzer ihre Homedirectories haben. Mann wollte, aus Grunden von Zuverlässigkeit (das Mounten von einem toten Server ist BÖSE) und netzwerkverkehr die Anzahl von Mount minimieren, ohne Leistungeinbußen. Die "offizielle" Meinung scheint zu sein dass der Automounter nur in Zusammenhang mit grosse Netze Sinn macht. Selbst habe ich zuhause seit >5 Jahren Automounter laufen, und finde er hat grosse Vorteile.

[Barf]

Mann, plötzlich wird es soo leise...

Ich habe weitergefummelt. Es hat sich gezeigt, dass CONFIG_FEATURE_MTAB_SUPPORT in busybox ist böse, verwirrt alle mögliche Programme, die nicht wissen falls sie /proc/mounts oder /etc/mtab glauben soll. So produziert "df" fehlerhaftiges Ergebniss.

Anstatt habe ich diese Option gelassen, und mache anstatt ein link (vom Makefile)

ln -s /proc/mounts /etc/mtab

und alles scheint zu laufen. Weiters habe ich herausfunden, dass der mountpount sich unbedingt in schreibbares Berech sich befinden muss.

Meine Tests zeigt dass Neutrino perfekt mit dem automounter klarkommt -- hätte ich nicht ganz erwartet Nur bei Anfangsauswahl (in Einstellungen) von z.B. audioplayerverzeichniss muss mann eventuell "ls /var/autofs/multimedia" oder sowas machen.

(Bei Probleme könnte mann sowas wie

ls /var/automount/multimedia >/dev/null

in autoplayer.start probieren. Ich brauchte aber nicht dirty tricks wie diese.)

Ich habe neue Versionen von Makefile.am (nur newmake), auto.stuff und start_automount eingecheckt. Die nicht-eingecheckte notwendige Patches befinden sich hier.

DIe alte diff für busybox.config.m4 nicht benutzen!

[Torsten73]

Hi Barf,
Super, dass Du Dich so in den Mounter reinhängst. BHin schon sehr gespannt wie das wird, wenns Enduserreif ist...

Thx!
Torsten

[MajorK]

Die "offizielle" Meinung scheint zu sein dass der Automounter nur in Zusammenhang mit grosse Netze Sinn macht.

Naja, das hat sich in Bezug auf "Wechselmedien" / USB-Sticks etc. IMHO ein wenig gewandelt.

Mann, plötzlich wird es soo leise...

Fuer meinen Teil liegt das daran, dass ich mich freue das es zu funktionieren scheint und ich nun freudig darauf warte, es in einem Yadi/JTG erwarten zu koennen Images selbst Brutzeln kann ich nicht...

Meine Tests zeigt dass Neutrino perfekt mit dem automounter klarkommt -- hätte ich nicht ganz erwartet

Glueckwunsch. Wie gesagt, ich hoffe autofs findet den Weg in die Images.

Gruss und Danke fuer Euer Engagement,
Major K.

[Barf]

Leider wird > 200 kB extra für den Automounter gebraucht. Ich schätze mann kann dieses ordentlich schrümpfen, falls mann nicht benötigte Teile (NIS- Hesoid, ...) support rausscheisst (nein scheint keine offensichtliche Konfigurationsoptionen für dies). Ferner habe ich nicht kontrolliert wie der AM mit CIF-Dateisysteme klarkommt: soll gehen, habe nur nicht versucht weil es mich nicht persönlich interessiert.

Endbenutzertauchlichkeit: Tja in einem Welt wo das Editieren von einem Konfigurationsfile als unzumutbar gilt... ICH werde kein Warmduschereditor für die Map-File schreiben, ... falls jemanden Anderen...

Ferner ist es möglicherwese mehr logisch (wie ich früher sagte) kernle 2.6 (inklusive Automounter!) zu laufen zu bekommen.

Nein, ein Binärpatch, auch für jffs2-images, macht kein Sinn.

[Papst]

So, melde mich auch mal wieder.
Benutze den automounter jetzt seit einigen Tagen ohne irgendwelche Probleme. Durch barfs mtab Geschichte haben sich meine Probleme mit dem busybox mount auch erledigt.
CIFS hab ich auch noch nicht probiert. Mal sehen...

[MajorK]

Endbenutzertauchlichkeit: Tja in einem Welt wo das Editieren von einem Konfigurationsfile als unzumutbar gilt... ICH werde kein Warmduschereditor für die Map-File schreiben,

Nana, also eine MAP mit vi editieren ist ja nicht das Problem. Was ich meinte ist eher einen entsprechenden Kernel zu kompilieren bzw. ein Image mit autofs - support zu brutscheln.
Daheim nutze ich selbst auch autofs/-mount fuer meine Notebook/NAS Verbindung (und editiere die Konfigfiles mit vi) ...

Major K.

[mb405]

@Papst
evtl. kannst du ja mal die nötigen änderungen posten. mit Barfs newmake kann ich nix anfangen . dann werd ich auch noch was zu der diskussion beitragen können.

[Papst]

In der Kernelconfig: linux-2.4.32-dbox2.config-flash änderst du diese Zeile:
# CONFIG_AUTOFS_FS is not set
in diese:
CONFIG_AUTOFS_FS=y
Dann kannste schonmal den Kernel neu bauen

Hier:
ftp://ftp.kernel.org/pub/linux/daemons/ ... 1.4.tar.gz
lädste dir das autofs Paket runter.
Nach dem Auspacken machste ein ./configure und überschreibst danach die entsprechenden Dateien von autofs mit denen aus diesem Archiv:
http://s24.yousendit.com/d.aspx?id=37IB ... CVDXGLTO7O

In der Makefile.rules musste noch eben den Pfad zu deinen powerpc-tuxbox-linux-gnu... anpassen.
Danach sollte ein make im AutoFS Ordner das Ganze kompilieren.

Nun kopierste "automount" aus dem Ordner daemon in /sbin deines Flashroots. Nach make flash-neutrino-all z.B. in /$HOME/dbox2/cdkflash/root/sbin
Aus dem Ordner modules alle Dateien mit Endung .so in flashroot /lib/tuxbox
Dann brauchste noch einen /var/lock Ordner, einen Symbolischen Link mit dem Namen mtab in /etc der auf /proc/mounts zeigt und ein Mapfile mit den eigentlichen Mountpunkten(Steht ja einiges auf Seite 1 hier).

Nach dem Imagebauen (make flash-jffs2image oder wie auch immer) und flashen sollte sich der automounter mit:
/sbin/automount /autofs file /etc/auto.net (autoi.net ist das besagte Mapfile) starten lassen.
Da der automounter seine Meldungen zum syslogd schickt ist dieser zur Fehlersuche ne gute Idee. (Kann man in busybox aktivieren).

So, hoffe ich habe nichts vergessen. Falls doch möge man mich korrigieren.

[mb405]

die *.so dateien sind knapp 260 kb groß und zusammen mit automount komplett 300kb.

ich bleib da weiter dran

[Papst]

Ja, Platz verbraucht es ganz schön. Allerdings sind es später im Image noch so ca. 220kb incl. automount. Wird ja nochmal gestripped beim Flashbauen. Vielleicht kann man auch noch die eine oder andere Lib irgendwie loswerden...

[mb405]

ich hab nur das problem, das mein squashfs bereich ziemlich voll ist (nur mehr 100kb platz) mal sehn, ob ich da ein paar links setzen kann, und die libs nach /var schmeissen kann.

[Papst]

CIFS Mounts funktionieren genauso gut wie NFS. Habs grad getestet.
Hier eine Beispielzeile für das Mapfile:
musik -fstype=cifs,ro,soft,user=root,password=dbox2,unc=//192.168.0.2/Musik //192.168.0.2/Musik

Drauf achten das das cifs Kernelmodul geladen ist.

[Papst]

Ich hab grade mal ausprobiert welche libs wirklich gebraucht werden.
Um NFS und CIFS mit dem automounter zu benutzen reichen folgende libs:
lookup_file.so
mount_bind.so
mount_generic.so
mount_nfs.so
mount_sun.so

Alle anderen können in die Tonne.
Damit verbraucht die ganze automounter Geschichte nur noch ca. 133kb im Image. Meiner Meinung nach ne völlig akzeptable Größe.

[mb405]

ja 133kb kann ich opfern
aber mount_sun.so gibts nicht du meinst parse_sun.so

noch ne frage. die *.so sollen die nach /cdkflash/root/lib(dort wo die libc.so.6 ist) oder nach /cdkflash/root/lib/tuxbox ?
EDIT hat sich erledigt syslog hat mir grad die antwort gegeben

das mapfile ist die /etc/auto.net . muss ich wohl noch nen link nach /var/etc/auto.net setzen