Skript für immer gleiche Mountpoints (auch nach Verlust des Mounts)

Was heißt es genau, Oliver? Werden wir in der absehbaren Zeit diese Busybox-Version auf FREETZ haben? Was bedeutet "Applet" im Falle "Busybox"? Kann man es dann per busybox's-menuconfig wählen?

MfG
 
Bei uns bisher nicht, weil wir noch nicht auf die aktuelle BB upgedatet haben, da dort diverse uClibc-0.30-Features drin benötigt werden.

Oliver und ich hatten das schon einmal in der Mache, ist bisher aber nicht trunkreif, so weit ich das weiss. Aber vielleicht hat Oliver da ja weitergemacht, meine Zeit ist grad irgendwie verschwunden, wo ich schon den Abbau meiner Überstunden unterbrechen musste auf Firmenweisung hin ;)
 
Ich hatte mir heute ein Image aus dem trunk3722 gebaut in dem ich unter Busybox folgende Optionen auswählen könnte:
Code:
FREETZ_BUSYBOX_MOUNT_LABEL=y
FREETZ_BUSYBOX_VOLUMEID=y
FREETZ_BUSYBOX_VOLUMEID_EXT=y
FREETZ_BUSYBOX_VOLUMEID_FAT=y
Nun habe ich blkid im image unter /usr/sbin/blkid. Das Binary ist 49kB gross. Also passt erstmal. Das Problem ist, beim starten von blkid friert die Box ein, sodass ich den Stecker ziehen muss. Anscheinend zieht blkid die Last voll auf 100% auf sich, sodass weder WebIFs noch dropbear noch telnet vernünftig gehen. Die Box rebootet aber nicht.
Wenn man allerdings die blkid "nur abfragt", dann bekommt man folgende Ausgabe:
Code:
/var/mod/root # blkid --help
blkid: invalid option -- -
blkid 1.0.0 (12-Feb-2003)
usage:  blkid [-c <file>] [-ghlLv] [-o format] [-s <tag>] [-t <token>]
    [-w <file>] [dev ...]
        -c      cache file (default: /etc/blkid.tab, /dev/null = none)
        -h      print this usage message and exit
        -g      garbage collect the blkid cache
        -s      show specified tag(s) (default show all tags)
        -t      find device with a specific token (NAME=value pair)
        -l      lookup the the first device with arguments specified by -t
        -v      print version and exit
        -w      write cache to different file (/dev/null = no write)
        dev     specify device(s) to probe (default: all devices)
Die Version scheint ziemlich alt zu sein. Kann da jemand eine Aussage dazu machen? Bzw. wie kann ich es debuggen? Start ohne Parameter geht also schon mal nicht.

Edit:
Ihr werdet nicht glauben, aber es geht!!!
Code:
/var/mod/root # blkid dev /dev/sda1
/dev/sda1: UUID="457c1f4b-8aec-e4ee-6843-fcded6ae79dd" TYPE="ext2"
/var/mod/root # blkid dev /dev/sda2
/dev/sda2: UUID="9A64-8DAD" TYPE="vfat"
/var/mod/root # tune2fs -L "SYSTEM" /dev/sda1
tune2fs 1.41.3 (12-Oct-2008)
/var/mod/root # tune2fs -L "DATA" /dev/sda2
tune2fs 1.41.3 (12-Oct-2008)
tune2fs: Bad magic number in super-block while trying to open /dev/sda2
Couldn't find valid filesystem superblock.
/var/mod/root # tune2fs -L "DATA" /dev/sda3
tune2fs 1.41.3 (12-Oct-2008)
tune2fs: Attempt to read block from filesystem resulted in short read while trying to open /dev/sda3
Couldn't find valid filesystem superblock.
/var/mod/root # tune2fs -L "DATA" /dev/sda4
tune2fs 1.41.3 (12-Oct-2008)
tune2fs: Bad magic number in super-block while trying to open /dev/sda4
Couldn't find valid filesystem superblock.
/var/mod/root # tune2fs -L "DATA" /dev/sda5
tune2fs 1.41.3 (12-Oct-2008)
/var/mod/root # tune2fs -L "ARCHIV" /dev/sda6
tune2fs 1.41.3 (12-Oct-2008)
/var/mod/root # blkid dev /dev/sda1
/dev/sda1: LABEL="SYSTEM" UUID="457c1f4b-8aec-e4ee-6843-fcded6ae79dd" TYPE="ext2"
/var/mod/root # blkid dev /dev/sda5
/dev/sda5: LABEL="DATA" UUID="7b097c41-5282-7a79-feba-b9b0d63459e7" TYPE="ext2"
/var/mod/root # blkid dev /dev/sda6
/dev/sda6: LABEL="ARCHIV" UUID="b1328ea0-2360-50da-6cc3-9adc5d42937d" TYPE="ext3"

