USB-Stick per Script formatieren (mit mount-Problem)
Ein USB-Stick wird gezwungener Maßen auf mit Malware verseuchten Windows-Rechnern verwendet. Daher soll dieser per Script "gelöscht" werden und anschließend sollen vordefinierte Daten wieder darauf kopiert werden. Das 1. Problem ist, wie identifiziere ich den Stick eindeutig? smartctl -d scsi -i /dev/sdc ... Device: Hama CardReaderMMC/SD Version: 1.9C Serial number: (keine Angabe) smartctl -d scsi -i /dev/sde ... Device: SWISSBIT Twist Version: 2.00 Serial number: (beim Stick wird das gar nicht gelistet) fdisk -l | grep /dev/sd | grep -v "Disk" | cut -c1-8 | xargs -r -n1 smartctl -d scsi -i | grep -i "Device:" | cut -f2 -d" " Hama SWISSBIT Irgendwie kann smartctl schon auswerten, aber damit kann ich nicht viel anfangen. Ich möchte, nachdem der Stick _eindeutig_ erkannt wurde, diesen mit badblocks löschen, Ich muss also das Device, das je nach Rechner unterschiedlich sein kann, sicher einer Kennung des USB-Sticks zuordnen, damit in diesem Fall badblocks -svw /dev/hde ausgeführt werden kann. Eventuell hilft mkdosfs volume-id? Badblocks will ich deswegen verwenden, weil damit auch Bootsektoren überschrieben werden und damit Malware sicher vernichtet ist. Es dauert auch nicht so lange wie Malware prüfen. Nächstes Problem ist, dass der Stick zumindest mit yast nach einem umount nicht formatiert werden kann. Wie kann ich folgendes per Script ausführen fdisk /dev/sde d(elete) - alle Partitionen sollen gelöscht werden (theoretisch Frage, nach badblocks brauche ich das ja nicht mehr) n - 1 neue primäre Partition Typ b anlegen zB mkdosfs -F 32 -c - -n "SWISSBIT64" /dev/sde1 sollte dann problemlos laufen. Al
Am Montag, 16. Oktober 2006 17:21 schrieb Al Bogner:
Ein USB-Stick wird gezwungener Maßen auf mit Malware verseuchten Windows-Rechnern verwendet. Daher soll dieser per Script "gelöscht" werden und anschließend sollen vordefinierte Daten wieder darauf kopiert werden.
Wieso machst du nicht einfach ein Image mit dd und bügelst das dann wieder zurück? Nachdem du den Stick eindeutig erkannt hast. Wie das geht, und wie du das dann dd beibringst müssen dir andere sagen. MFG Markus
Am Montag, 16. Oktober 2006 19:07 schrieb Markus Wunder:
Am Montag, 16. Oktober 2006 17:21 schrieb Al Bogner:
Ein USB-Stick wird gezwungener Maßen auf mit Malware verseuchten Windows-Rechnern verwendet. Daher soll dieser per Script "gelöscht" werden und anschließend sollen vordefinierte Daten wieder darauf kopiert werden.
Wieso machst du nicht einfach ein Image mit dd und bügelst das dann wieder zurück? Nachdem du den Stick eindeutig erkannt hast. Wie das geht, und wie du das dann dd beibringst müssen dir andere sagen.
An ein Image habe ich auch schon gedacht, ich frage jetzt einfach mal danach wie man den von mir vorgeschlagenen Weg löst. Zur Identifikation des Sticks könnte eventuell lshal hilfreich sein. Ich weis aber nicht, wie man "usb_device.serial" auf /dev/sdx umlegt. Al
Am Montag, 16. Oktober 2006 19:47 schrieb Al Bogner:
Zur Identifikation des Sticks könnte eventuell lshal hilfreich sein. Ich weis aber nicht, wie man "usb_device.serial" auf /dev/sdx umlegt.
Ich denke, ich habe die Lösung für den ersten Teil: fdisk -l | grep /dev/sd | grep -v "Disk" | cut -c1-8 | xargs \ -r -n1 udevinfo -q env -n | grep "ID_SERIAL" ID_SERIAL=Hama_CardReaderMMC.SD_ABCD12xxxxxx ID_SERIAL=SWISSBIT_Twist_40479E4643xxxxxx Die Frage ist nun, wie ich möglichst effizient alle Devices scanne und unter der Bedingung "ID_SERIAL=SWISSBIT_Twist_40479E4643xxxxxx" weitere Befehle ausführe. Al
Hallo, Am Die, 17 Okt 2006, Al Bogner schrieb:
Am Montag, 16. Oktober 2006 19:47 schrieb Al Bogner:
Zur Identifikation des Sticks könnte eventuell lshal hilfreich sein. Ich weis aber nicht, wie man "usb_device.serial" auf /dev/sdx umlegt.
Ich denke, ich habe die Lösung für den ersten Teil:
fdisk -l | grep /dev/sd | grep -v "Disk" | cut -c1-8 | xargs \ -r -n1 udevinfo -q env -n | grep "ID_SERIAL"
ID_SERIAL=Hama_CardReaderMMC.SD_ABCD12xxxxxx ID_SERIAL=SWISSBIT_Twist_40479E4643xxxxxx
Die Frage ist nun, wie ich möglichst effizient alle Devices scanne und unter der Bedingung "ID_SERIAL=SWISSBIT_Twist_40479E4643xxxxxx" weitere Befehle ausführe.
for d in `fdisk -l | awk '/^\/dev\/sd/ { print $1; }'`; do eval `udevinfo -q env -n "$d" | grep 'ID_SERIAL'` case "$ID_SERIAL" in Hama_CardReaderMMC.SD_ABCD12xxxxxx) : machwas mit dem Hama ;; SWISSBIT_Twist_40479E4643xxxxxx) : machwas mit dem Swissbit ;; esac done Wenn die "machwas" mehr als 2-4 Zeilen gross werden ist es sinnvoll, diese in eine Funktion auszulagern. HTH, -dnh -- Contrary to popular belief, Unix is user friendly. It just happens to be very selective about who its friends are. -- Kyle Hearn
Hallo. * Dienstag, 17. Oktober 2006 um 00:18 (+0200) schrieb Al Bogner:
Die Frage ist nun, wie ich möglichst effizient alle Devices scanne und unter der Bedingung "ID_SERIAL=SWISSBIT_Twist_40479E4643xxxxxx" weitere Befehle ausführe.
Du legst dir eine "/etc/udev/rules.d/53-my-usb.rules" an, mit dem Inhalt:
BUS=="usb", ENV{ID_SERIAL}=="SWISSBIT_Twist_40479E4643xxxxxx", RUN+="
Am Dienstag, 17. Oktober 2006 00:49 schrieb David Haller:
Hallo,
Am Die, 17 Okt 2006, Al Bogner schrieb:
Am Montag, 16. Oktober 2006 19:47 schrieb Al Bogner:
Zur Identifikation des Sticks könnte eventuell lshal hilfreich sein. Ich weis aber nicht, wie man "usb_device.serial" auf /dev/sdx umlegt.
Ich denke, ich habe die Lösung für den ersten Teil:
fdisk -l | grep /dev/sd | grep -v "Disk" | cut -c1-8 | xargs \ -r -n1 udevinfo -q env -n | grep "ID_SERIAL"
ID_SERIAL=Hama_CardReaderMMC.SD_ABCD12xxxxxx ID_SERIAL=SWISSBIT_Twist_40479E4643xxxxxx
Die Frage ist nun, wie ich möglichst effizient alle Devices scanne und unter der Bedingung "ID_SERIAL=SWISSBIT_Twist_40479E4643xxxxxx" weitere Befehle ausführe.
for d in `fdisk -l | awk '/^\/dev\/sd/ { print $1; }'`; do eval `udevinfo -q env -n "$d" | grep 'ID_SERIAL'` case "$ID_SERIAL" in Hama_CardReaderMMC.SD_ABCD12xxxxxx)
: machwas mit dem Hama
;; SWISSBIT_Twist_40479E4643xxxxxx)
: machwas mit dem Swissbit
;; esac done
Wenn die "machwas" mehr als 2-4 Zeilen gross werden ist es sinnvoll, diese in eine Funktion auszulagern.
Hallo David, ich hatte auch schon überlegt es mit eval zu machen, aber mit awk bzw. Regex bin ich nicht so befreundet, weil ich es _unbedingt_ so selten brauche. ;-) machwas wird vermutlich länger werden, bis auf das exit, falls kein bekannter Stick vorhanden ist. Ich denke ich schreibe einfach eine Bedinung rein und wie die erfüllt ist wird später der Stick mit bestimmten Daten beschrieben. Das Partitionieren bzw. Formatieren sollte immer ident sein, nur eben die Größe der Sticks ist unterschiedlich. Wenn kein Stick erkannt wurde, wird das Script beendet. Ich frage mich zur Zeit, wie ich formatieren soll. Mit parted oder fdisk? Bei fdisk müsste ich etwas mit "<" machen. fdisk /dev/hda < partinfo_$ID Es müsste irgendwie so gehen: cat "partinfo_$ID" << partinfo bla bla partinfo Ich bin mir nur nicht klar, wie ich das mache, ohne eine Datei anzulegen. Da Testen als root mit Partitonieren nicht ungefährlich ist, suche ich nach Beispielen, was ich da genau als Text übergeben muss. Es wurde jedenfalls mit badblocks vorher "gelöscht", sodass keine Partitionstabelle vorhanden ist. Ich will also 1 primäre Partition anlegen, Würde das ok sein: n p 1 t b Also new - primär - 1. Partition - Tyb - FAT32 Oder sollte ich es besser mit parted machen? Der Vorteil von fdisk ist, dass es wahrscheinlicher installiert ist. Al
Hallo, Am Die, 17 Okt 2006, Al Bogner schrieb:
Am Dienstag, 17. Oktober 2006 00:49 schrieb David Haller:
Am Die, 17 Okt 2006, Al Bogner schrieb:
Am Montag, 16. Oktober 2006 19:47 schrieb Al Bogner:
Zur Identifikation des Sticks könnte eventuell lshal hilfreich sein. Ich weis aber nicht, wie man "usb_device.serial" auf /dev/sdx umlegt.
Ich denke, ich habe die Lösung für den ersten Teil:
fdisk -l | grep /dev/sd | grep -v "Disk" | cut -c1-8 | xargs \ -r -n1 udevinfo -q env -n | grep "ID_SERIAL"
ID_SERIAL=Hama_CardReaderMMC.SD_ABCD12xxxxxx ID_SERIAL=SWISSBIT_Twist_40479E4643xxxxxx
Die Frage ist nun, wie ich möglichst effizient alle Devices scanne und unter der Bedingung "ID_SERIAL=SWISSBIT_Twist_40479E4643xxxxxx" weitere Befehle ausführe.
for d in `fdisk -l | awk '/^\/dev\/sd/ { print $1; }'`; do eval `udevinfo -q env -n "$d" | grep 'ID_SERIAL'`
Fuer den ersten Teil solltest du wohl den Vorschlag von Andreas uebernehmen, AFAIK muesste das Script die ID_SERIAL per Umgebung bekommen. Mach zu Andreas' Vorschlag ein Testscript, das ID_SERIAL ausgibt.
case "$ID_SERIAL" in Hama_CardReaderMMC.SD_ABCD12xxxxxx) : machwas mit dem Hama ;; SWISSBIT_Twist_40479E4643xxxxxx) : machwas mit dem Swissbit ;; esac done
Wenn die "machwas" mehr als 2-4 Zeilen gross werden ist es sinnvoll, diese in eine Funktion auszulagern.
[..] machwas wird vermutlich länger werden, bis auf das exit, falls kein bekannter Stick vorhanden ist. Ich denke ich schreibe einfach eine Bedinung rein und wie die erfüllt ist wird später der Stick mit bestimmten Daten beschrieben. Das Partitionieren bzw. Formatieren sollte immer ident sein, nur eben die Größe der Sticks ist unterschiedlich. Wenn kein Stick erkannt wurde, wird das Script beendet.
Ich frage mich zur Zeit, wie ich formatieren soll. Mit parted oder fdisk?
Weder noch. sfdisk ist darauf angelegt nicht-interaktiv verwendet zu werden.
Ich bin mir nur nicht klar, wie ich das mache, ohne eine Datei anzulegen.
man sfdisk ;)
Da Testen als root mit Partitonieren nicht ungefährlich ist, suche ich nach Beispielen, was ich da genau als Text übergeben muss.
Remounte die Partitionen ro und mach ein 'chmod a-w' auf die Festplattendevices /dev/hd*.
Es wurde jedenfalls mit badblocks vorher "gelöscht", sodass keine Partitionstabelle vorhanden ist.
ein 'dd if=/dev/zero' auf die ersten MB sollte reichen. Oder willst du gleich noch auf Defekte testen? -dnh -- 163: SMD Schwer Montierbare Dinger (Holger Köpke)
Am Dienstag, 17. Oktober 2006 21:38 schrieb David Haller: Hallo David!
Die Frage ist nun, wie ich möglichst effizient alle Devices scanne und unter der Bedingung "ID_SERIAL=SWISSBIT_Twist_40479E4643xxxxxx" weitere Befehle ausführe.
for d in `fdisk -l | awk '/^\/dev\/sd/ { print $1; }'`; do eval `udevinfo -q env -n "$d" | grep 'ID_SERIAL'`
Fuer den ersten Teil solltest du wohl den Vorschlag von Andreas uebernehmen, AFAIK muesste das Script die ID_SERIAL per Umgebung bekommen.
___________________________________________________________________________________ Am Dienstag, 17. Oktober 2006 12:05 schrieb Andreas Koenecke:
Du legst dir eine "/etc/udev/rules.d/53-my-usb.rules" an, mit dem Inhalt:
BUS=="usb", ENV{ID_SERIAL}=="SWISSBIT_Twist_40479E4643xxxxxx", RUN+="
"
Zum einen habe ich Andreas Vorschlag noch nicht ganz kapiert: Würde
RUN+="
man sfdisk ;)
Vielen Dank.
Es wurde jedenfalls mit badblocks vorher "gelöscht", sodass keine Partitionstabelle vorhanden ist.
ein 'dd if=/dev/zero' auf die ersten MB sollte reichen. Oder willst du gleich noch auf Defekte testen?
Die Praxis wird es zeigen, aber ich denke, dass eine Prüfung des gesamten Sticks auch zeitlich akzeptabel ist. Mit meinem 64MB-Teststick war die Dauer jedenfalls kein Thema. Sobald der erste 1GB-Stick neu installiert werden muss, denke ich vielleicht dann anders. Wenn das 20 Minuten dauert, ist das ok. Es kann ja im Hintergrund laufen, während an etwas anderes gearbeitet wird. Es wird ja hoffentlich auch nicht so oft notwendig sein, den Stick zu löschen, aber das hängt natürlich auch damit zusammen, wie verseucht die Rechner sind, an den der Stick verwendet wird. Al
Hallo. * Mittwoch, 18. Oktober 2006 um 14:06 (+0200) schrieb Al Bogner:
___________________________________________________________________________________ Am Dienstag, 17. Oktober 2006 12:05 schrieb Andreas Koenecke:
Du legst dir eine "/etc/udev/rules.d/53-my-usb.rules" an, mit dem Inhalt:
BUS=="usb", ENV{ID_SERIAL}=="SWISSBIT_Twist_40479E4643xxxxxx", RUN+="
"
Zum einen habe ich Andreas Vorschlag noch nicht ganz kapiert: Würde RUN+="
" das Script bei Einstecken des Sticks automatisch starten?
Ja!
Das will ich nämlich keinesfalls.
Dann vergiss die obige udev-Regel. Aber evtl. könntest du mit leicht geänderter Regel BUS=="usb", ENV{ID_SERIAL}=="SWISSBIT_Twist_40479E4643xxxxxx", SYMLINK+="mein_swissbit" einen Symlink auf den (Kernel-)Device-Namen in /dev anlegen lassen, mit dem dein Partitionier-/Formatier-Skript arbeiten kann.
Zum anderen, soll das Script auf mehreren Rechnern laufen und ich will nicht so gerne überall eine udev-Regel installieren.
Ok, das spricht natürlich auch gegen die geänderte Regel... Gruß Andreas -- XMMS spielt gerade nichts... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
Am Mittwoch, 18. Oktober 2006 14:45 schrieb Andreas Koenecke:
Aber evtl. könntest du mit leicht geänderter Regel
BUS=="usb", ENV{ID_SERIAL}=="SWISSBIT_Twist_40479E4643xxxxxx", SYMLINK+="mein_swissbit"
einen Symlink auf den (Kernel-)Device-Namen in /dev anlegen lassen, mit dem dein Partitionier-/Formatier-Skript arbeiten kann.
Zum anderen, soll das Script auf mehreren Rechnern laufen und ich will nicht so gerne überall eine udev-Regel installieren.
Ok, das spricht natürlich auch gegen die geänderte Regel...
Ich verstehe überhaupt nicht, was die Regel unter Annahme _eines_ Rechners bringen würde. Ich sehe es als eine Variante, aber nicht als Vorteil, oder übersehe ich da etwas? Al
Hallo. * Mittwoch, 18. Oktober 2006 um 15:02 (+0200) schrieb Al Bogner:
Am Mittwoch, 18. Oktober 2006 14:45 schrieb Andreas Koenecke:
Aber evtl. könntest du mit leicht geänderter Regel
BUS=="usb", ENV{ID_SERIAL}=="SWISSBIT_Twist_40479E4643xxxxxx", SYMLINK+="mein_swissbit"
einen Symlink auf den (Kernel-)Device-Namen in /dev anlegen lassen, mit dem dein Partitionier-/Formatier-Skript arbeiten kann.
Ich verstehe überhaupt nicht, was die Regel unter Annahme _eines_ Rechners bringen würde.
Dein Skript könnte sich vereinfachen: Wenn der USV-Stick mit obiger ID_SERIAL eingesteckt ist (und nur dann) wird ein Symlink "/dev/mein_swissbit" auf das entsprechende Kernel-Device "/dev/sdX" erzeugt. Dein Skript könnte nun direkt mit diesem Symlink "arbeiten", z.B.: 'mkfs.vfat ... /dev/mein_swissbit' o.ä. Du müsstest im Skript nicht mehr das Device suchen/prüfen.
Ich sehe es als eine Variante, aber nicht als Vorteil, oder übersehe ich da etwas?
Nein. Es ist natürlich nur eine Variante. Gruß Andreas -- XMMS spielt gerade nichts... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
Hallo, Am Mit, 18 Okt 2006, Al Bogner schrieb:
Am Dienstag, 17. Oktober 2006 21:38 schrieb David Haller:
Die Frage ist nun, wie ich möglichst effizient alle Devices scanne und unter der Bedingung "ID_SERIAL=SWISSBIT_Twist_40479E4643xxxxxx" weitere Befehle ausführe.
for d in `fdisk -l | awk '/^\/dev\/sd/ { print $1; }'`; do eval `udevinfo -q env -n "$d" | grep 'ID_SERIAL'` [..] Zum einen habe ich Andreas Vorschlag noch nicht ganz kapiert: Würde RUN+="
" das Script bei Einstecken des Sticks automatisch starten? Das will ich nämlich keinesfalls.
AFAIK ja.
Ich denke die "for/case"-Variante sollte schon reichen. Da kann ich dann an jedem Rechner das Script ausführen, ohne etwas konfigurieren zu müssen.
Jep. BTW: die Ausgabe von udevinfo ist ja in der Form ID_SERIAL=blablubb und das ist praktisch fuer 'eval'. Alternativ und sicherer kannst du (ungetestet) sowas verwenden: [..]; do ID_SERIAL="`udevinfo -q env -n \"$d\" | \ sed -n '/ID_SERIAL/s/ID_SERIAL=\(.*\)/\1/'`" HTH, -dnh -- [die 1970er Jahre] Die Zeit, in der Joschka Fischer seine kriminelle Karierre beendete, und Helmut Kohl seine so richtig durchstartete... -- Matthias Brodowy im "SR Gesellschaftsabend"
Am Mittwoch, 18. Oktober 2006 20:23 schrieb David Haller: Hallo David,
Jep. BTW: die Ausgabe von udevinfo ist ja in der Form ID_SERIAL=blablubb und das ist praktisch fuer 'eval'. Alternativ und sicherer kannst du (ungetestet) sowas verwenden:
[..]; do ID_SERIAL="`udevinfo -q env -n \"$d\" | \ sed -n '/ID_SERIAL/s/ID_SERIAL=\(.*\)/\1/'`"
Was spricht dagegen mit der _kompletten_ Augabe von ID_SERIAL zu vergleichen? dann wird der Code lesbarer, weil ja der Hersteller auch enthalten ist. Ich finde zB "SWISSBIT_Twist_40479E4643xxxxxx" bei if oder case verständlicher als "40479E4643xxxxxx" Al
Am Dienstag, 17. Oktober 2006 21:38 schrieb David Haller: Hallo David,
Ich bin mir nur nicht klar, wie ich das mache, ohne eine Datei anzulegen.
man sfdisk ;)
Ok, wenn ich es richtig verstanden habe, dann würde ich (nur) 1 FAT32-Partition so erstellen: sfdisk /dev/sdx << EOF ,,b EOF Da ich die genaue Größe gar nicht kenne, kann ich mir also die Option -uM sparen, da alles die 1. Partition sein soll, brauche ich keinen Anfang bzw. kein Ende angeben, einzig der Typ der Partition ist wichtig. Habe ich da einen Gedankenfehler? Al
Hallo, Am Mit, 18 Okt 2006, Al Bogner schrieb:
Am Mittwoch, 18. Oktober 2006 20:23 schrieb David Haller:
Jep. BTW: die Ausgabe von udevinfo ist ja in der Form ID_SERIAL=blablubb und das ist praktisch fuer 'eval'. Alternativ und sicherer kannst du (ungetestet) sowas verwenden:
[..]; do ID_SERIAL="`udevinfo -q env -n \"$d\" | \ sed -n '/ID_SERIAL/s/ID_SERIAL=\(.*\)/\1/'`"
Was spricht dagegen mit der _kompletten_ Augabe von ID_SERIAL zu vergleichen?
Ist es doch. Alles ab dem '='. Das ist ne effektivere Variante von: sed -n 's/ID_SERIAL=\(.*\)/\1/' da ich nicht weiss, was udevinfo sonst noch alles ausspuckt. -dnh -- F: Was sagt ein frisch Assimilierter zu seinem Ex-Captain? A: SCNR [Bernd Reinecke]
Hallo, Am Don, 19 Okt 2006, Al Bogner schrieb:
Am Dienstag, 17. Oktober 2006 21:38 schrieb David Haller:
Ich bin mir nur nicht klar, wie ich das mache, ohne eine Datei anzulegen.
man sfdisk ;)
Ok, wenn ich es richtig verstanden habe, dann würde ich (nur) 1 FAT32-Partition so erstellen:
sfdisk /dev/sdx << EOF ,,b EOF
Da ich die genaue Größe gar nicht kenne, kann ich mir also die Option -uM sparen, da alles die 1. Partition sein soll, brauche ich keinen Anfang bzw. kein Ende angeben, einzig der Typ der Partition ist wichtig.
Jup. Aktivieren willst du auch nicht und Geometrie sollte erkannt / vom Kernel uebernommen werden.
Habe ich da einen Gedankenfehler?
Ich glaube nicht. Evtl. Typ 0x0c "Win95 FAT32 (LBA)" statt 0x0b "Win95 FAT32". Ich selbst habe sfdisk noch nicht verwendet, aber du kannst ja erstmal mit '-n' testen. Oder an nem Image (da musst du dann aber mit -C / -H / -S eine Geometrie angeben). -dnh -- Some people have no repect of age unless it is bottled.
Am Dienstag, 17. Oktober 2006 00:49 schrieb David Haller:
Die Frage ist nun, wie ich möglichst effizient alle Devices scanne und unter der Bedingung "ID_SERIAL=SWISSBIT_Twist_40479E4643xxxxxx" weitere Befehle ausführe.
for d in `fdisk -l | awk '/^\/dev\/sd/ { print $1; }'`; do eval `udevinfo -q env -n "$d" | grep 'ID_SERIAL'` case "$ID_SERIAL" in
Hallo David, da gibt es noch ein Problem und zwar, wenn der Stick keine Partitionstabelle hat. fdisk -l | awk '/^\/dev\/sd/ { print $1; }' Disk /dev/sda doesn't contain a valid partition table Für udevinfo reicht auch das Device, also zB /dev/sda. Obiger awk-Befehl gibt aber die Partition sda1 aus. Wie sollte man das kürzen? Al PS: Auf dein anderes Posting antworte ich ASAP, vemutlich heute Abend.
Hallo, Am Sam, 21 Okt 2006, Al Bogner schrieb:
Am Dienstag, 17. Oktober 2006 00:49 schrieb David Haller:
Die Frage ist nun, wie ich möglichst effizient alle Devices scanne und unter der Bedingung "ID_SERIAL=SWISSBIT_Twist_40479E4643xxxxxx" weitere Befehle ausführe.
for d in `fdisk -l | awk '/^\/dev\/sd/ { print $1; }'`; do eval `udevinfo -q env -n "$d" | grep 'ID_SERIAL'` case "$ID_SERIAL" in [..] da gibt es noch ein Problem und zwar, wenn der Stick keine Partitionstabelle hat.
fdisk -l | awk '/^\/dev\/sd/ { print $1; }' Disk /dev/sda doesn't contain a valid partition table
Für udevinfo reicht auch das Device, also zB /dev/sda. Obiger awk-Befehl gibt aber die Partition sda1 aus.
for d in `awk '/ sd[a-z] / { print "/dev/" $4; }' /proc/partitions`; do Bin mir nicht sicher, ob's /proc/partitions bei 2.6.x gibt. -dnh -- hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is. -- bash.org/?top
Am Samstag, 21. Oktober 2006 17:10 schrieb David Haller: Hallo David,
Am Dienstag, 17. Oktober 2006 00:49 schrieb David Haller:
for d in `awk '/ sd[a-z] / { print "/dev/" $4; }' /proc/partitions`; do
Bin mir nicht sicher, ob's /proc/partitions bei 2.6.x gibt.
Ja, gibt es, aber irgendwas passt noch nicht. fdisk -l ... Disk /dev/sda: 64 MB, 64880640 bytes 2 heads, 62 sectors/track, 1021 cylinders Units = cylinders of 124 * 512 = 63488 bytes Disk /dev/sda doesn't contain a valid partition table grep sda /proc/partitions 8 0 63360 sda awk '/ sd[a-z] / { print "/dev/" $4; }' /proc/partitions (keine Ausgabe) Al
Hallo, Am Sam, 21 Okt 2006, Al Bogner schrieb:
Am Samstag, 21. Oktober 2006 17:10 schrieb David Haller:
Am Dienstag, 17. Oktober 2006 00:49 schrieb David Haller:
for d in `awk '/ sd[a-z] / { print "/dev/" $4; }' /proc/partitions`; do
Bin mir nicht sicher, ob's /proc/partitions bei 2.6.x gibt. [..] grep sda /proc/partitions 8 0 63360 sda
awk '/ sd[a-z] / { print "/dev/" $4; }' /proc/partitions ^ ^ (keine Ausgabe)
Da wird das Trennzeichen vor und/oder nach dem 'sda' ein Tab sein. Auf der sicheren Seite bist du mit einer Zeichenklasse: awk '/[ \t]sd[a-z][ \t]/ { print "/dev/" $4; }' /proc/partitions -dnh --
Ich habe das ausprobiert, aber wenn ich das auf yes stelle dann stürzt der PC beim Booten ab. Was Nun? Dann stell es am besten wieder auf "no". -- Betrefflose Frage und Antwort in suse-linux
Am Samstag, 21. Oktober 2006 21:48 schrieb David Haller: Hallo David,
Auf der sicheren Seite bist du mit einer Zeichenklasse:
awk '/[ \t]sd[a-z][ \t]/ { print "/dev/" $4; }' /proc/partitions
Leider nein. Damit gibt es auch kein Ergebnis. Vielleicht kannst aufgrund des Anhangs etwas erkennen. Al
Hallo, Am Sam, 21 Okt 2006, Al Bogner schrieb:
Am Samstag, 21. Oktober 2006 21:48 schrieb David Haller:
Auf der sicheren Seite bist du mit einer Zeichenklasse:
awk '/[ \t]sd[a-z][ \t]/ { print "/dev/" $4; }' /proc/partitions
Leider nein. Damit gibt es auch kein Ergebnis. Vielleicht kannst aufgrund des Anhangs etwas erkennen. [..] major minor #blocks name [..] 22 71 6160896 hdd7 8 0 63360 sda
Oh, da hat sich das Format deutlich geaendert. Da ist hinter dem 'sda' wohl garnix mehr. Ergo: awk '/[ \t]sd[a-z][ \t]*/ { print "/dev/" $4; }' /proc/partitions ^ das macht das Zeichen optional ;) Oder auch: awk '/[ \t]sd[a-z]$/ { print "/dev/" $4; }' /proc/partitions -dnh -- Linux is not a desktop OS for people whose VCRs are still flashing "12:00". -- Paul Tomblin
Am Sonntag, 22. Oktober 2006 01:51 schrieb David Haller: Hallo David,
Oh, da hat sich das Format deutlich geaendert. Da ist hinter dem 'sda' wohl garnix mehr. Ergo:
Ich mache in die for/case-Schleife sicherheitshalber eine Variable rein und in Folge eine Bedingung, ohne die das Script gestoppt wird. Es könnte sich das Format ja wieder ändern und bei Löschen per Script kann man nicht vorsichtig genug sein.
awk '/[ \t]sd[a-z][ \t]*/ { print "/dev/" $4; }' /proc/partitions ^ das macht das Zeichen optional ;)
Oder auch:
awk '/[ \t]sd[a-z]$/ { print "/dev/" $4; }' /proc/partitions
Beides funktioniert nun hier. Vielen Dank! Ich habe nun noch eine Verständnisfrage zu umount. Der Stick wird eventuell automatisch gemountet und ich möchte mir eine Analyse sparen, wie bzw. ob überhaupt der Stick partitioniert ist. Kann man alle Partitionen eines Devices unmounten, zB so umount /dev/sda umount: /dev/sda: not mounted Das stimmt natürlich, da der Stick total gelöscht wurde und keine Partitionen hat. Hast du eine Idee, wie man das mit eventuellem umount sauber hinbekommt? Al
Hallo, Am Son, 22 Okt 2006, Al Bogner schrieb:
Am Sonntag, 22. Oktober 2006 01:51 schrieb David Haller:
awk '/[ \t]sd[a-z][ \t]*/ { print "/dev/" $4; }' /proc/partitions ^ das macht das Zeichen optional ;)
Oder auch:
awk '/[ \t]sd[a-z]$/ { print "/dev/" $4; }' /proc/partitions
Beides funktioniert nun hier. Vielen Dank!
Prima. [..]
Kann man alle Partitionen eines Devices unmounten, zB so umount /dev/sda
umount: /dev/sda: not mounted
Nein.
Das stimmt natürlich, da der Stick total gelöscht wurde und keine Partitionen hat.
Hast du eine Idee, wie man das mit eventuellem umount sauber hinbekommt?
Ich hab' sowas fuer die Platte, die ich normal schlafen lege: awk ' /^[ \t]*#/ { next; } $1 ~ /hdd/ { print "umount "$1; }' /proc/mounts | sh -x Ich hoffe mal, das Format der /proc/mounts hat sich nicht geaendert. Hier z.B.: device MtPt fs opts ? ? /dev/hda1 /mnt/hda1 ext3 rw 0 0 Du musst das /hdd/ natuerlich anpassen, und dir das richtige /dev/sd? merken. Vielleicht legtst du mit dem script, in dem du nach der ID_SERIAL suchst, in /var/run/ oder so eine Datei an, in der das jew. Device drinsteht bzw. das "Grunddevice" sd[a-z]... HTH, -dnh --
Now, if I could just figure out how to get hold of egg yolks, without superfluous egg whites... -- S. Lamble Why not leave them with the whites? Properly cared-for, in time they will turn into a tasty chicken! -- Tanuki
Am Sonntag, 22. Oktober 2006 18:02 schrieb David Haller: Hallo David,
Am Son, 22 Okt 2006, Al Bogner schrieb:
Am Sonntag, 22. Oktober 2006 01:51 schrieb David Haller:
Kann man alle Partitionen eines Devices unmounten, zB so umount /dev/sda
umount: /dev/sda: not mounted
Nein.
Ich dachte mir das ja ;-)
Hast du eine Idee, wie man das mit eventuellem umount sauber hinbekommt?
Ich hab' sowas fuer die Platte, die ich normal schlafen lege:
awk ' /^[ \t]*#/ { next; } $1 ~ /hdd/ { print "umount "$1; }' /proc/mounts | sh -x
Hmmh, ganz verstehe ich das nicht. Ich habe in meinem Script nun eine Variable, die zB "/dev/sda" enthält. Würde diese Variable $1 entsprechen und müsste ich eine Variable definieren, die dann statt /hdd/ /sda/ enthält? Könnte man dafür auch nicht mount auswerten?
Ich hoffe mal, das Format der /proc/mounts hat sich nicht geaendert. Hier z.B.: device MtPt fs opts ? ? /dev/hda1 /mnt/hda1 ext3 rw 0 0
Bei mir: cat /proc/mounts rootfs / rootfs rw 0 0 none /sys sysfs rw 0 0 udev /dev tmpfs rw 0 0 /dev/hda15 / xfs rw 0 0 /dev/hda15 /dev/.static/dev xfs rw 0 0 proc /proc proc rw,nosuid,nodev,noexec 0 0 usbfs /proc/bus/usb usbfs rw,nosuid,nodev,noexec 0 0 tmpfs /dev/shm tmpfs rw,nosuid,nodev,noexec 0 0 devpts /dev/pts devpts rw,nosuid,noexec 0 0 /dev/hda14 /boot reiserfs rw 0 0 ...
Du musst das /hdd/ natuerlich anpassen, und dir das richtige /dev/sd? merken. Vielleicht legtst du mit dem script, in dem du nach der ID_SERIAL suchst, in /var/run/ oder so eine Datei an, in der das jew. Device drinsteht bzw. das "Grunddevice" sd[a-z]...
Ich will das Scritp möglichst flexibel auf verschiedenen Rechnern laufen lassen. Daher soll alles im Script selbst sein. Sobald ID_SERIAL abgeglichen ist, steht das Device in einer Variable "$USBGERAET" . Wenn ich nun mount oder /proc/mounts verwende, dann könnte man mit cut bis zum 1. Leerzeichen ausschneiden, Netzlaufwerke rauswerfen, dann nach der Variable "$USBGERAET" greppen und an xargs mit umount übergeben, oder? cat /proc/mounts | cut -f1 -d" " | grep -v ":" | grep "sda" | xargs \ -r -n1 umount Etwas in dieser Richtung finde ich nicht so kryptisch wie mit awk ;-) Ich überlege mir nun auch noch, ob das alles mit Userrechten zu schaffen ist, sodass der User aber bei den eingebauten HDs (hdx bzw. sdx, wenn SATA oder SCSI) nichts anstellen kann. Entscheidend dabei ist, dass alles über das Script läuft und keine Systemanpassungen am Rechner erfolgen sollen. Auf einem Fremdrechner erhalte ich zwar das Root-PW, aber man hat keine Freude, wenn ich dort was ändern, eintragen will. Al PS: Auf das andere Posting antworte ich, wenn diese Sache hier geklärt ist.
Hallo, Am Son, 22 Okt 2006, Al Bogner schrieb:
Am Sonntag, 22. Oktober 2006 18:02 schrieb David Haller:
Hast du eine Idee, wie man das mit eventuellem umount sauber hinbekommt?
Ich hab' sowas fuer die Platte, die ich normal schlafen lege:
awk ' /^[ \t]*#/ { next; }
Ups. Der Teil gehoert zum Kommentare ueberspringen in /etc/fstab (die im anderen Teil des scripts verwendet wird ;)
$1 ~ /hdd/ { print "umount "$1; }' /proc/mounts | sh -x
Hmmh, ganz verstehe ich das nicht. Ich habe in meinem Script nun eine Variable, die zB "/dev/sda" enthält.
Ok.
Würde diese Variable $1 entsprechen und
Nein. $1 ist das erste Feld der aktuellen Zeile, also bei /proc/mounts das Device.
müsste ich eine Variable definieren, die dann statt /hdd/ /sda/ enthält?
Ja.
Könnte man dafür auch nicht mount auswerten?
Die Ausgabe von mount ist nicht zuverlaessig und /proc/mounts auszulesen spart auch noch einen Prozess ;)
Ich hoffe mal, das Format der /proc/mounts hat sich nicht geaendert. Hier z.B.: device MtPt fs opts ? ? /dev/hda1 /mnt/hda1 ext3 rw 0 0
Bei mir:
cat /proc/mounts rootfs / rootfs rw 0 0 /dev/hda15 /dev/.static/dev xfs rw 0 0 /dev/hda14 /boot reiserfs rw 0 0 ^^^^^^^^^^ => wird im awk zu $1 ...
Passt. [..]
Ich will das Scritp möglichst flexibel auf verschiedenen Rechnern laufen lassen. Daher soll alles im Script selbst sein.
Sobald ID_SERIAL abgeglichen ist, steht das Device in einer Variable "$USBGERAET" .
Ah gut.
Wenn ich nun mount oder /proc/mounts verwende, dann könnte man mit cut bis zum 1. Leerzeichen ausschneiden, Netzlaufwerke rauswerfen, dann nach der Variable "$USBGERAET" greppen und an xargs mit umount übergeben, oder?
cat /proc/mounts | cut -f1 -d" " | grep -v ":" | grep "sda" | xargs \ -r -n1 umount
Etwas in dieser Richtung finde ich nicht so kryptisch wie mit awk ;-)
Schau's dir an, awk ist einfacher: awk -v dev="$USBGERAET" '$1 ~ dev { print "umount "$1; }' /proc/mounts | sh -x
Ich überlege mir nun auch noch, ob das alles mit Userrechten zu schaffen ist, sodass der User aber bei den eingebauten HDs (hdx bzw. sdx, wenn SATA oder SCSI) nichts anstellen kann.
Sollte gehen. -dnh -- ... "See, I told you, they'd listen to Reason," Fisheye says, shutting down the whirling gun. -- Neal Stephenson, "Snow Crash", p. 361
Am Sonntag, 22. Oktober 2006 21:46 schrieb David Haller: Hallo David,
Schau's dir an, awk ist einfacher:
awk -v dev="$USBGERAET" '$1 ~ dev { print "umount "$1; }' /proc/mounts | sh -x
Nun ja, in ein paar Monaten nicht mehr, wenn ich awk wieder brauche. Ich weis aber dann wo ich nachsehen kann ;-)
Ich überlege mir nun auch noch, ob das alles mit Userrechten zu schaffen ist, sodass der User aber bei den eingebauten HDs (hdx bzw. sdx, wenn SATA oder SCSI) nichts anstellen kann.
Sollte gehen.
Tipps? Es gibt noch ein Problem mit dem Mounten des Sticks nach Ausführen des Scripts. Vielleicht ist es aber ein KDE-Problem. Hast du Lust das Script per PM zu überfliegen? Ohne Kommentare sieht das Script gegen Ende etwa so aus: sfdisk "$USBGERAET" << EOF ,,b EOF mkdosfs -v -F 32 -n "$STICKNAME" "$USBGERAET"1 mount "$USBGERAET"1 /mnt cp -vr "$STICKBASIS"* /mnt umount "$USBGERAET"1 Beim Ab- und Anstecken des Scripts meckert dann KDE 3.5.5, dass kein "Mail versandt werden konnte, oder so ähnlich. Ich habe es leider nicht abgeschrieben, da ich schnell prüfen musste, ob die Daten am Stick ok sind und der Stick mitgenommen wurde. Da fällt mir gerade ein, ein "Verify" der kopierten Dateien mit star oder sha1sum-Vergleich könnte man noch daran hängen. Al
Hallo, Am Don, 26 Okt 2006, Al Bogner schrieb:
Am Sonntag, 22. Oktober 2006 21:46 schrieb David Haller:
Schau's dir an, awk ist einfacher:
awk -v dev="$USBGERAET" '$1 ~ dev { print "umount "$1; }' /proc/mounts | sh -x
Nun ja, in ein paar Monaten nicht mehr, wenn ich awk wieder brauche. Ich weis aber dann wo ich nachsehen kann ;-)
Das verwendet eigentlich nur awk Grundlagen, keinerlei Finessen. Der einzige "Trick" ist, dass per awk ein shellscript mit den passenden umount-Befehlen generiert wird, welches dann per pipe an sh verfuettert wird. Im Prinzip koennte man auch das noch in awk machen: $1 ~ dev { system("umount "$1); } wobei man da noch ne Fehlerbehandlung dazubauen sollte (Rueckgabewert von 'system')...
Ich überlege mir nun auch noch, ob das alles mit Userrechten zu schaffen ist, sodass der User aber bei den eingebauten HDs (hdx bzw. sdx, wenn SATA oder SCSI) nichts anstellen kann.
Sollte gehen.
Tipps?
user/users Optionen in /etc/fstab. bzw. Rechte an den Devices selbst. Wie das mit udev etc. geht weiss ich aber nicht. Das haengt natuerlich auch von den sonstigen Rechten ab, die die User haben sollen. Generell ist AFAIR fuer User ja kein Zugriff auf die Devicenodes noetig, ausser zum CD-Brennen.
Es gibt noch ein Problem mit dem Mounten des Sticks nach Ausführen des Scripts. Vielleicht ist es aber ein KDE-Problem. Hast du Lust das Script per PM zu überfliegen?
Mal schauen. Schick's ruhig mal :)
Ohne Kommentare sieht das Script gegen Ende etwa so aus: sfdisk "$USBGERAET" << EOF ,,b EOF
Bei nem Einzeiler wuerde ich echo ",,b" | sfdisk "$USBGERAET" vorziehen.
mkdosfs -v -F 32 -n "$STICKNAME" "$USBGERAET"1 ^^^^^^^^^^^^^ "${USBGERAET}1"
Liest sich IMHO einfacher, ist aber mehr Geschmackssache.
mount "$USBGERAET"1 /mnt
Dito. Bei beiden fehlt aber ne Fehlerbehandlung.
cp -vr "$STICKBASIS"* /mnt
Das duerfte die Rechte versauen. Besser: cp -av "${STICKBASIS}/*" /mnt/ oder cd "${STICKBASIS}" && tar -cp -f - . | ( cd /mnt/ && tar xp -f - )
umount "$USBGERAET"1
s.o.
Beim Ab- und Anstecken des Scripts meckert dann KDE 3.5.5, dass kein "Mail versandt werden konnte, oder so ähnlich.
Wie wird das script aufgerufen? Da soll wohl eine Ausgabe per Mail versandt werden... Oder so ;) Ggfs. hilft ein (script-globales) Umleiten der Ausgaben per exec 1>/bla.log exec 2>/bla.err oder ein Klammer des scripts mit: #!/bin/bash { script } | logger .... oder sowas ;)
Da fällt mir gerade ein, ein "Verify" der kopierten Dateien mit star oder sha1sum-Vergleich könnte man noch daran hängen.
Jo. Lesevorgaenge verkuerzen AFAIR ja nicht die Lebensdauer von Flash-Medien ;) -dnh -- "If you are using an Macintosh e-mail program that is not from Microsoft, we recommend checking with that particular company. But most likely other e-mail programs like Eudora are not designed to enable virus replication" -- http://www.microsoft.com/mac/products/office/2001/virus_alert.asp
Am Freitag, 27. Oktober 2006 00:18 schrieb David Haller: Hallo David,
Am Don, 26 Okt 2006, Al Bogner schrieb:
Am Sonntag, 22. Oktober 2006 21:46 schrieb David Haller:
Schau's dir an, awk ist einfacher:
awk -v dev="$USBGERAET" '$1 ~ dev { print "umount "$1; }' /proc/mounts
| sh -x
Nun ja, in ein paar Monaten nicht mehr, wenn ich awk wieder brauche. Ich weis aber dann wo ich nachsehen kann ;-)
Das verwendet eigentlich nur awk Grundlagen, keinerlei Finessen. Der einzige "Trick" ist, dass per awk ein shellscript mit den passenden umount-Befehlen generiert wird, welches dann per pipe an sh verfuettert wird. Im Prinzip koennte man auch das noch in awk machen:
$1 ~ dev { system("umount "$1); }
wobei man da noch ne Fehlerbehandlung dazubauen sollte (Rueckgabewert von 'system')...
Hmmh, ich habe schon gemerkt, dass es ziemlich komplex werden kann, wenn man jeden möglichen Fehler abfangen will. Ich nehme daher zB an, dass nur 1 USB-Stick angeschlossen ist. Wenn jemand als root angemeldet ist, dann darf davon ausgegangen werden, dass nicht jeder Blödsinn gemacht wird. Wie meinst du das mit der Fehlerbehandlung? Wenn das Script nicht abgebrochen wird, wird sowieso alles gelöscht. Warum sollte ein umount nicht klappen, wenn es als root ausgeführt wird? Es ist auch nicht davon auszugehen, dass die Partition gerade von jemanden anders gemountet wurde. In diesem Zusammenhang habe ich noch folgende theoretische Frage, da ich davon ausgehe, dass auf dem Stick nur 1 primäre Partition vorhanden ist. Wie mounte ich alle vorhandenen Partitionen automatisch ähnlich den awk-umount-Konstrukt? Als Problem sehe ich die Zuordnung der mountpoints. Zur Zeit habe ich: MOUNTVERZEICHNIS="/mnt" awk -v dev="$USBGERAET" '$1 ~ dev { print "umount "$1; }' /proc/mounts | sh -x mount "$USBGERAET"1 "$MOUNTVERZEICHNIS" ls -la "$MOUNTVERZEICHNIS" Das reicht solange nur 1 primäre Partition verwendet wird. Ich stelle mir vor, dass ich vorsichtshalber alle Partitionen abmelde und dann dynamische Mountpoints generiere.
user/users Optionen in /etc/fstab. bzw. Rechte an den Devices selbst. Wie das mit udev etc. geht weiss ich aber nicht.
Mit udev hatte ich schon genug Ärger, dann lasse ich das mal mit Root-Rechten.
Es gibt noch ein Problem mit dem Mounten des Sticks nach Ausführen des Scripts. Vielleicht ist es aber ein KDE-Problem.
Auf einem anderen Rechner machte es keine Probleme.
Hast du Lust das Script per PM zu überfliegen?
Mal schauen. Schick's ruhig mal :)
Mache ich, nachdem noch ein paar Dinge dazu gekommen sind, speziell der Teil oben.
Ohne Kommentare sieht das Script gegen Ende etwa so aus: sfdisk "$USBGERAET" << EOF ,,b EOF
Bei nem Einzeiler wuerde ich
echo ",,b" | sfdisk "$USBGERAET"
vorziehen.
mkdosfs -v -F 32 -n "$STICKNAME" "$USBGERAET"1
^^^^^^^^^^^^^ "${USBGERAET}1"
Liest sich IMHO einfacher, ist aber mehr Geschmackssache.
mount "$USBGERAET"1 /mnt
Dito. Bei beiden fehlt aber ne Fehlerbehandlung.
Wie sollte die aussehen und warum?
cp -vr "$STICKBASIS"* /mnt
Das duerfte die Rechte versauen. Besser:
cp -av "${STICKBASIS}/*" /mnt/
Rechte mit FAT 32? Siehe oben Partitionstyp ist b.
oder
cd "${STICKBASIS}" && tar -cp -f - . | ( cd /mnt/ && tar xp -f - )
umount "$USBGERAET"1
s.o.
Beim Ab- und Anstecken des Scripts meckert dann KDE 3.5.5, dass kein "Mail versandt werden konnte, oder so ähnlich.
Wie wird das script aufgerufen? Da soll wohl eine Ausgabe per Mail versandt werden... Oder so ;)
Nein, kein Mail. Das Script wird aus einem Root-Terminal aufgerufen.
Ggfs. hilft ein (script-globales) Umleiten der Ausgaben per
exec 1>/bla.log exec 2>/bla.err
oder ein Klammer des scripts mit:
#!/bin/bash { script } | logger ....
oder sowas ;)
In dieser Richtung habe ich noch keine Überlegungen.
Da fällt mir gerade ein, ein "Verify" der kopierten Dateien mit star oder sha1sum-Vergleich könnte man noch daran hängen.
Jo. Lesevorgaenge verkuerzen AFAIR ja nicht die Lebensdauer von Flash-Medien ;)
Bei den Preisen denke ich nicht mehr an die Lebensdauer. Ich habe 3 Jahre Garantie und dann ist der Stick sowieso etwas fürs Museum, wie der 64MB Test-Stick. Ähnliches gilt für SD-Karten, aber so oft kommen die sowieso nicht in gefährdete Systeme. Al
Hallo, Am Fre, 27 Okt 2006, Al Bogner schrieb:
Am Freitag, 27. Oktober 2006 00:18 schrieb David Haller:
Am Don, 26 Okt 2006, Al Bogner schrieb:
Am Sonntag, 22. Oktober 2006 21:46 schrieb David Haller:
Schau's dir an, awk ist einfacher:
awk -v dev="$USBGERAET" '$1 ~ dev { print "umount "$1; }' /proc/mounts
| sh -x
Nun ja, in ein paar Monaten nicht mehr, wenn ich awk wieder brauche. Ich weis aber dann wo ich nachsehen kann ;-)
Das verwendet eigentlich nur awk Grundlagen, keinerlei Finessen. Der einzige "Trick" ist, dass per awk ein shellscript mit den passenden umount-Befehlen generiert wird, welches dann per pipe an sh verfuettert wird. Im Prinzip koennte man auch das noch in awk machen:
$1 ~ dev { system("umount "$1); }
wobei man da noch ne Fehlerbehandlung dazubauen sollte (Rueckgabewert von 'system')...
Hmmh, ich habe schon gemerkt, dass es ziemlich komplex werden kann, wenn man jeden möglichen Fehler abfangen will.
Es reicht meist nur zwischen OK und Fehler zu unterscheiden. Bsp: $1 ~ dev { r = system("umount "$1); if( r != 0 ) { exit r; } } Oder so ;)
Wie meinst du das mit der Fehlerbehandlung? Wenn das Script nicht abgebrochen wird, wird sowieso alles gelöscht. Warum sollte ein umount nicht klappen, wenn es als root ausgeführt wird?
Wenn z.B. noch auf den Mountpunkt zugegriffen wird (aus welchem Grund auch immer). Ist auch eine Frage der Paranoia ;)
In diesem Zusammenhang habe ich noch folgende theoretische Frage, da ich davon ausgehe, dass auf dem Stick nur 1 primäre Partition vorhanden ist.
Wie mounte ich alle vorhandenen Partitionen automatisch ähnlich den awk-umount-Konstrukt? Als Problem sehe ich die Zuordnung der mountpoints.
Ohne, dass die Partitionen in der fstab stehen? /proc/partitions auslesen?
Zur Zeit habe ich:
MOUNTVERZEICHNIS="/mnt" awk -v dev="$USBGERAET" '$1 ~ dev { print "umount "$1; }' /proc/mounts | sh -x mount "$USBGERAET"1 "$MOUNTVERZEICHNIS" ls -la "$MOUNTVERZEICHNIS"
Das reicht solange nur 1 primäre Partition verwendet wird.
Ich stelle mir vor, dass ich vorsichtshalber alle Partitionen abmelde und dann dynamische Mountpoints generiere.
MOUNTVERZEICHNIS="/mnt" awk -v dev="$USBGERAET" '$1 ~ dev { print "umount "$1; }' /proc/mounts | sh -x # bitte erst ohne das "| sh -x" testen! awk -v dev="$USBGERAET" \ -v mp="$MOUNTVERZEICHNIS" \ '$4 ~ dev"[0-9]+" { print "mkdir -p " mp "/" $4; print "mount -t auto /dev/" $4 " " mp "/" $4; }' /proc/partitions | sh -x ls -la "${USBGERAET}"*/ Oder so ;) [..]
mkdosfs -v -F 32 -n "$STICKNAME" "$USBGERAET"1
^^^^^^^^^^^^^ "${USBGERAET}1"
Liest sich IMHO einfacher, ist aber mehr Geschmackssache.
mount "$USBGERAET"1 /mnt
Dito. Bei beiden fehlt aber ne Fehlerbehandlung.
Wie sollte die aussehen und warum?
Je nach dem ob du das Script bei nem Fehler abbrechen willst und ob du ne Fehlermeldung willst. Wenn du bei Fehlern abbrechen willst reicht auch ein 'set -e' vorher (und ggfs. 'set +e' anschliessend. Bei einzelnen Befehlen: '|| exit 1' und aehnliches. [..]
Das duerfte die Rechte versauen. Besser: Rechte mit FAT 32? Siehe oben Partitionstyp ist b.
Achja ;)
Beim Ab- und Anstecken des Scripts meckert dann KDE 3.5.5, dass kein "Mail versandt werden konnte, oder so ähnlich.
Wie wird das script aufgerufen? Da soll wohl eine Ausgabe per Mail versandt werden... Oder so ;)
Nein, kein Mail. Das Script wird aus einem Root-Terminal aufgerufen.
Seltsam. Udev? Hal? hotplug? [..] -dnh -- We're Germans and we use Unix. That's a combination of two demographic groups known to have no sense of humour whatsoever. -- Hanno Mueller, de.comp.os.unix.programming
Am Freitag, 27. Oktober 2006 13:47 schrieb David Haller: Hallo David,
Wie mounte ich alle vorhandenen Partitionen automatisch ähnlich den awk-umount-Konstrukt? Als Problem sehe ich die Zuordnung der mountpoints.
Ohne, dass die Partitionen in der fstab stehen? /proc/partitions auslesen?
Zur Zeit habe ich:
MOUNTVERZEICHNIS="/mnt" awk -v dev="$USBGERAET" '$1 ~ dev { print "umount "$1; }' /proc/mounts | sh -x mount "$USBGERAET"1 "$MOUNTVERZEICHNIS" ls -la "$MOUNTVERZEICHNIS"
Das reicht solange nur 1 primäre Partition verwendet wird.
Ich stelle mir vor, dass ich vorsichtshalber alle Partitionen abmelde und dann dynamische Mountpoints generiere.
MOUNTVERZEICHNIS="/mnt" awk -v dev="$USBGERAET" '$1 ~ dev { print "umount "$1; }' /proc/mounts | sh -x
# bitte erst ohne das "| sh -x" testen! awk -v dev="$USBGERAET" \ -v mp="$MOUNTVERZEICHNIS" \ '$4 ~ dev"[0-9]+" { print "mkdir -p " mp "/" $4; print "mount -t auto /dev/" $4 " " mp "/" $4; }' /proc/partitions | sh -x
ls -la "${USBGERAET}"*/
Oder so ;)
Ich komme nicht dahinter, wo das Problem ist: ls: /dev/sde*/: Datei oder Verzeichnis nicht gefunden Al
Hallo, Am Fre, 27 Okt 2006, Al Bogner schrieb:
Am Freitag, 27. Oktober 2006 13:47 schrieb David Haller: [..]
MOUNTVERZEICHNIS="/mnt" awk -v dev="$USBGERAET" '$1 ~ dev { print "umount "$1; }' /proc/mounts | sh -x
# bitte erst ohne das "| sh -x" testen! awk -v dev="$USBGERAET" \ -v mp="$MOUNTVERZEICHNIS" \ '$4 ~ dev"[0-9]+" { print "mkdir -p " mp "/" $4; print "mount -t auto /dev/" $4 " " mp "/" $4; }' /proc/partitions | sh -x
ls -la "${USBGERAET}"*/
Oder so ;)
Ich komme nicht dahinter, wo das Problem ist:
ls: /dev/sde*/: Datei oder Verzeichnis nicht gefunden
Das muss natuerlich ls -la "${MOUNTVERZEICHNIS}/${USBGERAET}"*/ sein. Wobei bei allem hier eigentich USBGERAET nur 'sd[a-z]' enthalten soll, nicht '/dev/sd[a-z]'. -dnh -- Paradox ist, wenn Glatzkoepfe sich in den Haaren liegen.
participants (4)
-
Al Bogner -
Andreas Koenecke -
David Haller -
Markus Wunder