| View previous topic :: View next topic |
| Author |
Message |
manuels
Advocate
Joined: 22 Nov 2003
Posts: 2146
Location: Europe
|
 Posted: Sun Jan 27, 2008 4:20 pm Post subject: initttab not found/Dateisystemwahl |
 |
|
Heut meld ich mich mal aus Windows heraus, da mein Linux nicht mehr booten möchte.
Ich habe ein LVM-System mit via cryptsetup-verschlüsselten Partitionen.
Wenn ich Linux starte wird erst die initrd gestartet und das Passwort für die Entschlüsselung abgefragt.
Danach kommt allerdings (seitdem mein Rechner vorhin abgestützt ist) jetzt danach immer die Fehlermeldung:
und dann sowas wie "Enter runlevel:"
Egal welche Zahl ich dann eingebe, daraufhin kommt
| Code: | | No more processes left in this runlevel |
Hat jemand nen Tipp, wie ich das reparieren kann?
_________________
Build your own live cd with catalyst 2.0!
Last edited by manuels on Tue Jan 29, 2008 5:54 pm; edited 1 time in total |
|
| Back to top |
|
 |
Finswimmer
Bodhisattva
Joined: 02 Sep 2004
Posts: 5467
Location: Langen (Hessen), Germany
|
| Posted: Sun Jan 27, 2008 9:31 pm Post subject: |
|
|
Schmeiß die LiveCD rein, entschlüssel die Partition und check dann das Filesystem.
Tobi
_________________
Bitte auf Rechtschreibung, korrekte Formatierung und Höflichkeit achten!
Danke |
|
| Back to top |
|
|
manuels
Advocate
Joined: 22 Nov 2003
Posts: 2146
Location: Europe
|
| Posted: Mon Jan 28, 2008 12:22 pm Post subject: |
|
|
normalerweise wird die Rootpartiton vor dem mounten immer gecheckt (macht mein Script).
Hab gerade herausgefunden, dass /etc weg ist. Gibt es ne Möglichkeit das Verzeichnis wieder herzustellen?
_________________
Build your own live cd with catalyst 2.0! |
|
| Back to top |
|
|
69719
l33t
Joined: 20 Sep 2004
Posts: 865
|
| Posted: Mon Jan 28, 2008 12:29 pm Post subject: |
|
|
denke mit
oder die packages neu installieren, falls du welche erstellt hattest
|
|
| Back to top |
|
|
manuels
Advocate
Joined: 22 Nov 2003
Posts: 2146
Location: Europe
|
| Posted: Tue Jan 29, 2008 5:01 pm Post subject: |
|
|
hab bis jetzt immer jfs als Dateisystem genutzt, weil es für Laptops ganz gut sein soll.
Jetzt hab ich aber die Schnauze voll.
Könnt ihr mir ein Dateisystem empfehlen, bei dem ich keine kompletten Verzeichnisse verliere?
_________________
Build your own live cd with catalyst 2.0! |
|
| Back to top |
|
|
69719
l33t
Joined: 20 Sep 2004
Posts: 865
|
| Posted: Tue Jan 29, 2008 5:07 pm Post subject: |
|
|
| Ich nutze ext3, und reiserfs für /usr/portage. |
|
| Back to top |
|
|
manuels
Advocate
Joined: 22 Nov 2003
Posts: 2146
Location: Europe
|
| Posted: Tue Jan 29, 2008 5:08 pm Post subject: |
|
|
also mit reiser3 hab ich mir auch mal meine kompletten Daten zerhauen (was der Auslöser war, weiß ich nicht mehr).
_________________
Build your own live cd with catalyst 2.0! |
|
| Back to top |
|
|
schachti
Advocate
Joined: 28 Jul 2003
Posts: 3765
Location: Gifhorn, Germany
|
| Posted: Tue Jan 29, 2008 5:25 pm Post subject: |
|
|
ext3 mit der mount-Option data=journal ist "rock-solid". Es gibt zwar durchaus Szenarien, in denen andere Dateisysteme schneller sind, aber wenn die Sicherheit und Integrität der Daten im Vordergrund steht ist es meiner Meinung nach erste Wahl.
_________________
Never argue with an idiot. He brings you down to his level, then beats you with experience.
How-To: Daten verschlüsselt auf DVD speichern. |
|
| Back to top |
|
|
manuels
Advocate
Joined: 22 Nov 2003
Posts: 2146
Location: Europe
|
| Posted: Tue Jan 29, 2008 5:52 pm Post subject: |
|
|
hört sich gut an, sieht aber _sehr_ langsam aus (http://de.wikipedia.org/wiki/Ext3):
| Quote: | | Full (Option data=journal), wobei sowohl Metadaten als auch Dateiinhalte erst ins Journal geschrieben werden, bevor sie ins Dateisystem geschrieben werden. Dies erhöht die Zuverlässigkeit, ist aber recht langsam beim Schreiben, da alle Daten zweimal auf den Datenträger geschrieben werden müssen. Lesevorgänge werden beschleunigt. |
_________________
Build your own live cd with catalyst 2.0! |
|
| Back to top |
|
|
manuels
Advocate
Joined: 22 Nov 2003
Posts: 2146
Location: Europe
|
| Posted: Tue Jan 29, 2008 6:46 pm Post subject: |
|
|
hab mir bis jetzt folgendes überlegt:
| Code: |
/boot ext2
/usr/portage reiserfs3
/ ???
/var ???
/usr ???
/home ???
/opt ???
/tmp reiserfs3?
|
Für die mit ??? gekennzeichneten Partitonen überlege ich ext3 (ohne full journaling) zu nutzen.
Wie gesagt: ist für einen Laptop.
Bevor ich starte: gibt es hierzu konstruktive Kritik?
_________________
Build your own live cd with catalyst 2.0!
Last edited by manuels on Tue Jan 29, 2008 6:48 pm; edited 2 times in total |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6749
|
| Posted: Tue Jan 29, 2008 6:47 pm Post subject: |
|
|
| manuels wrote: | | hört sich gut an, sieht aber _sehr_ langsam aus |
Ist es auch. Total unnötiger overkill, und bei Stromausfall keineswegs sicherer als der Default data=ordered. Nimm entweder letzteres oder reiserfs. Bezüglich Sicherheit bei funktionierender Hardware gibt sich das alles nichts, und reiserfs ist das Schnellste und Sparmsamste davon. Nur wenn Du bei der Hardware mit Problemen rechnest, ist reiserfs vielleicht nicht die beste Wahl.
Weil meine Harddisk auf ein paar Blocks Lesefehler brachte, dummerweise anscheinend einen auf einem Block, der für das reiserfs lebenwichtig war, habe ich vor kurzem - nach Jahren zufriedener Nutzung von reiserfs - ein paar besonders wichtige Partitionen sicherheitshalber ext3 anvertraut. Diesen Schritt habe ich aufgrund der deutlich geringeren Geschwindkeit aber schon wieder bereut... |
|
| Back to top |
|
|
schachti
Advocate
Joined: 28 Jul 2003
Posts: 3765
Location: Gifhorn, Germany
|
| Posted: Tue Jan 29, 2008 7:18 pm Post subject: |
|
|
| mv wrote: | | manuels wrote: | | hört sich gut an, sieht aber _sehr_ langsam aus |
Ist es auch. Total unnötiger overkill,
|
Stimmt nicht - beim täglichen Arbeiten stelle ich keinen Geschwindigkeitsunterschied zwischen data=ordered und data=journal fest. Und es gibt (gab) zumindest Szenarien, in denen ext3 mit data=journal deutlich schneller ist, siehe http://www.ibm.com/developerworks/linux/library/l-fs8.html#4 (Hinweis: der Bericht dort ist inzwischen ca. 6 Jahre alt, ich weiß nicht, ob es vergleichbare Fälle immer noch gibt).
| mv wrote: |
und bei Stromausfall keineswegs sicherer als der Default data=ordered.
|
Natürlich ist es das - data=ordered schreibt nur die Metadaten in's journal, im Falle eines Stromausfalls kann es daher passieren, dass der Dateiinhalt inkonsistent ist (das Dateisystem an sich nicht). Bei data=journal ist jedoch auch der Dateiinhalt nach einem Crash konsistent.
| mv wrote: | | Diesen Schritt habe ich aufgrund der deutlich geringeren Geschwindkeit aber schon wieder bereut... |
Mir ist Datensicherheit wichtiger als Geschwindigkeit - ich stehe nicht so auf Russisch Roulette mit meinen Daten.
_________________
Never argue with an idiot. He brings you down to his level, then beats you with experience.
How-To: Daten verschlüsselt auf DVD speichern. |
|
| Back to top |
|
|
Klaus Meier
Advocate
Joined: 18 Apr 2005
Posts: 2908
Location: Bozen
|
| Posted: Tue Jan 29, 2008 7:35 pm Post subject: |
|
|
Hab da mal etwas mit rumprobiert und bei mir war data=ordered schneller als data=journal. Insgesamt ist ext3 in der letzten Zeit modifiziert und auch deutlich beschleunigt worden, da sollte man mit Tests aus dem letzten Jahrtausend vorsichtig sein.
Und ansonsten habe ich auch mal ext3 mit reiser3 verglichen, da war ext3 eigentlich durchgängig schneller (emerge --sync, kernel kompilieren, Systemstart). Des weiteren war bei reiser bei mir die Platte immer irgendwie am schrubben, bei ext3 ist das viel ruhiger.
Von der Sicherheit kann man nur sagen, dass wohl jedes FS schon mal gecrasht ist und dann kommen immer diese Aussagen: Nie wieder xyz. Wenn es danach ginge, dann dürfte man gar kein FS mehr verwenden.
Mich interessieren dabei nicht irgendwelchen theoretischen Benchmarks, sondern ob ich bei meinem System einen Unterschied spüre. Und da habe ich mich von der Summe her eindeutig für ext3 entschieden. Besonders, da es bei reiser3 inzwischen an Support mangelt und selbst Suse/Novell inzwischen ext3 empfiehlt. |
|
| Back to top |
|
|
Fauli
l33t
Joined: 24 Apr 2004
Posts: 760
Location: Moers, Germany
|
| Posted: Tue Jan 29, 2008 8:57 pm Post subject: |
|
|
Ich habe mein 1 GB großes /usr/portage (benutzt sind 30%, das DISTDIR habe ich in der make.conf auf /var/tmp/distfiles gesetzt) mit Blockgröße 1024 formatiert (mke2fs -j -m 0 -b 1024 -i 2048 /dev/XXX) und mir kommt das "emerge --sync" viel schneller vor als mit reiserfs, mit dem das Volume vorher formatiert war.
_________________
Do your part to beautify the web! Turn off link underlining! |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6749
|
| Posted: Tue Jan 29, 2008 9:28 pm Post subject: |
|
|
| Klaus Meier wrote: | | Und ansonsten habe ich auch mal ext3 mit reiser3 verglichen, da war ext3 eigentlich durchgängig schneller (emerge --sync, kernel kompilieren, Systemstart). Des weiteren war bei reiser bei mir die Platte immer irgendwie am schrubben, bei ext3 ist das viel ruhiger. |
Merkwürdig, bei mir ist das exakt umgekehrt. Gerade mit ext3 höre ich - auf relativ frischen Partitionen ohne große Fragmentierung - die ganze Zeit nur Kopfbewegungen der Platte, was wohl der Hauptgrund gegenüber dem Geschwindigkeitsverlust gegenüber reiserfs ist. Gerade das Booten und Kernel kompilieren geht viel langsamer. (Für portage benutze ich squashfs+aufs, so dass ich hier keinen Vergleich habe). Und ich brauche keine Benchmarks, um zu sehen, dass Operationen wie Löschen um Größenordnungen langsamer sind: Bei reiserfs benötigt das ein oder zwei Plattenzugriffe, bei ext3 kann das bei einer 4 GB Datei schon mal 10 Sekunden dauern. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6749
|
| Posted: Tue Jan 29, 2008 9:48 pm Post subject: |
|
|
| schachti wrote: | | mv wrote: |
und bei Stromausfall keineswegs sicherer als der Default data=ordered.
|
Natürlich ist es das - data=ordered schreibt nur die Metadaten in's journal, im Falle eines Stromausfalls kann es daher passieren, dass der Dateiinhalt inkonsistent ist (das Dateisystem an sich nicht). Bei data=journal ist jedoch auch der Dateiinhalt nach einem Crash konsistent. |
Flasch. Bei einem Stromausfall kann keine Strategie irgendetwas garantieren, weil es keinerlei Kontrolle gibt, was noch wohin geschrieben wird. Wie mir Hardware-Experten versichert haben, fällt bei Stromausfall nämlich zuerst das RAM zusammen. Wenn Du Pech hast, ist also gerade das Register betroffen, das den Sektor angibt, auf das die Daten geschrieben werden, und Dein Journal wird in den Bootsektor geschrieben o.ä.
Was tatsächlich mit größerer Wahrscheinlichkeit Konsistenz sichert, ist nicht sehr leicht zu erfassen. Die Politik, möglichst wenig Daten zu schreiben hat den Vorteil, dass im Falle eines Stromausfalls mit größerer Wahrscheinlichkeit gerade kein Schreibzugriff nötig war...
Und selbst von den Hardware-Phänomenen abgesehen, kann es vorteilhaft sein, wenn eine beim Stromausfall gerade beschriebene Datei ganz kaputt ist, oder noch gar nicht existiert, als dass undefinierter und nicht beendeter Müll darin steht. Was da die größere Konsistenz ist, hängt immer vom Einzelfall ab.
| Quote: | | mv wrote: | | Diesen Schritt habe ich aufgrund der deutlich geringeren Geschwindkeit aber schon wieder bereut... |
Mir ist Datensicherheit wichtiger als Geschwindigkeit - ich stehe nicht so auf Russisch Roulette mit meinen Daten. |
Nur ist keineswegs gesagt, dass die Daten auf ext3 sicherer sind. Mit der erwähnten Harddisk mit Lesefehlern hatte ich z.B. mit ext3 riesige Probleme, als der Master-Sektor (oder so ähnlich wurde er von ext3 genannt) ausfiel. Es ist halt bei allen Systemen ein russisch Roulette, wenn Hardware ausfällt. |
|
| Back to top |
|
|
Klaus Meier
Advocate
Joined: 18 Apr 2005
Posts: 2908
Location: Bozen
|
| Posted: Wed Jan 30, 2008 5:02 am Post subject: |
|
|
| Fauli wrote: | | Ich habe mein 1 GB großes /usr/portage (benutzt sind 30%, das DISTDIR habe ich in der make.conf auf /var/tmp/distfiles gesetzt) mit Blockgröße 1024 formatiert (mke2fs -j -m 0 -b 1024 -i 2048 /dev/XXX) und mir kommt das "emerge --sync" viel schneller vor als mit reiserfs, mit dem das Volume vorher formatiert war. |
Bei solchen Vergleichen muß man aber vorsichtig sein, weil das alte FS eventuell ziemlich fragmentiert war und einfach das Kopieren auf ein neues FS den Geschwindigkeitsvorteil bringt. |
|
| Back to top |
|
|
Klaus Meier
Advocate
Joined: 18 Apr 2005
Posts: 2908
Location: Bozen
|
| Posted: Wed Jan 30, 2008 5:08 am Post subject: |
|
|
| mv wrote: | | Nur ist keineswegs gesagt, dass die Daten auf ext3 sicherer sind. Mit der erwähnten Harddisk mit Lesefehlern hatte ich z.B. mit ext3 riesige Probleme, als der Master-Sektor (oder so ähnlich wurde er von ext3 genannt) ausfiel. Es ist halt bei allen Systemen ein russisch Roulette, wenn Hardware ausfällt. |
Defekte Hardware jetzt für oder gegen etwas einzusetzen halte ich für ziemlich daneben. Es ging wohl um Probleme, die im normalen Betrieb auftreten. Wenn Sektor zwei kaputt ist, dann ist ext3 am Arsch, bei Sektor sieben ist es dann reiser. Da will sich für mich kein Vorteil ergeben. Wer eine Platte mit einer wachsenden Zahl von defekten Sektoren weiterhin benutzt, dem hilft dann auch kein Journaling mehr. |
|
| Back to top |
|
|
schachti
Advocate
Joined: 28 Jul 2003
Posts: 3765
Location: Gifhorn, Germany
|
| Posted: Wed Jan 30, 2008 6:31 am Post subject: |
|
|
| mv wrote: | | Und ich brauche keine Benchmarks, um zu sehen, dass Operationen wie Löschen um Größenordnungen langsamer sind: Bei reiserfs benötigt das ein oder zwei Plattenzugriffe, bei ext3 kann das bei einer 4 GB Datei schon mal 10 Sekunden dauern. |
Das stimmt durchaus - nur: wie oft löscht man eine mehrere GB große Datei, so dass die gesamte Zeitersparnis so groß ist, um als Entscheidungsgrundlage für die Dateisystemwahl herzuhalten? Da zählen für mich die beiden Punkte Performance im täglichen "Workflow" und Datensicherheit - und meiner Meinung nach gibt es in Punkt 1 keine gravierenden Unterschiede zwischen den meisten Dateisystemen, und meiner Überzeugung nach liegt ext3 bei Punkt 2 vorne.
_________________
Never argue with an idiot. He brings you down to his level, then beats you with experience.
How-To: Daten verschlüsselt auf DVD speichern. |
|
| Back to top |
|
|
schachti
Advocate
Joined: 28 Jul 2003
Posts: 3765
Location: Gifhorn, Germany
|
| Posted: Wed Jan 30, 2008 6:38 am Post subject: |
|
|
| mv wrote: | | schachti wrote: | | mv wrote: |
und bei Stromausfall keineswegs sicherer als der Default data=ordered.
|
Natürlich ist es das - data=ordered schreibt nur die Metadaten in's journal, im Falle eines Stromausfalls kann es daher passieren, dass der Dateiinhalt inkonsistent ist (das Dateisystem an sich nicht). Bei data=journal ist jedoch auch der Dateiinhalt nach einem Crash konsistent. |
Flasch. Bei einem Stromausfall kann keine Strategie irgendetwas garantieren, weil es keinerlei Kontrolle gibt, was noch wohin geschrieben wird. Wie mir Hardware-Experten versichert haben, fällt bei Stromausfall nämlich zuerst das RAM zusammen. Wenn Du Pech hast, ist also gerade das Register betroffen, das den Sektor angibt, auf das die Daten geschrieben werden, und Dein Journal wird in den Bootsektor geschrieben o.ä.
Was tatsächlich mit größerer Wahrscheinlichkeit Konsistenz sichert, ist nicht sehr leicht zu erfassen. Die Politik, möglichst wenig Daten zu schreiben hat den Vorteil, dass im Falle eines Stromausfalls mit größerer Wahrscheinlichkeit gerade kein Schreibzugriff nötig war...
|
Ich zitiere an dieser Stelle einfach mal http://www.ibm.com/developerworks/linux/library/l-fs8.html#4:
| Quote: |
When appending data to files, data=ordered mode provides all of the integrity guarantees offered by ext3's full data journaling mode. However, if part of a file is being overwritten and the system crashes, it's possible that the region being written will contain a combination of original blocks interspersed with updated blocks. This is because data=ordered provides no guarantees as to which blocks are overwritten first, so you can't assume that just because overwritten block x was updated, that overwritten block x-1 was updated as well. Instead, data=ordered leaves the write ordering up to the hard drive's write cache.
|
Dass sowas bei allen Dateisystemen, die kein volles Journaling machen, ebenfalls passieren kann, dürfte klar sein. Bei ext3 mit data=journal hingegen gilt: zuerst werden alle Änderungen in's Journal geschrieben, und dann erst von dort aus in's Dateisystem. Wenn der Rechner abstürzt, bevor die Änderungen vollständig in's Journal geschrieben wurden, sind die Änderungen weg, aber die Datei befindet sich konsistent im alten Zustand. Wenn der Rechner abstürzt, nachdem die Änderungen in's Journal geschrieben wurden, aber bevor die Übertragung in's Dateisystem fertig ist, befindet sich die Datei nach einem Absturz zuerst in einem nicht-konsistenten Zustand. Wird dann jedoch das Dateisystem wieder gemountet, stehen die zu machenden Änderungen noch im Journal und werden durchgeführt - und die Datei ist konsistent im neuen Zustand.
_________________
Never argue with an idiot. He brings you down to his level, then beats you with experience.
How-To: Daten verschlüsselt auf DVD speichern. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6749
|
| Posted: Wed Jan 30, 2008 9:05 am Post subject: |
|
|
| Klaus Meier wrote: | | Defekte Hardware jetzt für oder gegen etwas einzusetzen halte ich für ziemlich daneben. Es ging wohl um Probleme, die im normalen Betrieb auftreten. Wenn Sektor zwei kaputt ist, dann ist ext3 am Arsch, bei Sektor sieben ist es dann reiser. Da will sich für mich kein Vorteil ergeben. Wer eine Platte mit einer wachsenden Zahl von defekten Sektoren weiterhin benutzt, dem hilft dann auch kein Journaling mehr. |
Ja. Deswegen habe ich eben auch meinen Umstieg reiserfs->ext3 bereut. Bei intakter Hardware sind beide gleich sicher und (zumindest bei mir) ist reiserfs deutlich schneller und platzsparender. Trotzdem ist es schon ein Argument, wie wahrscheinlich es ist, bei einem Sektorverlust Vieles zu verlieren; intuitiv würde ich vermuten, dass da reiserfs schlechter abschneidet; das lässt sich aber natürlich nicht an einem Einzelfall klären, sondern dazu bedürfte es einer mathematischen Analyse des Formats.
Ein anderes Argument gegen reiserfs ist in der Tat die inzwischen mangelnde Unterstützung. IIRC gibt es nur einen Maintainer bei kernel.org, der nicht begeistert von dem Job ist und nur noch Bugfixes einfügt. Andererseits: Ist bei ext3 mehr als nur Bugfixes zu erwarten?
Die Persönlichkeit der Maintainer ist nicht immer ein Argument, aber im Falle von ext2/ext3 fand ich das schon sehr krass. Wenn ich da an das Trauerspiel denke, wie das perfekt funktionierende e2comp aus unerklärlichen Motiven mit lächerlichen Argumenten gemobbt wurde, bis der Autor es offensichtlich aufgab, und es jetzt folglich immer noch keine eingebaute Kompression gibt, lässt meine Begeisterung für dieses Filesystem sehr nach. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6749
|
| Posted: Wed Jan 30, 2008 9:21 am Post subject: |
|
|
| schachti wrote: | | Wenn der Rechner abstürzt, bevor die Änderungen vollständig in's Journal geschrieben wurden [...] Wenn der Rechner abstürzt, nachdem die Änderungen in's Journal geschrieben wurden [...] |
Du übersiehst die kritischen Fälle: Wenn der Strom ausfällt, während die Daten ins Journal oder vom Journal ins Filesystem geschrieben werden. Es ist beim Zusammenfall des RAMs dann eben normal, dass dabei irgendwelcher Unsinn geschrieben wird - aber (da der Prozessor davon ja nichts wissen kann) trotzdem das Flag "Journal voll/leer" geschrieben wird. Dann wird beim nächsten Booten der Müll vom Journal auf die Platte geschrieben bzw. es wird nicht erkannt, dass vorher Müll geschrieben wurde. Der Müll kann natürlich sowohl Daten als auch Metadaten betreffen.
Sicherlich: Volles Journaling sichert ein Szenario beim Zusammenfall etwas besser ab; dafür werden mehr Daten geschrieben, wodurch das obige Szenario wahrscheinlicher eintritt. Was insgesamt sicherer ist, kann man nur stochastisch abschätzen. Ich vermute, dass es keinen wesentlichen Unterschied macht. |
|
| Back to top |
|
|
Klaus Meier
Advocate
Joined: 18 Apr 2005
Posts: 2908
Location: Bozen
|
| Posted: Wed Jan 30, 2008 12:25 pm Post subject: |
|
|
| @mv: Ich bevorzuge Backups gegenüber wissentschaftlichen Untersuchungen zur Datensicherheit. Ich komme aus der Computerbranche und kenne Rechner, wo ein defektes Netzteil den ganzen Rechner geschrottet hat. Da hilft dir dann kein Raid, keine zweite Festplatte und kein Journaling. Da hilft dir nur noch eine Sicherung auf einem externen Medium. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Deutsches Forum (German)
