Ich habe einen bootbaren 8GB-USB-Stick, der nur ca 500MEGA-Byte Daten drauf hat. Von dem würde ich gerne mit dd ein ISO-Image erstellen, aber ohne das es mir 7,5GB leeren Rauminhalt mit ins Image schreibt. Gibts dafür nen Kniff? Nach einer Wiederherstellung soll dieser Stick auch wieder bootbar sein. Clonezilla scheidet aus, das soll so sein, dass das an einem Rechner wiederherstellbar ist, der bereits ein Linux laufen hat. -niggs neu mit CZ booten.
●DesIntegrator ●. schrieb: > Von dem würde ich gerne mit dd ein ISO-Image erstellen, > aber ohne das es mir 7,5GB leeren Rauminhalt mit ins Image schreibt. > Gibts dafür nen Kniff? Nein. Wenn da kein ISO-Dateisystem drauf ist, bekommst du auch mit einem Kniff mit dd keines davon erstellt. Wenn du ein ISO-Image davon haben willst, könntest du’s mit mkisofs oder genisofs probieren. Wenn’s aber gar nicht um ein ISO-Image geht, sondern um ein Image des Sticks: du könntest vor dem Erstellen des Images das Dateisystem auf dem Stick entsprechend verkleinern, und ein Image davon ziehen. Oder du schreibst den leeren Platz auf dem Stick explizit mit Nullen voll (dd if=/dev/zero of=/pfad_zum_stick/datei […]), löschst diese Datei im Anschluss und komprimierst das via dd gezogene Image dann – zusammenhängende Nullen lassen sich ausgezeichnet komprimieren, sodass die rausfallende Datei nur wenig größer, vielleicht sogar kleiner als die Daten auf dem Stick ist.
könnte man mit dd evtl auch gleich direkt aus einem Archiv heraus den Stick wiederherstellen?
Ja, du kannst das Archiv on the fly dekomprimieren und an dd pipen. Du kannst auch beim Auslesen schon die Ausgabe von dd an xz, oder was auch immer du nutzen willst, pipen, sodass die große Datei gar nicht erst auf deiner Platte landet.
Genau, und zum "Nullen" der freien Bereiche kannst Du auch "fstrim /" verwenden.
Archiv erstellen und komprimieren:
1 | sudo dd bs=4M if=/dev/sdb | gzip > image`date +%d%m%y`.gz |
Archiv zurückspielen: (vorher alle Partitionen des Sticks un-mounten)
1 | gunzip image....gz | sudo dd bs=4M of=/dev/sdb |
so ungefähr.
:
Bearbeitet durch User
Ja das mit dem Komprimieren klappt auch. Das erleichtert hier so einiges. Danke für die Tips
Pilot P. schrieb: > gunzip image....gz | sudo dd bs=4M of=/dev/sdb Das sollte eher so sein:
1 | gunzip < image....gz | dd bs=4M of=/dev/sdb |
Sonst dekomprimiert es das Archiv, aber nicht nach stdout, in ne neue Datei, und damit landet dann nichts auf dem Stick. Statt gunzip kann man auch "gzip -d" nehmen.
Auch wenn das für das reine Backup vom Stick nicht relevant ist: Wenn der bootbare USB-Stick aus einem Hybrid-ISO erstellt wurde, und das OS darauf keine automatischen Partitions-Resizes für Persistenz-Partion etc. macht, kriegt man das auch wieder als ISO image herunter und bootfähig auf eine CD oder DVD gebrannt. einfach dem "dd" zum Runterkopieren noch mit blocksize(bs) und count angeben, dass nur die ersten xxx MB kopiert werden sollen.
Εrnst B. schrieb: > einfach dem "dd" zum Runterkopieren noch mit blocksize(bs) und count > angeben, dass nur die ersten xxx MB kopiert werden sollen. Dann muss ich ja schon wieder rechnen ;-]
> Das sollte eher so sein: >
1 | > gunzip < image....gz | dd bs=4M of=/dev/sdb |
2 | > |
Ja, richtig. Oder auch mit -c (hatte ich vergessen):
1 | gunzip -c image....gz | dd bs=4M of=/dev/sdb |
Pilot P. schrieb: > Archiv erstellen und komprimieren: >
1 | sudo dd bs=4M if=/dev/sdb | gzip > image`date +%d%m%y`.gz |
Dafür bekommst du den useless use of dd award von mir. Ansonsten sind sparse Files auch sehr schnuckelig.
Beitrag #7632977 wurde vom Autor gelöscht.
●DesIntegrator ●. schrieb: > Εrnst B. schrieb: >> einfach dem "dd" zum Runterkopieren noch mit blocksize(bs) und count >> angeben, dass nur die ersten xxx MB kopiert werden sollen. > > Dann muss ich ja schon wieder rechnen ;-] x*1 ist nicht besonders schwer zu rechnen.
Hallo DesIntegrator, ●DesIntegrator ●. schrieb: > Von dem würde ich gerne mit dd ein ISO-Image erstellen, > aber ohne das es mir 7,5GB leeren Rauminhalt mit ins Image schreibt. > Gibts dafür nen Kniff? wenn Dein USB-Stick dadurch entstanden ist, dass eine ISO-Datei direkt auf den Stick (z.B. mit dd) geschrieben wurde, dann würde ich folgendes probieren (hab's noch nicht gemacht!): Voraussetzung: Du hast erst einmal den Stick komplett z.B. mit dd in eine Datei dupliziert. Lösung 1: (die naive) Du durchsuchst mit einem geeigneten Hexeditor, z.B. HxD die Datei von hinten nach vorne visuell. Wenn nur noch Nullen auftreten, gehören die vermutlich nicht zur ursprünglichen ISO-Datei. Dann speicherst Du nur den Dateiausschnitt vom Anfang der Datei bis zum Anfang des Null-Bereichs, bzw. vielleicht 2100 Bytes dahinter (siehe Info aus Lösung 2). Lösung 2: (für den ambitionierten ISO-Cutter) Du schmökerst in der Format-Definition, z.B. hier https://wiki.osdev.org/ISO_9660#System_Area und suchst mit HxD nach dem "Volume Descriptor Set Terminator". Du speicherst dann den Dateiausschnitt vom Dateianfang bis 2048 Byte hinter dem Beginn des Terminators. Fazit: Der DesIntegrator sucht also nun den Terminator. :) Melde Dich 'mal um zu sagen, dass es geklappt hat oder mir irgendwo ein Denkfehler unterlaufen ist!
:
Bearbeitet durch User
ja, das klingt auch interessant. Könnte nicht schaden, wenn da nicht immer irgendwo wieder die Info drin steckt, wie gross der ursprüngliche Stick war. Irgendwo kommen diese 8GB sonst ja immer wieder zustande. bei 8GB gehts ja noch halbwegs, aber wenn etwas von einer grossen Platte kommt, wirds blöd. Wenn das im jetzigen Falle dann vielleicht auf einen 1GB-Stick passen würde, müsste man keine Sorgen haben, ob im Bedarfsfalle das auch mal jaaah passt. wie gesagt, ich möchte den Umstand wenns geht vermeiden, dass ich zum sichern und Zurückspielen immer erst einen Rechner mit einem ext. Bootmedium neu booten muss. Das darf gerne aus einem laufenden System passieren.
Also ist es doch ein ISO-Hybrid-Image eines Live-Mediums o.Ä.? Wär’s in dem Fall nicht besser, einfach das Ausgangsimage ins Backup zu packen?
Ja das ist ein Acronis-Stick. Aber ich sehe grad, dass der eben installierte Hex-Editor mit 8GB garnicht klar kommt. Es lässt sich nichts bedienen (kein Markieren, Löschen... sonstwas) bei kleinen Dateien kein Prob. da brauche ich mal einen Tipp, was unter Mint läuft und 8GB-Dateien verarbeiten kann.
Ein Hybrid-Iso enthält normalerweise auch eine Partitionstabelle. Diese sollte eigentlich (muss aber in der Theorie nicht...) den ganzen belegten Platz abdecken. fdisk -l /dev/usbstick im Zweifel mit der Dateisystemgröße aus dem ISO9660-Header abgleichen und den größeren Wert nehmen.
●DesIntegrator ●. schrieb: > da brauche ich mal einen Tipp, was unter Mint läuft https://github.com/pixel/hexedit kommt mit großen Files klar. Vim sowieso, in Verbindung mit xxd (gehört zu vim).
●DesIntegrator ●. schrieb: > Ja das ist ein Acronis-Stick. > Aber ich sehe grad, dass der eben installierte Hex-Editor > mit 8GB garnicht klar kommt. > > Es lässt sich nichts bedienen (kein Markieren, Löschen... sonstwas) > > bei kleinen Dateien kein Prob. > > da brauche ich mal einen Tipp, was unter Mint läuft > und 8GB-Dateien verarbeiten kann. Ist bereits installiert: NAME od - dump files in octal and other formats [ ..... ] EXAMPLES od -A x -t x1z -v Display hexdump format output od -A o -t oS -w16 The default output format used by od
Nun ja – zwischen dumpen und editieren gibt es einen kleinen semantischen Unterschied ;)
Jack V. schrieb: > Nun ja – zwischen dumpen und editieren gibt es einen kleinen > semantischen Unterschied ;) Er soll/will ja nichts ändern.
G. K. schrieb: > Er soll/will ja nichts ändern. Wollte er aber offenbar: ●DesIntegrator ●. schrieb: > Es lässt sich nichts bedienen (kein Markieren, Löschen... sonstwas)
●DesIntegrator ●. schrieb: > Von dem würde ich gerne mit dd ein ISO-Image erstellen, > aber ohne das es mir 7,5GB leeren Rauminhalt mit ins Image schreibt. Nachdem ja schon Methoden genannt wurden das Problem mit dem LHC am CERN zu lösen, schlage ich einfach mal eines der einfachsten Werkzeuge vor welches ein Linux System zu bieten hat. Die Eingeweihten nennen es insgeheim ›cp‹ > Gibts dafür nen Kniff? Gibt's auch, steht an prominenter Stelle in der zum besagten ›cp‹ Befehl gehörenden man-page beschrieben.
In dem Fall wär’s gut, wenn du auch gleich den Weg zurück zu einem bootenden Stick für den Desintegrator aufzeigst. Im Grunde ist syslinux einfach zu handhaben, aber an der Art der Frage meine ich zu erkennen, dass es hier nicht die optimale Variante wäre.
Jack V. schrieb: > In dem Fall wär’s gut, wenn du auch gleich den Weg zurück zu einem > bootenden Stick für den Desintegrator aufzeigst. Oh ja, das habe ich in der Tat vergessen. Also … dafür nimmt man dann natürlich eines der einfachsten Werkzeuge welches ein Linux System zu bieten hat. Die Eingeweihten nennen es insgeheim ›cp‹ ›cp‹ ist eine echte Bestie. Das Ding funktioniert sogar in beiden Richtungen.
Norbert schrieb: > Also … dafür nimmt man dann natürlich eines der einfachsten Werkzeuge > welches ein Linux System zu bieten hat. Die Eingeweihten nennen es > insgeheim ›cp‹ > > ›cp‹ ist eine echte Bestie. Das Ding funktioniert sogar in beiden > Richtungen. Wenn du versuchen würdest, zu erfassen, worum es hier geht, wirst du erkennen, dass dein wenig subtiler Ironieversuch dich nicht gut dastehen lässt: es gibt zwei Möglichkeiten, hier mit cp zu hantieren. Einmal auf dem Devicefile – dann gibt es ein Image der Daten incl. des ganzen ungenutzten Platzes – genau den wollte der TE aber loswerden. Passt also nicht. Die zweite Möglichkeit wäre, das Dateisystem des Sticks zu mounten, und die Dateien mittels cp zu sichern. Kann man machen, allerdings fällt kein bootfähiger Stick raus, wenn man das auf gleichem Weg zurückkopiert. War also auch nix. Nun?
:
Bearbeitet durch User
Jack V. schrieb: > Wenn du versuchen würdest, zu erfassen, worum es hier geht, wirst du > erkennen, dass dein wenig subtiler Ironieversuch dich nicht gut dastehen > lässt: es gibt zwei Möglichkeiten, hier mit cp zu hantieren. Einmal auf > dem Devicefile – dann gibt es ein Image der Daten incl. des ganzen > ungenutzten Platzes – genau den wollte der TE aber loswerden. Auf Sparse Files die man mit cp erzeugen kann hatte ich ja auch schon hingewiesen.
:
Bearbeitet durch User
Jack V. schrieb: > Wenn du versuchen würdest, zu erfassen, Wenn du zumindest ansatzweise versuchen würdest zu erfassen was der ›cp‹ Befehl alles kann, kämst du nicht auf die Idee derart blödsinnige Statement öffentlich nieder zu schreiben. Selbstverständlich kann man mit ›cp‹ GANZ GENAU das erreichen was dem Threadersteller wichtig ist.
G. K. schrieb: > Auf Sparse Files die man mit cp erzeugen kann hatte ich ja auch schon > hingewiesen. Dafür gab's von mir auch den Pluspunkt. Aber ich vermute (wie man unschwer bestätigt sieht) das selbst dieser einfache Parameter zu komplex ist um verstanden zu werden.
Norbert schrieb: > Selbstverständlich kann man mit ›cp‹ GANZ GENAU das erreichen was dem > Threadersteller wichtig ist. Dann zeig mal bitte: gegeben sei bootbarer Stick, dessen 8GB großes Dateisystem mit 500MB belegt ist; die Aufgabe lautet, die Daten so zu sichern, dass einerseits nur der belegte Platz gesichert wird, wobei der Stick beim Zurücksichern direkt wieder bootbar ist. Sollte deiner Darstellung nach ja ganz einfach mit cp machbar sein. Ein weiteres „RTFM doch selbst!kk“ von deiner Seite kann man getrost als „ich hab ja auch keine Ahnung!“ interpretieren, denke ich. Copypasta ist gefragt.
Jack V. schrieb: > Dann zeig mal bitte: gegeben sei bootbarer Stick, Sag mal, bist du zu schusselig um eine man-page zu lesen? Müssen wir dir erklären wie ›cp‹ funktioniert? Müssen wir dir erklären wie ein device angesprochen werden kann?
Norbert schrieb: > Sag mal, bist du zu schusselig um eine man-page zu lesen? Jack V. schrieb: > Ein > weiteres „RTFM doch selbst!kk“ von deiner Seite kann man getrost als > „ich hab ja auch keine Ahnung!“ interpretieren, denke ich. Gut. Du hast also keinen Schimmer. Sonst würdest du’s nämlich einfach hinschreiben :)
Jack V. schrieb: > Gut. Du hast also keinen Schimmer. Sonst würdest du’s nämlich einfach > hinschreiben :) Du hättest als Kücken auf die Welt kommen sollen. Die bekommen auch alles erst einmal vorgekaut und vorverdaut.
Ich frag mich halt, wie man darauf kommt, sich so zu verhalten, wenn man selbst offenbar keine Ahnung hat – in jedem anderen Fall wär’s ja doch ein Leichtes, spätestens nach der dritten Nachfrage einfach die Option hinzuschreiben – von mir aus dann auch mit ’nem hämischen Kommentar über mein Lesevermögen, oder so. Ich geb dir mal noch eine Chance: welche Option von ›cp‹ soll den gewünschten Effekt erzeugen? Ich hab ’n ungefähre Ahnung, was in deiner Vorstellung funktioniert – probier’s besser aus, bevor du hier antwortest. Es tut nicht, was du dir vorzustellen scheinst. Kann natürlich sein, dass mir tatsächlich was entgangen ist – liegt an dir, mich bloßzustellen :D OT: „Küken“
:
Bearbeitet durch User
Die Loesung ist doch viel einfacher: Den 8 GB Stick mit dd auf einen 512 k Stick schreiben. Hab ich aehnlichst neulich gerade getan: Ein Rescuesystem, dass auf einem 64 GB Stick eine 32 GB Partittion fuer sich anlegt. Das ist schon bescheuert. Und dann in der 32 GB Partition gerade mal < 500 MB braucht... Also flugs den 64 GB Stick "roh" auf einen 16 GB Stick geschrieben. Natuerlich war das Dateisystem danach ein wenig karp0tt. Aber, der Stick bootet wie er soll. :)
Jack V. schrieb: > Ich geb dir mal noch eine Chance Hast du noch alle Tassen im Schrank? So eine verblödete Anmache funktioniert bestenfalls im Kindergarten. Immerhin solltest du dich daran doch noch gut erinnern können.
Norbert schrieb: > Hast du noch alle Tassen im Schrank? Meine Güte … mach’ doch kein Drama draus – poste, dass ich blöder Noob zu doof wäre, ›--sparse‹ zu erkennen, und zitiere noch die Zeilen dazu vom Ende der Manpage. Ich poste dann das Ergebnis einer solchen Operation, und du räumst ein, dass da ja noch ein Schritt fehlen würde, und dass du ja gemeint hättest, dass das schon gemacht worden wäre – was aber nicht zu dem von dir geposteten Quote aus dem Eingangsbeitrag passt. Außerdem verweise ich noch auf die Probleme, die dabei auftreten können, die du im Anschluss kleinzureden versuchst. Dann weiß jeder, woran er bei dir ist (falls das bis hier noch für irgendjemanden nicht klar geworden wäre, denn nur sehr narzisstische Leute handeln, wie du es hier gezeigt hast), und der TE hat eine weitere Option für sein Vorhaben, die allerdings etwas Umsicht erfordert.
:
Bearbeitet durch User
Motopick schrieb: > Natuerlich war das Dateisystem danach ein wenig karp0tt. > Aber, der Stick bootet wie er soll. :) Im Rheinland sagt man zu solchen Reparaturmethoden "beimachen". Es gilt: Prestolith und Fliegendraht halten auch bei schneller Fahrt. :)
Ich kann mich dunkel erinnern, dass ich in so einem Fall mal den Stick in ein Image geschrieben hatte, die Partition im Image verkleinern konnte, den Rest des Images gelöscht habe und dann das resultierende Image wieder auf einen kleineren Stick schreiben konnte. Ich weiß leider den genauen Weg dorthin nicht mehr.
Gerhard Z. schrieb: > Ich kann mich dunkel erinnern, dass ich in so einem Fall mal den Stick > in ein Image geschrieben hatte, die Partition im Image verkleinern > konnte, den Rest des Images gelöscht habe und dann das resultierende > Image wieder auf einen kleineren Stick schreiben konnte. Ich weiß leider > den genauen Weg dorthin nicht mehr. Ganz schoen umstaendlich. Gerade neulich habe ich einen "Ubuntu"-Installationsstick, 64 GB, auf einen mit 32 GB kopiert. Das ging mit fdisk, mkfs-vfat und cp -r eigentlich ganz einfach. Und der bootete auch. :) Ich weiss aber nicht mehr, ob das CSM da helfend eingegriffen hat, oder er aus dem UEFI bootete. Was ja schlussendlich auch egal ist. > Im Rheinland sagt man zu solchen Reparaturmethoden "beimachen". > Es gilt: > Prestolith und Fliegendraht halten auch bei schneller Fahrt. :) Naja, solange der prim./sek./tert. Bootlader auf dem Stick mit dem karp0tten Filesystem noch klarkommt, ist es ja Weisswust. Ich kenne auch weder "Prestolith" noch "Fliegendraht". Frohe Ostern!
Um die Verwirrung noch weiter zu steigern hier ein für diesen Zweck ausreichendes Miniscript um den Offset zu finden ab wann in einem File nur noch Nullen sind:
1 | od -A x -t x1z -v $1 | awk ' BEGIN { zero=0; flag=0}
|
2 | /00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00/ && flag == 1 { zero=1; flag=0; s=NR; off=$1; next}
|
3 | /00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00/ && flag == 0 { zero=1; next}
|
4 | !/00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00/ { flag=1; next}
|
5 | END { print zero ? (off " (" s ")") : ("none")}
|
6 | ' |
:
Bearbeitet durch User
G. K. schrieb: > Um die Verwirrung noch weiter zu steigern hier ein für diesen Zweck > ausreichendes Miniscript um den Offset zu finden ab wann in einem File > nur noch Nullen sind Wenn man weiß wie ein ext4 Dateisystem aufgebaut ist macht es wenig Sinn nach dem letzten Byte zu suchen. Motopick schrieb: > Die Loesung ist doch viel einfacher: > Den 8 GB Stick mit dd auf einen 512 k Stick schreiben. dd hat sogar die passenden Parameter dazu: conv=notrunc,noerror Gerhard Z. schrieb: > Ich kann mich dunkel erinnern, dass ich in so einem Fall mal den Stick > in ein Image geschrieben hatte, die Partition im Image verkleinern > konnte, den Rest des Images gelöscht habe und dann das resultierende > Image wieder auf einen kleineren Stick schreiben konnte. Ich weiß leider > den genauen Weg dorthin nicht mehr. So würde ich es auch machen. resize2fs -M
:
Bearbeitet durch User
> Motopick schrieb: >> Die Loesung ist doch viel einfacher: >> Den 8 GB Stick mit dd auf einen 512 k Stick schreiben. > > dd hat sogar die passende parameter dazu: conv=notrunc,noerror Was bringt "continue after read errors" konkret in diesem Fall?
Hallo Motopick, Motopick schrieb: > Ich kenne auch weder "Prestolith" noch "Fliegendraht". Prestolith ist eine Spachtelmasse, "Fliegendraht" ist eine Umschreibung für "Glasfasergewebematte". :) Hallo Alexander, Alexander schrieb: > Wenn man weiß wie ein ext4 Dateisystem aufgebaut ist macht es wenig Sinn > nach dem letzten Byte zu suchen. die startfähigen USB-Sticks entstehen typischerweise unter Nutzung von aus Dateiabbildern für optischen Datenträger, die bootfähig sind. Diese optischen Datenträger, wie z.B. CD-R oder DVD-R bergen ein IS09660-Dateisystem. Vermutlich mit ein paar Tricks werden diese ISO-Dateien so erstellt, dass sie auch bootfähig sind, wenn man sie direkt (also nicht auf Dateiebene) auf eine Festplatte schreibt. Auch dort bleibt dann das ISO9660-Dateisystem erhalten!
:
Bearbeitet durch User
Peter M. schrieb: > Hallo Motopick, Hallo Peter. > Vermutlich mit ein paar Tricks werden diese ISO-Dateien so erstellt, > dass sie auch bootfähig sind, wenn man sie direkt (also nicht auf > Dateiebene) auf eine Festplatte schreibt. > > Auch dort bleibt dann das ISO9660-Dateisystem erhalten! Vermutlich durch geschickte Sortierung der Dateien im Track. :) Ich habe mir mal eine bootfaehiger Solaris CD gebaut. Und das ging eigentlich ganz einfach. Mann nimmt sich eine Harddisk passender Groess, erzeugt darauf die Slices, in den Slices die (UFS-)Filesysteme, und bevoelkert die Filesysteme in den Slices mit den passenden Bootladern fuer die verschiedenen Architekturen. Dann "kopiert" man einfach seine Dateien in das "grosse" Filesystem das spaeter das Root-FS wird. Und die ganze Platte, muss man dann nur noch 1:1 auf das "ISO-Filesystem" einer CD brennen. Dazu braucht es nicht einmal ein mkisofs. Damit kann man dann von der Sun Classic, ueber den Sun Server 10 bis zur Sun Ultra davon booten und hat zumindest ein R/O Root-FS. Aber, wo bleibt dabei eigentlich das ISO-Filesystem? :) Auf der CD sind nur viele UFS-Filesysteme. Bei El-Torito weiss man ja woran man (nicht) ist...
Hallo Motopick, das klingt sehr beeindruckend, aber beim Thema Solaris bin ich definitiv kompetenzbefreit!
Peter M. schrieb: > Hallo Motopick, > > das klingt sehr beeindruckend, aber beim Thema Solaris bin ich definitiv > kompetenzbefreit! Ja schade. Die CD war recht nuetzlich um im Bedarfsfall ohne Geschraube eine Sun zu klonen. Die exportierte naemlich ihr Root-FS auch per NFS, und hatte auch die uebrigen Serverdienste die man zum Remote-Boot brauchte. Benutzt wird wohl das grundsaetzliche ISO-Format, also Fehlererkennung und Fehlerkorrektur, aber wohl nicht die Spezifika der Anordnung der Daten, Dateinamen, Verzeichnisse, ... wie sie der ISO-Standard vorsieht. Das sieht man ja auch bei Rettungssystemen, die FAT32/exFAT basiert sind, und so direkt auf eine CD/Stick geschrieben werden. Frohes Osterwochenende!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.