Schreiben auf FAT32 Partition macht Daten kaputt

[whop_go]

Hallo

Ich habe Debian testing und WinXP pro installiert. Am Ende der Festplatte habe ich eine FAT32-Partition, die ich für Daten vorgesehen habe, die ich von beiden Systemen brauche. Unter Windows habe ich damit keine Probleme, unter Linux allerdings schon. Ich verstehe nicht extrem viel davon, die Probleme, die ich habe, finde ich aber schon ziemlich seltsam...

Erstmal die Ausgangs-Situation: Die Partition ist als /mnt/daten gemountet, und zwar sieht das in /etc/fstab so aus (wurde bei der Installation automatisch gemacht):

Code: Alles auswählen

/dev/hda6       /mnt/daten      vfat    defaults        0       2

Demnach kann ich nur als root darauf zugreifen, das ist aber erstmal egal.

Das Problem ist, dass ich Dateien, die unter Windows erstellt wurden, wunderbar bearbeiten kann und auch neue Dateien anlegen kann. Wenn ich dann allerdings wieder mit Windows boote, kann ich die neu angelegten Dateien gar nicht sehen, und die bearbeiteten Dateien scheinen entweder defekt zu sein oder haben immer noch den alten Inhalt! (Wann welcher Fall eintritt, habe ich noch nicht genau herausgefunden). Den Filedefekt spezifiziert Windows spezifiziert jedoch nicht weiter, sagt nur, die Datei habe keinen Inhalt und ich solle doch checkdisk laufen lassen, was allerdings nur sagt, dass alles in Ordnung sei.

Wenn ich dann wieder Linux boote kommt fsck und bringt Fehlermeldungen, die neu angelegten Dateien werden dann gelöscht, dafür hat es ein paar fsck0001.rep Dateien. Die schon existierenden scheinen noch i.O. zu sein, jedoch konnte ich deren Inhalt unter Windows nicht sehen.

Hier habe ich zum Beispiel noch ein weiteres seltsames Verhalten:

Code: Alles auswählen

/# fsck /mnt/daten
fsck 1.35 (28-Feb-2004)
dosfsck 2.10, 22 Sep 2003, FAT32, LFN
/dev/hda6: 14723 files, 448127/1563386 clusters

/# cd /mnt/daten
/mnt/daten# mkdir linux_test
/mnt/daten# cd /

/# fsck /mnt/daten
fsck 1.35 (28-Feb-2004)
dosfsck 2.10, 22 Sep 2003, FAT32, LFN
Reclaimed 1 unused cluster (8192 bytes).
Free cluster summary wrong (1115258 vs. really 1115259)
1) Correct
2) Don't correct
? 1
Leaving file system unchanged.
/dev/hda6: 14724 files, 448127/1563386 clusters

Offensichtlich schlägt das Anlegen oder Ändern von Dateien auf FAT32 fehl! Was läuft hier falsch? Wie kann ich das reparieren? Viele Leute haben doch FAT32 in Linux eingebunden! Aber wenn die Dateien nachher kaputt sind, geht das natürlich nicht...

Ich weiss nicht genau, was für Angaben vom System euch in der Frage weiterhelfen könnten, ich versuchs mal mit ein paar:

/# lsmod | grep vfat
vfat 13184 1
fat 41792 1 vfat
/# uname -a
Linux 2.6.8-1-386 #1 Thu Nov 25 04:24:08 UTC 2004 i686 GNU/Linux
(Gleiche Probleme übrigens mit 2.4 Kernel)
/# mount
...
/dev/hda6 on /mnt/daten type vfat (rw)
...

Sonst noch was? Ich weiss wirklich nicht weiter.

Danke für jegliche hilfreiche Tipps!
Michael

[Joghurt]

was ist die Ausgabe von hdparm /dev/hda? Hast du irgendwelche Festplattenparameter getunt?

[whop_go]

was ist die Ausgabe von hdparm /dev/hda? Hast du irgendwelche Festplattenparameter getunt?

