Archiv verlassen und diese Seite im Standarddesign anzeigen : entfernen nicht möglich: read only file system
Hi Leute,
ich hab gestern angefangen mich mit LFS ein bisschen auseinander zu setzen.
Dabei bin ich nach der deutschen LFS Dokumentation (http://oss.erdfunkstelle.de/lfs-de/6.2/online/index.html) vorgegangen. Eigentlich klappte alles ziemlich gut bis ich den gcc kompilieren wollte und der Compiler dieses mit einer Fehlermeldung verweigerte. Die genaue Fehlermeldung weiß ich nicht mehr,jedoch war es etwas von wegen er könne die Log Datei nicht auf einer read-only gemounteten Partition schreiben.Ich hab mir nichts dabei gedacht und den Computer heruntergefahren um am nächsten Tag weiterzumachen. Als ich heute den Computer wieder gestartet habe um dem Problem auf den Grund zu gehen entdecke ich,dass anscheinend die komplette Partition read only gemountet ist.
ein "mount" liefert jedoch folgende Ausgabe:
/dev/hda3 on /mnt/lfs type ext3 (rw)
Derzeit wird die Partition automatisch beim Systemstart gemountet,der fstab Eintrag lautet folgendermaßen:
dev/hda3 /mnt/lfs ext3 rw 0 0
Ein "mount -a" ein Neustart,oder händisches mounten der Partition bringen auch nicht den gewünschten Erfolg.
Obwohl es eigentlich nicht daran liegen sollte habe ich schon mit allen drei Usern(bernhard,lfs und root) versucht eine Datei zu löschen.Doch es kommt,wie oben bereits geschrieben,der Fehler mit dem "read only file system"...
Irgendwie seh ich den Wald vor lauter Bäumen nicht...
Falls es von Bedeutung sein sollte:
verwendete Distribution: Ubuntu Edgy mit Vmplayer emuliert
Vielen Dank!
Mmh, die Ausgabe von mount ist tatsächlich irritierend. Kannst Du die Fehlermeldung (zusammen mit Deinem Befehl) bitte im Wortlaut hierher copypasten?
Zu dem Versuch, eine Datei zu löschen: Was sagt ein "lsattrib <dateiname>"?
Hast Du mal fsck über die Partition laufen lassen?
Probier in der fstab auch mal "defaults" statt nur "rw". Oder setz ein "mount -o remount,rw /dev/hda3 /mnt/lfs" ab. Kommen Meldungen?
Was sagt "file -s /dev/hda3" und "dmesg | grep hda3"?
Kreol
Hi Kreol,
mit "rm -rf gcc-4.0.3" möchte ich den kompletten Ordner mit zugehörigem Inhalt löschen.
Die Fehlermeldung lautet:
rm: Entfernen von „gcc-4.0.3/MD5SUMS“ nicht möglich: Read-only file system
Diese Fehlermeldung kommt natürlich bei jeder im Ordner befindlichen Datei.
Die Ausgabe von: "file -s /dev/hda3":
/dev/hda3: writable, no read permission
Die Ausgabe von: "dmesg | grep hda3":
[17179581.928000] hda: hda1 hda2 hda3 hda4
[17179623.500000] EXT3-fs warning (device hda3): ext3_clear_journal_err: Filesystem error recorded from previous mount: IO failure
[17179623.500000] EXT3-fs warning (device hda3): ext3_clear_journal_err: Marking fs in need of filesystem check.
[17179623.500000] EXT3 FS on hda3, internal journal
[17179816.868000] hda3: rw=0, want=5881864, limit=5863725
[17179816.868000] EXT3-fs error (device hda3): ext3_find_entry: reading directory #352001 offset 0
[17179816.868000] Aborting journal on device hda3.
[17179818.332000] EXT3-fs error (device hda3): ext3_journal_start_sb: Detected aborted journal
[17180104.392000] hda3: rw=0, want=5881864, limit=5863725
[17180104.392000] EXT3-fs error (device hda3): ext3_readdir: directory #352001 contains a hole at offset 0
[17180104.484000] hda3: rw=0, want=5874944, limit=5863725
[17180104.484000] EXT3-fs error (device hda3): ext3_readdir: directory #339092 contains a hole at offset 0
[17180104.508000] hda3: rw=0, want=5879064, limit=5863725
[17180104.508000] EXT3-fs error (device hda3): ext3_readdir: directory #339274 contains a hole at offset 0
[17180104.556000] hda3: rw=0, want=5955800, limit=5863725
[17180104.556000] EXT3-fs error (device hda3): ext3_readdir: directory #341207 contains a hole at offset 0
[17180104.560000] hda3: rw=0, want=5956008, limit=5863725
[17180104.560000] EXT3-fs error (device hda3): ext3_readdir: directory #341212 contains a hole at offset 0
[17180104.616000] hda3: rw=0, want=5959328, limit=5863725
[17180104.616000] EXT3-fs error (device hda3): ext3_readdir: directory #341300 contains a hole at offset 0
[17180104.628000] hda3: rw=0, want=5968088, limit=5863725
[17180104.628000] EXT3-fs error (device hda3): ext3_readdir: directory #341362 contains a hole at offset 0
[17180104.632000] hda3: rw=0, want=5968264, limit=5863725
[17180104.632000] EXT3-fs error (device hda3): ext3_readdir: directory #341373 contains a hole at offset 0
[17180105.092000] hda3: rw=0, want=5864704, limit=5863725
[17180105.092000] EXT3-fs error (device hda3): ext3_readdir: directory #339032 contains a hole at offset 0
[17180105.916000] hda3: rw=0, want=5864192, limit=5863725
[17180105.916000] EXT3-fs error (device hda3): ext3_readdir: directory #339016 contains a hole at offset 0
[17180178.856000] hda3: rw=0, want=5864192, limit=5863725
[17180178.856000] EXT3-fs error (device hda3): ext3_readdir: directory #339016 contains a hole at offset 0
[17180178.952000] hda3: rw=0, want=5864704, limit=5863725
[17180178.952000] EXT3-fs error (device hda3): ext3_readdir: directory #339032 contains a hole at offset 0
[17180179.004000] hda3: rw=0, want=5874944, limit=5863725
[17180179.004000] EXT3-fs error (device hda3): ext3_readdir: directory #339092 contains a hole at offset 0
[17180179.016000] hda3: rw=0, want=5879064, limit=5863725
[17180179.016000] EXT3-fs error (device hda3): ext3_readdir: directory #339274 contains a hole at offset 0
[17180179.532000] hda3: rw=0, want=5955800, limit=5863725
[17180179.532000] EXT3-fs error (device hda3): ext3_readdir: directory #341207 contains a hole at offset 0
[17180179.536000] hda3: rw=0, want=5956008, limit=5863725
[17180179.536000] EXT3-fs error (device hda3): ext3_readdir: directory #341212 contains a hole at offset 0
[17180185.660000] hda3: rw=0, want=5959328, limit=5863725
[17180185.660000] EXT3-fs error (device hda3): ext3_readdir: directory #341300 contains a hole at offset 0
[17180185.664000] hda3: rw=0, want=5968088, limit=5863725
[17180185.664000] EXT3-fs error (device hda3): ext3_readdir: directory #341362 contains a hole at offset 0
[17180185.668000] hda3: rw=0, want=5968264, limit=5863725
[17180185.668000] EXT3-fs error (device hda3): ext3_readdir: directory #341373 contains a hole at offset 0
[17180687.252000] EXT3-fs warning (device hda3): ext3_clear_journal_err: Filesystem error recorded from previous mount: IO failure
[17180687.252000] EXT3-fs warning (device hda3): ext3_clear_journal_err: Marking fs in need of filesystem check.
[17180687.260000] EXT3 FS on hda3, internal journal
[17180705.064000] hda3: rw=0, want=5881864, limit=5863725
[17180705.064000] EXT3-fs error (device hda3): ext3_find_entry: reading directory #352001 offset 0
[17180705.064000] Aborting journal on device hda3.
[17180705.940000] EXT3-fs error (device hda3): ext3_journal_start_sb: Detected aborted journal
[17180831.668000] hda3: rw=0, want=5864192, limit=5863725
[17180831.672000] EXT3-fs error (device hda3): ext3_readdir: directory #339016 contains a hole at offset 0
[17180831.772000] hda3: rw=0, want=5864704, limit=5863725
[17180831.772000] EXT3-fs error (device hda3): ext3_readdir: directory #339032 contains a hole at offset 0
[17180831.828000] hda3: rw=0, want=5874944, limit=5863725
[17180831.828000] EXT3-fs error (device hda3): ext3_readdir: directory #339092 contains a hole at offset 0
[17180831.840000] hda3: rw=0, want=5879064, limit=5863725
[17180831.840000] EXT3-fs error (device hda3): ext3_readdir: directory #339274 contains a hole at offset 0
[17180832.608000] hda3: rw=0, want=5955800, limit=5863725
[17180832.608000] EXT3-fs error (device hda3): ext3_readdir: directory #341207 contains a hole at offset 0
[17180832.620000] hda3: rw=0, want=5956008, limit=5863725
[17180832.620000] EXT3-fs error (device hda3): ext3_readdir: directory #341212 contains a hole at offset 0
[17180839.336000] hda3: rw=0, want=5959328, limit=5863725
[17180839.336000] EXT3-fs error (device hda3): ext3_readdir: directory #341300 contains a hole at offset 0
[17180839.340000] hda3: rw=0, want=5968088, limit=5863725
[17180839.340000] EXT3-fs error (device hda3): ext3_readdir: directory #341362 contains a hole at offset 0
[17180839.344000] hda3: rw=0, want=5968264, limit=5863725
[17180839.344000] EXT3-fs error (device hda3): ext3_readdir: directory #341373 contains a hole at offset 0
[17182594.380000] hda3: rw=0, want=5864192, limit=5863725
[17182594.380000] EXT3-fs error (device hda3): ext3_readdir: directory #339016 contains a hole at offset 0
[17182594.388000] hda3: rw=0, want=5864704, limit=5863725
[17182594.388000] EXT3-fs error (device hda3): ext3_readdir: directory #339032 contains a hole at offset 0
[17182594.408000] hda3: rw=0, want=5874944, limit=5863725
[17182594.408000] EXT3-fs error (device hda3): ext3_readdir: directory #339092 contains a hole at offset 0
[17182594.408000] hda3: rw=0, want=5879064, limit=5863725
[17182594.408000] EXT3-fs error (device hda3): ext3_readdir: directory #339274 contains a hole at offset 0
[17182594.484000] hda3: rw=0, want=5955800, limit=5863725
[17182594.484000] EXT3-fs error (device hda3): ext3_readdir: directory #341207 contains a hole at offset 0
[17182594.484000] hda3: rw=0, want=5956008, limit=5863725
[17182594.484000] EXT3-fs error (device hda3): ext3_readdir: directory #341212 contains a hole at offset 0
[17182595.472000] hda3: rw=0, want=5959328, limit=5863725
[17182595.472000] EXT3-fs error (device hda3): ext3_readdir: directory #341300 contains a hole at offset 0
[17182595.472000] hda3: rw=0, want=5968088, limit=5863725
[17182595.472000] EXT3-fs error (device hda3): ext3_readdir: directory #341362 contains a hole at offset 0
[17182595.472000] hda3: rw=0, want=5968264, limit=5863725
[17182595.472000] EXT3-fs error (device hda3): ext3_readdir: directory #341373 contains a hole at offset 0
[17182623.604000] hda3: rw=0, want=5864192, limit=5863725
[17182623.604000] EXT3-fs error (device hda3): ext3_readdir: directory #339016 contains a hole at offset 0
[17182623.624000] hda3: rw=0, want=5864704, limit=5863725
[17182623.624000] EXT3-fs error (device hda3): ext3_readdir: directory #339032 contains a hole at offset 0
[17182623.632000] hda3: rw=0, want=5874944, limit=5863725
[17182623.632000] EXT3-fs error (device hda3): ext3_readdir: directory #339092 contains a hole at offset 0
[17182623.632000] hda3: rw=0, want=5879064, limit=5863725
[17182623.632000] EXT3-fs error (device hda3): ext3_readdir: directory #339274 contains a hole at offset 0
[17182623.720000] hda3: rw=0, want=5955800, limit=5863725
[17182623.720000] EXT3-fs error (device hda3): ext3_readdir: directory #341207 contains a hole at offset 0
[17182623.720000] hda3: rw=0, want=5956008, limit=5863725
[17182623.720000] EXT3-fs error (device hda3): ext3_readdir: directory #341212 contains a hole at offset 0
[17182624.740000] hda3: rw=0, want=5959328, limit=5863725
[17182624.740000] EXT3-fs error (device hda3): ext3_readdir: directory #341300 contains a hole at offset 0
[17182624.740000] hda3: rw=0, want=5968088, limit=5863725
[17182624.740000] EXT3-fs error (device hda3): ext3_readdir: directory #341362 contains a hole at offset 0
[17182624.740000] hda3: rw=0, want=5968264, limit=5863725
[17182624.740000] EXT3-fs error (device hda3): ext3_readdir: directory #341373 contains a hole at offset 0
Die Ausgabe von "fsck /dev/hda3":
fsck 1.38 (30-Jun-2005)
e2fsck 1.38 (30-Jun-2005)
/dev/hda3: stelle das Journal wieder her
Die Dateisystem Größe ( laut SuperBlock) ist 767103 Blocks
Die physikalische Größe von Gerät ist 732965 Blocks
Entweder der SuperBlock oder die Partionstabelle ist beschädigt!
Abbrechen<j>?
Der Tipp mit dem Filesystemcheck ist wohl des Rätsels Lösung.
Ich hab ein wenig die Suchmaschine gequält und bin dabei auf keine schnelle Lösung gestoßen. Da ist eine einfache Neupartitionierung meist schneller als die Zeit mit der Rettung der Partition zu vergeuden.Oder hat von euch noch jemand einen Tipp?
Jedenfalls mal Danke an dich,Kreol!
Auf die Idee mit dem Check wäre ich ehrlich gesagt nie gekommen,da man die Partition bis auf ein paar wenige Dateien noch komplett lesen kann...
...
Der Tipp mit dem Filesystemcheck ist wohl des Rätsels Lösung.
Ich hab ein wenig die Suchmaschine gequält und bin dabei auf keine schnelle Lösung gestoßen. Da ist eine einfache Neupartitionierung meist schneller als die Zeit mit der Rettung der Partition zu vergeuden.fsck ist eigentlich recht zuverlässig, auch wenn ein Backup sehr empfehlenswert ist, solange die Daten lesbar sind.
Das brauchst Du ja auch bei einer Neuformatierung (!= "Neupartitionierung") und es ist eh nie verkehrt... ;)
Wenn
Entweder der SuperBlock oder die Partionstabelle ist beschädigt!nicht wäre. Was sagt denn "fdisk -l"? Alles normal?
Ich würde Daten sichern, es dann erst mit fsck probieren und auch mal das Prüftool des Herstellers sowie smartctl über die Platte laufen lassen.
Die Lage der Ersatz-Superblocks verrät Dir (wenn Du beim Formatieren keine besonderen Optionen angegeben hast) "mke2fs -n" (siehe man mke2fs). Dann einen der dadurch ermittelten Ersatzblöcke bei fsck mit "-b" mitgeben. Lies auf jeden Fall vorher die Manpage zu fsck (e2fsck) durch.
Kreol
Sodale,mein Entschluss steht fest,ich erstelle eine neue Partition.
Der Aufwand der durch das reparieren entstehen würde rechtfertigt das ganze nicht so wirklich.
Noch zur Info:
"fdisk -l" zeigte eigentlich alles normal an
"mke2fs -n" Den Befehl kannte ich noch gar nicht
Die automatische Reparatur mittels fsck ist fehlgeschlagen und eine SMART Unterstützung fehlt der Festplatte leider.
Nochmals Danke für deine Unterstützung :)
Hmm,das ist echt komisch....
Ich habe jetzt gestern die Partition mit "cfdisk /dev/hda" gelöscht und anschließend nochmals eine Partition,die etwas kleiner ist als die alte ist,erstellt.
Anschließend hab ich auf dieser mit "mke2fs -jv /dev/hda3" ein Dateisystem erstellt.Dann noch fix die gesicherten Daten zurückgespielt und ich wollte weiter an dem LFS System arbeiten.Bevor ich damit angefangen habe,habe ich noch einen Filesystemcheck gemacht: "fsck -f /dev/hda3"
Dabei sind mir keine Fehler aufgefallen.
Heute habe ich die virtuelle Maschine wieder angeworfen und wollte den Eigentümer von dem Inhalt des Ordners "sources" auf den Benutzer lfs ändern.
chown -hR lfs /mnt/lfs/sources
Nun kommt jedoch wieder die Meldung mit dem read-only-file system:
[....]
chown: Ändern des Eigentümers von „/mnt/lfs/sources/vim-7.0-spellfile-1.patch“: Read-only file system
[....]
Ein erneuter Filesystemcheck bringt wieder den bereits bekannten Superblock bzw Partitionstabellen Fehler.
Langsam glaube ich,bei der Erstellung der virtuellen Festplatte mit www.easyvmx.com ist etwas schiefgelaufen..
Ein erneuter Filesystemcheck bringt wieder den bereits bekannten Superblock bzw Partitionstabellen Fehler.
Langsam glaube ich,bei der Erstellung der virtuellen Festplatte mit www.easyvmx.com ist etwas schiefgelaufen..
Naja, so kompliziert ist das erstellen einer VMWare-Festplatte iirc nicht.
Aber eventuell hat ja die zugrunde liegende echte Platte einen Schaden? Hast du da mal mit "badlocks" nach dem Rechten gesehen?
Oder beendest du vmware einfach immer hart?
...
Die automatische Reparatur mittels fsck ist fehlgeschlagen...Wie ist das zu verstehen? Hast Du die Meldungen noch?
Und badblocks, das Prüftool des Herstellers oder auch die Ultimate Boot CD (http://www.ultimatebootcd.com/download.html) sind wohl eine gute Idee.
Kreol
Nein,die virtuelle Maschine wird bis auf ein paar wenige Ausnahmen immer ordnungsgemäß heruntergefahren.
Ich hab jetzt mit dem Tool "HUTIL" von Samsung meine Festplatte nach Fehlern durchsucht und leider meldet das Tool auch welche.
Error: LBA 377339275 /
Error: Undefined Error
Das Tool schlägt mir nun vor die Festplatte komplett zu formatieren um dann einfach nochmals den Test durchzuführen.
Derzeit bin ich aber noch am Überlegen ob ich dies wirklich machen soll,da mir eigentlich sonst überhaupt keine Fehler aufgefallen sind....
Ich hab übrigens nochmals nachgeschaut und die Platte unterstützt doch S.M.A.R.T. Ich habe mir nun mittels "smartctl -H /dev/hdd" den Gesundheitszustand anzeigen lassen und dort steht ein "Passed".
Zudem ist die Platte auch erst im Dezember 2006 gekauft worden,was natürlich einen Hardwareschaden nicht ausschließt.
Dennoch möchte ich zuerst,nachdem ich meine Musiksammlung gesichert habe,probieren den Fehler mit verschiedenen Tools zu Leibe zu rücken.
Hat da jemand für mich einen Tipp welche Programme dazu geeignet sind?
p.s: Die badblocks Prüfung mache ich morgen noch!
edit: Hab gerade einen (ich denke guten) Artikel dazu gefunden[1]
Das werde ich dann morgen noch ausprobieren
[1] http://www.pro-linux.de/t_system/badblock.html
Danke!
Hallo,
heute habe ich mit fsck die Festplatte nach Fehlern durchstöbert. Zuerst habe ich es mit folgendem Kommando probiert: "fsck /dev/hdd".Bei dem Aufruf kam die Fehlermeldung "bad magic number in superblock". Danach kam mir der Gedanke,dass auf der Festplatte mehrere Partitionen mit unterschiedlichem Dateiformat vorhanden sind. Keine Ahnung ob diese Überlegung richtig ist,aber ich habe daraufhin jede Partition mit dem zugehörigen Aufruf des Dateisystems nach Fehlern gescannt. Hier das Ergebnis:
sh-3.1# fsck.vfat /dev/hdd8
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
/dev/hdd8: 4076 files, 608806/1953928 clusters
sh-3.1# fsck.ext2 /dev/hdd6
e2fsck 1.40-WIP (14-Nov-2006)
Dateisystem hat keinen UUID ; generiere einen.
Kubuntu: clean, 11/12681216 files, 2804990/50724865 blocks
sh-3.1# fsck.vfat /dev/hdd7
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
There are differences between boot sector and its backup.
Differences: (offset:original/backup)
28:3f/71, 29:00/7b, 30:00/4c, 31:00/06
1) Copy original to backup
2) Copy backup to original
3) No action
?
Was würdet ihr hier auswählen? Ich würde hier Nummer 2 nehmen,ist das richtig?
sh-3.1# fsck.ext2 /dev/hdd9
e2fsck 1.40-WIP (14-Nov-2006)
Backup: clean, 11/5070848 files, 834426/20282031 blocks
e2fsck 1.40-WIP (14-Nov-2006)
Durchgang 1: Prüfe Inodes, Blocks, und Größen
Durchgang 2: Prüfe Verzeichnis Struktur
Durchgang 3: Prüfe Verzeichnis Verknüpfungen
Durchgang 4: Überprüfe die Referenzzähler
Durchgang 5: Überprüfe Gruppe Zusammenfassung
Freie Blocks Anzahl ist falsch Gruppe #101 (140, counted=138).
Repariere<j>? ja
Freie Blocks Anzahl ist falsch (1684501, counted=1684499).
Repariere<j>? ja
Freie Inodes Anzahl ist falsch für Gruppe #93 (15123, counted=15122).
Repariere<j>? ja
Freie Inodes Anzahl ist falsch für Gruppe #101 (14094, counted=14090).
Repariere<j>? ja
Verzeichnisanzahl ist falsch für Gruppe #101 (397, counted=398).
Repariere<j>? ja
Freie Inodes Anzahl ist falsch (5526950, counted=5526945).
Repariere<j>? ja
/dev/hdd10: ***** DATEISYSTEM WURDE VERÄNDERT *****
/dev/hdd10: 179903/5706848 files (3.6% non-contiguous), 9725659/11410158 blocks
sh-3.1#
Leider bin ich erst zum Schluss auf die Idee gekommen den Parameter "-f" dem Filesystemcheck mitzugeben.
Das werde ich bei den anderen Partitionen noch nachholen,ebenso wie der badblocks-Test(hab den mal probeweise gestartet und der dauert ziemlich lange).
...Zuerst habe ich es mit folgendem Kommando probiert: "fsck /dev/hdd".Bei dem Aufruf kam die Fehlermeldung "bad magic number in superblock". Danach kam mir der Gedanke,dass auf der Festplatte mehrere Partitionen mit unterschiedlichem Dateiformat vorhanden sind. Keine Ahnung ob diese Überlegung richtig ist,aber ich habe daraufhin jede Partition mit dem zugehörigen Aufruf des Dateisystems nach Fehlern gescannt.
...
Leider bin ich erst zum Schluss auf die Idee gekommen den Parameter "-f" dem Filesystemcheck mitzugeben.
Das werde ich bei den anderen Partitionen noch nachholen,ebenso wie der badblocks-Test(hab den mal probeweise gestartet und der dauert ziemlich lange).Die Überlegung ist richtig.
Bevor Du fsck oder badblocks ausführst solltest Du unbedingt die Manpages lesen. Gerade bei Parametern die -f lauten würde ich vorher wissen wollen, was sie eigentlich machen. Und bei fsck gibt es verschiedene manpages, je nach FS: man reiserfsck, man fsck.ext2 (bzw. e2fsck), ...
Warum das zu empfehlen ist: Bei badblocks iVm ext2/3 gibt es z.B. Besonderheiten, wenn die Ergebnisse von badblocks weiterverwendet werden sollen
Important note: If the output of badblocks is going to be fed to the e2fsck or mke2fs programs, it is important
that the block size is properly specified, since the block numbers which are generated are very dependent on the
block size in use by the filesystem. For this reason, it is strongly recommended that users not run badblocks
directly, but rather use the -c option of the e2fsck and mke2fs programs.So etwas liest man am besten vorher nach. Reines Rumexperimentieren auf Verdacht ist da eher Kontraproduktiv.
Kreol
Grundsätzlich schaue ich mir vorher mit dem Parameter --help an was die Funktionen grob machen.
Aber wie du bereits gesagt hast,ist es bei so heiklen Sachen wohl wirklich besser die Manpages zu lesen.Der von dir zitierte Auszug aus der badblocks Manpage wäre mir ohne deinen Hinweis entfallen.
Vielen Dank!
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.