Vraag & Antwoord

OS Linux

SuSe 8.0 met kernel 2.4.19: fouten op vfat (FAT32) partitie

10 antwoorden
  • Hoi, Ik heb een uiterst merkwaardig probleem, namelijk dat kernel 2.4.19 niet goed kan samenwerken met een windows FAT32-partitie. Kort maar goed: mijn hele FAT32-partitie is grondig om zeep geholpen door Linux; zo ernstig zelfs dan de scandisk van windows het probleem ook niet meer kon repareren. De enige oplossing was: kopieren wat er nog te kopieren viel en de partitie opnieuw formatteren (niet mijn favoriete bezigheid). Maar goed, op de nieuw geformatteerde partitie wil ik dus opnieuw vanuit linux schrijven en meteen beginnen de problemen weer: vage foutmeldingen over pogingen voorbij de maximale sector te schrijven en opnieuw de partitie onbruikbaar... Nou wil ik als Linux adapt natuurlijk wel graag weten wat nou toch de oorzaak is van dit vreemde en ongebruikelijke gedrag. Vooral omdat het wel altijd goed heeft gewerkt (tot kernel 2.4.19 dus). Dit probleem treedt op bij de standaard SuSE kernel (versie 8.0) en een kernel die ik zelf heb gecompileerd. In de kernel-Changelogs kan ik niets vinden over wijzigingen m.b.t. de vfat module. Heeft iemand een tip of suggestie of weet iemand van een probleem wat dit merkwaardige gedrag verklaard? Het is SuSE 8.0, dus ik gebruik nog de oude gcc-2.95.x compiler. Iemand? Groet, Philip
  • Ik gebruik ook een 2.4.19 kernel (gentoo-sources), maar geen problemen met lezen en schrijven op fat-partities. Is je hard-disk niet een beetje aan zijn eind? Download een rescue-tool van de fabrikant van de schijf en check de boel daarmee. Ik had problemen onder windows, tool gebruikt en de schijf werkt weer als vanouds. Wat die tools feitelijk doen is alle dat opnieuw schrijven. Blijkbaar verliezen de moderne schijven vrij snel hun magnetisiteit (schijf was toe ruim 3 jaar oud). Overigens heb ik Linux gebruitk om mijn data te redden.
  • Hoi Water, Ik denk niet dat de harde schijf het probleem is, want die zit er nog maar 1 1/2 jaar in. Op dezelfde schijf heb ik Linux geinstalleerd staan, wat wel goed werkt. Windows98 werkt ook goed op de FAT32-partitie, maar ik had het eigenaardige probleem dat fouten op de partitie niet ECHT werden opgelost door scandisk, waardoor de partitie opnieuw gerepareerd moest worden na ieder gebruik van Windows. Dat is natuurlijk niet de bedoeling, vooral omdat mijn vrouw windows vaak gebruikt (en ik ook voor mijn werk). Gisteren heb ik de kast maar eens opengemaakt. Vanwege wat krapte met ruimte/afstanden tussen de 2 harde schijven, was mijn probleemschijf (master) met de slave-connectie van de IDE-kabel verbonden en de slave was met de master-connectie verbonden. Dit mag normaalgesproken geen problemen opleveren, maar onder Linux gaat het dus wel fout (onder windows goed)! Ik heb de connectoren met veel moeite (en ietwat geweld :) ) omgedraaid en nu lijkt Linux redelijk met de FAT32 partitie overweg te kunnen, maar worden de lange bestandnamen weer niet meegenomen bij kopieeracties (van FAT32 naar FAT32 overigens). Ook was de kopieeropdracht niet helemaal vlekkeloos verlopen: ongeldige directory entries en meer van dat soort ongein. Maar dat kan nog een gevolg zijn van problemen met de originele (verminkte) partitie, waarbij de FAT's blijkbaar stevig op hun donder hebben gekregen. Als ik onder DOS de backup terugkopieer, dan zijn de lange bestandnamen wel in orde (vreemd). Al met al lijkt het op een hardwareprobleem dat nu hopelijk is opgelost. Ik hou de boel voorlopig goed in de gaten, want het is een serieus gemis als je niet meer onder Linux op je FAT32-partitie kan schrijven! Het lijkt er trouwens op dat de problemen pas optreden voorbij een bepaalde hoeveelheid opgeslagen gegevens. Tja, als er ergens een fout in de FAT zit, is alles wat daarna komt niet echt betrouwbaar meer, of is er misschien ook nog een andere reden? Groet, Philip
  • Ik heb met dezelfde kernel versie Mandrake9.0 ook problemen gehad . 2 harfde schijven begaven het. (de eerste uiteraard na 1 jaar en wat dagen) maar ligt dit aan Linux? Om met Musolini te spreken: het enige betrouwbare aan een harde schijf is dat ie onbetrouwbaar is (vrij vertaald, ambtenaar in het pre Musolini tijdperk)
  • Wat ik zelf ooit gehad heb is dat ik onder Linux een mappenstructuur heb aangelegd op een fat32-schijf, die voor Windows te diep bleek. Windows-applicaties (scadisk, defrag, virusscanners, etc..) liepen op deze mappenstructuur stuk. En ook de verkenner en trashcan gooiden de handdoek in de ring toen ik onder Windows trachte de betreffende mappenstructuur te verwijderen. Onder llinux was hij overigens zo weer verwijderd. Wat was de oorzaak? Windows kan slechts bestandsnamen incl. pad er naar toe aan van max 265 tekens. De structuur die ik (overigens per ongeluk) vanuit Linux heb aangelegd was echter enkele duizenden mappen diep :o Ander probleem waar windows niet vrolijk van wordt is het gebruik van bepaalde tekens in een bestandsnaam. Als het goed is laat Linux het gebruik hiervan niet toe, maar ik ken Windows-gebruikers die op een of andere wijze toch bestanden met illegale namen op hun schijf wisten te krijgen (met als gevolg dat ze niet te verwijderen waren en scan-applicaties er op stuk liepen....). Is dus mogelijk dat zoiets vanuit Linux ook zou kunnen gebeuren.. Rinse
  • Hoi Rinse, Wat je meldt over rare tekens en te diepe mappen zou best wel eens waar kunnen zijn. Volgens mij zijn de problemen ooit eens begonnen tijdens een kopieeractie vanuit Linux naar Windows. Sterker nog: toen was ik tegelijkertijd bezig met het verwijderen (en kopieren) van bestanden, waarbij ik het probleem had dat de harde schijf vol zat (daarom verwijderde ik eigenlijk het bestand). Toen is alles ook vreselijk in de soep gelopen (beide bestanden verminkt e.d.), maar ik dacht het probleem te hebben opgelost door alle betreffende bestanden simpelweg te deleten. Blijkbaar is er toen een fout in de FAT geslopen die er met geen mogelijkheid meer uit te krijgen was, wat dus uiteindelijk resulteerde in dit onderwerp. Bovenstaande kopieeractie was ik trouwens al weer bijna vergeten :) . Ik heb nu mijn windows machine weer goed aan de praat gekregen, juist met hulp van Linux! Lange bestandnamen kopieren onder DOS 7 is niet bepaald prettig (zeg maar gerust: onmogelijk zonder de juiste tools die DOS zelf natuurlijk niet verschaft), maar met Linux kon ik de backup keurig netjes terugkopieren naar de ondertussen geformatteerde harde schijf. Alleen bij het kopieren van de windows directory ging het fout, maar dat klopt ook wel (fouten waren meegekopieerd). Met het nodige kunst en vliegwerk heb ik mijn systeem weer draaien. Het grappige is dat ik zelfs de windows installatieCD niet hoefde te draaien: lilo startte meteen windows op (en ik kreeg helemaal geen foutmeldingen). Mijn systeem is dus weer terug in de originele staat :) :) :) !!! Wel met de IDE-connectoren nog steeds GOED aangesloten (dus de master op de 1e IDE kabelaansluiting en de slave op de "middelste" IDE connector. Dat handhaaf ik voor de zekerheid maar even. Natuurlijk hou ik de partitie de komende tijd extra goed in de gaten, maar aangezien ik een backup heb, heb ik wel enige ruimte om te experimenteren met kopieeropdrachten vanuit Linux om te kijken of dat nu allemaal weer goed gaat. Horen jullie nog wel een keer. Groetjes, Philip
  • Hoi, Voor de mensen die nog geinteresseerd zijn in hoe het is afgelopen. Ik heb SuSE 8.2 Prof gekocht, de hele harde schijf opnieuw gepartitioneerd en geformatteerd (ik wilde toch al een keer naar ReiserFS overstappen) en nu zijn de problemen opgelost. Het bleek dat windows in de Linux swap-partitie aan het schrijven was... Vandaar mijn hardnekkige problemen onder windows, want windows beschouwde de swap-partitie als onderdeel van zijn eigen FAT32-partitie. Hoe ik dat voor elkaar heb gekregen??? Groet, Philip
  • Ik heb pas wel ergens een howto gezien, hoe je je swap-partitie zowel onder windows als Linux kunt gebruiken. Maar ja, windows doet wel meer rare dingen, alhoewel windows 98 se, Gentoo en Mandrake 9.0 gebroederlijk naast elkaar staan op één schijf. Hierbij wordt de swap gedeeld door Gentoo en Mandrake, alhoewel ik de laatste vrijwel nooit gebruik.
  • Ik vermoed dat je probleem eerder in de addressering van je partties heeft gelegen. kortom hda1 = sect 1-1000 hda2 = sect 980 - 1500 windows gaat zo slecht met partities overweg dat die het wellicht nieteens in de gaten heeft maar linux gaat erop over zijn nek :D Daarom wordt ook aangeraden ALTIJD slechts 1 en de zelfde partitiemanager te gebruiken. (zelf gebruik ik altijd de diskette versie van PQ-magic alleen kent die helaas geen reiserfs maar dan maak ik simpel een fat32 en formatteer die gewoon naar reiserfs.)
  • Hoi wstolk, Ik denk dat je gelijk hebt. Ik heb uiteindelijk de (nieuwe) partities aangemaakt m.b.v. de installatie-DVD van SuSE 8.2. De problemen lijken nu opgelost. Vreemd trouwens dat dit soort rare problemen kunnen ontstaan. Ik dacht namelijk te weten dat wordt aangeraden te partitioneren m.b.v. het partitioneringsprogramma van het desbetreffende besturingssysteem op je computer (dus win98 voor de FAT32 partitie en Linux voor de (toen nog) ext2-partitie). Juist door dat te doen heb ik waarschijnlijk het probleem gecreeerd. Een erg lastig probleem, waarbij het moeilijk is de uiteindelijke oorzaak te achterhalen. Groet, Philip

Beantwoord deze vraag

Weet jij het antwoord op deze vraag? Registreer of meld je aan met je account

Dit is een gearchiveerde pagina. Antwoorden is niet meer mogelijk.