Ich habe nichts an den Festplatten eingestellt, jedenfalls nicht wissentlich. Die Installation ist brandneu. Ich habe eine aktuelle testing-netinst-CD heruntergeladen, damit ein Debian mit Kernel 2.4.irgendwas installiert, und dann mittels apt auf kernel-image-2.6.8-1-386 upgedatet.

Code: Alles auswählen

/# hdparm /dev/hda

/dev/hda:
 multcount    =  0 (off)
 IO_support   =  0 (default 16-bit)
 unmaskirq    =  0 (off)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 readahead    = 256 (on)
 geometry     = 65535/16/63, sectors = 37121157632, start = 0

Es ist übrigens eine Laptop-Festplatte (IBM Thinkpad X31).

[Joke Cookie]

Hat jemand ebenfalls eine FAT32 Partition in Linux zum Schreiben eingebunden und könnte mal seine /etc/fstab posten?

[KBDCALLS]

Hat jemand ebenfalls eine FAT32 Partition in Linux zum Schreiben eingebunden und könnte mal seine /etc/fstab posten?

Das zwar nicht , ist aber eigentlich kein problem.

Code: Alles auswählen

/dev/sdb1       /media/sdb1     vfat    rw,user,noauto  0       0

[Baer]

Hallo whop_go
ich bekomme von

Code: Alles auswählen

lsmod |grep fat
vfat                   14656  6 
fat                    46784  2 vfat,msdos

und lade die module
/kernel/fs/fat/ vfat und msdos
Ich finde das ganze ein bischen verwirrend, weil nicht so ganz klar wird was da fat 16, fat 32 und vfat ist.

meine fstab zum thema sieht wie volgt aus:

Code: Alles auswählen

/dev/hda5       /home/baer/c:         vfat    rw,gid=1000,umask=002       0       2 

und ergibt volgende rechte

Code: Alles auswählen

drwxrwxr-x   2 root baer   32768 2004-10-05 15:15 eMule Temp

gruss Urs

[Mr.Floppy]

ich push den thread mal, weil ich exakt dasselbe problem habe.

ich glaube auch nicht, dass es am kernel, oder den fstab-einträgen liegt, ich denke vielmehr, dass es (jedenfalls auch) mit der (notebook-)festplatte zusammenhängt, die möglicherweise mit irgendeinem hdparm-flag überfordert ist, denn ich habe mit selbigen einstellungen auf meinem desktop-pc keine probleme.

weiss jemand vielleicht noch einen rat oder hat dasselbe problem?

[KBDCALLS]

Aber falls du meinst es liegt am DMA dann schalte den doch mal aus.

Mit nur hdparm /dev/hdx kannste erstmal sehen ob der eingeschaltet ist.

mit hdparm -d 0 /dev/hdx läßt der die sich auschalten.

Und mit hdparm -i /dev/hdx bekommste eine etwas ausführlichere Übersicht und kannst auch sehen welcher DMA Mode denn aktiv ist
ist mit nem * markiert. -I Ergibt noch mehr Infos.

Code: Alles auswählen

biljana:/home/matthias# hdparm -i /dev/hdd

/dev/hdd:

 Model=SAMSUNG SP1604N, FwRev=TM100-24, SerialNo=0651J1FWA09515
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=34902, SectSize=554, ECCbytes=4
 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
 CurCHS=4047/16/255, CurSects=16511760, LBA=yes, LBAsects=268435455
 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: (null):

 * signifies the current active mode

biljana:/home/matthias#      

[Mr.Floppy]

Hi,

ja also wie es scheint habe ich das Problem gelöst - vielleicht muss ich aber auch nur noch etwas warten, bis wieder fehlerhafte daten gefunden werden und das problem war doch nicht so reproduzierbar, wie ich annahm.

