Automount / autofs

Wünsche, Anträge, Fehlermeldungen
JtG-Riker
Image-Team
Beiträge: 1015
Registriert: Freitag 7. Februar 2003, 18:37

Beitrag von JtG-Riker »

mb405 hat geschrieben:alle 12 nicht, nur ein paar. papst hat die aufgelistet hier im thread
Ahso, meine Fehler hab ich gerad schon muss ma sehen wie ich den wegbekomme *g*

Mar 25 16:24:02 (none) daemon.crit automount[154]: mount(nfs): cannot open mount module bind (//lib/autofs/mount_bind.so: symbol tempnam, version GLIBC_2.0 not defined in file libc.so.6 with link time reference)
JtG-Riker
Image-Team
Beiträge: 1015
Registriert: Freitag 7. Februar 2003, 18:37

Beitrag von JtG-Riker »

Also Pabst schreibt das die Libs in /lib/tuxbox sollen - da wird auch nix weggestrippt, aber autofs sucht die doch in /lib/autofs

Das versteh ich noch nicht so recht....


Riker


EDIT - funktioniert nun hab bei flash-lib einfach /lib/autofs mit eingetragen


Nun hab ich aber noch ein Problem

Hab am Rechner ein AllegroNFS laufen, per Neutrino geht der Mount auch.



per Automounter gehts nicht, hier die Fehlermeldung

auto.net steht folgendes:
movies -fstype=nfs,rw,soft,udp,nolock,rsize=8192,wsize=8192 192.168.0.10:/movies


Mar 25 17:13:49 (none) daemon.notice automount[154]: >> mount: 192.168.0.10:/movies failed, reason given by server: No such file or directory
Mar 25 17:13:49 (none) daemon.notice automount[154]: >> mount: nfsmount failed: Bad file descriptor
Mar 25 17:13:49 (none) daemon.notice automount[154]: >> mount: Mounting 192.168.0.10:/movies on /var/autofs/movies failed: No such file or directory
Mar 25 17:13:49 (none) daemon.err automount[154]: mount(nfs): nfs: mount failure 192.168.0.10:/movies on /var/autofs/movies
Mar 25 17:13:49 (none) daemon.err automount[154]: failed to mount /var/autofs/movies


Jemand eine Idee ?

Riker
Tommy
Tuxboxer
Tuxboxer
Beiträge: 4332
Registriert: Dienstag 7. Mai 2002, 17:04

Beitrag von Tommy »

also normal tuts ein make automount in den customizing skripten.

zitat BARF's Website:
In newmake, automake is an unpack-patch-build-install-delete-target. Installing in YADD is done with the make target automount, for images with the make target flash-automount (installing in $flashprefix/root). Therefore, the elegant way is to include the line make automount in (e.g.) yadd-neutrino-local.sh and/or the line make flash-automount in root-local.sh, possibly together with an appropriate /etc/auto.net configuration file instead of the default one (which is effectively empty).
---------------------------
Alle weiteren Infos findest Du im WIKI
Bitte vor dem posten Boardregeln lesen und verstehen!
Wie erstelle ich ein Bootlog? Wo finde ich die FAQ?
JtG-Riker
Image-Team
Beiträge: 1015
Registriert: Freitag 7. Februar 2003, 18:37

Beitrag von JtG-Riker »

@Tommy

Schon klar, aber ich nutze noch kei NEWMAKE


Es klappt aber mittlerweile, @Barf wie kann man denn am besten den automounter restarten wenn man im Boxbetrieb die auto.net geändert hat ?

So, für heut erstmal genug :)


Riker

[/quote]
Tommy
Tuxboxer
Tuxboxer
Beiträge: 4332
Registriert: Dienstag 7. Mai 2002, 17:04

Beitrag von Tommy »

JtG-Riker hat geschrieben:@Tommy

Schon klar, aber ich nutze noch kei NEWMAKE
Sorry - eigentlich dachte ich das :lol:
---------------------------
Alle weiteren Infos findest Du im WIKI
Bitte vor dem posten Boardregeln lesen und verstehen!
Wie erstelle ich ein Bootlog? Wo finde ich die FAQ?
jmittelst
Tuxboxer
Tuxboxer
Beiträge: 6044
Registriert: Montag 17. November 2003, 06:48

Beitrag von jmittelst »

Dank an alle, die dabei waren, das zum Laufen zu bekommen und natürlich an Riker für den Testschuß.