Jetzt fehlt mir nur ein Ersatz/Erweiterung von e2fsprogs für vfat. Denn AVM-AB&Co wollen immer noch vfat haben. Und die zu checken/zu ändern sollte man auch können.
Edit 1.5:
Mein Wunsch nach DOS-Tools ist relativ schnell in Erfüllung gegangen: http://www.ip-phone-forum.de/showthread.php?t=200238

Edit2: Meine Nachforschung zeigte, dass blkid gar nicht von busybox stammt. Es ist auch eine separate Datei und nicht in busybox-binary integriert. Deswegen hat es mich schon etwas irritiert. Dieses blkid stammt nämlich von e2fsprogs. Vermutlich von tuning-tools. Blöderweise wurde per external gar nicht angeboten blkid auszulagern, obwohl da eine Menge an e2fsprogs-Tools zum auslagern frei standen. Ich werde da noch weiter nachhacken, ob es möglich wäre gnu-blkid direkt zu besorgen und zu kompilieren. Denn diese Version von blkid kann zwar Partitionen gezielt ansprechen, aber jede Art der Suche scheitert. Vermutlich weil blkid mit flash-Partitionen nicht klar kommt.

Edit2.5: Es war letztendlich doch richtig, dass ich blkid gar nicht für external angeboten bekommen hatte. Denn es darf nicht ausgelagert werden, wenn mdev im Spiel ist. Und bei mir ist es vermutlich im Spiel, weil ich USB-ROOT mit dem integrierten check im Image habe.

MfG
 
Zuletzt bearbeitet:
Nach meinen 2,5 edits und 1,5 vergangenen Tagen erlaube ich es mir doch einen Doppelpost, damit es hier überhaupt einer liest.
Man kann doch mit blkid "vorsichtig" arbeiten, wenn man z.B. Folgendes angibt:
Code:
/var/mod/usr/sbin # blkid /dev/sd*
/dev/sda1: LABEL="SYSTEM" UUID="457c1f4b-8aec-e4ee-6843-fcded6ae79dd" TYPE="ext2"
/dev/sda2: LABEL="FAT" UUID="9A64-8DAD" TYPE="vfat"
/dev/sda4: TYPE="swap"
/dev/sda5: LABEL="DATA" UUID="7b097c41-5282-7a79-feba-b9b0d63459e7" TYPE="ext2"
/dev/sda6: LABEL="ARCHIV" UUID="b1328ea0-2360-50da-6cc3-9adc5d42937d" TYPE="ext3"

/var/mod/usr/sbin # blkid -s TYPE /dev/sd*
/dev/sda1: TYPE="ext2"
/dev/sda2: TYPE="vfat"
/dev/sda4: TYPE="swap"
/dev/sda5: TYPE="ext2"
/dev/sda6: TYPE="ext3"
/var/mod/usr/sbin # blkid -t LABEL=FAT /dev/sd*
/dev/sda2: LABEL="FAT" UUID="9A64-8DAD" TYPE="vfat"
/var/mod/usr/sbin # blkid -t LABEL=FAT -s LABEL /dev/sd*
/dev/sda2: LABEL="FAT"
Man muss die Suche also nur passend beschränken, damit sie auch geht und blkid sich nicht aufhängt. Für den Einsatz hier würde es eigentlich reichen.
Jetzt wäre es sinnvoll blkid in e2fsprogs zu separieren, damit man es auch vereinzeln wählen kann. Dann kann man schon darauf aufbauen. Binary an sich ist auch nicht so besonders groß.

MfG
 
Automount nach LABEL

Nun ist es mir gelungen run_mount so zu patchen, dass es anstatt "uStorXX" die Namen nach dem Label der jeweiligen Partition vergibt (Näheres dazu s. oben).
Dafür wird blkid-Binary aus dem Paket e2fsprogs benötigt. Zur Zeit lässt sich blkid nicht separat wählen nur in einem Pack mit anderen Tools. Es ist aber durchaus möglich blkid für solche Zwecke später zu separieren.
Wird kein blkid gefunden, ist auch nicht schlimm. Dann wird nach dem alten Schema "uStorXX" gemounted.
Wie man den Partitionen Label vergeben kann, steht z.B. oben.

