[linux] Erg zieke USB-disk, mogelijkheid voor herstel? (3 antwoorden

[Daniel C. von Asmuth]

Aldus schreef meine op Sat, Mar 30, 2019 at 09:46:06AM +0100:
> goeiemorgen!
> 
> ik heb nog eens op internet en in mijn eigen how-to files gezocht:
> 
> eerste misschien overbodige vraag: heb je de USB drive ge-unmount? dd
> kan niets met gemounte volumes.
> 
> # umount /dev/sdb (ik gebruik root en geen sudo)
> 
> het zou ook kunnen dat `dd' niet door een sudoer gebruikt mag worden of
> dat er in de sudo rechten ergens een regeltje is omgevallen of niet
> gelezen.
> 
> $ sudo su -
> password (root)
> # dd [etc]
> 
> > >> De eerste stap: formattering mislukt met
> > >>
> > >> sudo mkfs.ext4 /dev/sdb
> > >> mke2fs 1.44.1 (24-Mar-2018)
> > >> mkfs.ext4: Device size reported to be zero.  Invalid partition
> > >> specified, or
> > >>     partition table wasn't reread after running fdisk, due to
> > >>     a modified partition being busy and in use.  You may need to
> > >> reboot
> > >>     to re-read your partition table.
> 
> mkfs geeft een boel opties waar het fout kan zijn gegaan. ik ken `mkfs'
> niet, maar zou het kunnen dat je een partitienummer moet opgeven om die
> te formatteren?

De foutmelding zegt genoeg: de schijf kan niet gelezen worden. De Linux
kernel zet de grootte per default op 0 bytes. Dat verklaart meteen
waarom dd bij de eerste byte al zegt 'no space left on device'.

Probeer eens:
cat /proc/partitions
We kunnen voorspellen wat eruit komt.

> /dev/sdb is de hele USB drive;
> 
> /dev/sdb1 is een partitie daarop
> 
> het kan zijn dat mkfs nog een paar schakelopties nodig heeft om goed te
> werken, bijvoorbeeld een naam voor de partitie.
> 
> `$ man mkfs'
> 
> > >> Ook een poging er random iets op te schrijven lukt niet:
> > >>
> > >> sudo dd if=/dev/zero of=/dev/sdb bs=64K
> > >>
> > >> dd: error writing '/dev/sdb': No space left on device
> > >> 1+0 records in
> > >> 0+0 records out
> 
> ik kwam twee mogelijkheden tegen:
> 
> de /dev/zero is om de een of andere reden overschreven als normale file.
> dit schijnt vrij eenvoudig te zijn. controleren en eventueel terugzetten
> is op internet wel beschreven, voor nu zou je ook `/dev/null' kunnen
> gebruiken, maar die geeft waarschijnlijk het zelfde resultaat;
> 
> dd kan bij deze operatie doorgaan met nullen blijven schrijven tot de
> wereld of je computer ophoudt met draaien, 'whatever comes first'. met
> `bs=64K' zou het moeten werken. je zou `bs=1m' nog kunnen proberen.

dd gaat gewoon door totdat de schijf vol is. In dit geval dus na 0
bytes. Normaliter zou die er uren over doen.

> > De disk zit wel achter /dev/sdb: doe ik een "ls /dev/sd* ", dan zie ik
> > /dev/sdb wanneer de usb-kabel in de machine zit, en alleen de partities
> > onder /dev/sda* met de kabel eruit.
> 
> je USB drive wordt maw wel door het systeem gezien, hij kan er alleen
> niet bij. NB als je Hannah Montana Linux gebruikt is het systeem een
> _zij_ ;-)
> 
> weet je nog waar deze schijf vandaan komt, waar je hem eerder voor hebt
> gebruikt? Linux leest bijvoorbeeld niet altijd een UFS of HFS
> geformatteerde drive, maar ziet wel dat er een volume is aangekoppeld.
> 
> > Betreffende de suggestie van Daniel: dan moet ik eerst de disk openmaken
> > en demonteren.  Daar wacht ik nog even mee ...
> 
> omdat je drive wel door het systeem wordt opgemerkt zou ik er inderdaad
> hardwarematig afblijven. je moet een drive wel zo verschrikkelijk lang
> gebruiken of zwaar fysiek mishandelen dat 'ie het niet meer doet. vaak
> denken we dat iets kapot is, maar blijkt dat we een voor de hand liggende
> essentiele stap vergeten zijn of gewoon een typo uit de history
> hergebruiken. bij computers komen de meeste storingen door software...

Het apparaat wordt wel door de PC gezien, maar dat zegt alleen maar dat
de USB-chip in het kastje praat met de USB-chip in de PC. Je zou
hetzelfde resultaat kunnen krijgen door de schijf fysiek uit het kastje
te verwijderen en een leeg kastje aan te sluiten. We praten hier over
Linux, niet Windows 95: dit is echt een hardware probleem. De vraag is
dus of het probleem zit in de USB-chip, de stuurelektronica van de
drive, of de mechanica van de schijf. Ik denk het laatste. 

Te doen: 
- check de kernel log op relevante foutmeldingen. 
- probeer de schijf te ondervragen met 'smartctl'

Harde schijven zijn niet duur. Hopelijk heb je back-ups gemaakt. anders
moet je naar een gespecialiseerd data recovery bedrijf en die zijn duur.

> mijn oude netbook en 16G SD kaartje leken ook helemaal dood tot ik me
> herinnerde dat ik beide ge-encrypt had onder Linux en ik er [dus] niet
> zomaar bij kon -- beveiliging werkte dus. uiterlijk zag het er net zo
> uit als dit geval van @Julien, maar de oplossing lag in een spoor dat ik
> in eerste instantie niet zag...
> 
> in duckduckgo staat een hele waslijst aan vragen over precies dit
> probleem, misschien handig om daar nog eens doorheen te bladeren. ik heb
> gezocht op `unix dd No space left on device' -- zoeken op _unix_ geeft
> me doorgaans betrouwbaarder resultaten dan `Linux' (teveel gemier, te
> weinig oplossingen).
> 
> ik ben wel benieuwd waar het hem nou uiteindelijk in zit!

Zie boven. We hebben zo'n probleem al vaak op deze lijst gezien.


> mooi weekend-klusje ;-)
> 
> //meine
> 
Met vriendelijke groet,



Daniel von Asmuth

-- 
	
		Geeks of a feather cruft together