/etc/hotplug/run_mount modifizieren

[cuma]

@hermann72pb: Also ich sähe es nur ungern, wenn meine 7270 die 250GB HDD einmal im MOnat scannt ;-)
zum unmounten: Hatte mir auch schon überlegt, den "reboot" Befehl um autoend und unmounten zu erweitern. Ich bekomme immer viele Fehlermeldungen beim Neustart bevor die Box runterfährt

 

[Silent-Tears]

Du musst das ja nicht aktivieren oder den trunk nutzen....

 

[coolphoenix]

@cuma: vielleicht war mein letzter post bzgl. unmount nicht ganz klar, also nochmal: bei der 7270 (zumindest mit der letzten preview-beta-fw, davor aber meiner meinung auch) unmountet avm die platten bei einem reboot vollautomatich (per "storage unplug"). nur, falls noch programme laufen, die darauf zugreifen, schläg das natürlich fehl. das sind dann irgendwelche freetz-programme (avms werden automatisch beendet), die bei mir per autoend.sh beendet werden. deswegen klappt das unmounten. dann gibt es keine probleme nach einem neustart.

was wiederum für die modifizierung von hermann hieße, dass beim umount "nur" darauf geachtet werden muss, dass alle freetz-programme beendet werden, die auf die platte zugreifen (externalized, logs speichern, ...). zumindest, wenn das bei allen fboxen wie o.g. liefe.

 

[hermann72pb]

@coolphoenix: Das, was du mit autoend.sh da veranstaltest, lässt sich nur bedingt und relativ schwer automatisieren. Du kennst ja deine Sachen und trägst sie alle manuell ein. Was ich mir als erste Übergangslösung in diese Richtung vorstellen könnte wäre so eine Datei/Liste einzuführen, die beim unplug verarbeitet werden könnte. In die Liste würde man dann manuell die betroffenen Dienste eintragen. Später könnte man überlegen, ob die Eintragung in irgendeiner Art zuverlässig automatisch erfolgen kann.
@cuma: Du hast mich missverstanden. Ich schlage vor, dass alle Medien im Lesemodus REGELMÄSSIG gescannt werden (z.B. jede Nacht). Und erst nach Bedarf, wenn die Prüfung im Lesemodus Fehler liefert, sollte darüber entschieden werden ob die Partition unmounted / repariert / wieder gemounted wird, oder ob die Box dafür vielleicht sogar extra neu startet. Mach doch bitte an deiner Platte Folgendes (sda6 nur als Beispiel):

/var/mod/root # e2fsck -n /dev/sda6
e2fsck 1.41.9 (22-Aug-2009)
Warning!  /dev/sda6 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
ARCHIV has been mounted 53 times without being checked, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
ARCHIV: 11/311296 files (9.1% non-contiguous), 17981/610462 blocks

-n ist wichtig, weil für NUR-LESE-Modus. Mich würde interessieren, wie lange die Prüfung bei dir dauern würde, ob es viel Resourcen verbraucht und ob es Probleme damit auftreten, dass die Partition während der Testphase von irgendwo anders (z.B. logs) beschrieben wird. Es wurde hier und da zwar über dies alles genügend spekuliert, keiner hat aber bis jetzt handfeste Beweise zu seinen Bedenken und Äußerungen geliefert. Du sagtest z.B., dass es irrelang dauern würde und viel Resourcen verbrauchen würde. Jemand anderer behauptete dagegen, dass er problemlos während der Prüfung telefonieren könnte usw. Ich glaube persönlich keiner der beiden Behauptungen und erwarte die Wahrheit irgendwo in der Mitte. Wie wäre es, wenn einige freimutige hier die Read-Only-Tests bei sich laufen lassen würden und uns über Laufzeiten und Prozessorlast (subjektiv und objektiv) berichten würden. Zielsetzung wäre es: In einer Zeit von höchstens 1-2 Stunden eine angemessene Festplatte (cuma scheidet da mit seinen 250GB fast aus) lesend zu checken.

MfG

 

[olistudent]

Hallo Hermann,
mir ist heute noch was zu deinem Patch aufgefallen. Unser ntfs-3g binary ist nicht im gleichen Pfad wie das von AVM (/usr/bin vs. /bin). Da sollten wir was ändern.
Zweitens steht in der run_mount hinter "unserem" mount_fs Aufruf noch das ganze AVM Zeugs für ntfs. Das sollten wir auch noch entfernen. Wobei wir da evtl. noch was mit der Fehlerbehandlung abschauen können. Wobei ich nicht weiß welche Boxen und Firmwares das mit der LED können.

