Laufwerk vor fstab

[KBDCALLS]

Dann kommt ja wohl auch noch dazu das die Speicherbausteine der USBsticks eine mindere Qualität haben , dann kommen die Speicherkarten wie SD CF und wie se alle heißen und dann die für die SSDs . Und will man bessere Qualität haben kostets halt mehr.

[logoft]

logoft, hast du dir mal CentOS angeguckt? Da kommt das noch am ehesten hin mit deinen sieben Jahren.

Und egal, welches Betriebssystem du wählst ... wenn du es auf einen USB-Stick installierst, hält es nicht mal ein Jahr.

Wie meinst Du das mit Cent??

Mir gehts beim Stick ums schnelle testen können. Ich habe Debian auf einer SSD. Ob sie wegen den Schreibyklus optimiert ist weiß ich nicht.

BSD gibts als Real Time OS, nennt sich NUTTX, das würde ich dann vorziehen.

mfg

[logoft]

Mir ist realativ egal ob man ein Stick abziehen kann oder nicht. Ein Stick ist dafür gedacht einfach abgezogen zu werden. Wenn es zu Problemen führt mache ich es zukünftig eben nicht mehr. Es kann aber nicht sein das ein ganzer Stick gesperrt wird. Das mußwieder rückgänig gemacht werden können und dann wird der Stick eben nicht mehr abgezogen. Es muß aber ein Hinweis erscheinen wer sowas gemacht hat.

Ist er nicht, zumindest bei laufenden Schreiboperationen. Und da warnt selbst Winziglweich vor. Man soll einen Stick oder was auch immer erst unmounten und dann kann man ihn sicher entfernen. Das kann man übrigens ganz leicht selbst ausprobieren. Während eines Schreivorgangs den Stick mal unmounten, macht man das auf einer Konsole , meldet sich der Prompt erst nach einer Weile zurück.

Das ich ein Stick whrend des Schreibvorgangs nicht einfach abziehen soll ist mir klar. Ich denke auch nicht das es so passiert ist. Ich glaube ich habe den Rechner mit dem AUS Knopf einfach ausgemacht.

Ich finde es aber höchst ärgerlich das dasteht ich sollte fsck nehmen, aber der Stick läßt keine Korrektur zu. Da steht write protected und das System wäre nicht clean. Was immer das bedeutet, nicht sauber zu sein.
Ich weiß doch nicht wann das wieder passieren könnte, in einer Woche oder 7 Jahren? Soll ich mir immer einen neuen Stick kaufen?
Ich weiß nicht mal was es bedeutet eine Datei mit Flags zu versehen und wo der Unterschied zu einem Filesystem liegt? Ist ein Filesystem eine Datei? Oder ein Abschnitt auf dem Datenträger, ähnlich einem Bootsektor?
Ich verstehe leider diesen RAM-Tester nicht,komme jetzt nicht drauf, ist ganz bekannt. Der läuft Tage lang. Wenn der melden würde KAPUTT hätte ich Klarheit, selbst wenn es 4 Tage dauert.

[chmod007]

nicht Cent, sondern CentOS. Das ist der freie u. kostenlose Nachbau von Redhat Enterprse Linux, der wie das Original ewig lange supported wird.

Wenn du noch nichtmal sicher sagen kannst, ob deine SSD richtig eingerichtet ist, solltest du dich vielleicht erstmal damit beschäftigen, ehe du weitere USB-Sticks grillst oder gar Exoten wie Realtime-Betriebssysteme ins Auge fasst.

--------------------------------------------

Die Anzeige "Filesystem nicht clean" kommt daher, dass du den Stick einfach ziehst, ohne ihn vorher zu unmounten.
FSCK weigert sich da zu recht, denn jeder Schreibzugriff könnte zu einem inkonsistenten DAteisystem führen.

Ich weiß nicht mal was es bedeutet eine Datei mit Flags zu versehen und wo der Unterschied zu einem Filesystem liegt? Ist ein Filesystem eine Datei? Oder ein Abschnitt auf dem Datenträger, ähnlich einem Bootsektor?

