USB-Stick als Backup

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • hallo,

    nachdem es mir gelungen ist nach

    [Tutorial] Laufwerk/Gerät immer der selben Gerätedateien zuweisen (udev)

    den USB-Stick so einzubinden - tolle Beschreibung!! :) - dass ich es bereits fertig gebracht habe, dort Videos zu speichern, würde ich jetzt gerne auch auf "Backup" zugreifen.

    In diesem Tutorial ist z.B. ein Script /usr/local/bin/backup.sh genannt. Wie würde dies denn aussehen und was würde gesichert? Komplettes System?

    Viele Grüße, Charly

  • Ja, hallo.

    Du hattest ja in Deinem Tutorial das backup mit drin, da hatte ich angenoomen, dass Du auch ein Script dazu hast.

    Man kann ja auch ein backup über win32diskimager ziehen, es wäre aber vielleicht einfacher wenn das ginge ohne jedesmal die SD rumzufummeln.

    Meine Vorstellung, die ja nicht unbedingt sinnvoll sein muss, wäre, gesamte SD sichern. Da aber hier doch noch einiges zu beachten ist, soweit habe ich ja schon mal gelesen, kannst Du ein Script vorschlagen?

    Und ja, finde ich ganz toll was bei Dir so ganz unten steht: "..... indem wir es tun". Hier bin ich auch Spieler, und backups sind auch dazu da ein System zu restaurieren wenn mal eine "Spielerei" in die Hose gegangen ist. Da wäre es wirklich sinnvoll, man könnte dies tun, ohne dass man die SD immer von einem Ort zum anderen stecken muss.... :) Könnte als Anfänger es vielleicht auch mal fertig bringen - geht das?? - den Pi aufzuhängen. Ob er sich dann immer wieder fängt, wenn man Netzstecker zieht/wieder reinsteckt, das weiß ich halt auch nicht.

    Hm. Noch ein Zusatz:

    Ich sichere mein Win-NB mit Acronis. Alle 2-3 Monate wird ein Image gezogen über alle Platten. Dann läuft täglich ein inkrementelles Backup von gewählten Ordnern/Dateien, dabei wird beim ersten Start ein Vollbackup erstellt, die nächsten Tage dann ein inkrementelles.

    Ließe sich sowas - das Voll-Image mal ausgenommen - auch hier machen?

    1. mit ner if-Abfrage,
    2. Zählschleife jeden 5. Tag oder so. DAtum Zeit sollten immer aktuell sein, WLAN ist immer an
    3. oder wie evtl. noch?

    Ne, noch weit davon entfernt selbst Scripts schreiben zu können. Aber für manches kommt schon ein leises Verständnis auf. Wie schrieb meigrafd: ".... indem wir es tutn". :)

    Viele Grüße, Charly

    Einmal editiert, zuletzt von karomue (15. September 2014 um 14:48)

  • Jedesmal die komplette SD zu sichern ist i.d.R. Quatsch und würde auch die SD zu sehr belasten - die verträgt nicht unendlich viele Lese-/Schreib- Zugriffe.

    Sicher lieber nur ein mal die komplette SD, mounte dann das Image und sichere mithilfe von rsync nur noch die Dateien die verändert wurden. Darauf geht zum Beispiel die Anleitung von framp (1.Link) ein. Oder kopiere (mit Owner und Dateirechten) dann nur die Dateien die Dir wichtig sind wie zB /etc/*

    Bezüglich "Image mounten" habe ich auch hier eine Anleitung geschrieben: Festplatten/SD Image unter Linux einbinden/mounten

  • Noch ein Nachtrag: Jo, in den beiden Beiträgen steht ja vielleicht wirklich schon alles drin. Aber:

    Bei "Überwachungscamera" hatte ich Probleme einen Eintrag in die crontab zu bekommen, besser: es ging nicht. Ich meine aber auch so mit einem halben Auge bemerkt zu haben, dass bei wiederholtem Aufruf crontab -e immer "andere" crontabs aufgemacht wurden. Ist das so? Und welches ist die richtige?

    Gerade mal probiert und schon 2 gesehen: 2EwFm und Sdp6ZP. Wenn es nn verschiedene crontabs gibt, woher weiß dann das Sysstem welche geändert und genommen werden muß, oder muß man "eine bestimmte" nehmen, die man dann aber kaum unter crontab -e erreichen kann, oder?

    meigrafd: letztes Posting verstehe ich jetzt nicht - ok, noch nicht wirklich darüber nachgedacht.

    Es ist aber so vorgesehen, auf dem USB-Stick zu sichern, denn der läuft ja jetzt. Und den Pfad habe ich auch, auch wenn der Stick-Ordner einen ungewöhnlichn Namen hat der sich (von mir) auch nicht ändern läßt.

    Und "mounten" zu wissen hat momentan geringe Priorität, denn dank Deines Scripts "mountet" sich der USB-Stick ohne weiteres zutun. :)

    [OT]:))) Wird Deine Signatur per Zufallsgenerator gewählt??[/OT]

    Viele Grüße, Charly

    Einmal editiert, zuletzt von karomue (15. September 2014 um 15:08)


  • Ich meine aber auch so mit einem halben Auge bemerkt zu haben, dass bei wiederholtem Aufruf crontab -e immer "andere" crontabs aufgemacht wurden. Ist das so? Und welches ist die richtige?

    Gerade mal probiert und schon 2 gesehen: 2EwFm und Sdp6ZP. Wenn es nn verschiedene crontabs gibt, woher weiß dann das Sysstem welche geändert und genommen werden muß, oder muß man "eine bestimmte" nehmen, die man dann aber kaum unter crontab -e erreichen kann, oder?

    Nun, es macht halt einen großen Unterschied ob man crontab -e oder sudo crontab -e nutzt, denn über sudo führt man den Befehl als root aus also wäre das dann die crontab des root Benutzers.

    Es wird aber in jedem Fall von dem Befehl zunächst eine temporäre Datei erzeugt, die nach speichern in den jeweiligen Ordner von CRON verschoben wird. Letztlich hat also jeder Benutzer nur ein crontab File.


    Es ist aber so vorgesehen, auf dem USB-Stick zu sichern, denn der läuft ja jetzt. Und den Pfad habe ich auch, auch wenn der Stick-Ordner einen ungewöhnlichn Namen hat der sich (von mir) auch nicht ändern läßt.

    Du sprichst ein wenig in Rätseln. Kann mir darunter nichts vorstellen - den SYMLINK Namen, den man über UDEV für /dev/ einstellt, kann man ebenso wie den Mount-Point selber festlegen :huh:

    Und "mounten" zu wissen hat momentan geringe Priorität, denn dank Deines Scripts "mountet" sich der USB-Stick ohne weiteres zutun. :)

    Den Stick mounten und ein *.img Image mounten sind 2 verschiedene Sachen. Das Image läge auf dem USB-Stick, den du vorher natürlich mounten musst um auf die Image-Datei auf dem Stick zugreifen zu können..


    [OT]:))) Wird Deine Signatur per Zufallsgenerator gewählt??[/OT]

    Ja :D
    Das ist ein PHP Script was bei Aufruf ein anderen Spruch als Bild erzeugt. Siehe dazu >> hier <<. Diese Idee stammt aber von combie, habe das nur adaptiert :fies:

  • meigrafd.

    Nochmal langsam.

    Den usb-stick habe ich nach Deinem Tutorial

    [Tutorial] Laufwerk/Gerät immer der selben Gerätedateien zuweisen (udev)

    eingebunden, dass Script

    Code
    #USB-Stick
    KERNEL=="sd*", SUBSYSTEMS=="usb", ATTRS{idVendor}=="SanDisc Corp.", SYMLINK+="Backup", ACTION=="add", RUN+="/bin/bash /usr/local/bin/backup.sh


    übernommen. Der Stick meldet sich mit


    der Name ist mit 982F-07EF für meine Begriffe schon ungewöhnlich, ich konnte ihn nicht umbenennen. Das die Rechte nicht veränderbar sind, wurde mir schon gesagt.
    Aus Jan Karres "Überwachungskamera" speichere ich jetzt auf den Stick:


    also unter "/media/Video", Video ist ein Ordner auf dem Stick. Die ersten Test-Videos sind gespeichert.

    Und genau auf diesem Stick würde ich auch das Backup speichern wollen. Auf neuem Ordner, vielleicht "Backup".

    Was der SYMLINK Name wirklich "tut" weiß ich momentan noch nicht. Er wurde original aus Deinem Script übernommen.

    Und so ganz nebenbei: das (obige) Überwachungskamera-Script läuft inzwischen ohne die von Dir eingefügten Zeilen, wie im Thread "Compilerfehler" netterweise von Dir angegeben. Warum das so ist, grübel, grübel...

    Viele Grüße, Charly


  • Den usb-stick habe ich nach Deinem Tutorial

    [Tutorial] Laufwerk/Gerät immer der selben Gerätedateien zuweisen (udev)

    eingebunden, dass Script

    Code
    #USB-Stick
    KERNEL=="sd*", SUBSYSTEMS=="usb", ATTRS{idVendor}=="SanDisc Corp.", SYMLINK+="Backup", ACTION=="add", RUN+="/bin/bash /usr/local/bin/backup.sh


    übernommen. Der Stick meldet sich mit


    der Name ist mit 982F-07EF für meine Begriffe schon ungewöhnlich, ich konnte ihn nicht umbenennen. Das die Rechte nicht veränderbar sind, wurde mir schon gesagt.

    Die UDEV Rule legt fest das für ein USB Gerät mit der idVendor = "SanDisc Corp." ein SYMLINK, also eine Verknüpfung, in /dev/ namens Backup angelegt und ein Script ausgeführt wird.

    Irgendeine andere Rule sorgt desweiteren dafür das generell USB Datenträger, mit einer jedesmal anderen Kennung, nach /media/ gemounted wird - in deinem Fall als " 982F-07EF ".

    In dem RUN Script müsstest du also entweder veranlassen das /dev/Backup zunächst zum Beispiel nach /mnt/Backup gemounted wird (das Verzeichnis muss existieren) und anschließend ein backup gemacht wird - oder du legst dir nur ein " usbmount.sh " script an was das Mounten vornimmt, und dann eben über Crontab ein weiteres Script welches prüft "ist mount vorhanden? wenn ja dann führe backup durch..."

    Aus Jan Karres "Überwachungskamera" speichere ich jetzt auf den Stick:

    Bash
    #!/bin/bash
    VIDEODIR="/media/Video"
    VIDEOFILELENGTH=600000 # in miliseconds (default 10 min)
    VIDEOBITRATE=6000000
    VIDEOFPS=4
    VIDEORASPIVIDPARAM=""


    also unter "/media/Video", Video ist ein Ordner auf dem Stick. Die ersten Test-Videos sind gespeichert.

    Einen mount von /media/Video sehe ich in deiner obigen "df -h" Liste aber nicht :huh:
    Bist du sicher das /media/Video/ tatsächlich auf dem USB-Stick ist und nicht vielleicht doch auf der SD - weil eben noch kein Mount gesetzt ist? ;)

  • Du bist gut, schreibst ein Tutorial wie man ext. Geräte über udev-Geschichte einbindet und fragst mich jetzt, der Stick wäre "nicht gemountet" und ob wirklich auf dem Stick und nicht auf der SD gespeichert wäre. Zugegeben, erst war es so, das war ein Fehler den ich aber nicht mehr beschreiben kann. Nachdem ich aber als Pfad " 982F-07EF " eingegeben habe, landete das Video wirklichh auf dem Stick. Verstehen tut ich es nicht wirklich, aber es funktioniert. :)

    Hm, hier in der Schnellantwort kann man offenbar kein Bild anhängen. Muss ich gleich nochmal versuchen.

    Nachtrag des Bildes

  • Wie gesagt, es mag den Ordner /media/Video/ zwar geben aber darauf ist kein Mount eingebunden - deshalb landete eine Aufnahme auch auf der SD, nicht dem USB-Stick ;)
    Deine "df -h" Ausgabe zeigt jedenfalls das es für /media/Video/ keinen Mount gibt.

    In meiner Anleitung wird beschrieben wie der SYMLINK von der UDEV Rule verwendet werden kann - den tust du bisher aber noch nicht benutzen.
    In deiner UDEV Rule hast du SYMLINK+="Backup" stehen, also existiert eine Verknüpfung (Gerätename) /dev/Backup für dein USB-Stick die du mounten kannst - normalerweise über den RUN+= Eintrag bzw über das dortige Script, zum Beispiel: mount /dev/Backup /media/Video

    In meiner Anleitung, ganz am Ende des Beitrags, findest du unter "Weitere Hinweise:" ein paar Links zu Scripts die mit RUN+= ausgeführt werden können...

  • Nein, nein. Ich hatte zunächst einen Fehler gemacht und unter /media mit Umbenennungen herumgespielt. Sagen wir mal, ein blindes Huhn findet auch eine Eichel. Es waren ja irgendwie 3 Ordner da, 982F-07EF, 982F-07EF_, 982F-07EF__. Irgendwie, trial and error, habe ich die mit den "_" gelöscht, den übriggebliebenen umbenannt in Video - warim das ging, ????? - und dann darauf gespeichert. Warum und wie, jedenfalls war es letztlich ein Ordner /media/Video, der war aber auf der SD. Also nochmal, dann den Ordner 982F-07EF ohne Umbenennugsversuche genommen die Scripte angepasst, 2. Versuch. Und natürlich immer wieder den Stick in den Win-PC gestopft und geschaut was drauf ist. Und eben, dann ging es.

    Mir ist der Spur nach schon bekannt was mounten heißt, wie man es wirklich macht - sorry, sehe mir das nach - habe ich nach allen Anleitungen von Dir noch nicht begriffen. Das liegt jetzt sicher daran, dass ich momentan nicht dazu gezwungen bin, denn das Speichern auf dem Stick funktioniert ja.

    Weißt Du, das Hauptproblem ist immer noch und wird es auch noch eine Weile bleiben: Du befindest Dich in einer ganz anderen Ebene, ich bin ja schon sehr froh wenigstens Teile Deiner Beschreibungen zu verstehen. Und ja, ich bin so ein Typ der besser durch learning by doing kapiert. Also werde ich jetzt die nächste Zeit versuchen zunächst ein ganz einfaches Backup auf den Stick zu kriegen. Dann sehen wir weiter, und wenn ich mir dann eine blutige Nase geholt habe, komme ich hier wieder.

    Ja, und es ist natürlich einfacher den Weg des geringsten Widerstandes zu gehen und hier zu fragen. Aber auch dasd führt zu einem Lerneffekt.

    Dann werde ich mich mal mit den beiden Tutorials/Beschreibungen zu Backup beschäftigen. ...

    Viele Grüße, Charly

  • :thumbs1:

    Dann gebe ich dir noch mal was zum dran knabbern :D

    Deine UDEV Rule könnte zum Beispiel so aussehen:

    Code
    ACTION=="add", KERNEL=="sd*", SUBSYSTEMS=="usb", ATTRS{idVendor}=="SanDisc Corp.", SYMLINK+="USBStick", RUN+="/bin/bash /usr/local/bin/usbmount.sh mount /dev/%k"
    ACTION=="remove", KERNEL=="sd*", SUBSYSTEMS=="usb", ATTRS{idVendor}=="SanDisc Corp.", SYMLINK+="USBStick", RUN+="/bin/bash /usr/local/bin/usbmount.sh umount /dev/%k"

    Das hat jeweils 2 Effekte:

    • Beim einstecken des USB-Sticks wird ein zusätzlicher Gerätenamen-Symlink /dev/USBStick erzeugt.

      • Es wird das Script /usr/local/bin/usbmount.sh ausgeführt und der neue Gerätenamen-Symlink ans Script übergeben, sowie das Argument "mount".
    • Beim abziehen des USB-Sticks wird der Mount mithilfe des Scripts entfernt.

    Nun legst du das Script /usr/local/bin/usbmount.sh mit folgendem Inhalt an:

    Sobald jetzt die UDEV Rule greift, weil ein passendes USB Gerät erkannt wurde, wird an das Script der Gerätename und die Anweisung "mount" übergeben. Das Script prüft dann ob das MountTo Verzeichnis existiert und falls nicht wird es angelegt. Anschließend könnte dann ein Backup-Script ausgeführt werden (die Zeile ist zZt auskommentiert wird also ignoriert).

    Bezüglich Backup erzeugen:

    Am einfachsten wärs du erstellst dir über den WindowsPC eine *.img Sicherung, also ein vollständiges Abbild (zB mit dem Tool usbit) deiner SD Karte und legst die Datei auf besagten USB-Stick.

    Nehmen wir jetzt mal an deine Sicherungsdatei heißt rpiBackup.img

    Nun würden wir die Daten-Partition des Images mounten sodass wir veränderte Dateien in das Image aktualisieren können:
    Standardmäßig sind die Partitionsgrößen bei Raspbian überall identisch, also die boot Partition hat immer den startsector 8192 und die Datenpartition ( / ) hat immer den startsector 122880 . Das kannst du aber wie beschrieben ruhig noch mal kontrollieren ;)

    Nun erweitern wir das Script /usr/local/bin/usbmount.sh um ein paar Zeilen die entsprechende Partition des Backup-Images zu mounten, sodass das Script dann so aussähe:

    Damit mountet er die 2.Partition vom Image nach ImageTo und du kannst auf die Dateien ganz normal zugreifen, verändern, überschreiben oder sogar löschen. Sobald du den Stick wieder entfernst sind alle Veränderungen die in /media/rpiBackupRoot/ gemacht wurden auch im Image rpiBackup.img und wenn du das dann auf die SD spielen würdest hättst du eben die Veränderungen...

    Nun müsstest du noch ein Script basteln was mithilfe von rsync nur die veränderten Dateien regelmäßig (über crontab) nach ImageTo schreibt.... Aber dazu ggf später mehr ;)

    Viel Erfolg :fies:

  • Uff.

    Gem. Deiner letzten 2 Worte: wir hoffens.

    Ist um diese Zeit ein wenig viel, das braucht Zeit um es zu verdauen. na gut, zu versuchen. Wir werden sehen.

    Versucht wird es auf jeden Fall, so wie es da steht.

    Ein großes Danke und gute Nacht. Über denn netten Spruch in Deiner Signatur kann man aber auch nachdenken. Kch bin aber ganz zufrieden mit Antworten...

    Viele Grüße, Charly

    Einmal editiert, zuletzt von karomue (16. September 2014 um 00:55)

  • Ich lese gerade mal ein wenig quer in wicki.unbuntuusers unter udev. Und stelle fest:

    Da erhebt sich jetzt bei mir die Frage, nachdem sich der Stick ja durch das udev-Script von meigrafd "selbst" mountet (und beim Abziehen wohl auch unmountet) warum nochmal explizit mounten? Ist das dann nicht ein weißer Schimmel oder ist das letzte Script von meigrafd einfach "besseres" Programmieren? Oder, was ja auch sein kann, man hat damit mehr Möglichkeiten einzugreifen. ???

    Es kann aber auch sein - bestätigt das jemand?? - dass durch explizites mounten/unmounten vermieden wird, was ich so als Fehler interpretieren würde:

    Vor allem die letzte Zeile stört mich schon ein wenig, könnte das zu Schwierigkeitn führen wenn ich einfach "so" weitermache und Daten (ohne mount) auf den Stick speichere?

    Noch was fällt mir auf: mir lsusb -vs 004 bekomme ich lediglich idVendor. Im syslog stehen aber auch

    Code
    New USB device fou                                              nd, idVendor=0781, idProduct=556b


    und

    Code
    Sep 16 14:44:36 raspberrypi kernel: [ 1395.560690] usb 1-1.2: SerialNumber: 2005                                              3247201B6B9188B4

    Sind das die Angaben, die in der udev-Regel benutzt werden können? (Falls mal ein 2. SanDisk-Stick zum Einsatz käme, denn dann bräuchte man ja eine Unterscheidung.

    Viele Grüße, Charly

    Einmal editiert, zuletzt von karomue (16. September 2014 um 14:57)

  • So, weiter mit "lernen".

    Ich habe jetzt gem. Beitrag 12 die udev.rule geändert,

    Code
    #USB-Stick
    ACTION=="add", KERNEL=="sd*", SUBSYSTEMS=="usb", ATTRS{idVendor}=="SanDisc Corp.", ATTRS{serial}=="20053247201B6B9188B4", SYMLINK+="USBStick", RUN+="/bin/bash /usr/local/bin/usbmount.sh mount /dev/%k
    ACTION=="remove", KERNEL=="sd*", SUBSYSTEMS=="usb", ATTRS{idVendor}=="SanDisc Corp.", ATTRS{serial}=="20053247201B6B9188B4", SYMLINK+="USBStick", RUN+="/bin/bash /usr/local/bin/usbmount.sh umount /dev/%k

    und ein neues Script


    trotzdem commt in dmesg immer noch

    Volume was not properly unmounted...

    Jetzt bitte zum Verständnis:

    1. wie läßt sich das prüfen
    2. was bedeutet, bewirkt "MountTo=/media/Daten"
    3. was ist/sind "ACTION=$1
    DEVICE=$2
    4. " [ ! -d $MountTo ] && mkdir -p $MountTo
    /bin/mount $DEVICE $MountTo" soll ein Direktory erstellen, tut es bei mir wohl nicht, zumindest finde ich unter 7bin7mount kein Direktory.

    Was mache ich falsch, bzw was bedeutet obiges, was soll es tun und wie finde ich es?

    Danke.

    Viele Grüße, Charly

  • Code
    #USB-Stick
    ACTION=="add", KERNEL=="sd*", SUBSYSTEMS=="usb", ATTRS{idVendor}=="SanDisc Corp.", ATTRS{serial}=="20053247201B6B9188B4", SYMLINK+="USBStick", RUN+="/bin/bash /usr/local/bin/usbmount.sh mount /dev/%k
    ACTION=="remove", KERNEL=="sd*", SUBSYSTEMS=="usb", ATTRS{idVendor}=="SanDisc Corp.", ATTRS{serial}=="20053247201B6B9188B4", SYMLINK+="USBStick", RUN+="/bin/bash /usr/local/bin/usbmount.sh umount /dev/%k

    Wo man " öffnet muss man sie auch wieder schließen - wie zuvor auch schon fehlen bei dir aber die letzten "


    1. wie läßt sich das prüfen

    Mit dem Befehl fsck . Musst das Laufwerk aber vorher umount'n damit du dir nix kaputt machst.

    2. was bedeutet, bewirkt "MountTo=/media/Daten"

    Es wird eine Variable MountTo mit dem Inhalt /media/Daten gesetzt. MountTo -> Mount To -> wohin es gemountet werden soll ..

    3. was ist/sind "ACTION=$1
    DEVICE=$2

    Allgemein üblich sind Parameter oder auch Argumente (args), die an ein Script/Programm übergeben werden durch Leerzeichen getrennt.
    Zum Beispiel wäre ls der Befehl -la das erste Argument und /tmp das zweite Argument.

    Gleiches Spiel wie gerade: Es wird eine Variable ACTION mit dem Inhalt des ersten Arguments gesetzt.

    4. " [ ! -d $MountTo ] && mkdir -p $MountTo
    /bin/mount $DEVICE $MountTo" soll ein Direktory erstellen, tut es bei mir wohl nicht, zumindest finde ich unter 7bin7mount kein Direktory.

    /bin/mount ist kein Verzeichnis sondern der Befehl der ausgeführt wird.
    Es wird also /bin/mount mit den Argumenten $DEVICE und $MountTo aufgerufen; zum Beispiel: /bin/mount /dev/USBStick /media/Daten

  • Wo man " öffnet muss man sie auch wieder schließen - wie zuvor auch schon fehlen bei dir aber die letzten "


    Schäm....

    Das hätte nicht passieren dürfen, Tomaten auf den Augen...

    Rest brauch ich wieder etwas Ruhe :)
    Danke meigrafd. [/u]

    Viele Grüße, Charly

  • Über fsck müssen wir und gelegntlich auch mal unterhalten. Momentan plagt mich was anderes.

    Ich habe (nach Neustart) mal die komplette dmesg angehängt, dazu als erstes mal die Frage, was bedeuten die Zahlen am Anfang jeder Zeile in [] ? Es sind wohl Zeitangaben, sind die interpretierbar?

    Jetzt zum Inhalt. Der erste teil bis 183... sind wohl allg. Kernelmeldungen, wieweit die hier jetzt interessant sind weiß ich nicht. Bei 183 wurde der usb-Stick - war bei Neustart gesteckt - gezogen, zur nächsten Zeit wieder gesteckt. Der "unmount"-Fehlermeldung kommt nach wie vor, das Script sollte aber jetzt fehlerfrei sein. Da ist immer noch ein Hund begraben.

    Die Info über "man -k dmesg": "print or control the kernel ring buffer" ist ja auch sehr aufschlßreich....

    Nochmal zum Script:


    Verständnis immer noch nicht viel besser. Was steckt in $1, in $2? Ganz dunkel habe ich da noch was nebulöses im Kopf von meinen gescheiterten C...-Versuchen, bringe das aber nicht mehr zusammen. Argumente ok. welche?

    Und was willst du mir mit

    Code
    Zum Beispiel wäre ls der Befehl -la das erste Argument und /tmp das zweite Argument.


    sagen?

    Wieder reingeflogen, bei der Schnellantwort kann man offenbar keine Anhänge anhängen.

    Übrigens: ist es statthaft bei Scrips auch Kommentare an eine zeile anzuhängen?

  • was bedeuten die Zahlen am Anfang jeder Zeile in [] ? Es sind wohl Zeitangaben, sind die interpretierbar?

    Das ist die Zeit (Sekunden) die seit dem Starten vergangen ist und ja, durch ein Script ließe sich das "menschlich lesbar" darstellen:

    Spoiler anzeigen

    sudo nano /usr/local/bin/DMESG && chmod +x /usr/local/bin/DMESG

    Zum Ausführen einfach DMESG in der Konsole eingeben.


    Nochmal zum Script:


    Verständnis immer noch nicht viel besser. Was steckt in $1, in $2? Ganz dunkel habe ich da noch was nebulöses im Kopf von meinen gescheiterten C...-Versuchen, bringe das aber nicht mehr zusammen. Argumente ok. welche?

    Und was willst du mir mit

    Code
    Zum Beispiel wäre ls der Befehl -la das erste Argument und /tmp das zweite Argument.


    sagen?

    Das hängt zusammen.
    Wie ich bereits versucht habe zu erklären ist das erste Argument was man an ein Script übergibt in $1 hinterlegt, das zweite Argument in $2, das dritte in $3 usw.
    Im Fall der UDEV Rule bedeutet das:

    /usr/local/bin/usbmount.sh ist das Script was ausgeführt wird
    mount ist das 1. Argument was an das Script übergeben wird
    /dev/%k ist das 2.Argument, wobei %k von UDEV mit dem aktuellen Gerätenamen ersetzt wird, das ist quasi eine art Platzhalter.

    Übrigens: ist es statthaft bei Scrips auch Kommentare an eine zeile anzuhängen?

    Wenn man das Kommentar auskommentiert, ja


    Ich hab mir deine dmesg noch nicht angeguckt, hole ich gleich nach...

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!