Leider ist run_mount ein Mißtstück von AVM, welches wir aus rechtlichen Gründen hier nicht publizieren dürfen. Ehrlich gesagt, steckt da nicht viel Gehirnschmalz von AVM drin, wir respektieren aber trotzdem deren Copyright.
Das Ding wird an mehreren Stellen durch FREETZ durch- und durchgepatcht. Davon kann sich jeder überzeugen, der im patch-Ordner nachschaut. Und nun schlage ich noch eine weitere Veränderung der armen Datei.
Mein patch wurde auf die Datei aus dem build/modified-Verzeichnis angewendet. Also, auf eine bereits gepatchte Datei. Die diff-Datei sollte hier nur Information dienen. Wie man es letztendlich in FREETZ integrieren könnte, weiß ich nicht.

Ergebnisse könnt ihr auch bildlich ansehen. Es funktioniert also tatsächlich. Leider hält dies bei mir nicht lange, weil der AVM-AB sein Verzeichnis nicht findet und die Box zum Rebooten zwingt. Und nach dem Reboot sind meine zunächst mal temporären Änderungen weg.

MfG
 

Anhänge

  • automount.diff.bz2
    521 Bytes · Aufrufe: 19
  • avm_usb_geraete.jpg
    avm_usb_geraete.jpg
    90.1 KB · Aufrufe: 55
  • freetz_partitionen.jpg
    freetz_partitionen.jpg
    57.7 KB · Aufrufe: 72
Hei, ich hab blkid vorhin doch separiert ;)
 
Gut, dann müssen wir nur zusehen, wie wir meine Veränderungen da reinintegrieren. Ideal wäre noch, wenn man diesen Automatismus auch per WebIF abschaltbar machen könnte. Damit es allerdings leichter möglich wird, plädiere ich dazu alle unseren Sachen aus run_mount auszulagern. Wie ich schon sagte, wird die Datei durch und durch gepatcht. Und zwar gibt es dort pro Box jedesmal einen separaten Patch.
Meine Vorstellung wäre: Wir bauen in run_mount an einer/mehreren (muss man noch genau herausfinden) Stelle/n einen Aufruf vom unseren Skript freetzmount.sh (oder wie wir es immer benennen). In diesem freetzmount.sh werden dann all die Sachen reingepackt, die momentan da umgepacht werden, nämlich mount von ext-Systemen, Erhöhung der Devices auf 9 Stück usw. Dadurch wird die Wartungsarbeit für uns deutlich leichter und wir haben unsere Sachen separiert.
Denn das Problem an der Geschichte, die ich hier vorschlage besteht darin, dass man es entweder in etwa 20 Patches (je Boxmodell) reinintegrieren muss, oder die bereits gepatchte Datei run_mount nochmal ganz am Ende patchen.
Wie hier bereits bekannt ist, reicht es dabei vollkomend aus, wenn AVM nur eine einzige Zeile in der Datei ändert und schon bricht unser Kartenhäuschen aus den Patches in sich zusammen. Und man darf wieder von vorne anfangen zu patchen. Auf anderer Seite, selbst wenn wir etwas in unseren Sachen anpassen wollen, müssen wir denselben Aufwand betreiben.

MfG
 
@hermann72pb

Ist das jetzt schon im trunk ? Ich würds gerne testen - wenn des für Dich in Ordnung geht.

Gruß

Yeti :D
 
Es ist noch nicht im trunk. Ich hatte es lediglich getestet, ob es grundsätzlich so geht. Und es scheint zu funktionieren, wie man oben sehen kann. Damit es in den trunk kommt, bedarf es einer Reihe gravierender Änderungen, die nicht so einfach ohne weiteres und per zwei Zeilen in einer patch-Datei zu machen sind. Wie ich oben bereits beschrieben hatte, wäre es zunächst mal sinnvoll die Patch-Strategie für alle mount-Sachen grundsätzlich zu überdenken und etwas anders zu realisieren. Und weil diese Änderungen sehr gravierend sind, will ich es nicht ganz alleine tätigen, sondern benötige eine gewisse Unterstützung der sachkundigen Entwickler unter uns. Momentan sind jedoch Silent-Tears und Oliver vollständig mit dem Serverumzug beschäftigt, und ich will jetzt mit dieser Sache noch nicht dazwischen funken und sie von der viel wichtigerer Aufgabe abhalten. Wenn sie mit dem Umzug fertig sind, können wir die Sache nochmal in Ruhe angehen und zunächst mal die Voraussetzungen für weitere Schritte schaffen, wie ich oben vorgeschlagen hatte. Wenn man unsere eigene mount-Geschichte von den AVM-Sachen separiert hat, kann man daran weiterwerkeln. Und das wird noch mehrere Iterationsschritte hinter sich ziehen, glaub mir.
Alternativ könnte ich natürlich ohne diese Vorbereitung jetzt schon los legen. Es würde aber dann daraufhin laufen, dass ich die einzelne Patches für jede einzelne Box anpassen muss, was ich sicherlich mangels Zeit und Hardware zum testen nicht beliebig weit treiben kann. Dies macht in meinen Augen wenig Sinn. Deswegen lass uns mal abwarten und methodisch vorgehen.