Du solltest dich echt mal mit den Grundlagen beschäftigen...
Ein Dateisystem verwaltet Dateien auf einem Datenträger. Darin wird gespeichert, auf welchen Sektoren der Festplatte / Partition die Inhalte der Datei gespeichert sind.
Je nach Dateisystemtyp werden noch einige andere Metadaten geschrieben, bei modernen Dateisystemen zudem auch ein Journal, welches Änderungen an einem Dateisystem festhält. Mit Hilfe des Journals können zum Beispiel die Folgen von unvollständigen Schreibvorgängen (wie sie zum Beispiel entstehen, wenn ein Datenträger einfach so abgesteckt wird) repariert werden.

Und was willst du jetzt mit nem RAM-Tester?

[logoft]

Ich weiß schon das es CentOS ist. Ich weiß auch was ein Filesystem ist. Nur wie tief das alles liegt weiß ich nicht. Mein erster PC hatte 8 Mhz. Ich hatte den Atari 800XL.

Ich habe was gefunden:

root@trag:~/Downloads/Stick-Test/f3-6.0# f3read /media/disk
SECTORS ok/corrupted/changed/overwritten

Data OK: 0.00 Byte (0 sectors)
Data LOST: 0.00 Byte (0 sectors)
Corrupted: 0.00 Byte (0 sectors)
Slightly changed: 0.00 Byte (0 sectors)
Overwritten: 0.00 Byte (0 sectors)
Average reading speed: 0.00 Byte/s
root@trag:~/Downloads/Stick-Test/f3-6.0#
root@trag:~/Downloads/Stick-Test/f3-6.0#
root@trag:~/Downloads/Stick-Test/f3-6.0#
root@trag:~/Downloads/Stick-Test/f3-6.0# f3write /media/disk
Free space: 945.47 MB
Creating file 1.h2w ... f3write: Can't create file /media/disk/1.h2w: Read-only file system
root@trag:~/Downloads/Stick-Test/f3-6.0#

+++++++++++++++++++++++

Nun ein RAM tester wäre was gewesen um was zu testen. Aber sowas meinte ich nicht ganz. Es wäe MemTest86 gewesen.
Mir schwebte was vor die Bereiche auf dem Stick zu testen.

Ich bin anders gestrickt. Ich werde mir ein Stick kaufen, aber den Stick der jetzt streikt werde ich nicht wegwerfen. Ich werde lieber auf BSD verzichten. Denn ein System das den ganzen Stick sperrt kann ich nicht gebrauchen. Ich weiß nicht malob es BSD war.

Und ein Real Time OS ist schnell, weil es die Hardware nicht so nutzt. Ich hatte schon QNX 6 installiert. Leider kann ich kaum Englisch ummich vernünftig auszudrücken. Ich fand den Login nicht, wie das Login-Programm heißt. Da guckt einen ein kleiner Mann an
da muß man root eingeben ohne Passwort. Das Ding fand ich nicht. QNX4 läuft mit IDE im BIOS, ist aber viel zu alt.

Ich will weg von Windows und will ein System das zuverlässig läuft. QNX oder NUTTX wäre eine Spielerei gewesen. Und Debian läuft. Ich hätte mich mit OpenBSD angefreundet,aber so ein Stick-Blockierer ist untragbar. Ich weiß nicht mal ob es BSD war oder ob der Stick tatsächlich kaputt ist. Wenn man mit der Winblöd Registry den Stick beeinflussen kann muß das auch mit einer Linux oder BSD Installation gehen. Zu sagen der Stick ist kaputt ist weder bewiesen noch nehme ich das so hin. Und das er kaputt ist, ist viel zu einfach. Mein Auto läuft nicht, deshalb werfe ich es in die Presse? Mein Haus geht nicht auf, deshalb reiße ich es ab? So gehts nicht.

mfg

[logoft]

Die Anzeige "Filesystem nicht clean" kommt daher, dass du den Stick einfach ziehst, ohne ihn vorher zu unmounten.
FSCK weigert sich da zu recht, denn jeder Schreibzugriff könnte zu einem inkonsistenten DAteisystem führen.