Arbeitet wirklich sehr gut.

Allerdings hab ich eine Anmerkung:
Bislang hält sich das Ganze nicht wirklich an die Neutrino-üblichen Pfade bzw. Konventionen.
Ich hab mir das Ganze etwas umgestrickt.
Meine start_automount:

Code: Alles auswählen

# The parent directory of AUTOFSMOUNT must be absolute, must exist,
# and be writeable. The AUTOFSMOUNTDIR should not exist.
#AUTOFSMOUNTDIR=/autofs
AUTOFSMOUNTDIR=/var/mnt
MAPFILE=/var/tuxbox/config/automount.conf

echo "Starting the automounter"

MD=/lib/modules/$(uname -r)/

# Load nfs-necessary modules.
# For CIF-stuff this needs to be extended

if [ -x /sbin/modprobe ] ; then
    # If nfs-support is contained in the kernel, this will fail. The 
    # error can be ignored.
    modprobe nfs
    modprobe cifs
else
    insmod $MD/kernel/net/sunrpc/sunrpc.o
    insmod $MD/kernel/fs/lockd/lockd.o
    insmod $MD/kernel/fs/nfs/nfs.o
    insmod $MD/kernel/fs/cifs/cifs.o
fi

if [ ! -d /var/lock ]; then
    mkdir /var/lock
fi
 
if [ -e $MAPFILE ] ; then
    automount $DEBUG $VERBOSE -t $TIMEOUT -p $PIDFILE $AUTOFSMOUNTDIR file $MAPFILE
fi
Die .pid wird also direkt nach /tmp geschrieben.
Mount-Verzeichnis ist /var/mnt - finde ich passender.
Auch das das Config-File automount.conf heißt und in /var/tuxbox/conf liegt, finde ich etwas sinniger.

Ich starte die start_automount im Moment aus der start_neutrino heraus, als allererstes. Das macht es z.B. auch möglich Files wie sectionsd, zapit und sogar neutrino individuell aus einem gemounteten Verzeichnis zu starten, was mir vorher nie geglückt ist.

Klasse Arbeit!

cu
Jens

P.S. Was ich noch nicht ganz verstanden habe: Wozu ist eigentlich /var/lock gut?
JtG-Riker
Image-Team
Beiträge: 1015
Registriert: Freitag 7. Februar 2003, 18:37

Beitrag von JtG-Riker »

var/run ist doch tmp - ist das gleiche und pid-files gehören auch dahin ;)
mb405
Tuxboxer
Tuxboxer
Beiträge: 2331
Registriert: Donnerstag 24. März 2005, 21:52

Beitrag von mb405 »

ich glaub ein paar variblen haste vergessen ??
automount $DEBUG $VERBOSE -t $TIMEOUT -p $PIDFILE $AUTOFSMOUNTDIR file $MAPFILE
was bedeuten die ? etwa so wie bei tuxmail/tuxcal

Code: Alles auswählen

static void sig_statemachine(int sig)
{
	int save_errno = errno;
	enum states next = ap.state;

	switch (sig) {
	default:		/* all the "can't happen" signals */
		error("process %d got unexpected signal %d!", getpid(), sig);
		break;
		/* don't FALLTHROUGH */

	case SIGTERM:
	case SIGUSR2:
		if (ap.state != ST_SHUTDOWN)
			nextstate(next = ST_SHUTDOWN_PENDING);
		break;

	case SIGUSR1:
		assert(ap.state == ST_READY);
		nextstate(next = ST_PRUNE);
		break;

	case SIGALRM:
		assert(ap.state == ST_READY);
		nextstate(next = ST_EXPIRE);
		break;

	case SIGHUP:
		assert(ap.state == ST_READY);
		nextstate(next = ST_READMAP);
		break;
	}

	debug("sig %d switching from %d to %d", sig, ap.state, next);

	errno = save_errno;
}
kann man mit HUP das ding aktualisieren
kann man mit TERM/USR2 das ding beenden
kann man mit USR1 ?????
kann man mit ALRM ?????
jmittelst
Tuxboxer
Tuxboxer
Beiträge: 6044
Registriert: Montag 17. November 2003, 06:48

Beitrag von jmittelst »

JtG-Riker hat geschrieben:var/run ist doch tmp - ist das gleiche und pid-files gehören auch dahin ;)
Ich seh das halt aus Usersicht - und da ist mir ein direkter Pfad ohne über einen Symlink zu gehen, nunmal wesentlich lieber.

