Elveszett partíciós tábla visszaállítása - multiboot és LVM nehezítéssel

Fórumok

Gondoltam, lecserélem a legújabb Mint-re a (Linux Mint 17-es) rendszerem, és nagy bátran belefogtam egy telepítésbe. Hogy miért? Mert a sok csomagtelepítgetés és -leszedegetés közepette igen elromlott az X-em.
Sajnos a partícionálás lépésnél a megfelelő változatot keresve nyomtam egy "visszaállítást" a "mégse" helyett. Ezzel elveszett az eredeti tábla és a Grub betöltő sem indul.

Ez egy 250GB-os SSD. Nagyjából igaz, amit a testdisk lát:

Disk /dev/sdb - 250 GB / 232 GiB - CHS 30401 255 63
Partition Start End Size in sectors
>* HPFS - NTFS 0 32 33 44 190 18 716800 [System Reserved] NEM KELL
HPFS - NTFS 44 190 19 10836 27 7 173363200 NEM KELL
Linux LVM 96 128 33 30401 75 10 486846464 IRTÓ FONTOS!
Linux 10836 27 8 10963 150 3 2048000 SZÜKSÉGES A KIINDULÁSHOZ

Structure: Ok. Use Up/Down Arrow keys to select partition.
Use Left/Right Arrow keys to CHANGE partition characteristics:
*=Primary bootable P=Primary L=Logical E=Extended D=Deleted
Keys A: add partition, L: load backup, T: change type, P: list files,
Enter: to continue
NTFS, blocksize=4096, 367 MB / 350 MiB

Most próbálok megküzdeni lépésről-lépésre az adatok visszaszerzésével.
- Volt tehát 4 elsődleges partíció (ha egyáltalán még ebben a világképben gondolkodunk, mert nem tudom miben más az amiről az fdisk beszél: "az .. eszközön GPT (GUID partíciós tábla) található!")
- Látszik a 2 NTFS, az 1GB-os boot partíció (ki tudom menteni), de furán néz ki az LVM, mintha átlapolódna...
- Azon belül kell lennie 4GB/8GB swap-nek, 30GB/40GB root-nak és 110GB(?) home-nak.

A nehézség az, hogy (1) van ez az átlapolás/GPT dolog, (2) a swap lehetett 2 féle (mert 8GB a RAM), (3) a root kerekszám méretű a maradék pedig a home, (4) ami lehetett titkosított is, de sebaj!

Vagyis ELŐSZÖR ki kéne írjam dd-vel az SSD-t, hogy sokat próbálkozhassak. Ugye?
Azután értenem kéne a testdisk számait...
Ha eltalálom az lvm kötetek sorrendjét és méretét, akkor már gyerekjáték.

Tanácsokat várok és együttérző izgalmat :)

Hozzászólások

Nekem egyszer hasonló esetben bevált a parted rescue funkciója, igaz ott nem volt lvm.
Egyébként testdisk témában szerintem kell egy dd image mentésnek, és egy másik amint a testdisk-kel bohóckodsz. Ez utóbbi persze lehet az első másolata is. A fizikai eszköz pedig legyen csak félretéve.

Ha pedig vérre megy, pláne nagy betűvel és felkiáltójellel, tehát "VÉRRE MEGY!", akkor legrosszabb esetben visszaállsz a legutóbbi backup-ra.

Ez utóbbi persze lehet az első másolata is.

BTRFS és copy-on-write :)

Hogy offon-topicabb is legyek: első körben én kipróbálnám, hogy a mentett anyagból dd-vel kihúznám attól az offset-től, amit a testdisk mond (ha nincs nagyon este és jól számolom dd skip=15565312), aztán ezt a fájlt odaadni az LVM-nek, hogy mit lát benne.
Az overlapped FS simán lehet annyi, hogy megtalálta benne a root fs-ed (ha jól olvasom a másik kettő kódolt/swap, úgyhogy nem nagyon volt fs headerjük)

Valami ilyesmi: https://anitechtalk.wordpress.com/2010/12/15/mount-lvm-based-volumes-fr…

Szerk.: Nagyon este van ha már az on/off topic közti különbséget se látom...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

1. Kiírtam az SSD-t image-be, 250.....byte lett.
2. Telepítek VirtulaBox-on egy hasonló rendszert.
3. Nem értem, a testdisk számai miképpen feleltethetők meg az fdisk által látottaknak? Vagyis kiírnám az elsődleges 4 partíciót (figyelmen kívül hagyva az átlapolást), de próbálom értelmezni a szektorszámokat, hogy reprodukálhassam tesztrendszerben...