Der untere Absatz ist interessant. Es könnte also ein Fehler auf dem Stick sein, den ich erst beseitigen müßte. Ich glaube das Ding heißt supergrub. Der Bootloader funktioniert zwar, aber vielleicht ist trotzdem was kaputt. Es ist zwar nicht Grub der drauf ist, aber vielleicht ist was tiefers kaputt.

mfg

[DeletedUserReAsG]

Du solltest dir echt die Grundlagen draufschaffen. Ob dein erster Rechner 8MHz hatte, oder nicht, ist unerheblich – offensichtlich hast du nicht gelernt, dass RAM und Storage verschiedene Dinge sind, sonst würdest du nicht von memtest86 im Zusammenhang mit ’nem USB-Stick faseln. Häng’ den Stick endlich mal aus und schreib mit fdisk aus util-linux eine neue Partitionstabelle auf das Device (und nicht wieder auf eine Partition – auch eine der Grundlagen, die du mal lernen könntest) – und wenn’s mit ≠0 endet, schreib’ hier die Meldung rein. Wenn’s mit 0 endet, lass ’n mkfs.wasauchimmerdudraufhabenwillst auf die Partition los und schreib’ hier die Fehlermeldung, wenn’s etwas anderes als 0 zurückgibt. Gibt schon fdisk zurück, dass es die Tabelle nicht schreiben konnte, kannst du den Stick entsorgen. Kann doch nicht so schwer sein, das zu verstehen, wenn der erste Rechner 8MHz hatte?

[smutbert]

Ob das etwas mit dem unangekündigten Abziehen des Sticks zu tun hat oder nicht - keine Ahnung, aber ratsam ist es natürlich allein im Hinblick auf das Dateisystem nicht.

Meines Wissens „mountet“ Windows USB-Sticks übrigens mit dem was unter Linux der Mountoption sync entspricht - dies hat, weil dann alles schnellstmöglich auf den Stick geschrieben wird, mehr Schreibzugriffe zur Folge als ohne diese Option (zB weil irgendein Speicherbereich zwei Mal kurz hintereinander direkt auf dem Stick beschrieben wird, was ohne diese Option im Cache passieren würde). Das hat Vor- wie Nachteile:
- man kann den Stick, ohne Gefahr für das Dateisystem abziehen, wenn gerade nichts geschrieben wird
- es geht wesentlich langsamer vonstatten
- der Flash-Speicher verschleißt schneller (ich habe den starken Verdacht, dass dieses Verhalten vor einiger Zeit einen meiner USB-Sticks vorzeitig das Leben gekostet hat, defekt war der Speicherbereich wo bei FATxx die Dateizuordnungstabelle liegt, also der Speicherbereich, der unter der sync-Option bestimmt am stärksten leidet)


Das Problem liegt hier — jedenfalls in erster Linie — nicht am Dateisystem. Schon das Blockgerät selbst ist nicht beschreibbar.
Wie gesagt, wenn der Stick nicht über einen richtigen Schreibschutz als ein-/ausschaltbares Feature verfügt, dann kann die Ursache meiner Meinung nach nur ein Defekt des Sticks die Ursache sein und genau das glaube ich.
Und wenn das so ist, dann kannst du den Stick unter keinem Betriebssystem mehr beschreiben - mein Hinweis also einmal zu versuchen ihn unter Windows oder Mac OS X zu formatieren, dient also auch der Diagnose.

Solange sich der Stick nicht mehr beschreiben lässt und ich glaube fast nicht, dass er das jemals wieder tun wird, kannst du rein gar nichts machen…

[DeletedUserReAsG]

Das Problem liegt hier — jedenfalls in erster Linie — nicht am Dateisystem. Schon das Blockgerät selbst ist nicht beschreibbar.

… wäre auch meine Vermutung, aber die Bestätigung des Threadstarters in Form einer entsprechenden Fehlermeldung und/oder eines entsprechenden Logeintrages steht noch aus (oder ich hab’s aufgrund der unformatierten Sülze oben übersehen […]). Soweit ich das bislang aufgefasst habe, rödelte der Threadstarter jedenfalls recht uninformiert auf der Partition bei eingehängtem FS rum, und das sagt über den Zustand es Devices ansich so gar nix aus.