Jedenfalls hab ich es jetzt geschafft unter Linux was auf die FAT32-Parition zu schreiben (neues verzeichnis erstellt und n paar daten reinkopiert) und sie waren dann unter windows fehlerfrei vorhanden. Vorher waren neu erstellte verzeichnisse gar nicht erst vorhanden, daten waren verstückelt...

Nunja, was ich gemacht habe?
Die fstab geändert (natürlich^^)

habe "sync" hinzugefügt, das sieht nun folgendermaßen aus ->

Code: Alles auswählen

/dev/hda1       /media/system   vfat    auto,sync,users,exec,rw,gid=uid=1000,iocharset=iso8859-15,umask=000        0       0

ganz verstehen tue ich es dennoch nicht, da früher alles auch ohne diesen eintrag funktioniert hat, aber scheinbar war es dann ja ein problem beim unmounten, dass noch nicht alle daten geschrieben waren oder dergleich?
(kannt das mit dem sync bisher nur bei usb-sticks.)

ka, jedenfalls bin ich erleichtert, dass keine hardware kaputt ist etc.

mit hdparm hab ich natürlich auch vorher nichts eingestellt gehabt, udma2 war eingestellt (is ja auch ne notebook-hd)....

nunja, sollten fehler auftreten, werde ich den thread einfach wieder pushen - würde mich dennoch sehr freuen, wenn vielleicht jemand eine (bessere als von mir gelieferte) erklärung für dieses phänomen wüsste...

trotzdem vielen dank!

[KBDCALLS]

Möglich das noch Daten im Cache waren, und das deshalb die Daten kaputt waren.

[pdreker]

Es kann auch passieren, dass das FAT FS einfach inkonsistent ist, und ganz dringend 'mal einen Scandisk Durchlauf unter Win gebrauchen koennte. Es kann naemlich sein, dass das FS aus irgendeinem Grund inkonsistent geworden ist (unsauberer Shutdown z.B.) und der Linux VFAT Treiber das nicht erkannt hat. Wenn er dann in die korrupten Directory Daten schreibt, produziert das natuerlich noch mehr Unfug...

Patrick

[Mr.Floppy]

Daten im Cache? In welchem Cache denn? Wenn dem so ist, müsste das ja auch immer der Fall sein, weil es ja eigentlich auch immer Fehler gegeben hat.


Dass die Partition inkonsistent ist, kann ich auch ausschließen, hab immer Scandisk laufen lassen und es wurden dann immer nur die Daten geschrottet, die unter Linux geschrieben wurden.

Habe ich nur windows benutzt, kam es nie zu problemen und auch scandisk hatte dann ni ewas gefunden...

Das kanns also auch nicht sein... finde das wirklich sehr, sehr merkwürdig...

Ich würde ja theoretisch in die Richtung tippen, dass es an einem neuen Kernel lag, der ja von mir auch immer wieder neu geupdatet wurde (aber nur die images), aber das kann man ja auch ausschließen, weil ja jemand geschrieben hatte, dass es sogar mit nem 2.4er kernel auftritt.

Schliesslich hatte es ja früher bei mir auch alles ohne den sync-eintrag funktioniert...

[CC2000]

hast du schon probiert, die Platte vor dem check mal unzumounten ?

[sth_]

Ein prinzipielles Problem ist es jedenfalls nicht. Habe hier seit Jahren auf meinen Arbeitsrechnern FAT32-Daten-Partitionen im Einsatz (zum Beispiel auch auf dem Notebook, auf dem ich das hier gerade schreibe). Der Linux FAT-Treiber scheint sogar recht robust und sicher zu sein, da ich trotz mehrerer Hard-Freezes (ATI sei dank) noch nie eine Korruption auf einer FAT-Partition gehabt habe.

