[ Megoldva ] Pendrive dd után halott

Merevlemezek, vezérlők

Egy 2GB-os CD képmást dd-ztem ki egy 8GB-os pendrive-ra. Azóta nem tudom érdemben használni. Próbáltam már a /dev/zero-ból 8GB-nyit dd-vel ráírni, de még így is csak 3GB-osnak látja, és vannak rajta olyan partíciók, amiket a gparted sem lát, törölni sem tudom.

Bár azt sem értem, ez hogyan történhet meg, de valahogyan inicializálni kellene, hogy újra használhassam.

Ötletek? Valamiféle program, ami mindent tényleg letöröl? Találkoztatok már ilyennel?

  • 557 megtekintés

( Atekka | 2020. 01. 22., sze – 10:53 )

Ha linux alatt vagy és nem kell semmi róla akkor egy "mkfs.ext4 /dev/"akármi"" nem hozza helyre?

Akkor ahogy lentebb is írták ha fdisk látja akkor fdisk /dev/sdc ( ha még mindig ezzel a bötűvel jelöli,arról bizonyosd meg) , asszem aztán m mint multiple options, d delete partition, mindet ami van és n-el hozz létre egy ujat ami az egész drive területét lefogja, w write  hogy kiirja az uj táblát és quit ,elvileg ennyi.

( peterson v | 2020. 01. 22., sze – 10:58 )

fdisk látja?

"A megoldásra kell koncentrálni nem a problémára."

Az fdisk, cfdisk és gparted is csak 3GB-osnak látja most épp.

Ajánlották, hogy az első 32KB-ot nullázzam, a /dev/zero-ból dd-vel, de utána csak 32KB-osnak látta.

Most elvileg partíció nincs rajta, de az eszköz mérete nem a valós méret.

Azért nagyon fura, mert azt hittem, hogy a /dev/sdc-be írva folyamatosan, felül kell íródnia minden bájtnak... aztán mégsem.

# fdisk -l /dev/sdc
Disk /dev/sdc: 3,8 GiB, 4109627392 bytes, 8026616 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xd66c6b74      

Nem tudom, eredetileg milyen volt az image. Szerintem MBR, de simán lehet, hogy nem, és ez is baj.

A dd-s parancsok effélék voltak:
dd if=disk.img of=/dev/sdc bs=4M
dd if=/dev/zero of=/dev/sdc bs=32k count=1
dd if=/dev/zero of=/dev/sdc bs=1G count=8

( plt | 2020. 01. 22., sze – 12:47 )

Annyi fejlemény van, hogy a gnome-disks látja a teljes 8G eszközt, és lát rajta 4 partíciót, ebből 2 freebsd partíció. De ezeket már törölni nem tudja, így nem tudom visszaállítani a teljes területet szabaddá. :(

Tudom, nem elegáns Windows-ból megoldani, de ha van egy Windows vhol, cmd-ből

diskpart

list disk

select disk # (ahol a # az usb kulcs száma)

clean

vagy linux alól írj rá 8 GB-ot a /dev/null-ból, dd-vel!

( •̀ᴗ•́)╭∩╮

"speciel a blockchain igenis hogy jó megoldás, ezért nagy erőkkel keressük hozzá a problémát"
"A picsat, az internet a porno es a macskas kepek tarolorandszere! : HJ"

Az élet ott kezdődik, amikor rájössz, hogy szart sem kell bizonyítanod senkinek

Ha meg akarod nevettetni Istent, készíts tervet!

( lcsaszar v | 2020. 01. 22., sze – 13:05 )

Meg lehetne próbálni win32 disk image-errel felírni valami nagy img-t.

( taarzaan | 2020. 01. 22., sze – 15:13 )

Szerkesztve: 2020. 01. 22., sze – 15:17

...es mindenek elott:

umount /dev/device*

en raeresztenek egy badblocks-ot elso korben (torol mindent is 4x):

badblocks -wsv /dev/device

Ha rendben lefutott, utana ujrainditanam a gepet, hogy a particios tablak frissuljenek.

Ez utan probalkoznek gparted-del vagy hasonloval.

...en is kivancsi lennek egy pontos "fdisk -l" es "lsblk" kimenetre :) ez a 3GB gyanus...

Köszönöm, megoldotta! Isten vagy!

A badblocks után a gparted még a régi állapotot mutatta, de az újraindítás csodákat tett! Onnantól a gparted is látta az összes partíciót, és le is tudtam törölni. Minden helyreállt.

Lehet, hogy csak a particiós táblák elkeselése miatt nem ment előtte?

No, mire ideértem, megoldottátok :) Majdnem biztos, hogy az MBR borult meg, én hasonló esetben 2 Mb-t szoktam felülvágni az elején dd-vel - mert az még időben nem sok, de biztosan túl van az mbr-en meg az esetleges partíció elején, majd ezután sync, eszköz ki-be, és az fdisk vagy a parted innentől megoldja a többit. Végülis a badblocks is hasonlóan felülírja, csak az az egész disket, meg legalább kiderül, hogy nem haldoklik-e az eszköz.

Ez sem kizárt, de sync meg eszköz ki-be után azért reboot nélkül is kellene frissülnie. Illetve ha jól emlékszem pl gparteddel lehet triggerelni is ezt. Réges régen volt valami olyan gebasz nálam is, ami csak reboot után oldódott meg, az akkor vmi kernel bug volt, de ennek már 10+ éve, ilyesmi most nem kéne, hogy előforduljon.

Azért ne köszönd neki túlságosan. Nem azért, mert ne érdemelné meg, hanem nincs semmi megoldva. Valószínű halódik az a pendrive, most még helyretetted, de innentől fogva rábízni nem nagyon lehet semmit, bármikor elkezdhet újra szórakozni. Cseréld le, gyorsan elhasználódnak ezek, nem egy nagy pénz másikat venni, már a 16-32 gigások is rettenet olcsók, meg én egy ideje piszok olcsó vagy használt 60-240 gigás SSD-ket használok USB3-SATA3 adapterkábellel pendrive-nak, sokkal gyorsabbak és tartósabbak.

Egyébként meg de, lehet nem is a badblocks hozott javulást, hanem az újraindítás. Bár ezt biztosra így utólag nem tudjuk meg. A badblocks talált hibás szektorokat?

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( Addam2 | 2020. 01. 23., cs – 18:31 )

Etcher szokott hasonlókat produkálni nálam, de a "sudo dd if=/dev/zero of=/dev/sdc bs=2048 count=32 && sync" parancs megoldja.