[owl102]

Wenn man mit der Winblöd Registry den Stick beeinflussen kann

Hast du da einen Link für uns?

[smutbert]

[…] auf der Partition bei eingehängtem FS rum, und das sagt über den Zustand es Devices ansich so gar nix aus.

Das nicht, aber die Datei im sysfs, die er in den mc-Screenshots gepostet hat und die Fehlemeldungen von parted zeigen eindeutig, dass tatsächlich der Stick an sich nicht beschreibbar ist und das Dateisystem allenfalls eine weitere Hürde wäre, die man vermutlich mit fsck leicht beheben könnte, wenn der Stick eben beschreibbar wäre.
(Auch die etwas merkwürdigen Fehlermeldungen von fsck deuten darauf hin, dass das blockgerät selbst nicht beschreibbar ist.)

[NAB]

Hast du da einen Link für uns?

Man findet da Anleitungen wie diese hier:
http://de.wikihow.com/Den-Schreibschutz ... aktivieren
in zig Variationen und Sprachen. Außerdem geistern teils undurchsichtige "Tools" herum, die den USB-Stick wieder heil machen sollen:
http://www.fixya.com/support/t259854-tu ... rbatim_4gb
Diese Tools funktionieren teils tatsächlich, je nach Hersteller ... ändern aber nichts daran, dass der USB-Stick sich nach Stunden bis Monaten wieder sperrt, weil er über den nächsten Fehler gestolpert ist.

[KBDCALLS]

Sorry , wie kann man sich eigentlich derartig auf die Hinterbeine stellen und nicht akzeptieren wollen das der Stick Schrott ist, zudem da alle Gebrauchsregeln mißachtet worden sind. Und wenn man dann sowas ließt

hat geschrieben:
Mir ist realativ egal ob man ein Stick abziehen kann oder nicht. Ein Stick ist dafür gedacht einfach abgezogen zu werden. Wenn es zu Problemen führt mache ich es zukünftig eben nicht mehr. Es kann aber nicht sein das ein ganzer Stick gesperrt wird. Das mußwieder rückgänig gemacht werden können und dann wird der Stick eben nicht mehr abgezogen. Es muß aber ein Hinweis erscheinen wer sowas gemacht hat.

Da fällt einem dann nichts mehr weiter zu ein.

[guennid]

Ein Stick ist dafür gedacht, einfach abgezogen zu werden.

So 'ne Aussage halte ich dann für die Konsequenz von ausufernder Automatisiererei, und insofern:

Da fällt einem dann nichts mehr weiter zu ein.

[NAB]

Naja ... wenn man auf einem Atari 800XL gelernt hat ... den konnte man auch einfach ausschalten und die Diskette dann rausnehmen ... die war nachher trotzdem noch beschreibbar. Es wird immer komplizierter mit der modernen Technik!

[logoft]

Wenn man mit der Winblöd Registry den Stick beeinflussen kann

Hast du da einen Link für uns?

https://www.google.de/?gfe_rd=cr&ei=9rA ... te+protect


Nur grob gesucht, es gibt unzählige Einträge.

[logoft]

Das Problem liegt hier — jedenfalls in erster Linie — nicht am Dateisystem. Schon das Blockgerät selbst ist nicht beschreibbar.

… wäre auch meine Vermutung, aber die Bestätigung des Threadstarters in Form einer entsprechenden Fehlermeldung und/oder eines entsprechenden Logeintrages steht noch aus (oder ich hab’s aufgrund der unformatierten Sülze oben übersehen […]). Soweit ich das bislang aufgefasst habe, rödelte der Threadstarter jedenfalls recht uninformiert auf der Partition bei eingehängtem FS rum, und das sagt über den Zustand es Devices ansich so gar nix aus.

Schreib mir was ich machen soll.

[DeletedUserReAsG]

Mit fdisk oder auch cfdisk (hat ein curses-UI) versuchen, die Partitionen auf dem Stick zu löschen und eine Neue anzulegen. Bei beiden Programmen muss man das Schreiben explizit anfordern. Sollte es beim Schreiben einen Fehler geben, die Meldung hier posten.

[logoft]