Am wahrscheinlichsten halte ich:
- Schon vorher existierende Korruption im Dateisystem (mal windoze-scandisk drüberlaufen lassen wenn fsck nichts findet)
- Fsck auf gemountetem Dateisystem laufen gelassen (vorher unmounten)
- Hardware-Problem mit der Festplatte
- Kompatibilitätsproblem mit dem Mainboard/Chipsatz (Notebooks sind immer so 'ne Sache)

Poste mal die Ausgabe von

Code: Alles auswählen

dmesg | tail -n 15

nachdem du eine Korruption festgestellt hast.

[Mr.Floppy]

Ja, an meinem Desktop hatte ich auch noch nie Probleme mit FAT32 und auch hier am Notebook erst seit kurzem. Aufgefallen ist es mir dadurch, dass die auf FAT32 gelagerten Thunderbird-Emails immer kaputt waren. Es hat vorher mind. 3Monate lang keine Probleme gegeben.

Das Filesystem ist ansonsten relativ sicher nicht korrupt. Das einzige, was beschädigt wird, sind immer nur die unter Linux geschriebenen Daten.
Die Annahme, dass es durch den sync-Eintrag gegessen ist, hat sich leider auch nicht ganz bewahreitet, auch wenn es jetzt viel seltener ist.
Ist es normal, dass durch den sync-Eintrag die Festplatte recht langsam wird?
hdparm -t /dev/hda1 (hda1 ist die FAT32-Partition) gibt zwar noch über 20MB/s, aber beim Kopieren auf die FAT32-Partition bekomm ich nun auch nicht mehr als 4MB/s hin.

fsck hab ich auch ziemlich sicher nicht auf gemounteter partition ausgeführt. Eigentlich hab ich an diesem Notebook noch niemals fsck augeführt (jdenfalls nichts damit geändert), hab besagte Fehler immer mit scandisk behoben.

Hardware-Problem... hmm, naja... weiss nich, unter Win hab ich nie Probleme.

Und kompatibilitätsprobleme fänd ich auch komishc, weil es ja über 1/4 jahr tadellos funktioniert hat.

Es ist so ärgerlich, dass das alles nicht so leicht reproduzierbar ist, sonst würd könnte ich wahrscheinlich mehr Hinweise geben...

Nunja, beim (un)mounten scheint alles in Ordnung zu gehen, und hier ist die dmesq-ausgabe:

Code: Alles auswählen

dmesg | tail -n 15
Disabled Privacy Extensions on device c0322340(lo)
eth0: Promiscuous mode enabled.
eth0: Promiscuous mode enabled.
IPv6 over IPv4 tunneling driver
eth0: no IPv6 routers present
wlan0: no IPv6 routers present
apm: BIOS not found.
ACPI: PCI interrupt 0000:00:02.0[A] -> GSI 10 (level, low) -> IRQ 10
mtrr: 0xb0000000,0x8000000 overlaps existing 0xb0000000,0x100000
[drm] Initialized i915 1.1.0 20040405 on minor 0: Intel Corp. 82852/855GM Integrated Graphics Device
PCI: Enabling device 0000:00:02.1 (0000 -> 0002)
mtrr: 0xb0000000,0x8000000 overlaps existing 0xb0000000,0x100000
[drm] Initialized i915 1.1.0 20040405 on minor 1: Intel Corp. 82852/855GM Integrated Graphics Device (#2)
mtrr: base(0xb0020000) is not aligned on a size(0x300000) boundary
unable to register OSS mixer device 0:0

sagt uns das was?

hier nochmal hdparm -i /dev/hda1:

Code: Alles auswählen

hdparm -i /dev/hda

/dev/hda:

 Model=IC25N060ATMR04-0, FwRev=MO3OAD4A, SerialNo=MRG309K3HV6TUK
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=DualPortCache, BuffSize=7884kB, MaxMultSect=16, MultSect=off
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=117210240
 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 *udma2 udma3 udma4 udma5
 AdvancedPM=yes: mode=0x80 (128) WriteCache=enabled
 Drive conforms to: ATA/ATAPI-6 T13 1410D revision 3a:

 * signifies the current active mode

Noch Hinweise, was ich noch testen könnte??

[sth_]

Also der sync-Eintrag bewirkt nur, dass jegliche Zwischenspeicher deaktiviert werden, d.h. alle Daten werden so wie sie kommen ohne Verzug auf die Festplatte geschrieben. Das kostet natürlich extrem Performance. hdparm ist da kein guter Test, da das nur einen kontinuierlichen Datenstrom liest, was in der Praxis aber kaum vorkommt.

Ich schätze mal, dass du einen Intel-Chipsatz hast (da auch Intel Grafikeinheit). Ist das Modul "piix" geladen? (modprobe piix)

[Mr.Floppy]

ja, ist ein Centrino-Notebook, also auch Intel-Chipsatz.
lsmod ->

Code: Alles auswählen

lsmod
Module                  Size  Used by
isofs                  37208  0
ide_cd                 42592  0
cdrom                  40956  1 ide_cd
snd_mixer_oss          20192  0
i915                   82820  3
ipv6                  264096  8
af_packet              22504  2
ds                     18628  2
binfmt_misc            11656  1
thermal                13000  0
fan                     3812  0
button                  6448  0
processor              17256  1 thermal
ac                      4644  0
battery                 9188  0
deflate                 3648  0
zlib_deflate           22584  1 deflate
twofish                38560  0
serpent                13504  0
aes_i586               39060  0
blowfish               10112  0
des                    11584  0
sha256                  9536  0
sha1                    8832  0
crypto_null             2176  0
xfrm_user              16676  0
ipcomp                  8296  0
esp4                    8448  0
ah4                     6816  0
af_key                 34096  0
yenta_socket           21664  0
pcmcia_core            70484  2 ds,yenta_socket
eth1394                22024  0
ipw2200               132812  0
ieee80211              36452  1 ipw2200
ieee80211_crypt         5928  1 ieee80211
ohci1394               35396  0
ieee1394              114456  2 eth1394,ohci1394
snd_intel8x0m          18696  0
snd_intel8x0           35276  0
snd_ac97_codec         73200  2 snd_intel8x0m,snd_intel8x0
snd_pcm                98696  2 snd_intel8x0m,snd_intel8x0
snd_timer              25668  1 snd_pcm
snd_page_alloc          9992  3 snd_intel8x0m,snd_intel8x0,snd_pcm
gameport                4512  1 snd_intel8x0
snd_mpu401_uart         7872  1 snd_intel8x0
snd_rawmidi            24900  1 snd_mpu401_uart
snd_seq_device          7976  1 snd_rawmidi
snd                    56804  9 snd_mixer_oss,snd_intel8x0m,snd_intel8x0,snd_ac97_codec,snd_pcm,snd_timer,snd_mpu401_uart,snd_rawmidi,snd_seq_device
i810_audio             37780  1
ac97_codec             18764  1 i810_audio
soundcore              10176  3 snd,i810_audio
shpchp                101924  0
pciehp                 98916  0
pci_hotplug            34448  2 shpchp,pciehp
ehci_hcd               32068  0
uhci_hcd               32944  0
intel_agp              22592  1
irtty_sir               9024  0
sir_dev                19116  1 irtty_sir
irda                  197184  2 irtty_sir,sir_dev
crc_ccitt               1920  1 irda
parport_pc             37188  0
parport                41704  1 parport_pc
pcspkr                  3464  0
nls_iso8859_15          4480  1
nls_cp437               5568  1
vfat                   14528  1
fat                    46624  1 vfat
tsdev                   7648  0
mousedev               11576  2
evdev                   9504  0
dm_mod                 60284  0
capability              4392  0
commoncap               7008  1 capability
reiserfs              248976  0
ntfs                  104144  0
psmouse                21960  0
8139cp                 20768  0
8139too                26240  0
mii                     4928  2 8139cp,8139too
usb_storage            69504  0
usbcore               119396  5 ehci_hcd,uhci_hcd,usb_storage
scsi_mod              125676  1 usb_storage
firmware_class         10112  1 ipw2200
agpgart                34600  4 intel_agp
crc32                   4192  2 8139cp,8139too
rtc                    12664  0
ext3                  126184  2
jbd                    64056  1 ext3
mbcache                 9220  1 ext3
ide_generic             1280  0
piix                   13216  1
ide_disk               20480  5
ide_core              143024  5 ide_cd,usb_storage,ide_generic,piix,ide_disk
unix                   28564  334
fbcon                  40416  71
font                    8128  1 fbcon
vesafb                  6656  1
cfbcopyarea             3936  1 vesafb
cfbimgblt               2880  1 vesafb
cfbfillrect             3584  1 vesafb

sind vielleicht ein wenig viele module? Beißen sich da vielleicht ein paar miteinander?

Also an dem sync-Eintrag kann es nicht liegen, dass es mir vorkommt, dass es nun seltener passiert? Dann kann ich den also wieder raushauen??

[sth_]

Hmmm... das ist auf jeden Fall sehr mysteriös. Das mit den Modulen ist normal so und i.d.R. beißt sich da nix.

Ich würde mal pauschal sagen: Probier' doch mal den aktuellen Kernel 2.6.10 aus sid.

[Mr.Floppy]

hm, am kernel lags auch nicht, hatte das problem schon mit 2.6.8, hatte dann auf 2.6.9 geupdated und jetzt mit 2.6.10 isses dasselbe...

der threadersteller hatte ja sogar geschrieben, dass es mit 2.4 dasselbe wäre

sonst noch irgendjemand ideen?

[fobos]

Hi

Ich habe das selbe FAT32(vfat) problem, und ich weis auch nicht mehr weiter.

Ich habe hier 2 PC ein P1 133 (übertaktet auf 166, 32MB edo 1.2GB seagate HD) und ein 1.5+ Athlon XP (256MB matsonic via motherboard, maxtor ATA 133 7200 80GB und ein langsamer 40GB maxtor)

Auf beide rechner ist der alle neuste Debian Sarge instaliert. Die kleine leuft mit den 2.4.27 kernel der grosse seit gester mit den 2.6.8 (vorher 2.4.27),DMA ist standarmässig aus (die kernels sind aus officielle quelle, nicht selber kompiliert), nichts getunet.

Hauptsächlich grössere files werden bei kopieren, bewegen verschrottet. Also wenn ich 100MB in eine stück kopieren will z.B. ein iso ist nach ein md5 check mindesten 20-40 fehler drin wenn ich 100MB in kleinen files kopiere werden sie höchst warscheinlich garnicht betroffen, oder nur sehr selten.

Was mir aber merkwördig erscheint ist das folgende:
wenn ich z.B. den netinstall iso von linux auf linux (vfat) über samba kopiere wird die datei "natürlich" immer defekt, aber wenn ich den netinstall iso von linux auf win mit vfat kopiere bleibt die datei in ortnung. Und ich frag mich wieso, Ich mounte bei mal den share von linux aus und das kopierungs vorgang löse ich auch von da aus.

Ich habe in den lezten beiden tage viele tests gemacht mit gemischten ergebnissen, und ich kann den problem immer noch nicht wörklich begrenzen.
Ich habe auch ein alte kanotix life CD in den test eingezogen, wo man den dma unterstützung bei booten einschalten kann, die datei bleibt da in ortnung so fern ich den datei auf den selbe plate bewege so weit ich es über hda von hdc bewege oder umgekehrt wird es kaput.

Na ja die sache ist sehr ärgerlich.

[sth_]

via motherboard

Das Ding hat nicht zufällig eine der verbuggten 686B-Southbridges? Falls doch: BIOS-Update!

Näheres dazu findet sich bei Google: http://www.google.de/search?hl=de&q=686B

[Mr.Floppy]

also selbst an meinem desktop MIT verbuggtem VIA686-chipsatz funktioniert das einwandfrei nur eben nicht an meinem notebook.

ich bin kurz vor einer neuinstallation (glaube ich...). hat ja alles irgendwie keinen sinn... das is sicherlich irgendeine ganz banale sache, auf die man aber nicht kommt...

ich versuch das auch mal mit knoppix vonner live-cd, ob es da fehler beim kopieren gibt...

[fobos]

@sth_: Als ich das mit den bug gelesen habe hatte ich fasst ein herzinfakt bekommen. Allerdings erklärt das so einiges.

Was ich darauf hin getan habe:
1. den bios update von der matsonic seite gezogen und mein bios geflasht... keine verbesserung
2. Soundblaster sound karte rausgenomen... es sah kurz so aus als wäre die sache erledigt aber dann doch nicht.
3. Alle PCI katen entfernt (nur noch meine NV GF2 64MB MX400 war noch drinne auser den HD-s)... ich habe bislang nur 1 test gemacht und zwischen den HD-s kann ich immernoch nicht kopieren.

Ich weis nicht genau was ich jezt machen sollte, wenn der bug der schuldige ist und es sieht ganz so aus... gipt es eine patch oder sowas unter linux was den problem beheben oder veringern kann? Oder soll ich ein neue board kaufen?!? Warscheinlich schon aber bis ich den geld zusamenhabe muss ich noch mit diesem auskommen.

Wäre froh über ratschläge.

cu

Fobos

[sth_]

Also ich bin selbst 686B-Bug-Geschädigter. Auf meinem Abit KT133A war die Sache aber nach einem BIOS-Update weitestgehend erledigt. Der Kernel hat soweit ich mich erinnern kann auch einen Patch gegen den 686B-Bug eingebaut. Ich hatte jedenfalls die letzten 3 1/2 Jahre absolut keinen Ärger mit dem Board.

Wenn es wirklich das Mainboard ist, dann müsste der Fehler auch beim Kopieren von Linux-Partition zu Linux-Partition auftreten. Mir hatte es jedenfalls damals, als ich das Board gerade neu hatte (vor dem BIOS-Update und bevor der Bug wirklich bekannt war) regelmäßig die Partitionen zerschossen, egal ob ext2, reiser oder fat. Wenn der Rechner also die letzten Jahre schon problemlos unter Linux lief, dann würde ich eher nicht auf das Mainboard als Fehlerquelle tippen.

Anstatt das Mainboard auszutauschen würde ich erstmal testen:
- Knoppix-CD
- Neuinstallation
- IDE-Kabel tauschen

[fobos]

Wenn es wirklich das Mainboard ist, dann müsste der Fehler auch beim Kopieren von Linux-Partition zu Linux-Partition auftreten.

Die fehler trit hauptsächlich dann auf wenn ich grosse files bewege (z.B. netinstall, knoppix CD,) und die lagere ich auf fat32 weil ich die meisst sharen will. Und nur in den matsonic rechner habe ich HDs mit Fat32 partitionen. Files beschädigen sich übrigens auch auf linux partitionen nur halt viel, viel seltener, und da ich da nur kleine files lagere..., wer kann es schon sagen wieso ein jpg oder ein 50kb tar schrot wird.

Wenn der Rechner also die letzten Jahre schon problemlos unter Linux lief, dann würde ich eher nicht auf das Mainboard als Fehlerquelle tippen.

Ich habe diese board seit 2002 und fehlern wie hard freeze, datenverlusst , beschädigung waren seit her stendig altägliche sache. Ich habe mich daran gewönt, deshalb mache ich von alles doppelt und mehrfach kopien. Aber ich hatte immer meine unkentniss, linux, ram , hd, graka, tv karte, treiber am verdacht.

Ich bin immernoch nicht ganz sicher ob wörklich der bug daran schuld ist das ich datenverlusst, beschädigung habe aber, ich habe von diesen bug zuerst heute gehört und es wörde so einiges erklären.
In vielen artikeln die ich jezt gelesen habe schreibt man das datenverlusst bei grosse beanschpruchung, und bei kopieren von eine hd auf ein andere auftrit. Und da hauptsächlich meine grosse files kaput gehen liegt der verdacht nah.