cu
Jens
Tommy
Tuxboxer
Tuxboxer
Beiträge: 4332
Registriert: Dienstag 7. Mai 2002, 17:04

Beitrag von Tommy »

Mount-Verzeichnis ist /var/mnt - finde ich passender.
ich habe bei mir symlinks in /mnt/ nach /var/autofs/ fest verdrahtet. Damit umgehe ich auch, das ich über Menü (Aufnahmeeinst./MP) nichts auswählen kann da grad nix gemounted ist- die links sind immer da :wink:
---------------------------
Alle weiteren Infos findest Du im WIKI
Bitte vor dem posten Boardregeln lesen und verstehen!
Wie erstelle ich ein Bootlog? Wo finde ich die FAQ?
Barf
Developer
Beiträge: 1475
Registriert: Dienstag 4. Februar 2003, 22:02

Beitrag von Barf »

Es ist wichtiger und richtiger sich an etablierte standards/konventionen für "Unix-ähnliche" Betriebssysteme zu halten, als was Leute "gefallen". Im Tuxboxprojekt hat sich leider einige eigensinnige (Un-)Sitten entwickelt.

Es existiert der Filesystem Hierarchy Standard (FHS). Es ist nicht wünschenswert, dass jede Projekt eigene Filesystemsemantik entwickelt.

Einige Auszüge:
/mnt : Mount point for a temporarily mounted filesystem
Purpose

This directory is provided so that the system administrator may temporarily mount a filesystem as needed. The content of this directory is a local issue and should not affect the manner in which any program is run.
jmittelst Vorschag zu Mountpunkt (sowie (Un-)Sitten die leiter etwas verbretet sind) ist also nicht FHS-konform.
/var contains variable data files. This includes spool directories and files, administrative and logging data, and transient and temporary files.
/etc : Host-specific system configuration
Purpose

The /etc hierarchy contains configuration files. A "configuration file" is a local file used to control the operation of a program; it must be static and cannot be an executable binary. [4]
Konfigurationsfiles gehören also in /etc, nicht in /var. (Konzeptionell, dass (oft) nur /var bescreibbar und /etc ein symlink ist, ist eine andere Sache.)
/var/run : Run-time variable data
Purpose

This directory contains system information data describing the system since it was booted. Files under this directory must be cleared (removed or truncated as appropriate) at the beginning of the boot process. Programs may have a subdirectory of /var/run; this is encouraged for programs that use more than one run-time file. [42] Process identifier (PID) files, which were originally placed in /etc, must be placed in /var/run. The naming convention for PID files is <program-name>.pid. For example, the crond PID file is named /var/run/crond.pid.
Eine Versetzung von .pid-Files nach /tmp ist also nicht FHS-konform.
jmittelst hat geschrieben:P.S. Was ich noch nicht ganz verstanden habe: Wozu ist eigentlich /var/lock gut?
Das Verzeichniss ist in FHS bescrieben. Es wird (IIRC) ein lock-file für /etc/mtab abgelegt, was eigentlich etwas daneben ist.

@mb405: Die Signalhandling ist in manpage automount.8 beschrieben. Siehe auch meine Kommentarein am Anfang von start_automount. Hier ein Auszug von automount.8:
If the automount daemon catches signal USR1, it will unmount all cur-
rently unused autofs-mounted filesystems and continue running (forced
expire). If it catches signals TERM or USR2 it will unmount all unused
autofs-mounted filesystems and exit if all filesystems were unmounted.
Busy filesystems will not be unmounted. The daemon also responds to a
HUP signal which triggers an update of maps for which ghosting is
implemented (currently FILE and NIS maps).

If the autofs directory itself is busy when the daemon is signalled
with an exit signal then the daemon will exit without unmounting the
autofs filesystem. The filesystem is left in a catatonic (non-func-
tional) state, and can be unmounted when it becomes unused.
Weil der automounter nicht Neutrino gehört, und auch für z.B. Enigma-benutzer von interesse ist, ist ein Aufruf aus rcS das Richtige, nicht aus start_neutrino.
jmittelst
Tuxboxer
Tuxboxer
Beiträge: 6044
Registriert: Montag 17. November 2003, 06:48

Beitrag von jmittelst »