Sorry , wie kann man sich eigentlich derartig auf die Hinterbeine stellen und nicht akzeptieren wollen das der Stick Schrott ist, zudem da alle Gebrauchsregeln mißachtet worden sind. Und wenn man dann sowas ließt

hat geschrieben:
Mir ist realativ egal ob man ein Stick abziehen kann oder nicht. Ein Stick ist dafür gedacht einfach abgezogen zu werden. Wenn es zu Problemen führt mache ich es zukünftig eben nicht mehr. Es kann aber nicht sein das ein ganzer Stick gesperrt wird. Das mußwieder rückgänig gemacht werden können und dann wird der Stick eben nicht mehr abgezogen. Es muß aber ein Hinweis erscheinen wer sowas gemacht hat.

Da fällt einem dann nichts mehr weiter zu ein.

Weil absolut nichts bewiesen ist. Nur weil etwas nicht funktioniert, heißt das noch lange nicht der Stick ist kaputt. Außerdem will ich nicht ein Stick kaufen und in 3 Tagen,in 3 Jahren ode in 30 Jahren passiert mir das wieder. Entweder ich weiß der Stick ist kaputt oder ich habe ihn kaputt gemacht. Wenn ich ihn kaputt gemacht habe, dann kann ich das beim nächsten Stich verhindern. Wenn der Stick kaputt ist,weil er nicht vom Betriebsystem zerstört wurde, dann kann ich mir gelassen einen 2. kaufen. Wenn er vom Betriebsystem zerstört wurde, fasse ich BSD niemals wieder an. Dann kaufe ich mir ein Mac oder nehme Debian.

USB ist dafür bekannt ein und ausgestöpselt werden zu können. Bisher dachte da geht eine Datei kaputt. Aber das ein Stick read only werden kann, ahnte ich nicht mal. Es gibt Programme die können Blöcke makieren sodaß sie nicht mehr verwendet werden. Waum sollte ich also einen ganzen Stick wegwerfen, wenn vielleicht nur ein einziger Blockkaputt ist? Es geht doch darum zuverlässig den Fehler zu finden,ihn vielleicht zu beseitigen.

Und wer so ein Mist programmiert hat, sollte wenigstens hinschreiben wie sein Programm heißt. So wüßte ich was den Stick blockiert hat.
Es gibt auch Hinweise das eine Datei readonly sein könnte, die den Stick dann blockiert. Eine Datei ist einfach zu finden, Ein Vezeichnis auch. Aber wie geht das bei einem Stick? Wie oder wo liegt ein Dateisystem?? Das weiß ich nicht. Ist das Dateisystem wie ein Bootsektor unsichtbar? Ist das Dateisystemeine Datei? Keine Ahnung.

Mir geht es darum sicher zu sein was kaputt ist, eine Datei oder die Hardware imwinzig kleinen Bereich oder komplett. Und das weiß ich eben nicht. Es soll einen Stick geben mit einem Terra Byte Bereich. Der ist bestimmt sehr teuer. Ein 32 GB Stick kann man getrost wegwerfen, aber weiß trotzdem nicht ob es wieder passieren könnte. Ich will nur wissen ob es BSD war, denn dann ist BSD nicht zu gebrauchen.

root@trag:~# dmesg | tail
[ 1498.714449] UFS-fs error (device sdb4): ufs_readdir: bad page in #2
[ 1498.714484] UFS-fs error (device sdb4): ufs_readdir: bad page in #2
[ 1498.714517] UFS-fs error (device sdb4): ufs_readdir: bad page in #2
[ 1498.714551] UFS-fs error (device sdb4): ufs_readdir: bad page in #2
[ 1498.714586] UFS-fs error (device sdb4): ufs_readdir: bad page in #2
[ 1498.714615] UFS-fs error (device sdb4): ufs_readdir: bad page in #2
[ 1498.714648] UFS-fs error (device sdb4): ufs_readdir: bad page in #2
[ 1498.714688] UFS-fs error (device sdb4): ufs_readdir: bad page in #2
[ 1498.722257] UFS-fs error (device sdb4): ufs_readdir: bad page in #2
[ 1499.002604] UFS-fs error (device sdb4): ufs_readdir: bad page in #2
root@trag:~# clear

