Disk /dev/xxx doesn't contain a valid partition table

Debian GNU/Linux

Sziasztok!

Történt ugyanis, hogy lenny->squeeze frissítés után elszállt a rendszer winchester. Semmi gond, mentés volt, friss squeeze felment.
A rendszer működik, azonban a volt még a gépben 3 SCSI winchester, amiket azóta nem lát a rendszer.
Pontosabban a tárgyban levő tájékoztatást adja az #fdisk -l kimenete.

Részletesen egy winchesternél:
#fdisk -l

Disk /dev/sdc: 73.5 GB, 73543163904 bytes
64 heads, 32 sectors/track, 70136 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/sdc doesn't contain a valid partition table

Mi a teendő ilyenkor? A lemezeken reiserFS volt, lemezenként egy partíció.
Az új rendszer nem írt a lemezekre, azokat már nem is látta. Mivel nem fontos adatok vannak rajta (filmek, zenék), ezért eddig nem foglalkoztam a kérdéssel. Érdekelne azért, hogy mi lehet a probléma, illetve, hogyan lehet azt kijavítani.

Köszönöm előre is a válaszokat!

Üdv: redman

  • 1662 megtekintés

( redman | 2011. 04. 22., p – 16:32 )

még valami:

ha megpróbálom felmountolni, akkor

# mount /dev/sdc /mnt/sdc
mount: unknown filesystem type 'adaptec_raid_member'

Pedig nem volt raid-be a disk.

http://www.redman.hu

Egy partíció az azt jelenti, hogy a partíció elérése így nézett ki: /dev/sda

vagyis particionalas nelkul hasznaltad az egesz diszket egyetlen filesystemnek.
(big floppy koncepcio)

en is igy szoktam, ezzel semmi baj nincs, de ne mondjuk azt, hogy egyetlen particio volt rajta, mert nem volt rajta egy sem.

( XmIsTeR | 2011. 04. 22., p – 16:33 )

Ha nagyon nem fontosak az adatok, akkor csinálhatsz új partíciós táblát és újraformázhatod.
Ha ennél fontosabbak, akkor valami adatvisszaállító progival nekiállhatsz(lévén nem fizikai sérülés történt).

Ezek az alapvető dolgok, de lehet valakinek van jobb ötlete is :)

------------------
My Open-Source Android "Projects"

( pts | 2011. 04. 22., p – 16:38 )

Az fdisk kimenete arra enged következtetni, hogy a vinyó első 512 bájtja, ami a partíciós táblát is tartalmazza, le lett nullázva. Az adatok még lehet, hogy megvannak valahol odébb a vinyón, csak meg kell találni, hol kezdődnek a fájlrendszerek.

gpart-tal valami hasonlóval keresd meg a partíciókat, generáltasd vele újra a partíciós táblát, majd próbáld meg bemountolni. Vigyázz: a mountolási kísérletek destruktívak is lehetnek, ezért inkább előbb készíts egy másolatot, és a másolat mountolásával próbálkozz.

( egeresz | 2011. 04. 26., k – 09:35 )

Az tortenhetett, hogy a diszkek alaplapi adaptec jellegu raidben voltak. Az a tippem, hogy olyan hw jellegu sw raid ;-) kutyulassal. Te ugy tudtad, hogy nem voltak raidban, ami jelenthette azt, hogy egy diszkes raid0 -ban voltak. Es akkor az alaplapi bigyusz felirta ra a sajat raid0 metaadatat.

Azonban ezek az alaplapi hw jellegu sw raidok (ezek az olcso szutykok) erosen bios es kernel fuggoek. Elofordulhat, hogy a korabbi "1 diszkes raid0" beallitas hirtelen "true jbod" beallitassa valtozott, vagyis a programok most mar a korabbi raid0 metaadat teruletet is latjak. Ennek az az eredmenye, hogy nincs a helyen a filesystem superblockja, elmaszott az egesz, nem lehet mountolni.

Egyszeri megoldaskent csinalhatod azt, hogy dmsetup -pal letrehozol egy masik block devicet, aminek kezdetet nem a block0, hanem valami blockN, es aztmountolod fel. Ha valahogy sikerul kideritened, hogy mi volt a hw jellegu sw raid bizbasz metaadat terulete, akkor meg akar fel is lehet utana mountolni. Az az elonye a dmsetup -pal valo jateknak,. hogy readonly modon is tudszjatszani. Azt hiszem, en csinalnek egy ciklust, ahol N megy 1-tol parezerig, es minig megprobalnam femountolni. Gyorsabb, mint a google.