Danke für die Ausführungen Barf. So ist Dein Weg verständlich.

Wo letzten Endes der Startaufruf sitzt, wäre mir notfalls egal, hauptsache, es startet vor sectionsd ;)

Ne, mal im Ernst, die Anmerkungen oben waren für mich verständlicher, da ich halt nur das laufende System Tuxbox beachtet habe und nicht die Hintergründe kannte. Wie das letzten Endes dann mal ins Head wandert, soll aber nicht von mir abhängen. Ich wollte halt nur einiges zu bedenken geben. Wenn ich in Neutrino im Telnet bin und eine .pid suche, schaue ich in /tmp, weil ich sie da finde. Wenn ich eine Config-Datei bearbeiten will, schaue ich in /var/tuxbox/config nach. Die auto.net ist für mich halt ein Config-File. Aber wenn diese Logik gegen Standards verstoßen, dann lassen wir die User-Logik mal aussen vor. Solange es dann einen ausführlichen Artikel im Wiki dazu gibt (;)), wird das eher problemlos.

cu
Jens
saruman
Erleuchteter
Erleuchteter
Beiträge: 682
Registriert: Samstag 13. Juli 2002, 10:05

Beitrag von saruman »

JtG-Riker hat geschrieben:Es klappt aber mittlerweile, @Barf wie kann man denn am besten den automounter restarten wenn man im Boxbetrieb die auto.net geändert hat ?
Normalerweise mit 'nem kill -HUP, dann sollte der die Maps neu einlesen.
Papst
Developer
Beiträge: 279
Registriert: Mittwoch 26. Juni 2002, 22:19

Beitrag von Papst »

Da es offenbar in dem anderen Thread niemand registriert poste ich es hier nochmal:
Hab mir grade die ghostinggeschichte angesehen. Es muss nur der Kernel gepatched werden damit das läuft.
In diesem Archiv ist der benötigte Patch:
http://www.kernel.org/pub/linux/daemons ... 404.tar.gz

Und zwar module-patches/autofs4-2.4.29.patch

Den Patch einfach in tuxbox-cvs/cdk/linux kopieren und mit patch -p1 < autofs4-2.4.29.patch anwenden.

Nun den automounter noch zusätzlich mit der Option -g starten und die Verzeichnisse sind immer sichtbar. Auch wenn sie grade nicht gemounted sind.

Ein fertig gepachtes Autofs4 Kernelmodul hab ich hier hochgeladen:
http://rapidshare.de/files/19607146/autofs4.o.html

@Barf
Kannste den Kernelpatch nicht mal in den Newmake Branch einchecken?
Gruß

Der Papst
JtG-Riker
Image-Team
Beiträge: 1015
Registriert: Freitag 7. Februar 2003, 18:37

Beitrag von JtG-Riker »

Papst hat geschrieben:Da es offenbar in dem anderen Thread niemand registriert poste ich es hier nochmal:
Hab mir grade die ghostinggeschichte angesehen. Es muss nur der Kernel gepatched werden damit das läuft.
In diesem Archiv ist der benötigte Patch:
http://www.kernel.org/pub/linux/daemons ... 404.tar.gz

Und zwar module-patches/autofs4-2.4.29.patch

Den Patch einfach in tuxbox-cvs/cdk/linux kopieren und mit patch -p1 < autofs4-2.4.29.patch anwenden.

Nun den automounter noch zusätzlich mit der Option -g starten und die Verzeichnisse sind immer sichtbar. Auch wenn sie grade nicht gemounted sind.

Ein fertig gepachtes Autofs4 Kernelmodul hab ich hier hochgeladen:
http://rapidshare.de/files/19607146/autofs4.o.html

@Barf
Kannste den Kernelpatch nicht mal in den Newmake Branch einchecken?
Meinst du das gibt keine Probleme wenn man das im jffs2 hat und das Verzeichniss immer vorhanden ist, wenn dann der mount nicht klappt, das dir aber da ist wird doch das JFFS2 vollgeschrieben.

Riker


Gruß Riker
mb405
Tuxboxer
Tuxboxer
Beiträge: 2331
Registriert: Donnerstag 24. März 2005, 21:52

Beitrag von mb405 »

@Papst
was muss ich machen, um die kernelmodule selbst zu erstellen ?
ich arbeite nicht mit newmake .
Tommy
Tuxboxer
Tuxboxer
Beiträge: 4332
Registriert: Dienstag 7. Mai 2002, 17:04