MfG
 
Ihr könnt ruhig loslegen und machen, denn der Status des Serverumzugs ist ja nun im Rahmen. Wir helfen denk ich gern mit Gedanken und Testereien, so weit möglich :)
 
Hallo,

ihr habt mein Anfänger-Skript ja ordentlich weiter gebracht ;-)
Super Arbeit. Noch besser natürlich wenn es per Default im Freetz integriert ist.

Dazu vielleicht noch eine Idee:
Ich kenne die run_mount nicht. Aber wenn da nicht so viel Hirnschmalz drin steckt, wäre es vielleicht auch möglich, die run_mount komplett zu ersetzen / neu zu schreiben?

Für das Problem mit dem AB:
Reicht es da nicht aus, einen Symlink zu erzeugen?

Gruß,
Hendrik
 
@henfri:
1. Mit deinem Skript hat meine automount-Geschichte eher wenig zu tun. Vielleicht nur die Idee an sich. Die Realisierung ist komplett anders. Es hat auch relativ wenig mit anderen Geschichten, wie udev zu tun.
2. Es kommt mit Sicherheit irgendwann mal rein, wenn ich etwas mehr Zeit habe.
3. run_mount komplett zu ersetzen halte ich für nicht besonders sinnvoll. Da stecken auch andere Sachen von AVM drin. Und nachaffen ohne, dass es auffällig wird, kann man da auch nicht. Wenn wir aber den Aufruf von unserem eigenen Skript da rein integrieren, dann sollte es besser funktionieren...
4. Zum AB. Symlink kann man natürlich erzeugen. Aber es wäre ein Workarround, keine Lösung. Und wenn es anderswie ohne Workarround ginge, sollte man es vermeiden. Sonst weiß man nachher gar nicht mehr, warum es denn nicht geht.

MfG
 
Hallo Hermann,

ich weiß, dass es kaum noch etwas mit meinem Skript zu tun hat.
Deshalb der zwinker. Mein Skript war eine Notlösung. Du hast das 'Not' entfernt ;-)

Gruß,
Hendrik
 
Also ich würds einfach mal gerne testen ;)

So long

Yeti :D
 
@Yeti: Es ist noch nicht testreif. Wenn es so weit wird, dann wird es entweder hier publiziert oder kommt in den trunk rein. Die Idee ist aufgezeigt, jeder darf sie aufgreifen und weiterentwickeln, wenn er etwas mehr Zeit hat. Sonst gilt einfach: Warten.
Diese Geschichte hier greift sehr tief in die Systeminternalien, nämlich auf die mounts. Deswegen muss es vorher gründlich durchdacht werden, bevor man los legt. Und das versuche ich zu tun. Es sind auch Risiken bekannt und erkannt (z.B. AB, external, USB-Root). Und es ist gut, dass ich diese Risiken schon jetzt vorhersehen kann und nicht erst während der Testphase. Wie ich bereits angedeutet hatte, führt es z.B. im Falle von AVM-AB zu einer Reboot-Schleife. Und das will ja auch keiner haben. Deswegen bitte nicht nur "haben wollen", sondern konstruktive Vorschläge bringen, warten oder aktiv mitwirken.

MfG
 
@hermann72pb

Sorry, aber scheinbar hast Du hier was falsch verstanden. Ich will nicht haben, sondern würde es gerne testen - da ist ein großer Unterschied. Test für zu Weiterentwicklung - Haben wollen zu Frustration.

Also wenn Du es jemanden zum testen geben willst, dann biete ich mich an, wenn nicht - auch gut.

So long

Yeti :D
 
Hallo zusammen,

