Hi zusammen, gleich vorne weg: mir ist klar, daß ich auf eigenes Risiko gebastelt habe. Ich habe ein Memory Center 6TB, welches teilweise schon mit Daten befüllt ist. Da mich die (nicht überschreibbare) Spindown-Funktion nach 3min in meiner Anwendung sehr gestört hat, habe ich die Firmware der USB-Bridge nach der Anleitung von Hardkernel (https://wiki.odroid.com/odroid-xu4/software/jms578_fw_update) aktualisiert. Um die Daten nicht zu gefährden, habe ich während des Flashvorgangs eine alte Platte eingebaut. Allerdings wird die Original-Platte nach dem Update zwar korrekt erkannt, aber die Partitionierung etc scheint hinüber. Vermutlich emuliert die USB-Bridge andere Sektorgröße. Jetzt dachte ich: OK, dann back to the roots... Nur habe ich das Problem nach dem Rückspielen der backup-Firmware von oben immer noch. Bislang habe ich noch nicht schreibend auf die Platte zugegriffen - ich habe also noch einen Funken Hoffnung (außer die USB-Bridge schreibt von sich aus) Hat jemand von Euch eine gute Idee? Wenn es wirklich eine doofe Sektor-Emulation ist: Gibt es ein Tool unter Linux, mit dem man solche Verquirlungen zumindest lesen kann (=> Rettung auf neue Platte [die ich dann kaufen würde])? Was macht man eigentlich, wenn so eine Platte mal am USB kaputt geht? Am PC auslesen geht ja dann auch nicht mehr. Vielen Grüße und einen guten Start ins Neue Jahr! Andreas P.S. Platte hängt eigentlich am BananaPi (Armbian) oder Raspberry. Auf dem PC habe ich Linux Mint.
Vermutlich ist die SATA-Verschlüsselung aktiv oder so. Den Schlüssel hast du gequirlt. Neu Partitionieren und Backup einspielen...
Roland E. schrieb: > Vermutlich ist die SATA-Verschlüsselung aktiv oder so. Den Schlüssel > hast du gequirlt. > > Neu Partitionieren und Backup einspielen... Hi Roland, SATA-Verschlüsselung? Dazu habe ich im product brief von JMicron nichts gesehen. Warum sollte der verschlüsseln? Hast Du ein Datenblatt o.ä.? Ich hoffe immer noch, daß es nur ein Interpretationsfehler mit Sektorgröße ist. Hoffnung stirbt zuletzt :( Die Ausgabe von
1 | lsblk -t |
liefert folgendes:
1 | NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME |
2 | sda 0 4096 0 4096 512 1 mq-deadline 60 128 0B |
3 | └─sda1 0 4096 0 4096 512 1 mq-deadline 60 128 0B |
Außerdem sehe ich mit dmesg beim Anstecken der Platte etwas bislang unbekanntes:
1 | [sda] Optimal transfer size 33553920 bytes not a multiple of preferred minimum block size (4096 bytes) |
VG Andreas
Hi, sorry, wenn es jetzt etwas gestückelt kommt. Vielleicht kann der eine oder andere noch etwas zu meinem Lernprozeß beitragen. Oder irgendjemand hat in Zukunft man ein ähnliches Problem und sieht direkt, was (schief) ging. ;) Habe mir mal den Anfang der Platte mit dd in eine Datei geladen und mit einem Hex-Editor angeschaut. Der Anfang schaut gar nicht mal so übel aus. MBR: Bei 0x00 habe ich bis 0x4a was drinstehen. Danach bis 0x1b7 nur noch 0. Das müßte eigentlich der Bootloader sein. Danach eine Datenträgersignatur von genau 4 Byte. Danach 2 Bytes 0. => paßt Ab 0x1BE soll die Partitionstabelle kommen. Da stehen auch Werte !=0. Ab 0x1FE habe ich die Signatur 55 AA => paßt. GPT-Header finde ich in den ersten 100MB des Dumps nicht. Partitionstabelle besteht aus:
1 | 00 04 05 00 83 FE FF FF 00 01 00 00 00 1D 54 57 |
Der Rest sind 0er. Die erste 0 paßt, die CHS-Adressierung kann ich nicht beurteilen (doof, wenn das der Knackpunkt ist), 83 lt. Wikipedia Linux-Partition => paßt Danach wieder CHS-Adresse. Anzahl der Sektoren in der Partition 1D 54 57 wäre bei 4096Byte/Sektor 7,3TB - das erscheint mit etwas viel für eine 6TB Platte!?! Bei 512Byte/Sektor wäre etwas zu wenig. Ursprünglich war 1 Partition auf der Platte, die von vorne bis ganz hinten ging. Bei 0x100478 finde ich das Linux Disklabel (Zufall?) und ein paar Bytes später den Mount-Pfad (?). Zwischen der Partitionstabelle und 0x100401 stehen nur 0er Jetzt mal eine blöde Frage: GPT-Header finde ich ja nicht. Müßte der nicht bei 0x0200 oder 0x1000 (=Beginn 2. Sektor) kommen? Also da, wo die ganzen 0er stehen? VG Andreas
:
Bearbeitet durch User
ein letztes Update für heute (falls überhaupt noch jemand mitliest ;) ) Habe mir mal einen Dump von meiner Seagate-Platte angeschaut. Disklabel und Mountpoint stehen da exakt an der gleiche Stelle. Die Partition scheint also prinzipiell noch da zu sein. Unterschiede habe ich bei fdisk -l festgestellt. Intenso hat Disklabel type: dos, Seagate Disklabel type: gpt. Und bei der Seagate finde ich auch den GPT-Header bei 0x200. Was zu der Frage führt: wo kommt der neue MBR her? Schreibt Linux was direkt beim Einstecken (ohne mounten?) Wenn ich die Tage mal so richtig Mut habe, versuche ich einfach mal den ersten Sektor mit der Partitionstabelle zu überschreiben. Entweder ich sehe die Partition wieder oder ich habe halt alles geschrottet... VG Andreas
Beschaff dir eine weitere Platte, die minimal so gross ist, wie das was drauf war. Dann benutze einen partition Manager z.b. EaseUS Partition Master, der ist normalerweise in der Lage, selbst zerschossene Partitionen zu lesen. Dann kopiere alles auf die neue Platte. Dann kannst du ja mit der eh schon kaputten Platte deine Experimente weiter treiben.
Von K. schrieb: > Außerdem sehe ich mit dmesg beim Anstecken der Platte etwas bislang > unbekanntes:[sda] Optimal transfer size 33553920 bytes not a multiple of > preferred minimum block size (4096 bytes) 2^25 - 2^9 Seltsam. Könnte das die Größe eines ›Shingles‹ sein?
Von K. schrieb: > Was zu der Frage führt: wo kommt der neue MBR her? Schreibt Linux was > direkt beim Einstecken (ohne mounten?) Linux schreibt - im Gegensatz zu Windows und Mac - nichts auf Datenträger, wenn man sie anschliesst.
Von K. schrieb: > Wenn ich die Tage mal so richtig Mut habe, versuche ich einfach mal den > ersten Sektor mit der Partitionstabelle zu überschreiben. Entweder ich > sehe die Partition wieder oder ich habe halt alles geschrottet... Wen Du dies tust, ist die Partition über 'normale' Wege nicht mehr erreichbar. Du wirst kaum das Installationsschema so hinbringen, wie es war. Außer es wurde ursprünglich mit GPartet erstellt. Denn dies richtet die Partition nach Cylinder aus, und nicht nach Sektor. Du solltest den ersten Daten/Partitionsektor suchen, und schauen, ob der Eintrag der Partitionstabelle (4 Einträge) passt. Sektor-genau !!! Du müsstest erstmal in der Partitionstabelle schauen, ob die Einträge zum Anfang der Partition passen. Ich hatte es mal, dass hier durch 'hartes Ausschalten' der Eintrag nicht mehr passte. Ich wusste aber zufällig wo die Partition wirklich anfing, stellte dies in der Part-Tabelle wieder richtig, und alles war wieder okay. Was mich wundert, Linux erstellt eigentlich immer eine 'Swap-Partition'. Diese sollte nach der Linux-Partition, bzw am Ende der Platte liegen. Desweiteren kann es sein, dass der erste 'Superblock' defekt ist. - Keine Sorge, der ist X-mal als Kopie vorhanden. Superplock-Kopie dann wieder an den ersten Platz kopiere, alles wieder gut. Es gibt Tools (R-Studio) die finden die Daten auch ohne Partitionstabellen, Superblock's. Dafür scannt die Software die 6TB ab, und bringt Dir ALLE Daten wieder, sofern nicht drauf geschrieben wurde. Dann ist halt der Bereich 'futsch', der beschrieben wurde. Wir reden hier von Extf4 ?
:
Bearbeitet durch User
Hi Stephan, hi Thomas, erstmal alles Gute im Neuen Jahr! > Linux schreibt - im Gegensatz zu Windows und Mac - nichts auf > Datenträger, wenn man sie anschliesst. Das dachte ich mir so auch. Als einzige Ausnahme würde ich Desktop-Linux sehen. Cinnamon mountet Datenträger beim Einstecken automatisch. Könnte mir vorstellen, daß er auch automatisch ein Recovery versucht, wenn das gefundene Dateisystem nicht "clean" ist. > Wir reden hier von Extf4 ja, ext4. Auch nur die eine Partition, weil die externe Platte nur ein Datengrab ist und auch nicht immer angeschlossen. Daher würde swap keinen Sinn machen. Meine Idee mit der neuen Partitionstabelle + GPT ist nicht, mich da mit fdisk oder gparted rumzuschlagen. Da ist mir zu viel "magic" drin bzw ich nutze die zu selten, um ungewolltes Eigenleben auszuschließen. Meine Idee war eher, mit die ersten xx kB von der Seagate-Platte zu nehmen und dort den Endsektor anzupassen. Der Anfang der Partition ist ja bytegenau identisch, sonst hätte ich das Label nicht an exakt der gleichen Position gefunden. Oder habe ich da einen Denkfehler? Also mit dd die Seagate-Platte auslesen (habe ich ja schon für die Analyse), die End-Sektor-Bytes anpassen und mit dd auf die Intenso-Platte schreiben. Halt wirklich nur die ersten xx kB überschreiben, nicht gleich alles. Habe mich noch nicht entschieden, ob ich dd nehme oder was fix selbst baue. Was macht denn das Gerät /dev/sda, wenn ich nur ein paar Bytes am Anfang schreibe und dann die Geräte-Datei schließe? Ein truncate macht ja prinzipiell keinen Sinn - setzt er noch ein Sonderzeichen danach auf die Platte? Hoffe ich nicht, aber auch noch nicht ausprobiert... Aber um die Backup-Platte zum Testen komme nicht drum herum. Daher wird sich das ganze wahrscheinlich noch bis Februar verschieben müssen. :( VG Andreas
Von K. schrieb: > Was macht denn das Gerät /dev/sda, wenn ich nur ein paar Bytes am > Anfang schreibe und dann die Geräte-Datei schließe? Falsche Frage :( Und wieso sda? Bootest du von nvme oder sowas? Hast du schon probiert, die Partition am PC zu mounten? Also
1 | mount -o ro,offset=0x100000 /dev/sdxyz /mnt |
Hi Bauform, sda macht durchaus Sinn, weil ich wie oben schon geschrieben eigentlich auf dem Bananapi unterwegs bin und da die SD-Karte nicht sd_ heißt. Am PC (auch Linux) möchte ich momentan lieber nichts experimentieren, weil Cinnamon besagten Auto-Mount mitbringt - das ist mir viel zu viel Magie im Hintergrund. So ein recht rudimentäres System ohne auto-irgendwas ist mir da lieber. Mount könnte ich tatsächlich mal probieren. Die Idee ist so naheliegend, daß ich nicht drauf gekommen bin. :( Mit ro dürfte er ja eigentlich auch keinesfalls schreiben, oder? Auch kein fsck etc. Und dann damit die Daten kopieren, die (hoffentlich) noch erreichbar sind. VG Andreas
Von K. schrieb: > Am PC (auch Linux) möchte ich momentan lieber nichts experimentieren, > weil Cinnamon besagten Auto-Mount mitbringt - das ist mir viel zu viel > Magie im Hintergrund. So ein recht rudimentäres System ohne > auto-irgendwas ist mir da lieber. Guter Plan! > Mit ro dürfte er ja eigentlich auch keinesfalls schreiben, oder? Auch > kein fsck etc. fsck nicht, dazu müsste die Platte in /etc/fstab drin stehen. Dank USB musst du ja nicht booten, damit entfällt auch das Risiko. Allerdings: u.U. macht ext4 journal replay. Normalerweise will man das, auch wenn man nur lesen will. Aber man kann dem Block Device selbst einen Schreibschutz verpassen:
1 | blockdev --setro /dev/sdxyz |
https://unix.stackexchange.com/questions/190012/how-do-i-prevent-ubuntu-from-writing-anything-to-an-external-harddrive
:
Bearbeitet durch User
@klausewitz Sind Dir die Daten 'wichtig'? - dann ohne Schreibversuche mit z.B. R-Studio versuchen die Daten zu lesen. Sind alle Sektoren lesbar, ist das Wiederherstellen mit R-Studio ein 100% Erfolg. Einzig Umlaute in Dateinamen werden falsch interpretiert. Aber das wäre das geringste Übel. Hinweis: Wenn Du die Platte stundenlang an einem Linux-PC hast, kann es sein, dass Linux das Desaster merkt, und 'selbständigt' versucht die Superblock's wieder zu synchronisieren. Meist klappt das auch, kann aber auch schiefgehen. Mit R-Studio kannst Du übrigens an jeder beliebigen Stelle der HDD schreiben was Du willst.
Thomas S. schrieb: > Hinweis: Wenn Du die Platte stundenlang an einem Linux-PC hast, kann es > sein, dass Linux das Desaster merkt, und 'selbständigt' versucht die > Superblock's wieder zu synchronisieren. Meist klappt das auch, kann aber > auch schiefgehen. Nun, dieses Timeout würde mich interessieren. Also wirklich interessieren. Wann greift das? Halbjährlich, Vierteljährlich, Täglich oder gar garnich? ;-)
Maximal wenige Sekunden: normalerweise läuft bei jedem booten ein fsck und normalerweise macht der das. Jedenfalls gibt es mit bookworm und sysv-init entsprechende Meldungen, auch in /var/log/fsck/ Edit: oder solange, bis ein USB-Wackelkontakt das Filesystem ruiniert ;)
:
Bearbeitet durch User
Bauform B. schrieb: > Maximal wenige Sekunden: normalerweise läuft bei jedem booten ein > fsck > und normalerweise macht der das. Jedenfalls gibt es mit bookworm und > sysv-init entsprechende Meldungen, auch in /var/log/fsck/ Das finde ich insofern verblüffend, als das ich hier eine Festplatte mit händisch zerstörtem ersten Superblock problemlos extern anstecken kann ohne das auch nur das Geringste (schreibend) passiert. Nun ist mein System auch nicht auf alles Mögliche an Auto-Gimmiks eingerichtet, daran mag es liegen. Dranstecken heißt hier einfach nur: Dranstecken.
:
Bearbeitet durch User
Norbert schrieb: > Das finde ich insofern verblüffend, als das ich hier eine Festplatte mit > händisch zerstörtem ersten Superblock problemlos extern anstecken kann > ohne das auch nur das Geringste (schreibend) passiert. Ja, natürlich, es sollte wohl heißen: "normalerweise läuft bei jedem booten ein fsck und normalerweise macht der das, wenn die Platte in /etc/fstab eingetragen ist." Was bei einer regelmäßig benutzten externen ja leicht sein kann.
Norbert schrieb: > Nun, dieses Timeout würde mich interessieren. > Also wirklich interessieren. > Wann greift das? extf4 hat eben einen Journaling-Mechanismus, der bei jedem Dateizugriff das Journaling aktualisiert. Deshalb kann Linux zumindest extf4 (extfs3 wohl auch schon ?) Schäden im FS durch z.B. hartes Ausschalten aufspüren, und meist wieder reparieren. Dies erledigen zum einen die mehrfachen Kopien vom Superblock. Zum anderen scannt Linux in Intervallen das Medium auf Fehler. Wann die passiert, steht evtl. in der fstab, oder ist ein Cron-Job. Korrigiert mich da, wenn ich falsch liege. Dazu muss natürlich das Journaling auch 'eingeschaltet sein'.
:
Bearbeitet durch User
Thomas S. schrieb: > extf4 hat eben einen Journaling-Mechanismus, der bei jedem Dateizugriff > das Journaling aktualisiert. Das ist mir alles seit sehr, sehr langer Zeit bekannt. Ich war nur verblüfft über die Meinung, das bei einem ›*RO*‹ Device eine der Partitionen plötzlich und automagisch beschrieben werden soll. Obwohl, magisch wäre da ja schon eine zutreffende Bezeichnung. Wenn man allerdings - und ich weiß beim besten Willen nicht warum man so etwas tun sollte - aber wenn man nun einen automount Mechanismus und dann noch als RW konfiguriert hat…
Thomas S. schrieb: > extf4 hat eben einen Journaling-Mechanismus, der bei jedem Dateizugriff > das Journaling aktualisiert. Das ja. Ist allerdings keinesfalls ein Alleinstellungsmerkmal, das konnte z.B. NTFS schon vor 30 Jahren, also lange vor ext4. > Deshalb kann Linux zumindest extf4 (extfs3 > wohl auch schon ?) Schäden im FS durch z.B. hartes Ausschalten > aufspüren, und meist wieder reparieren. Reparieren aber nur in dem Sinne, dass das FS wieder konsistent wird. Das heißt aber NICHT, dass: 1) zuletzt geschriebene Änderungen im reparierten Ergebnis ankommen (Normalfall ist das Gegenteil) 2) Dass der Inhalt des reparierten Filesystems auch aus Sicht von Anwendungen konsistent ist (logische Folge von 1) Das allerdings gilt natürlich auch nicht nur für ext4 sondern auch für NTFS. Gleiche Konzepte führen halt zu gleichen Ergebnissen. > Dies erledigen zum einen die > mehrfachen Kopien vom Superblock. Nein. Das ist was völlig anderes, das gab es auch schon viel früher, also z.B. bei ext2 oder sogar schon den diversen FAT-Varianten. Das hat nix mit mit dem Journaling zu schaffen. Das ist Redundanz auf einer viel primitiveren Ebene.
Ob S. schrieb: > Reparieren aber nur in dem Sinne, dass das FS wieder konsistent wird. Das aber bedeutet, schreibend auf die Festplatte zuzugreifen. Den Widerspruch zu "ro" (read-only) erkennst Du dabei nicht?
Naja, die Grenze zwischen Technik und Magie... man mount sagt z.B.:
1 | -r Mount the filesystem read-only. A synonym is -o ro. |
2 | |
3 | Note that, depending on the filesystem type, state and kernel |
4 | behavior, the system may still write to the device. For example, |
5 | ext3 and ext4 will replay the journal if the filesystem is dirty. |
6 | To prevent this kind of write access, you may want to mount an ext3 |
7 | or ext4 filesystem with the ro,noload mount options or set the |
8 | block device itself to read-only mode, see the blockdev(8) command. |
Bauform B. schrieb: > man mount sagt z.B.: ›mount‹ kann _evtl._ schreiben, aber NUR wenn man für das darunter liegende Device Schreiboperationen überhaupt zulässt. Aber das wurde bereits von einem Vorredner genügend dargelegt.
Norbert schrieb: > ›mount‹ kann _evtl._ schreiben, aber NUR wenn man für das darunter > liegende Device Schreiboperationen überhaupt zulässt. Und welches Device, was grundsätzlich zum Zugriff auf HDDs/SSDs ausgelegt ist, erlaubt keine Schreibzugriffe? Das wäre ein armseliges, für praktische Zwecke unbenutzbares Device. Ausnahme wäre: forensische Zwecke. Deswegen gibt es tatsächlich solche Devicetreiber. Aber sicher nicht in Standard-Kernels von der Stange...
Ob S. schrieb: > Und welches Device, was grundsätzlich zum Zugriff auf HDDs/SSDs > ausgelegt ist, erlaubt keine Schreibzugriffe? Das wäre ein armseliges, > für praktische Zwecke unbenutzbares Device. Das ist einfach, das beantworte ich. Standard Debian, Standard Kernel: jedes armselige Device welches mit ›blockdev‹ in den RO Modus versetzt werden kann. Also 'ne ganze Menge… Danach ein mount ro,norecovery … fertig.
Norbert schrieb: > Das ist einfach, das beantworte ich. > Standard Debian, Standard Kernel: jedes armselige Device welches mit > ›blockdev‹ in den RO Modus versetzt werden kann. Hmm... Und wie genau macht das jezt der TO? Und zwar bevor der erste Zugriff auf das Device erfolgt?
Ob S. schrieb: > Und wie genau macht das jezt der TO? Und zwar bevor der erste > Zugriff auf das Device erfolgt? Von K. schrieb: > P.S. Platte hängt eigentlich am BananaPi (Armbian) oder Raspberry. Auf > dem PC habe ich Linux Mint. Ein Armbian ist ein Debian. Also macht er's so wie er's zuvor am Raspberry oder am PC mit Mint geübt hat. Im schlimmsten anzunehmenden Fall kann er ja zuvor eine Sicherung durchführen. Obwohl, so etwas machen wir ja im 21. Jahrhundert nicht mehr. Da operieren wir erst einmal bei Windstärke acht in der Kiesgrube am offenen Herzen. ;-)
Hi zusammen, bitte entschuldigt die späte Rückmeldung. War unter der Woche beruflich eingespannt und hatte abends keinen Nerv mehr für solche Experimente. 1.) Platte an BabanaPi angesteckt 2.) /dev/sda blockdev auf read-only gesetzt. Vielen Dank für diesen Befehl, den kannte ich noch nicht 3.) Partition manuell mit offset ro gemounted (wie oben vorgeschlagen) 4.) ich sehe meine Dateien!!! :) 5.) aktuell ziehe ich alles runter, was geht. Muß das ein bißchen Stückeln, weil ich keine 4TB (Datenmenge) am Stück irgendwo frei habe. Aber alles besser als nichts. Mal gespannt, ob noch Lesefehler kommen... VG Andreas
Von K. schrieb: > 5.) aktuell ziehe ich alles runter, was geht. Muß das ein bißchen > Stückeln, weil ich keine 4TB (Datenmenge) am Stück irgendwo frei habe. > Aber alles besser als nichts. Mal gespannt, ob noch Lesefehler kommen... So, und in Zukunft packst Du gefälligst nicht alle Eier in einen Korb, wie die Briten sagen, sondern machst Backups. fchk
Von K. schrieb: > Muß das ein bißchen > Stückeln, weil ich keine 4TB (Datenmenge) am Stück irgendwo frei habe. Das ist eine der Naturkonstanten: Bei Datenrettungen hat man nie genug Platz.
Hi zusammen, ein finales Update: Daten waren alle unbeschädigt verfügbar. Das mit dem Übernehmen des modifizierten GPT von der anderen Platte hat so nicht ganz funktioniert. Irgendwas muß ich da übersehen haben. Jedenfalls hat er zwar eine GPT-Tabelle erkannt, aber trotzdem immer was erzählt, daß eine DOS-Partition nicht so groß sein könnte ... In einem Anflug von Euphorie habe ich dann doch fdisk probiert (mit cfdisk kam ich so gar nicht zurecht). Neue GPT-Tabelle erstellt, neue primäre Partition mit entsprechend Anfang und Ende erzeugt - und siehe da: Rückfrage, ob er gefundene EXT4-Markierung löschen oder übernehmen soll. Natürlich übernehmen ;) Speichern, Platte weg, Platte dran - geht :) Danke an alle für die Hilfe, vor allem das blockdev. Wären die Daten verloren gewesen, wäre auch kein Weltuntergang gewesen. Aber so habe ich noch sehr viel gelernt über Partitionen :) VG Andreas
Harald K. schrieb: > Von K. schrieb: >> Muß das ein bißchen >> Stückeln, weil ich keine 4TB (Datenmenge) am Stück irgendwo frei habe. > > Das ist eine der Naturkonstanten: Bei Datenrettungen hat man nie genug > Platz. Beim Drama kauft man sich die. Ich finde allerdings interessant, wie oft, mitunter auch recht leichtfertig Leute Firmwareupdates machen, BIOS neu flashen etc. Das tat bei mir irgendwie noch nie wirklich not. Ausser wenn Mudderns Sat-Receiver danach gelüstet und so'n Ding sonst nichts mehr macht. (Jungeeeh kannst Du da mal bitte gucken?)
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.