Beitrag von Tommy »

Du must nur den patch anwenden und anschließend bauen
Papst
Developer
Beiträge: 279
Registriert: Mittwoch 26. Juni 2002, 22:19

Beitrag von Papst »

@Riker
Falls das Verzeichnis nicht gemounted werden kann bringt Neutrino die Meldung "Das Aufnahmeverzeichnis ist nicht beschreibbar..."
Und ich habe ein jffs2 Image

@mb405
Wie Tommy sagte. Einfach den Kernelpatch anwenden und den Kernel neu bauen.
Gruß

Der Papst
Barf
Developer
Beiträge: 1475
Registriert: Dienstag 4. Februar 2003, 22:02

Beitrag von Barf »

@Papst: es kommt... (kannst du glauben, wie viel Zeit ich in dies gesteckt habe?)

@Riker: Wie Papst schon sagt, der Automountersetup ist jffs2-sicher.
Papst
Developer
Beiträge: 279
Registriert: Mittwoch 26. Juni 2002, 22:19

Beitrag von Papst »

Sorry Barf, ich wollte dich nicht nerven. Dachte nur das du es nicht gelesen hast.
Gruß

Der Papst
mb405
Tuxboxer
Tuxboxer
Beiträge: 2331
Registriert: Donnerstag 24. März 2005, 21:52

Beitrag von mb405 »

@Papst
:gruebel: ich nehm kein newmake. geht das auch im normalen cvs ??
ich habs ja bisher gemacht, wie auf seite 2 oder 3 hier im thread.
ich hab also die automount binary, und die 5libs.
Papst
Developer
Beiträge: 279
Registriert: Mittwoch 26. Juni 2002, 22:19

Beitrag von Papst »

Der Kernelpatch hat nichts mit Newmake zu tun.
Du patchst deinen Kernel wie oben beschrieben und machst dann ein make linuxkernel
Am automounter selbst brauchste nix verändern. Für ghosting fehlte bisher nur der Kernelsupport.
Falls du in deinem Kernel Autofs4 als Modul kompiliert hast kannste auch das fertige Modul nehmen welches ich oben verlinkt habe.
Gruß

Der Papst
mb405
Tuxboxer
Tuxboxer
Beiträge: 2331
Registriert: Donnerstag 24. März 2005, 21:52

Beitrag von mb405 »

also ich hab in der kernelconfig das drin jetzt.
CONFIG_AUTOFS_FS=y
CONFIG_AUTOFS4_FS=y

ich versteh nur das mit den modul nicht ?? meints du so

CONFIG_AUTOFS_FS=y
CONFIG_AUTOFS4_FS=m

muss ich das immer frisch patchen, wenn ich den linukkernel frisch baue ?

ich weiss . viele fragen :(
Papst
Developer
Beiträge: 279
Registriert: Mittwoch 26. Juni 2002, 22:19

Beitrag von Papst »

Erstmal brauchste die Zeile CONFIG_AUTOFS_FS=y nicht. Autofs4_fs reicht aus.
Du kannst autofs4 entweder direkt in den Kernel kompilieren indem du ein y schreibst oder du baust ein Modul mit einem m
Ein Modul wird dann zur Laufzeit mit insmod in den Kernel geladen.
Hier spielts aber keine Rolle ob du ein Modul baust oder nicht.
Lass es ruhig auf y wenn du es schon immer so hattest.
Solange das linux-2.4.32 Verzeichnis in tuxbox-cvs/cdk besteht und du nicht z.B. make linuxdir machst, brauchste nur einmal patchen.
Gruß

Der Papst
Tommy
Tuxboxer
Tuxboxer
Beiträge: 4332
Registriert: Dienstag 7. Mai 2002, 17:04

Beitrag von Tommy »

@Papst:
ich hab nun den Kernel gepatcht und starte in der start_automount mit zusätzlich -g . Beim patchen kam kein Fehler. Leider zeigt alles keine wirkung. Kann es sein das ein make flash-semiclean den Kernel nicht zum neubau veranlaßt (newmake)? Mache gerade nochmal einen Durchlauf mit make mostlyclean :wink:
---------------------------
Alle weiteren Infos findest Du im WIKI
Bitte vor dem posten Boardregeln lesen und verstehen!
Wie erstelle ich ein Bootlog? Wo finde ich die FAQ?