[DeletedUserReAsG]

Wie oder wo liegt ein Dateisystem?? Das weiß ich nicht. Ist das Dateisystem wie ein Bootsektor unsichtbar? Ist das Dateisystemeine Datei? Keine Ahnung.

Wie schon (nicht nur von mir) in diesem Thread geschrieben wurde: du solltest so grundlegende Sachen wie „was ist ein Dateisystem“ unbedingt mal nachlesen, wenn du überhaupt mal verstehen willst, was du da machst. Grob gesagt, verwaltet ein Dateisystem deine Dateien auf dem Datenträger. Entsprechend kann es selbst keine Datei sein. Ein brauchbarer Einstieg wäre z.B. https://de.wikipedia.org/wiki/Kategorie:Dateisystem

Auch zum Rest: es gibt kein Programm, das deinen Stick auf ro gesetzt hätte – es gibt einen Controller im Stick, der sich um die Verwaltung des eigentlichen Speichers kümmert. Dieser ist’s auch, der dann sinnvollerweise Schreibzugriffe auf den Speicher verhindert, wenn er keine korrekte Funktion mehr garantieren kann (etwa, weil sämtliche Reserveblöcke aufgebraucht sind). Flash ist nunmal nicht sonderlich haltbar, was Schreibzyklen angeht – insbesondere der Typ, der üblicherweise in Sticks zu finden ist. Häufiges Beschreiben verschleißt jeden Stick, außerdem kann das Abziehen des Sticks während einer Schreiboperation den instant kaputtmachen. Wieso versuchst du eigentlich immer noch, den Fehler wahlweise zu leugnen („muss doch wieder zum Funktionieren zu bringen sein“), oder ihn dem OS anzulasten? Kauf’ dir einen neuen Stick, wenn das oben erläuterte Vorgehen zur Partitionierung keinen Erfolg haben sollte, behandle den anständig und confe auch dein OS so, dass es nicht unnötig drauf rumrödelt – dann besteht eine gute Chance, dass er lange (wenn auch nicht ewig) hält.

[logoft]

Ein Stick ist dafür gedacht, einfach abgezogen zu werden.

So 'ne Aussage halte ich dann für die Konsequenz von ausufernder Automatisiererei, und insofern:

Da fällt einem dann nichts mehr weiter zu ein.

Wenn man merkt es funktioniert nicht so einfach, dann mache ich es eben zukünftig nie mehr. Aber ich weiß nicht ob das der Fehler war.Bei Debian war noch nie sowas passiert, ich konnte Debian ausmachen wie ich wollte.
Was mich damals an Debian störte was die fstab. Ich habe die absichtlich umbenannt/gelöscht und das Systemist mit kernel panic stehengeblieben. Heute gibts Sicheheitskopien vom System. Durch solche Spielchen habe ich erfahren das ein root ein fremdes System übernehmen kann.
Ich habe zum Spaß ein System mal verschlüsselt um zu sehen mit was ich da rechnen müßte.
Ich habe auf ReactOS gewartet. Ich dachte es wäre ein Windows. Aber es hat ein Installer der funktioniert nach Linux-Prinzip. Online wählt man Pakete. Also Windows-Pogramm-Sammlungen nehmen,DVD einlegen,installieren,geht nicht. Es könnte vomKern noch so nah an WinNT sein, für mich ist das wenig interessant.

So teste ich,spiele rum, weil mir das Spaß macht. Linux vebreitet sich nur schwer. UNIX wäre vielleicht besser,und so habe ich mal BSD auf Sticks gemacht und mal reingeschnuppert. Das nun ein Filesystem ro ist,ist eher ein Schock für mich. Und google kennt Leute seit vielen Jahren denen ist das auch passiert

[DeletedUserReAsG]

Was mich damals an Debian störte was die fstab. Ich habe die absichtlich umbenannt/gelöscht und das Systemist mit kernel panic stehengeblieben.

lol! Dich stört, dass ein System kaputt ist, wenn du es kaputtmachst? Ich klaue mal bei eggy:

Soviel Naivität ist echt bewundernswert
<^><