local new_filesystem=false
if mount_fs; then
new_filesystem=true
else
if test -x /bin/ntfs-3g ; then
ntfs-3g $DEVNODE $MNTPATH -o $READMODE -o locale=de_DE.ISO-8859-1
local NTFS_RET=$?
case "$NTFS_RET" in
0 )
new_filesystem=true
;;
12 ) # NTFS_VOLUME_NOT_NTFS
## ignore - not formatted with NTFS
;;
15 ) # NTFS_VOLUME_UNCLEAN_UNMOUNT
## need option -o force, but we don't do this, because its not safe!
eventadd 144 $MNTNAME
## no fail event later on
FAIL_EVENT=0
led-ctrl filesystem_mount_failure
;;
* )
## NTFS mount error
eventadd 145 $MNTNAME $NTFS_RET
## no fail event later on
FAIL_EVENT=0
led-ctrl filesystem_mount_failure
;;
esac
else
echo "ntfs not yet ready -> mount later" > /dev/ttyS0
FAIL_EVENT=0
fi
fi

MfG Oliver

 

[Silent-Tears]

Dort wird simpel nicht gemountet, wenn != ntfs oder unclean umountet wurde und wohl darauf hingewiesen per Webinterface (und led), dass das Dingen nicht ganz sauber ist, und man das kontrollieren sollte. Ist mir im übrigen lieber, so ein Hinweis, notfalls nicht nur per Webinterface und LED, sondern auch noch per mailer.

 

[hermann72pb]