nun hatte ich meine ersten Experimente Richtung automount endlich fortgesetzt. Ich habe eine halbwegs trunkwürdige Version bereits fast fertig und bin gerade am feinschleifen und vorab-testen.

Da meine Bemühungen allerdings in erster Linie dem run_mount gelten, werde ich meine Ergebnisse im run_mount-Thread posten.

Damit ihr allerdings jetzt schon den Vorgeschmack bekommt, poste ich zwei Bilderchen. Das erste ist von der FREETZ-Einstellungsseite. Dort kann man anhacken, dass blkid die Namen anstatt uStorXX nimmt. Dadrunter gibt es ein Feld, in dem man uStorXX in MuellerSchulzeXX umbenennen kann. Selbstverständlich werde ich dafür sorgen, dass per default die neue Namensgebung erstmal deaktiviert ist und MuellerSchulze doch uStor heißt. Man bekommt aber die Möglichkeit zur Umstellung.

Das zweite Bild zeigt noch etwas mehr. Und zwar es beweist, dass meine Methode auch die gewünschten Ergebnisse bringt, wenn das unmount vorher unsauber verlief. Ich hatte meinen Stick ohne wenn und aber abgezogen (unsauberes Unmount). Und anschließend wieder eingesteckt. Interessant war zu beobachten, dass die alten mounts darauf hin alle nacheinander verschwanden und einige Zeit später die neuen kamen. Obwohl mein Stick aufgrund der bekannten Problematik nicht mehr "sda" hieß, sondern "sdb" (s. rote Markierung im Bild), wurden die mountpoints trotzdem "sauber" nach meinen Labels wieder benannt.

Zum weiteren Vorgehen. Ich werde im ersten Schuss nicht alles zu Ende realisieren, was da noch zu tun ist. Trotzdem werde ich die erste Version heute oder morgen im besagten run_mount-Thread publizieren. Das größte Problem für mich besteht darin, sehr viele usbstorage-Patches für diverse Boxen umzuschreiben. Ich werde im ersten Schuss nur 7170, 7270v1/2 und 7270v3 fertig stellen. Für die anderen (inkl. Labors) würde dann die alte Behandlung vom run_mount gelten. Im schlimmsten Fall wird man im WebIF zwar die Einstellungen sehen, sie werden jedoch nichts bewirken, weil die Patches noch nicht fertig sind. Ich denke, dass man damit trotzdem zunächst leben kann und dass die Sache trotzdem trunkwürdig wäre.

MfG
 

Anhänge

  • muellerschulze.jpg
    muellerschulze.jpg
    23.6 KB · Aufrufe: 73
  • autoremount.jpg
    autoremount.jpg
    46.4 KB · Aufrufe: 96
Mach damit aber bitte auch ein Ticket auf, dann hat man das insgesamt besser im Blick. Vor allem aber könnten dann "Freiwillige" die anderne PAtches evtl. gleich mit anpassen und alles an den Thread hängen. (Ok, Wunschdenken meinerseits, aber: Wer weiss....). Danke :)

Gruss

Lars
 
Ja, mache ich. Mit box-info/freetz-info hatte ich es auch so behandelt, dass die patches sowohl in das Ticket auf freetz.org, als auch in den Thread in IPPF kamen.

MfG
 
Hallo Hermann,

die Methode, sich mit tune2fs -L blabla /dev/sda1 für das Device ein eigenes Label zu setzen und dann in /etc/fstab dieses zu verwenden, hast Du beschrieben.
Nun frage ich mich, ob man uStor01 (oder wie auch immer) nicht fest in fstab eintragen kann (sorry, falls die Frage dumm ist).

Auf meiner NSLU2 (NAS) habe ich alle Platten so mit eigenem Label versehen:
Code:
nslu:~# cat /etc/fstab
# /etc/fstab: static file system information.
#
# <file system>         <mount point>           <type>  <options>                               <dump>  <pass>  <device>
proc                    /proc                   proc    defaults                                0       0
LABEL=boot              /boot                   ext2    defaults                                0       2       #/dev/sda1
LABEL=rootfs            /                       ext3    errors=remount-ro,noatime,commit=120    0       1       #/dev/sda2
LABEL=swap              none                    swap    sw                                      0       0       #/dev/sda5
LABEL=backups           /media/backups          ext3    errors=remount-ro,noatime,commit=120    0       1       #/dev/sdd3
Nochmals sorry, falls mein Beitrag unqualifiziert erscheint. In dem Fall danke für's Augenöffnen. ;)
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.