Ahojte.
Podařilo se mně zrušit si logické svazky a to tak, že jsem si chtěl nainstalovat jinou fedoru (7) na USB disk. Vždycky jsem toto dělal na notebooku s windows a nikdy jsem neměl žádné problémy. Teďka jsem to vyzkušel na PC s fedorou 10 na pevném disku, při instalaci jsem všude uváděl, že chci všechno instalovat na sdb disk (což byl ten USB disk) a i že chci odtud bootovat. Takže jsem předpokládal, že se moje instalování nijak nedotkne disku sda.
Omyl. Když jsem odpojil usb disk a chci bootovat z harddisku naskočí obrazovka, kde je možné vybrat dvě poslení nainstalované jádra fedory na pevném disku a nebo windows. Windows fungují, ale fedora ne protože logické svazky se ztratily. To jsem zjistil, když jsem rozjel záchranný režim z instalačního disku. Myslíte si někdo, že je možné data nějak zachránit? Měl jsem tam vedle primarní partition pro windows ještě extended partition, kterou jsem používal pro linux rozdělenou na logický svazek / a /home (a asi nějaký swap), ale nevím ani v jakém poměru. Momentálně když nastartuji novou instalaci fedory 10 vidím, že disk je rozdělený na sda1 (ntfs), sda2 (ext3 - což bylo /boot) a sda3 typu LVM PV.
Nevím co s tím. :-(
Vypadá to, že jeden pc nesnese dvě fedory. Zkoušeli jste to někdo?
Díky za případnou radu.
Jak jsi instaloval ten USB klic? Pokud jsi pouzil livecd-creator . Tak by nemel byt problem. Pokud jsi ale instaloval na USB pomoci normlani instalace a jenom jako disk jsi vybral USB (nikdy jsem to nezkousel) a podle toho co poises upravil boot tak aby ukazoval na USB disk.
Muj navrh je pokud chces mit fedoru na USB je lepsi pouzit http://fedoraproject.org/wiki/FedoraLiveCD/USBHowTo .Vyhoda je ze pouziva ramdisk na spustu veci (nenici tak USB).
JInak co se tyka opravy.
Nejjednodussi:
prinstalovat fedoru.
Slozitejsi:
rekl bych ze ti v /boot/grub.conf
ukazuji cesty nekam jinam nez maji (asi se zmenili UUID pri instalaci dalsi fedory).
Takze zjistit na jakem disku /dev/cosi se nachazi root puvodni fedory a zapsat to do grub.conf.
Nabootovat do rescue a zkusit vgscan (precte vsechny disk a najde VG) vgdisplay.
Melo by ti to rict UUID disku, ktere by jsi pak mel zmenit v grub.conf.
Tohle je jenom nastrel podle informaci co jsi dal. Pravda muze byt uplne nekde jinde :)).
Momentálně, když dám fdisk -l vidím tohle:
Device boot start end blocks id system
/dev/sda1 * 1 2432 19535008 7 HPFS/NTFS
/dev/sda2 2433 2457 200812 83 Linux
/dev/sda3 2458 24321 175622580 8e Linux LVM
/dev/sda3 byl rozdělen myslím na tři svazky. Na root, swap a home. Takže root byl na /dev/sda3 ale nevím kolik zabíral který. Jinak bych to takto rozdělil novou instalací a zapsal bez formátování. Nevím teda co by to udělalo, ale aspoň bych se o to pokusil, protože tam mám data. Archiv mám, ale stejně, nearchivuji každý den.
Zkoušel jsem v rescue pustit ten vgscan a vgdisplay ale takové příkazy to nebere.
V grub mám toto:
root (hd0,1)
kernel /vmlinuz-2.6xxxxx.fc10 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
initrd /initrd-2.6xxxxx.fc10.i686.img
No a protože VolGroup00 a LogVol00 jaksi není tak to skončí tímto:
Unable to access resume device (/dev/VolGroup00/LogVol01)
mount: error mounting /dev/root on /sysroot as ext3: No such file or directory
Snažil jsem se nějak namontovat ten /dev/sda2 v rescue režimu ale hlásí to že fstab neexistuje a že /dev/sda2 není ani ve fstab ani v mtab. Ale i kdybych se na sda2, což předpokládám, že je /boot dostal tak nevím, kde bych měl hledat původní hodnoty nastavení těch LogVol01 a LogVol02 a ví bůh co tam ještě bylo.
Řekl bych, že tomu příliš nerozumím a tím pádem je těžké něco popsat a následně pak rady pochopit. 
Nicméně díky za radu a kdyby byla ještě nějaká tak se budu snažit vydržet než to celé přepíšu novou instalací. Do takové situace se sice můžu zase lehce dostat, ale musel bych si na takové věci koupit testovací počítač. A to už bych si tu mohl udělat zrovna výpočetku.
Díky ještě jednou a přeji vám ať vás provází síla. To stejné přeji i sobě až budu něco hledat.
Karel
Tak jo. Neměl jsem tušení, že existuje nějaké lvm a vůbec to celkově bylo velmi užitečné. Výsledek je, že jedině pvs a pvdisplay zobrazuje /dev/sda3. lvscan, vgscan, vgdisplay, lvdisplay nevypisují nic. /dev/sda2 kde je boot se namontovat podařilo ale /dev/sda3 není namontovaný - montáž hlasí “wrong fs type, bad option, bad superblock on /dev/sda3…” a v syslogu je pak “VFS: Cannot find ext3 filesystem on dev sda3”.
V grub.conf je:
splashimage=(hd0,1)/grub/splash.xpm.gz
hiddenmenu
title Fedora (2.6.27.15-170.2.24.fc10.i686)
root (hd0,1)
kernel /vmlinuz-2.6.27.15-170.2.24.fc10.i686 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
initrd /initrd-2.6.27.15-170.2.24.fc10.i686.img
Nemáš ještě nějaký nápad, který by mně popostrčil dál? A nebo to mám už zabalit?
Díky.
V prvni rade musis pochopit, ze /dev/sda3 neni oddil ktery se da primountovat a uz vubec na nem neni souborovy system ext3. /dev/sda3 je korenovy oddil struktury LVM - Logical Volume Manager. Tento obsahuje dalsi logicke deleni disku do tzv. Volume Group a ty jsou nasledne deleny do logickych oddilu disku Logical Volume. Tyto jsou pro fdisk, ktery rozumi pouze klasickemu deleni disku neviditelne. Duvod proc se to dela je, ze VolGroup muzes roztahnout na nekolik disku a nasledne ji nezavisle na rozdeleni fyzickych disku delit na diskove oddily.
Pokud zachranny mod nemuze VolGroup/LogVol najit, je bohuzel neco hodne spatne. Je to stejne jako by si smazal tabulku deleni disku - pak by ti fdisk taky nic nevypsal.
Bohuzel s LVM mam zatim pouze minimum zkusenosti, nicmene myslim si, ze logickou tabulku LVM lze obnovit. Je ale potreba bud znat rozdeleni disku, coz neni tvuj pripad, nebo pokud si pouzil vychozi instalaci Fedory doufat, ze ti fedora v instalatoru prozradi jake automaticke rozdeleni disku udelala, toto opsat a aplikovat na disk. Je to velice obecna rada, ale kucharku na tento problem proste napsat nelze. V prvni rade bych tedy z livecd nebo rescue mode zazalohoval oddil /dev/sda3 na jiny disk (dd if=/dev/sda3 of=/mnt/sempripojnovydisk/soubor.hda3 bs=512), nasledne, pust instalaci a zaskrtni ze chces zkontrolovat rozdeleni disku. To si pak nekam opis. Idealni by bylo kdyby mozne rozdeleni jeste aplikovat ale oddily neformatovat, ale to se obavam z anacondy uz nejde. Pak by si musel pomoci prikazu vgcreate atd. z rescumode znovuvytvorit tabulku s rozdelenim LVM a nasledne se modlit aby to bylo spravne.
Provedl jsem podle rady -> vgcreate, lvcreate a aktivaci pomocí vgchange -a y Volgroup00
Teďka když udělám:
mount -t ext3 /dev/mapper/VolGroup00-LogVol00 /mnt/sysimage
dostanu toto:
wrong fs type, bad option, bad superblock on /dev/mapper/VolGroup00-LogVol00, missing codepage or helper porgram or other error. V syslog je toto:
VFS: CAnnot find ext3 filesystem on dev dm-0
Pokud se na rozdělení disku dostanu přes anakondu tak se tam u LogVol00 ukazuje typ foreign.
Nemáš ještě nějakou radu? Díky.
To je samozrejme. Jako u normalniho diskoveho oddilu, musis teto casti disku rici jaky soubory system na ni ma byt. Tedy fdiskem nastavit paritition type. Pokud ani pote nepujde tento oddil pripojit, tak si spatne nastavil velikost nebo umisteni te VolGroup… pokud se proste netrefis do stejnych parametru jako mela ta puvodni na disku, proste to nepujde. A cim vic spatnych pokusu, tim vic prepisujes na disku dat…
To je detektivka. Bez konfigurace LVM je skoro nemožné se takovou palbou do něčích oken kamkoli smysluplně trefit.
LVM zálohuje konfiguraci v metadatech na disku. Ve výchozím nastavení ukládá 1 kopii v oblasti pro metadata na každém fyzickém svazku v rámci skupiny svazků. Data jsou uložena v normálním textovém formátu - prostě lze zkopírovat příslušné sektory ze svazku a použít je pro vytvoření konfigurace LVM. Oblast metadat je kruhová vyrovnávací paměť - nová data se kopírují za stará. Pokud tam nějaká byla, mohla by ještě být obnovitelná (ani ta tvá poslední operace je nemusela úplně přepsat).
Další možností je najít na disku příslušné sektory (odhadem 4 souvislé), kde je uložena záloha LVM, obvykle v /etc/lvm/backup/VolGroup00 (a v /etc/lvm/archive je archiv záloh). Pro takové hledání není moc záchranný disk Fedory vybaven (i když lze třeba grepovat část disku). Můžeš použít jeden z diskových editorů na http://www.ultimatebootcd.com/.
Ten textový soubor vypadá nějak takhle: http://www.centos.org/docs/5/html/Cluster_Logical_Volume_Manager/meta_example.html. Mimochodem je to docela pěkná příručka.
Hledáš takový, kde je 1 fyzický (pv0) a asi 3 logické (LogVolxx; “/dev/sda3 byl rozdělen myslím na tři svazky. Na root, swap a home.”). Datum vytvoření (na konci prvního řádku) by mělo být z původní instalace.
Pokud se ti příslušná data podaří najít, mohlo by stačit obnovit metadata za použití tohoto souboru. Pokud byl přepsán začátek fyzického svazku a prvního logického, měl by ses tak dostat bez potíží minimálně k zbylým dvěma - je velice pravděpodobné, že svazek /home nebyl první.
Pokud po těch operacích není fyzický svazek stejný (musí mít stejný UUID, velikost), musíš napřed obnovit ten:
pvcreate --uuid <z toho obnoveného souboru> --restorefile <cesta k tomu obnovenému souboru> /dev/sda3
Pak už by mělo stačit obnovit metadata skupiny svazků:
vgcfgrestore --file <ten nalezený soubor> VolGroup00
vgchange -ay VolGroup00
(V záchraném režimu přes binárku lvm. Pro otestování slouží --test, další informace vypisuje -v.)
Příčina těchto potíží je podle mne v Anacondě a výchozím pojmenování VolGroup00/LogVolxx.
Za normálních podmínek (neporušený LVM) proběhne instalace bez potíží. Pokud je LVM poškozen nebo Anaconda prostě původní svazky v tu chvíli nevidí, vytvoří stejně pojmenované svazky, a pak je podle mne dokonáno.
Podíváš-li se do Bugzilly, najdeš podobná hlášení za celou dobu existence LVM. Nikdy se nepodařilo vývojářům stav simulovat, protože to prováděli v čistém stavu. Bohužel také trvale ignorují doporučení na změnu jména svazků.
Doporučuji všem při instalaci vlézt do ruční konfigurace disků a přejmenovat VolGroup00/LogVolxx na cokoli jiného. Vyzkoušejte si třeba připojit kamarádův disk se stejnými VolGroup00/LogVolxx k vlastnímu počítači (pro zálohování nebo zkopírování jeho souborů). Ta sranda, kterou při tom zažijete, se jako zkušenost vyplatí.