Zum Pfad für ntfs würde ich vorschlagen, dass wir ganz doof in fwmod irgendwo am Ende eine Überprüfung einbauen, die feststellt, ob ntfs-3g von AVM unter /bin sitzt. Tut es nicht, wird ein symlink auf /usr/bin angelegt, wenn dort natürlich unser ntfs-3g vorhanden ist.
Oder noch einfacher, man verodert es bei der Prüfung (ich hab's nicht getestet, dürfte aber gehen):

if [ -x /bin/ntfs-3g -o -x /usr/bin/ntfs-3g ]
then
...

Grundsätzlich hast du aber Recht, dass es mit nicename() und fs_mount() noch beim Weiten nicht alles getan ist. Mir wird im Nachhinein erst langsam klar, dass wir am Besten noch einige weitere Sachen aus /etc/hotplug/storage auslagern sollten. Aber lass uns doch step-by-step vorgehen. Die ntfs-Sachen sehe ich noch im Schritt 1, weil davon run_mount betroffen ist. Mit dem storage-Skript könnte man sich später auseinander setzen.
Zu diesen Fehlern allgemein. Sind sie denn NTFS-spezifisch, oder könnten wir uns dadrauf aufsatteln und die Fehler in unserem fs_mount generieren? Dann könnte man die Sachen dort ab "local NTFS_RET=$?" so stehen lassen. Alternativ patchen wir dort alles weg und generieren diese events innerhalb von fs_mount(). In dem Falle müssen wir etwas nachaffen. Aber dafür werden sie uns hoffentlich nicht böse.

@Silent-Tears: Ob per mailer oder per log oder wie auch immer, alles wäre machbar, wenn wir es innerhalb von fs_mount() haben. Dorthin könnte man etwas einbauen, was die Fehler erstmal in einer temp-Datei aufsammelt und bei Bedarf per Mail verschickt, oder was auch immer damit tut.

MfG

 

[Silent-Tears]

Sinniger wäre

if [ `which ntfs-3g` ]; then

oder im Script direkt per "which ntfs-3g" absolut im Script aufrufen...

@hermann: Der Mailer ist sicherlich schwer beim boot der Box, da da ja auch noch kein Netzwerk besteht....

 

[coolphoenix]

zur sache mit ntfs-3g: man muss beachten, dass das avm-ntfs-3g eventuell per download nachgeladen wird, also ein [ -x ... ] check auf einen symlink dann in der fwmod natürlich nicht funzt, da das keine auskunft darüber gibt, ob es nachgeladen wird oder nicht.

und ob ein ein programm per "`which program`" oder nur per "program" aufruft, ist doch egal. anders natürlich bei checks ( also [ -x `which program` ] ) - vielleicht hast du das ja gemeint, silent-tears.

man muss bei ntfs-3g auch beachten, dass das freetz-ntfs-3g die daten utf-8-kodiert auf die platten schreibt, avms aber de_DE.ISO-8859-1 (wie man im skript sieht). beim freetz-ntfs-3g braucht man die mountopion mit dem locale nicht.

 

[olistudent]

Ich hatte das die Tage mal probiert und konnte mit dem Freetz-ntfs-3g keine Dateien mit Umlauten erstellen. Und auch die Dateinamen vom AVM-ntfs-3g erstellten Dateien mit Umlauten werden nicht richtig angezeigt.

MFG Oliver

 

[RalfFriedl]

reetz-ntfs-3g die daten utf-8-kodiert auf die platten schreibt, avms aber de_DE.ISO-8859-1

Gemeint sind nicht die Daten, sondern die Dateinamen.

Damit Umlaute funktionieren, muß an allen Stellen die gleiche Kodierung verwendet werden. Also bei NTFS, Samba, Terminal, oder was auch immer sonst noch daran beteiligt ist. Bei moderneren Linux-Distributionen wird durchgehend UTF-8 verwendet, da funktioniert alles.

Für NTFS würde ich erstmal damit anfangen, auf einem Windows-System Dateinamen mit Umlauten anzulegen und diese dann auf der Box anzeigen.

ls | hexdump -C

 

[hermann72pb]

Wollen wir vielleicht besser für ntfs-Problematik ein eigenes Thread aufmachen? Sonst weichen wir hier vom eigentlichen Thema ab.
Der Hinweis zu den Symlinks ist eigentlich generell nicht verkehrt. Ob es im Zusammenhang mit AVM-Auslagerung, oder mit unseren downloader/external-Geschichten. Es kann schon vorkommen, dass Symlinks ins Leere zeigen. Man sollte es doch prüfen, ob da einfache Möglichkeiten existieren das Vorhandensein der eigentlichen Datei zu prüfen. Bei "test" gibt es sicherlich viele Optionen und man kann die Symlinks wenigstens erkennen. Die Frage ist, was macht man damit weiter, ohne, dass man die Verlinkung bis zum bitteren Ende vefolgt und damit die Performance-Einbusse erleiden muss.

MfG

 

[Silent-Tears]

"ls" hat Optionen, um symlinks direkt zu dereferenzieren. (Zumindest auf meinem Buildsyste, ob BB das hat, weiss ich aktuell nicht). file" soltle ebenfalls seinen Dienst tun können.

 

[hermann72pb]

...
Zweitens steht in der run_mount hinter "unserem" mount_fs Aufruf noch das ganze AVM Zeugs für ntfs. Das sollten wir auch noch entfernen. Wobei wir da evtl. noch was mit der Fehlerbehandlung abschauen können. Wobei ich nicht weiß welche Boxen und Firmwares das mit der LED können.

Ich weiß nicht, welche LED-Ereignisse du meintest. Die "eventadd" gehen schon auf meiner 7170, obwohl sie dieses NTFS-Zeigs zu Sonderbehandlung per se nicht hat. Es mach also sinn, die Dinge in mount_fs() mitzunehmen, oder vielleicht irgendwo anders behandeln.
Ich tendiere letzte Zeit dazu, etwas mehr "zu uns" zu nehmen, als ursprünglich gedacht. Am liebsten würde ich so vorgehen, dass neben nicename() und fs_mount() "zu uns" auch do_mount() und do_umount() komplett rüberwandern. Ich würde dann den Aufruf von unserer Bibliothek /usr/lib/libmodmount.sh in AVM's /etc/hotplug/storage an den Anfang nach deren Semaphoren packen und nicht ins run_mount, wie ursprünglich gedacht. Somit stünden alle Unterprogramme sowohl unter "storage" als auch unter "run_mount" (wird von storage aufgerufen) zur Verfügung. nicename(), do_mount(), do_umount() patchen wir komplett aus, da sie ja in unserer Bibliothek zu finden sein werden.
Wo ich dabei etwas Bedenken habe, ist ein offensichtliches copy-paste von diversen Passagen von AVM in diesen Unterstrukturen. Ob AVM da sich nicht beklaut fühlt. Auf der anderer Seite können sie ihre Passagen sowieso in einer oder anderen Form in unseren patches finden. Von daher, wenn sie Bedenken hätten, würden sie auch schon dagegen längst vorgehen. Sie tolerieren es aber bis jetzt.
Es ist schon nicht so, dass ich 100% die Queltexte von AVM rüberkopieren will. Ich will sie auch etwas abändern / anpassen. Sodass man am Ende sagen könnte, dass man sich davon lediglich inspirieren ließ.

Was denkt ihr dazu?

MfG

 

[henfri]

Hallo,

ich will nur ganz kurz stören:
Ich lese was ihr hier vorhabt mit Begeisterung. Vielen Dank für diese Mühen!

Gruß,
Hendrik

 

[hermann72pb]

Naja, von der Begeisterung ist hier weniger die Rede. Es ist viel Arbeit, egal, wie rum man es macht und es bedeutet in diesem Falle den Verstoß gegen eine allgemeingültige Regel "never touch a running system".

Mich würde da eine grundsätzliche Frage zum Speichern der Einstellungen für solche Fälle interessieren. Angenommen, ich würde im Rahmen von irgendeiner FREETZ-CGI eine Variable anlegen, die ich in einem von diesen Skripten zum Mounten nutzen würde. Wenn das System läuft, ist es überhaupt kein Problem, beim Hochfahren dagegen schon. Denn die ganzen /mod/etc/package.cfg - Dateien sind erst dann da, wenn rc.mod durchgelaufen ist. Beim Hochfahren wird jedoch die Reihenfolge vermutlich anders ablaufen: Zuerst hotplug/storage/->do_mount und erst später rc.mod und das Vorhandensein der Variablen. Sehe ich das richtig? Wie wird das Problem bei dnsmasq umgegangen? Denn es startet doch auch relativ früh? Oder USBROOT? Denn es muss auch irgendwie wissen, ob es aktiv ist. Irgendwie hatte ich mich in den Startskripten verlaufen und den roten Faden verloren...

MfG

 

[Silent-Tears]

USBroot nutzt die kernel_args.

 

[hermann72pb]

Eine Alternative wäre, nach der Existenz der cfg-Datei zu checken (was man sowieso machen sollte) und falls nicht vorhanden, die entsprechende freetz-Datei aus dem flash entpacken. Dieses device im Flash mit freetz-conigs wird relativ früh definiert, von daher wäre es schon möglich. Vielleicht sollte man dafür sogar eine allgemeine Funktion irgendwo schreiben:

loadcfg()
{
  if [ -x "$1" ]
  then
     ."$1"
  else
    ...
    hier kommen Kommandos zum Laden der betroffenen cfg aus dem flash ins ram
    ...
  fi
}
# Aufruf:
loadcfg "/mod/etc/mypackage.cfg"

MfG

 

[hermann72pb]

FREETZMOUNT Version 1.0

Nun ist es vollbracht, und die erste Version ist halbwegs trunkreif. Nach den kurzen Tests bitte ich mein FREETZMOUNT einzuchecken, denn ich sehe keine großen Gefahren für den Trunk. Man kann den Patch nun auch abwählen.

Änderungen gegenüber automount.patch:

1. Das ganze nennt sich nun FREETZMOUNT, denn ich habe sehr viel aus /etc/hotplug/storage und /etc/hotplug/run_mount in /usr/lib/libmodmount.sh ausgelagert.
2. FREETZMOUNT kann in menuconfig als Punkt gewählt werden.
3. blkid wird nach Bedarf und Wunsch ausgewählt (LABEL-Mounts)
4. FREETZMOUNT ersetzt alte Patches usbstorage und autorun/autoend. Deswegen werden sie ausgeblendet, sobald FREETZMOUNT aktiviert wird.
5. FREETZMOUNT braucht rc.ftpd. Deswegen nehme ich es hier mit. rc.ftpd wird mitausgewählt, sobald FREETZMOUNT gewählt wird. rc.ftpd brauche ich, weil dort die Erkennung auf ftpd-Binary miteingebaut ist. Später kann man dadurch auf alle 400-FTPD-Patches verzichten.
6. autorun/autoend sind leider fest aktiviert, wenn man FREETZMOUNT mitnimmt. Später will ich es per WebIF aktivierbar machen.
7. Um vernünftig patchen zu können, habe ich mir tools/scriptpatcher.sh gebaut. Es ist mit dabei. Kann übrigens für andere Patchereien gut gebraucht werden.
8. Ich hatte in fwmod auch meine frühere Sünden mit freetzinfo von STEP3 nach STEP2 geschoben. Die entsprechenden Einträge für FREETZMOUNT finden sich davor.

Ich hatte sehr viele Sachen aus run_mount und storage aus guten Gründen ausgelagert. An diversen Stellen ist es unverändert, aber meistens etwas besser strukturiert und moduliert. Die mounts und unmounts verlaufen jetzt etwas besser. Einige unsaubere Stellen von AVM sind von mir beseitigt.

Allerdings basiert alles auf AVM-Quellen für die neuen Boxen. Ausprobiert von mir auf 7170 und 7270. Theoretisch dürfte es aber auch auf alten Boxen gehen.

Viel Spass beim testen!

Edit: Leider werden die Ausführungsrechte beim Patchen nicht automatisch gesetzt. Es ist erforderlich nach dem Patchen und vor dem make in seiner Buildumgebung Folgendes auszuführen:

chmod 755 root/usr/lib/libmodmount.sh
chmod 755 root/etc/init.d/rc.ftpd
chmod 755 tools/scriptpatcher.sh

ACHTUNG!!!
Diese Version war nur der erste Schuss meinerseits. Sie enthält noch sehr viele Bugs. Bitte die Version nicht mehr verwenden!

DORT gibt es aktuellere Version von FREETZMOUNT.

MfG

 

[henfri]

Toll!
Vielen Dank hierfür!