[logoft]

[…] auf der Partition bei eingehängtem FS rum, und das sagt über den Zustand es Devices ansich so gar nix aus.

Das nicht, aber die Datei im sysfs, die er in den mc-Screenshots gepostet hat und die Fehlemeldungen von parted zeigen eindeutig, dass tatsächlich der Stick an sich nicht beschreibbar ist und das Dateisystem allenfalls eine weitere Hürde wäre, die man vermutlich mit fsck leicht beheben könnte, wenn der Stick eben beschreibbar wäre.
(Auch die etwas merkwürdigen Fehlermeldungen von fsck deuten darauf hin, dass das blockgerät selbst nicht beschreibbar ist.)

Und da stellt sich doch die Frage wie ein Gerät gesteuert wird. Im Verzeichnis DEV finden sich alle Geräte. Da hätte ich vermutet das Verzeichnis wäre RO gesetzt. Aber der Stick bootet und ein fremdes System Linux bootet auch und sofort ro. Da liegt die Tatsache nahe andere Programme haben vorher Zugriff auf die Hardware bzw Software. Und so tief betrachtet man sich selten ein System. Ich brauche die Daten nicht. Ich will nur wissen ob ich es beseitigen kann um beim 2. mal Daten retten zukönnen. Und ich will alles versuchen, jede Idee nutzen egalob sie unsinnig erscheint. Ich will den Fehler begreifen können. Was ich nicht glauben kann. BSD soll auch für Server gut sein. Ein Server der sich selbst blockiert wäre völlig unlogisch. Das BSD ein Stick blockiert wäre unlogisch. Ich brauche also ein Programm das den Stick repariert oder den Fehler isoliert. Das wäre für mich am Logischsten. Deshalb glaube ich erst an eine Hilfs-Software und dann erst an den Hardware-Tod.

[DeletedUserReAsG]

Liest du eigentlich auch mal, was geschrieben wird? Für /dev ist udev zuständig, und solange es für den betreffenden Stick keine entsprechende Regel gibt, wird es den nicht eigenmächtig auf ro setzen – das macht, wenn es denn so sein sollte, der Controller auf dem Stick direkt. Und dann ist der Stick auch als defekt zu betrachten.

[logoft]

Mit fdisk oder auch cfdisk (hat ein curses-UI) versuchen, die Partitionen auf dem Stick zu löschen und eine Neue anzulegen. Bei beiden Programmen muss man das Schreiben explizit anfordern. Sollte es beim Schreiben einen Fehler geben, die Meldung hier posten.

root@trag:~# fdisk /dev/sdb
Warning: Unable to open /dev/sdb read-write (Das Dateisystem ist nur lesbar).
/dev/sdb has been opened read-only.
Warning: Unable to open /dev/sdb read-write (Das Dateisystem ist nur lesbar).
/dev/sdb has been opened read-only.
GNU Fdisk 1.2.4
Copyright (C) 1998 - 2006 Free Software Foundation, Inc.
This program is free software, covered by the GNU General Public License.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.

Using /dev/sdb
Command (m for help):

Partition number (1-4): 4
Error: Partition /dev/sdb4 is being used. You must unmount it before you modify
it.
Command (m for help):



Disk /dev/sdb: 32 GB, 32259548160 bytes
255 heads, 63 sectors/track, 3922 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sdb4 * 1 3922 31495432 a6 OpenBSD
Command (m for help): d
Partition number (1-4): 4
Command (m for help): p

Disk /dev/sdb: 32 GB, 32259548160 bytes
255 heads, 63 sectors/track, 3922 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
Command (m for help): w
Information: Don't forget to update /etc/fstab, if necessary.


Writing all changes to /dev/sdb.
Error: Can't write to /dev/sdb, because it is opened read-only.
i Ignore
c Cancel


Using /dev/sdb
Command (m for help): p

Disk /dev/sdb: 32 GB, 32259548160 bytes
255 heads, 63 sectors/track, 3922 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sdb4 * 1 3922 31495432 a6 OpenBSD
Command (m for help):

Ich kann sie löschen, ist dann aber wieder da. Die Partition schreiben geht nicht.