Jó, felejtsük el a testdisk számait, "p"-re váltottam a testdiskben az 1. 3 elsődleges partíciót és Write! Most valóban úgy néz ki az SSD eleje, ahogy kell. A Win-es és a boot partíciók felcsatolódnak, olvashatók, lementhetők. A maradék utolsó partíció már ebből adódik. A homály csak az lvm-es kiosztása...

Az fdisk már ezt látja:
Disk /dev/sdc: 250.1 GB, 250059350016 bytes
255 fej, 63 szektor, 30401 cilinder, összesen 488397168 szektor
Egység: szektorok 1 * 512 = 512 bájt
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Lemezazonosító: 0x00000000

Eszköz Indítás Eleje Vége Blokkok Az Rendszer
/dev/sdc1 2048 718847 358400 7 HPFS/NTFS/exFAT
/dev/sdc2 718848 174082047 86681600 7 HPFS/NTFS/exFAT
/dev/sdc3 174082048 176130047 1024000 83 Linux
/dev/sdc4 176130048 488397167 156133560 8e Linux LVM

Elővettem az eredeti mint 17-et és indítottam a telepítést VirtualBox-ban ugyanekkora dinamikus lemezen. Fdisk-kel megcsináltam a partíció kiosztást, majd restart. Azután megcsináltam az lvm kiosztást 3 logikai partícióval. Azt hiszem eltaláltam, hogy swap 8GB, root 30GB, home a maradék, mert ez pont annyi lett, amire emlékszem (110GB körül).
Azután Mint 17 telepítés. Itt tartok.

Mivel az fdisk kizárásos alapon jól látja, az lvm log. partíciók kerek számok voltak, a sorrendjük a szokásomat követi, a vége stimmelt és a korábbi telepítést követtem, SZERINTEM KÖVETKEZHET AZ LVM FELDERÍTÉSE AZ EREDETI SSD-n!

Ha látni fogom a root fájljait, akkor már kiderül, hogy látható-e a home is, vagy a titkosítás alapján kell eljárni - erről van leírásom.

Részlet az eredeti grub.conf-ból:
linux /vmlinuz-3.13.0-24-generic root=/dev/mapper/mint--vg-lvroot ro quiet splash $vt_handoff
initrd /initrd.img-3.13.0-24-generic

Részlet a virtuális gép grub.conf-ból:
linux /vmlinuz-3.13.0-24-generic root=/dev/mapper/mint--vg-lvroot ro quiet splash $vt_handoff
initrd /initrd.img-3.13.0-24-generic

Egyezik! Most hogyan derítsem fel az eredetin az lvm-et? Ötleteket kérek. Köszi

Bizony, az ideiglenesen most telepített rendszerem már paranoiásan tervezett. Több felhőbe, adathordozóra, eltérő földrajzi helyen mentett, cron-nal segített, - de folyamatosan dolgozom rajta. A felhőkbe mentett cucc a szerkezetről pl. egy pici titkosított konténer, melynek a kulcsa több pendrive-on éntudommianeve fájl...

Összefoglalva:
1) Az elsődleges partíciók testdisk alapján visszaállítva, csatolhatók, olvashatók, az lvm-est kivéve
2) Az eredeti vinyó imidzsbe elmentve
3) Virtualboxban az eredetivel egyező (Mint 17, SSD méret, partíció kiosztás) rendszer telepítve
4) Az LVM becsatolása a https://anitechtalk.wordpress.com/2010/12/15/mount-lvm-based-volumes-fr… leírás alapján nem sikerül, nem látható

Favágó módszer - ehhez mit szóltok?
------------------------------------

Ha biztos vagyok benne, hogy
1) a virtuális gép partíció kiosztása és az LVM pontosan egyezik,
2) akkor az eredeti vinyóra ezt visszaírva
3) elindul a rendszer, vagy legalábbis olvasható lesz a logikai kötet?

megjegyzések a fenti pontokhoz:
1) a Virtualboxnak hogyan kéne megadjam a pontos SSD méretet (bájtra pontosan)
2) elég ha az MBR-t és az sfdisk dump-ot írom vissza?
3) itt úgy érzem probléma lehet a VG UUID, vagy az LV UUID, ami az eredeti grub.conf-ban más

A fenti doksiban írt pvscan ír valamit? dmesg-ben látszik valami?

Még azt kipróbálhatod, hogy dd-vel/grep-pel/akármivel végigfutsz a lemezen és keresteted benne az LVM fejléc valami jellemző darabját (pl. lv_root - Szerk.: lásd az Implementation rész első képét https://en.wikipedia.org/wiki/Logical_Volume_Manager_%28Linux%29). Ha nem találod benne, akkor buktad az LVM meta adatokat, ami baj.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)