+++ Flash erweiterung mit Mr. Freeze !!! leider nur für OE2.0 +++

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Hmm, ja ok. Das stimmt. Aber macht das auch Sinn? Da Du doch sowieso einen mit
      extfs formatierten Stick benötigst, kannst Du den doch partitionieren und bereits über
      die /etc/fstab als /usr mounten.
      Damit erhältst Du auch Zugriff auf /usr auf dem Stick, brauchst den Stick nur ein mal
      mounten.
      Welchen Vorteil ausser, das Du den Stick nicht partitionieren musst hätte dein
      Vorgehen? Die Frage ist ernst gemeint... ;)

      Du kannst mit Mount ja auch Partitionen in "volle" Verzeichnisse einbinden, so dass es
      keine Rolle spielt, ob das Verzeichnis schon existiert und Daten enthält.
      Mein Vorschlag wäre, den entsprechenden USB-Stick über eine udev-Regel zu erkennen
      und Ihm dann automatisch in die entsprechenden Verzeichnisse zu mounten.
      Damit würde die Box auch starten, wenn der Stick nicht gesteckt ist und wenn der Stick
      gesteckt ist würden die entsprechenden Mountpoints gesetzt....
    • Hmm, ja ok. Das stimmt. Aber macht das auch Sinn? Da Du doch sowieso einen mit
      extfs formatierten Stick benötigst, kannst Du den doch partitionieren und bereits über
      die /etc/fstab als /usr mounten.
      Damit erhältst Du auch Zugriff auf /usr auf dem Stick, brauchst den Stick nur ein mal
      mounten.
      ...

      Naja, wenn man es genau nimmt, musst Du auch hier mindestens zwei mounts durchführen, außer Du hast nicht vor die andere(n) Partition(en) zu benutzen. Kann man machen, würd ich mir wahrscheinlich auch überlegen, wenn ich einen neuen einbinden wollte. Letzten Endes beschränkst Du allerdings wieder deinen Space wie beim internen Speicher.


      ...
      Welchen Vorteil ausser, das Du den Stick nicht partitionieren musst hätte dein
      Vorgehen? Die Frage ist ernst gemeint... ;)
      ...

      Wie ich schon oben angedeutet habe, funktioniert dies sehr einfach für Speichersysteme die schon in Benutzung sind. Da dies doch etwas Zeit in Anpruch nimmt, würde ich das jetzt so machen. Ansonsten müsste ich ersteinmal meine Aufnahmen verschieben, die Timer deaktivieren (um sicher zu gehen, dass keine neuen Aufnahmen hinzukommen), Space löschen, partitionieren, Patitionen formatieren, den ganzen Content (/usr FS und meine alten Daten) wieder entsprechend kopieren und dann natürlich noch ausreichend testen. Hinterher natürlich den/die Timer wieder aktivieren u.s.w.u.s.f. Wie Du siehst, macht auch dieses Vorgehen durchaus Sinn. Auch sollte man bedenken, dass man so nur von der Größe der Hardware beschränkt ist. Wenn Dir die Patition zu klein würde, müsstest Du wieder umpartitionieren. Das andere ist, wenn der Speicher wirklich mal zu 100% voll wäre, könnten unerwartete Nebeneffekte auftreten bei nur einer Partition.

      ...
      Du kannst mit Mount ja auch Partitionen in "volle" Verzeichnisse einbinden, so dass es
      keine Rolle spielt, ob das Verzeichnis schon existiert und Daten enthält.
      Mein Vorschlag wäre, den entsprechenden USB-Stick über eine udev-Regel zu erkennen
      und Ihm dann automatisch in die entsprechenden Verzeichnisse zu mounten.
      Damit würde die Box auch starten, wenn der Stick nicht gesteckt ist und wenn der Stick
      gesteckt ist würden die entsprechenden Mountpoints gesetzt....

      Mhm, ja sicher könnte man das tun. Allerdings will ich eigentlich nicht so weit ins System eingreifen. Normale Einträge in der /etc/fstab reichen bei solchen Systemen eigentlich aus. Es wäre allerdings schön, wenn das VU System wenigstens Block-UUIDs unterstützen würde, um etwas mehr Sicherheit beim Mountvorgang zu haben.

      EDÜT sagt: falscher Butten gedrückt

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von geblubber ()

    • Original von geblubber

      Naja, wenn man es genau nimmt, musst Du auch hier mindestens zwei mounts durchführen, außer Du hast nicht vor die andere(n) Partition(en) zu benutzen. Kann man machen, würd ich mir wahrscheinlich auch überlegen, wenn ich einen neuen einbinden wollte. Letzten Endes beschränkst Du allerdings wieder deinen Space wie beim internen Speicher.

      Ja, ok.


      Wie ich schon oben angedeutet habe, funktioniert dies sehr einfach für Speichersysteme die schon in Benutzung sind. Da dies doch etwas Zeit in Anpruch nimmt, würde ich das jetzt so machen. Ansonsten müsste ich ersteinmal meine Aufnahmen verschieben, die Timer deaktivieren (um sicher zu gehen, dass keine neuen Aufnahmen hinzukommen), Space löschen, partitionieren, Patitionen formatieren, den ganzen Content (/usr FS und meine alten Daten) wieder entsprechend kopieren und dann natürlich noch ausreichend testen. Hinterher natürlich den/die Timer wieder aktivieren u.s.w.u.s.f. Wie Du siehst, macht auch dieses Vorgehen durchaus Sinn. Auch sollte man bedenken, dass man so nur von der Größe der Hardware beschränkt ist. Wenn Dir die Patition zu klein würde, müsstest Du wieder umpartitionieren. Das andere ist, wenn der Speicher wirklich mal zu 100% voll wäre, könnten unerwartete Nebeneffekte auftreten bei nur einer Partition.


      Das müsstest Du doch sowieso machen. Auch bei -bind wird doch der ursprüngliche Inhalt versteckt, so das Du deine Daten kopieren musst. Aber Du musst das natürlich nur einmal alles kopieren, stimmt. Lach, naja. Das lasse ich jetzt nicht gelten. Einen 32GB-Stick mit 3 Partitionen /etc/, /usr/ und /bin bekommst Du nicht voll. :P

      ...
      Mhm, ja sicher könnte man das tun. Allerdings will ich eigentlich nicht so weit ins System eingreifen. Normale Einträge in der /etc/fstab reichen bei solchen Systemen eigentlich aus. Es wäre allerdings schön, wenn das VU System wenigstens Block-UUIDs unterstützen würde, um etwas mehr Sicherheit beim Mountvorgang zu haben.

      Du hast Recht, da stande ich gerade auf dem Schlauch, fehlt der Stick würde ja einfach weiter gearbeitet und die orginalen Daten der / Partition (das wäre allerdings Vorraussetzung das diese unter / gemountet wird) würden verwendet werden....
      Ich habe die UUID's bisher nicht verwendet, es wundert mich allerdings das diese von der VU nicht unterstützt werden. Das ist tatsächlich Mist.

      Gruß

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von s.meier77 ()

    • ...
      Du hast Recht, da stande ich gerade auf dem Schlauch, fehlt der Stick würde ja einfach weiter gearbeitet und die orginalen Daten der / Partition (das wäre allerdings Vorraussetzung das diese unter / gemountet wird) würden verwendet werden....
      Ich habe die UUID's bisher nicht verwendet, es wundert mich allerdings das diese von der VU nicht unterstützt werden. Das ist tatsächlich Mist.
      ...

      Naja, ich weis dies auch nicht sicher. Da leider das blkid Kommando fehlt, hab ich noch nicht rausbekommen, welche UUID mein FS auf dem Stick haben, dann hätte ich das einfach mal getestet. Ich muss mal schauen, was mir alles an Informationen mir das /proc und /dev FS anbieten. Aber ich hab so den Verdacht, dass dies nicht unterstützt ist.
    • Mhm, auf meiner ULTIMO existiert das blkid Kommando nicht. Hab gerade noch mal nachgesehen. Allerdings hab ich noch das 4.1er Image drauf, oder hast Du noch etwas nachinstalliert? Auf der UNO kann ich leider nicht nachsehen, die ist bei meinen Eltern. Im Kernel scheint der UUID Support drin zu sein. Wenn ich ein ls -lAhv /dev/disk/by-uuid absetzte bekomme ich schon mal:

      Quellcode

      1. root@vuultimo:/media/usb# ls -lAhv /dev/disk/by-uuid/
      2. lrwxrwxrwx 1 root root 10 Oct 5 18:51 447c536d-e2c0-4856-b2e6-cee6b81cbc48 -> ../../sdb1
      3. root@vuultimo:/media/usb#
      Ein fstab Entry mit UUID= Anfang bringt aber eine Fehlermeldung. Ich denke mal, dass die BusyBox nicht gegen die libuuid gebunden (also beim Compiling die UUID Option deaktiviert) wurde, und damit das mount-Kommando die Makros nicht kennt.
    • Hmm, ich glaube wir haben aneinander vorbeio geredet. Es gibt noch ein spezielles Kommando,
      welches direkt zu den libs gehört. Dieses heißt /lib/udev/vol_id .
      Das lässt sich ohne Gemecker ausführen, zeigt aber nichts an.

      Das wundert mich. /lib/udev/vol_id gehört zu udev. Wenn der Kernel damit umgehen kann, müsste
      der Befehl etwas anzeigen.

      Das Image ist ein 4.1 ohne Schnickschnack

      Gruß
    • Nun, das kann schon sein. Aber wie ich schon geschrieben habe, kann das mount Kommando Devices mit einem entsprechenden UUID Eintrag in der fstab nicht mounten. Ich hatte später noch das Packet e2fsprogs nachinstalliert, bei dem dann auch das blkid Kommando (ist aber scheinbar ein extra Packet e2fsprogs-blkid) erscheint. Allerdings hab ich noch nicht ausprobiert, ob dies etwas an der mount Problematik ändert.