Jak postupovat při záchraně dat: Porovnání verzí
m úroveň nadpisů, interpunkce a typografie, semtam další jazykové úpravy, v sekci o virtualizaci oprava věcné chyby (velikost sektoru, ne bajtu), kategorie |
|||
Řádek 1: | Řádek 1: | ||
Stává se, že se vám do rukou dostane neznámý disk o jehož obsahu nemáte ani tušení a přitom z něj máte zachránit co se dá. Někdy také |
Stává se, že se vám do rukou dostane neznámý disk, o jehož obsahu nemáte ani tušení a přitom z něj máte zachránit, co se dá. Někdy také „zdědíte“ stroj, který instaloval kdysi dávno někdo před vámi, a vy máte zdokumentovat, kde má co nainstalované. V takovém případě se vám mohou hodit následující postupy. |
||
=Připojení neznámého disku= |
==Připojení neznámého disku== |
||
{{Výpis|1={{Linux:root}}[[Linux:tail|tail]] -f /var/log/messages}} |
{{Výpis|1={{Linux:root}}[[Linux:tail|tail]] -f /var/log/messages}} |
||
Ukázka výpisu |
Ukázka výpisu: |
||
<small> |
<small> |
||
Řádek 45: | Řádek 45: | ||
{{Výpis|1={{Linux:root}}[[Linux:fdisk|fdisk]] -l /dev/sdb |
{{Výpis|1={{Linux:root}}[[Linux:fdisk|fdisk]] -l /dev/sdb |
||
Disk /dev/sdb: 250,0 GB, 250 |
Disk /dev/sdb: 250,0 GB, 250 059 350 016 bajtů |
||
hlav: 255, sektorů na stopu: 63, cylindrů: 30 |
hlav: 255, sektorů na stopu: 63, cylindrů: 30 401 |
||
Jednotky = cylindry po |
Jednotky = cylindry po 16065 * 512 = 8 225 280 bajtech |
||
Identifikátor disku: 0x00000000 |
Identifikátor disku: 0x00000000 |
||
Řádek 56: | Řádek 56: | ||
}} |
}} |
||
Z výpisu je zřejmé, že je disk rozdělen na tři diskové oddíly, z toho první dva byly součástí linuxového softwarového |
Z výpisu je zřejmé, že je disk rozdělen na tři diskové oddíly, z toho první dva byly součástí linuxového softwarového RAIDu. Třetí diskový oddíl je běžného typu, tudíž na něm mohl být nejspíš nějaký souborový systém. |
||
=Reaktivace softwarového |
==Reaktivace softwarového RAIDu== |
||
Zkusíme tedy nejdřív zjistit, jak je to s oddíly, které byly určeny pro |
Zkusíme tedy nejdřív zjistit, jak je to s oddíly, které byly určeny pro RAID. |
||
{{Výpis|1={{Linux:root}}[[Linux:mdadm|mdadm]] --examine --scan /dev/sdb1 /dev/sdb2 |
{{Výpis|1={{Linux:root}}[[Linux:mdadm|mdadm]] --examine --scan /dev/sdb1 /dev/sdb2 |
||
Řádek 67: | Řádek 67: | ||
}} |
}} |
||
Jak vidno, tyto oddíly patří do |
Jak vidno, tyto oddíly patří do RAID 1 (mirror), tudíž z nich je možné kompletně obnovit původní RAIDová pole. Neúplná RAIDová pole obnovíme velice snadno, neboť předchozí výpis odpovídá syntaxi v souboru <code>mdadm.conf</code>. |
||
Můžeme tedy tento výpis rovnou přidat do našeho konfiguračního souboru. |
Můžeme tedy tento výpis rovnou přidat do našeho konfiguračního souboru. |
||
Řádek 73: | Řádek 73: | ||
{{Výpis|1={{Linux:root}}[[Linux:mdadm|mdadm]] --examine --scan /dev/sdb1 /dev/sdb2 >> /etc/mdadm/mdadm.conf}} |
{{Výpis|1={{Linux:root}}[[Linux:mdadm|mdadm]] --examine --scan /dev/sdb1 /dev/sdb2 >> /etc/mdadm/mdadm.conf}} |
||
{{Pozn|V případě, že v systému do kterého tento |
{{Pozn|V případě, že v systému, do kterého tento RAID chcete připojit, již existuje jiný RAID se stejným číslem, jako má některé z polí na připojeném disku, je třeba otevřít soubor <code>/etc/mdadm/mdadm.conf</code> a změnit pořadové číslo pole, které by se mohlo dostat do konfliktu. |
||
}} |
}} |
||
Poté |
Poté, kdy máme upraven soubor <code>/etc/mdadm/mdadm.conf</code>, můžeme provést reaktivaci nově přidaných polí. |
||
{{Výpis|1={{Linux:root}}[[Linux:mdadm|mdadm]] -A -s |
{{Výpis|1={{Linux:root}}[[Linux:mdadm|mdadm]] -A -s |
||
Řádek 96: | Řádek 96: | ||
}} |
}} |
||
se můžete přesvědčit o úspěšnosti reaktivace. |
|||
=Zjišťování použitého souborového systému= |
==Zjišťování použitého souborového systému== |
||
Nyní je je třeba zjistit, jak to na těchto diskových polích vypadá. Je nad nimi ještě další vrstva, nebo přímo souborový systém? |
Nyní je je třeba zjistit, jak to na těchto diskových polích vypadá. Je nad nimi ještě další vrstva, nebo přímo souborový systém? |
||
Abyste zabránili nechtěnému poškození, je vhodné si vyexportovat |
Abyste zabránili nechtěnému poškození, je vhodné si vyexportovat počáteční oblast disku do dočasného souboru a dále pracovat s ním. |
||
{{Výpis|1={{Linux:root}}[[Linux:dd|dd]] if=/dev/md0 bs=512 count=255 of=/tmp/md0-raw-start |
{{Výpis|1={{Linux:root}}[[Linux:dd|dd]] if=/dev/md0 bs=512 count=255 of=/tmp/md0-raw-start |
||
255+0 vstoupivších záznamů |
255+0 vstoupivších záznamů |
||
255+0 vystoupivších záznamů |
255+0 vystoupivších záznamů |
||
130 |
130 560 bajtů (131 kB) zkopírováno, 0,0396919 s, 3,3 MB/s |
||
}} |
}} |
||
Na vyexportovaný soubor lze pak pustit utilitu [[Linux:file|file]] |
Na vyexportovaný soubor lze pak pustit utilitu [[Linux:file|file]]: |
||
{{Výpis|1={{Linux:root}}[[Linux:file|file]] -s /tmp/md0-raw-start |
{{Výpis|1={{Linux:root}}[[Linux:file|file]] -s /tmp/md0-raw-start |
||
Řádek 116: | Řádek 116: | ||
}} |
}} |
||
Ta prozradí nejenom typ souborového systému, ale také UUID diskového oddílu. Když se zkusíme jen tak pro zajímavost podívat na začátek třetího diskového oddílu, tak se dozvíme, že byl součástí LVM svazku |
Ta prozradí nejenom typ souborového systému, ale také UUID diskového oddílu. Když se zkusíme jen tak pro zajímavost podívat na začátek třetího diskového oddílu, tak se dozvíme, že byl součástí LVM svazku: |
||
{{Výpis|1={{Linux:root}}[[Linux:file|file]] -s /tmp/sdb3-raw-start |
{{Výpis|1={{Linux:root}}[[Linux:file|file]] -s /tmp/sdb3-raw-start |
||
Řádek 122: | Řádek 122: | ||
}} |
}} |
||
=Obnova LVM svazku= |
==Obnova LVM svazku== |
||
Když jsme se do vyexportovaného souboru podívali editorem, nalezli jsme v něm následující zajímavou část: |
|||
{{Výpis|1= |
{{Výpis|1= |
||
Řádek 186: | Řádek 186: | ||
}} |
}} |
||
Z těchto údajů lze zjistit nejenom na kterém stroji a kdy byl LVM svazek vytvořen, ale také (podle UUID) zjistit zda byl diskový oddíl součástí LVM svazku i v okamžiku odpojení. Pak lze |
Z těchto údajů lze zjistit nejenom, na kterém stroji a kdy byl LVM svazek vytvořen, ale také (podle UUID) zjistit, zda byl diskový oddíl součástí LVM svazku i v okamžiku odpojení. Pak lze přinejmenším část uložených dat obnovit. U výše uvedeného příkladu lze již zběžným pohledem odhalit, že diskový oddíl byl před vytažením disku ze svazku odstraněn, tudíž s největší pravděpodobností již neobsahuje žádná data. |
||
=Jak se dostat na diskové oddíly= |
==Jak se dostat na diskové oddíly== |
||
Systém by si měl většinou při připojení externích disků poradit a pro |
Systém by si měl většinou při připojení externích disků poradit a pro jednotlivé diskové oddíly vytvořit příslušná zařízení. Někdy, zvláště pokud je prostor na disku nějakým způsobem poškozen nebo pokud jde o pouhý obraz disku vytvořený přes [[Linux:fdisk|fdisk]], si je třeba poradit jinak – při [[Linux:mount|mountu]] použít tzv. '''offset'''. Offsetem se udává, kolik se má při mountu přeskočit. Zjistit, jakou velikost offsetu musíte použít, můžete takto: |
||
{{Výpis|1={{Linux:root}}[[Linux:fdisk|fdisk]] -l /dev/sdb |
{{Výpis|1={{Linux:root}}[[Linux:fdisk|fdisk]] -l /dev/sdb |
||
Disk /dev/sdb: 250,0 GB, 250 |
Disk /dev/sdb: 250,0 GB, 250 059 350 016 bajtů |
||
hlav: 255, sektorů na stopu: 63, cylindrů: 30 |
hlav: 255, sektorů na stopu: 63, cylindrů: 30 401 |
||
Jednotky = cylindry po |
Jednotky = cylindry po 16065 * 512 = 8 225 280 bajtech |
||
Identifikátor disku: 0x5b6ac646 |
Identifikátor disku: 0x5b6ac646 |
||
Řádek 212: | Řádek 212: | ||
/dev/sdb4 : start= 0, size= 0, Id= 0 |
/dev/sdb4 : start= 0, size= 0, Id= 0 |
||
}} |
}} |
||
{{Výpis|1={{Linux:root}}[[Linux:dd|dd]] if=/dev/sdb bs=512 count=255 skip=63 of=/tmp/sdbs-raw-start |
{{Výpis|1={{Linux:root}}[[Linux:dd|dd]] if=/dev/sdb bs=512 count=255 skip=63 of=/tmp/sdbs-raw-start |
||
255+0 vstoupivších záznamů |
255+0 vstoupivších záznamů |
||
255+0 vystoupivších záznamů |
255+0 vystoupivších záznamů |
||
130 |
130 560 bajtů (131 kB) zkopírováno, 0,0207372 s, 6,3 MB/s |
||
{{Linux:root}}[[Linux:file|file]] -s /tmp/sdbs-raw-start |
{{Linux:root}}[[Linux:file|file]] -s /tmp/sdbs-raw-start |
||
/tmp/sdbs-raw-start: x86 boot sector, Microsoft Windows 98 Bootloader, code offset 0x5a, OEM-ID "MSWIN4.1", sectors/cluster 64, Media descriptor 0xf8, heads 255, hidden sectors 63, sectors 488392002 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 59611, reserved3 0x800000, serial number 0x4b1a02bd, label: "WD Passport" |
/tmp/sdbs-raw-start: x86 boot sector, Microsoft Windows 98 Bootloader, code offset 0x5a, OEM-ID "MSWIN4.1", sectors/cluster 64, Media descriptor 0xf8, heads 255, hidden sectors 63, sectors 488392002 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 59611, reserved3 0x800000, serial number 0x4b1a02bd, label: "WD Passport" |
||
Řádek 228: | Řádek 227: | ||
{{Výpis|1={{Linux:root}}[[Linux:mount|mount]] -t vfat /dev/sdb /mnt -o offset=32256}} |
{{Výpis|1={{Linux:root}}[[Linux:mount|mount]] -t vfat /dev/sdb /mnt -o offset=32256}} |
||
=Oprava poškozeného souborového systému= |
==Oprava poškozeného souborového systému== |
||
Po zjištění jaký souborový systém neznámý disk obsahuje, je dobré provést jeho kontrolu. Hovorově se tato kontrola souborového systému nazývá ''čekování''. Tento slangový výraz vychází z anglického výrazu ''check'' |
Po zjištění, jaký souborový systém neznámý disk obsahuje, je dobré provést jeho kontrolu. Hovorově se tato kontrola souborového systému nazývá ''čekování''. Tento slangový výraz vychází z anglického výrazu ''check'' („ověřit“), ze kterého vycházejí i názvy pro utility, kterými se tato kontrola provádí. Obvykle je totiž v systému najdete pod názvem, který začíná '''fsck''' (z angl. '''''f'''ile'''s'''ystem '''c'''hec'''k''''' – ověření souborového systému). Narazíte-li tedy na aplikaci, která má v názvu '''fsck''', půjde vždy s největší pravděpodobností o utilitu, která slouží ke kontrole a opravě souborového systému. |
||
Jelikož pojmenování těchto utilit není zcela jednotné, jsou u Debianu v adresáři <code>/sbin</code> skripty, které sjednocují volání těchto kontrolních utilit podle následujícího vzoru: |
Jelikož pojmenování těchto utilit není zcela jednotné, jsou u Debianu v adresáři <code>/sbin</code> skripty, které sjednocují volání těchto kontrolních utilit podle následujícího vzoru: |
||
{{Výpis|1=fsck.<typ_souborového systému>}} |
{{Výpis|1=fsck.<typ_souborového systému>}} |
||
Díky tomu tak nemusíte přemítat jak se pro onen souborový systém, který potřebujete ověřit |
Díky tomu tak nemusíte přemítat, jak se pro onen souborový systém, který potřebujete ověřit, tato utilita jmenuje. |
||
V drtivé většině případů postačí pouhá kontrola, během níž ověřovací utilita sama opraví drobné chybky, které se mohly vyskytnout kupř. při nekorektním vypnutí stroje. |
V drtivé většině případů postačí pouhá kontrola, během níž ověřovací utilita sama opraví drobné chybky, které se mohly vyskytnout kupř. při nekorektním vypnutí stroje. |
||
{{Pozor|Pozor! Aby bylo možné provést kontrolu souborového systému, nesmí být diskový oddíl připojen pro zápis. |
{{Pozor|Pozor! Aby bylo možné provést kontrolu souborového systému, nesmí být diskový oddíl připojen pro zápis. Může však být připojen v režimu „pouze pro čtení“. |
||
Nelze-li tedy jinak, je třeba provést před kontrolou kořenového souborového systému tzv. '''remount''' do ''readonly'' režimu (tj. jen pro čtení). Systém je třeba najet do jednouživatelského režimu |
Nelze-li tedy jinak, je třeba provést před kontrolou kořenového souborového systému tzv. '''remount''' do ''readonly'' režimu (tj. jen pro čtení). Systém je třeba najet do jednouživatelského režimu (''single user mode'') a pak provést následujícím příkazem <code>remount</code>: |
||
{{Výpis|1={{Linux:root}}[[Linux:mount|mount]] -r -o remount /}} |
{{Výpis|1={{Linux:root}}[[Linux:mount|mount]] -r -o remount /}} |
||
Není-li stroj v jednouživatelském režimu a nějaký démon již s diskem pracuje, pak se vám '''remount''' nepodaří |
Není-li stroj v jednouživatelském režimu a nějaký démon již s diskem pracuje, pak se vám '''remount''' nepodaří. |
||
;Co si počít v případě |
; Co si počít v případě, kdy selže pokus o remount? : V takovém případě se pokuste zjistit pomocí [[Linux:fuser|fuser]] nebo [[Linux:lsof|lsof]], který proces pracuje s diskem, a pak buď službu, která jej spouští, korektně zastavit, nebo ho ''odstřelit'' příkazem [[Linux:kill|kill]] a pokusit se o '''remount''' znovu. |
||
}} |
}} |
||
==ext2== |
===ext2=== |
||
{{Výpis|1={{Linux:root}}[[Linux:fsck|fsck]] /dev/sda1 |
{{Výpis|1={{Linux:root}}[[Linux:fsck|fsck]] /dev/sda1 |
||
Řádek 260: | Řádek 259: | ||
}} |
}} |
||
Jak je zřejmé z ukázky, [[Linux:fsck|fsck]] poznal že jde o souborový systém ext2, který nebyl v |
Jak je zřejmé z ukázky, [[Linux:fsck|fsck]] poznal, že jde o souborový systém ext2, který nebyl v minulosti korektně odpojen, a tak provedl kontrolu. U čistého disku s ext2 bez chyb vypadá výpis po kontrole takto: |
||
{{Výpis|1={{Linux:root}}[[Linux:fsck|fsck]] /dev/sda1 |
{{Výpis|1={{Linux:root}}[[Linux:fsck|fsck]] /dev/sda1 |
||
Řádek 270: | Řádek 269: | ||
{{Pozor|Pozor! Stav po nekorektním odpojení se nemusí automaticky opravit při spouštění systému, pokud to nemáte nastaveno v souboru <code>/etc/fstab</code>. Takže i když máte disk připojen a pak ho korektně odpojíte, přesto může stále obsahovat chyby.}} |
{{Pozor|Pozor! Stav po nekorektním odpojení se nemusí automaticky opravit při spouštění systému, pokud to nemáte nastaveno v souboru <code>/etc/fstab</code>. Takže i když máte disk připojen a pak ho korektně odpojíte, přesto může stále obsahovat chyby.}} |
||
==reiser4== |
===reiser4=== |
||
Kontrola disku u reiser4 je sice |
Kontrola disku u reiser4 je sice „ukecaná“, ale rychlá. |
||
{{Pozn|Při používání reiser4 jsem se setkal s několika nepěknými situacemi. Je však otázkou, do jaké míry je to vina tohoto souborového systému. Kupř. při následující ukázce mi |
{{Pozn|Při používání reiser4 jsem se setkal s několika nepěknými situacemi. Je však otázkou, do jaké míry je to vina tohoto souborového systému. Kupř. při následující ukázce mi [[Linux:umount|umount]] neustále odmítal disk s tímto diskovým oddílem korektně odpojit. Pozastavoval jsem kde co. Nakonec jsem vyřešil kontrolu disku jeho přemoutováním do ''readonly'' režimu. |
||
A víte která služba nakonec za tím vězela? <code>/etc/init.d/xfs</code> |
A víte, která služba nakonec za tím vězela? <code>/etc/init.d/xfs</code> – X font server. Absolutně je mi záhadou, proč zrovna tato služba, která s tím diskem nemá absolutně nic do činění, blokuje jeho odpojení.}} |
||
<small>{{Výpis|1= |
<small>{{Výpis|1= |
||
Řádek 421: | Řádek 420: | ||
}}</small> |
}}</small> |
||
V případě že na tomto diskovém oddíle je již vše |
V případě že na tomto diskovém oddíle je již vše OK, vypadá výsledek kontroly takto: |
||
<small>{{Výpis|1= |
<small>{{Výpis|1= |
||
{{Linux:root}}[[Linux:fsck.reiser4|reiser4]] /dev/sdb1 |
{{Linux:root}}[[Linux:fsck.reiser4|reiser4]] /dev/sdb1 |
||
Řádek 476: | Řádek 475: | ||
}}</small> |
}}</small> |
||
=Oprava diskových oddílů virtuálních disků VMware= |
==Oprava diskových oddílů virtuálních disků VMware== |
||
Používáte-li virtualizaci, |
Používáte-li virtualizaci, může se stát, že narazíte na problém s poškozeným souborovým systémen na virtuálním disku. S uplatněním výše uvedených technik jej můžete opravit, aniž by bylo nutné virtuální stroj spouštět. |
||
'''Nezapomínejte na vytvoření zálohy!!!''' |
'''Nezapomínejte na vytvoření zálohy!!!''' |
||
Než začnete s diskem pracovat, vytvořte jeho kopii pomocí konverzního nástroje [[Linux:vmware-vdiskmanager|vmware-vdiskmanager]] |
Než začnete s diskem pracovat, vytvořte jeho kopii pomocí konverzního nástroje [[Linux:vmware-vdiskmanager|vmware-vdiskmanager]] a pomocí mountovací utility [[Linux:vmware-mount|vmware-mount]] zjistěte potřebný '''offset''', tj. od kterého sektoru začíná diskový oddíl, který potřebujete opravit. Dále pak pracujte již pouze s touto kopií. |
||
{{Výpis|1= |
{{Výpis|1= |
||
Řádek 494: | Řádek 493: | ||
}} |
}} |
||
{{Pozor|Vytvoření kopie je důležité zejména tehdy, pokud chcete vytáhnout data ze snapshotu. Mountovací utilita [[Linux:vmware-mount|vmware-mount]] totiž při připojení mění tzv. CID disku a mohlo by se vám stát, že byste se potom nedostali do snapshotů, které následovaly. Nástroj [[Linux:vmware-vdiskmanager|vmware-vdiskmanager]] totiž sloučí data z jednotlivých snapshotů |
{{Pozor|Vytvoření kopie je důležité zejména tehdy, pokud chcete vytáhnout data ze snapshotu. Mountovací utilita [[Linux:vmware-mount|vmware-mount]] totiž při připojení mění tzv. CID disku a mohlo by se vám stát, že byste se potom nedostali do snapshotů, které následovaly. Nástroj [[Linux:vmware-vdiskmanager|vmware-vdiskmanager]] totiž sloučí data z jednotlivých snapshotů tak, jak postupně předcházela.}} |
||
Aby bylo možné pracovat s virtuálním diskem jako by šlo o kopii disku vytvořenou pomocí utility [[Linux:dd|dd]] je třeba připojit virtuální disk jako tzv. '''flat''' disk. Po jeho připojení se v přípojném bodě objeví soubor s názvem <code>flat</code>, se kterým lze dále pracovat. |
Aby bylo možné pracovat s virtuálním diskem, jako by šlo o kopii disku vytvořenou pomocí utility [[Linux:dd|dd]], je třeba připojit virtuální disk jako tzv. '''flat''' disk. Po jeho připojení se v přípojném bodě objeví soubor s názvem <code>flat</code>, se kterým lze dále pracovat. |
||
{{Výpis|1= |
{{Výpis|1= |
||
Řádek 504: | Řádek 503: | ||
}} |
}} |
||
Nyní přichází řada na tzv. '''loop zařízení'''. Pro práci s loop zařízeními je určen nástroj [[Linux:losetup|losetup]]. Ten umožňuje jejich vytváření i rušení. Z výše uvedeného výpisu víme, že diský oddíl, který nás zajímá začíná 690795 |
Nyní přichází řada na tzv. '''loop zařízení'''. Pro práci s loop zařízeními je určen nástroj [[Linux:losetup|losetup]]. Ten umožňuje jejich vytváření i rušení. Z výše uvedeného výpisu víme, že diský oddíl, který nás zajímá, začíná 690795. sektorem. Obvyklá velikost jednoho sektoru je 512 bajtů, a jelikož se velikost offsetu udává v bajtech, vynásobíme počet sektorů velikostí jednoho sektoru a výslednou hodnotu použijeme jako ''offset''. |
||
{{Výpis|1= |
{{Výpis|1= |
||
Řádek 624: | Řádek 623: | ||
}}</small> |
}}</small> |
||
Po opravě disku |
Po opravě disku nezapomeňte zrušit všechna loop zařízení, která pracují s tímto diskem, a teprve pak jej odmountujte. |
||
{{Pozn|Pokud je při opravě reiserfs použita volba '''--rebuild-tree''', je určitě dobré mít |
{{Pozn|Pokud je při opravě reiserfs použita volba '''--rebuild-tree''', je určitě dobré mít uložený log, protože vám pak umožní identifikovat soubory z adresáře <code>/lost+found</code>.}} |
||
}} |
|||
[[Kategorie:Linux]] |
Verze z 26. 5. 2009, 18:33
Stává se, že se vám do rukou dostane neznámý disk, o jehož obsahu nemáte ani tušení a přitom z něj máte zachránit, co se dá. Někdy také „zdědíte“ stroj, který instaloval kdysi dávno někdo před vámi, a vy máte zdokumentovat, kde má co nainstalované. V takovém případě se vám mohou hodit následující postupy.
Připojení neznámého disku
root@stroj:~# tail -f /var/log/messages
Ukázka výpisu:
Apr 22 17:44:15 stroj X: Libgcrypt warning: missing initialization - please fix the application Apr 22 17:47:42 stroj kernel: [ 264.117586] usb 1-7: new high speed USB device using ehci_hcd and address 4 Apr 22 17:47:42 stroj kernel: [ 264.243891] usb 1-7: New USB device found, idVendor=152d, idProduct=2338 Apr 22 17:47:42 stroj kernel: [ 264.243905] usb 1-7: New USB device strings: Mfr=1, Product=2, SerialNumber=5 Apr 22 17:47:42 stroj kernel: [ 264.243914] usb 1-7: Product: USB to ATA/ATAPI Bridge Apr 22 17:47:42 stroj kernel: [ 264.243921] usb 1-7: Manufacturer: JMicron Apr 22 17:47:42 stroj kernel: [ 264.243927] usb 1-7: SerialNumber: 222293F04658 Apr 22 17:47:42 stroj kernel: [ 264.244503] usb 1-7: configuration #1 chosen from 1 choice Apr 22 17:47:42 stroj kernel: [ 264.344488] Initializing USB Mass Storage driver... Apr 22 17:47:42 stroj kernel: [ 264.348033] scsi4 : SCSI emulation for USB Mass Storage devices Apr 22 17:47:42 stroj kernel: [ 264.350151] usbcore: registered new interface driver usb-storage Apr 22 17:47:42 stroj kernel: [ 264.350166] USB Mass Storage support registered. Apr 22 17:47:47 stroj kernel: [ 269.351427] scsi 4:0:0:0: Direct-Access ST325031 0NS PQ: 0 ANSI: 2 CCS Apr 22 17:47:47 stroj kernel: [ 269.354109] sd 4:0:0:0: [sdb] 488397168 512-byte hardware sectors: (250 GB/232 GiB) Apr 22 17:47:47 stroj kernel: [ 269.354982] sd 4:0:0:0: [sdb] Write Protect is off Apr 22 17:47:47 stroj kernel: [ 269.355989] sd 4:0:0:0: [sdb] 488397168 512-byte hardware sectors: (250 GB/232 GiB) Apr 22 17:47:47 stroj kernel: [ 269.356846] sd 4:0:0:0: [sdb] Write Protect is off Apr 22 17:47:47 stroj kernel: [ 269.356876] sdb: sdb1 sdb2 sdb3 Apr 22 17:47:47 stroj kernel: [ 269.416988] sd 4:0:0:0: [sdb] Attached SCSI disk
root@stroj:~# sfdisk -d /dev/sdb # tabulka rozdělení disku pro /dev/sdb unit: sectors /dev/sdb1 : start= 63, size= 240912, Id=fd, bootable /dev/sdb2 : start= 240975, size= 58605120, Id=fd /dev/sdb3 : start= 58846095, size=429545970, Id=83 /dev/sdb4 : start= 0, size= 0, Id= 0
nebo
root@stroj:~# fdisk -l /dev/sdb Disk /dev/sdb: 250,0 GB, 250 059 350 016 bajtů hlav: 255, sektorů na stopu: 63, cylindrů: 30 401 Jednotky = cylindry po 16065 * 512 = 8 225 280 bajtech Identifikátor disku: 0x00000000 Zařízení Zavádět Začátek Konec Bloky Id Systém /dev/sdb1 * 1 15 120456 fd Linux RAID samorozpoznatelný /dev/sdb2 16 3663 29302560 fd Linux RAID samorozpoznatelný /dev/sdb3 3664 30401 214772985 83 Linux
Z výpisu je zřejmé, že je disk rozdělen na tři diskové oddíly, z toho první dva byly součástí linuxového softwarového RAIDu. Třetí diskový oddíl je běžného typu, tudíž na něm mohl být nejspíš nějaký souborový systém.
Reaktivace softwarového RAIDu
Zkusíme tedy nejdřív zjistit, jak je to s oddíly, které byly určeny pro RAID.
root@stroj:~# mdadm --examine --scan /dev/sdb1 /dev/sdb2 ARRAY /dev/md1 level=raid1 num-devices=2 UUID=21c6ea2f:416ebb32:c0b47c07:a2972704 ARRAY /dev/md0 level=raid1 num-devices=2 UUID=5084e71d:71fac395:2f70a1ed:2d127230
Jak vidno, tyto oddíly patří do RAID 1 (mirror), tudíž z nich je možné kompletně obnovit původní RAIDová pole. Neúplná RAIDová pole obnovíme velice snadno, neboť předchozí výpis odpovídá syntaxi v souboru mdadm.conf
.
Můžeme tedy tento výpis rovnou přidat do našeho konfiguračního souboru.
root@stroj:~# mdadm --examine --scan /dev/sdb1 /dev/sdb2 >> /etc/mdadm/mdadm.conf
Poté, kdy máme upraven soubor /etc/mdadm/mdadm.conf
, můžeme provést reaktivaci nově přidaných polí.
root@stroj:~# mdadm -A -s mdadm: /dev/md1 has been started with 1 drive (out of 2). mdadm: /dev/md0 has been started with 1 drive (out of 2).
Výpisem souboru /proc/mdstat
root@stroj:~# cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md0 : active (auto-read-only) raid1 sdb1[0] 120384 blocks [2/1] [U_] md1 : active (auto-read-only) raid1 sdb2[0] 29302464 blocks [2/1] [U_] unused devices: <none>
se můžete přesvědčit o úspěšnosti reaktivace.
Zjišťování použitého souborového systému
Nyní je je třeba zjistit, jak to na těchto diskových polích vypadá. Je nad nimi ještě další vrstva, nebo přímo souborový systém?
Abyste zabránili nechtěnému poškození, je vhodné si vyexportovat počáteční oblast disku do dočasného souboru a dále pracovat s ním.
root@stroj:~# dd if=/dev/md0 bs=512 count=255 of=/tmp/md0-raw-start 255+0 vstoupivších záznamů 255+0 vystoupivších záznamů 130 560 bajtů (131 kB) zkopírováno, 0,0396919 s, 3,3 MB/s
Na vyexportovaný soubor lze pak pustit utilitu file:
root@stroj:~# file -s /tmp/md0-raw-start /tmp/md0-raw-start: Linux rev 1.0 ext2 filesystem data (mounted or unclean), UUID=7509beb3-fa4b-434a-bce1-54f99449b7ba
Ta prozradí nejenom typ souborového systému, ale také UUID diskového oddílu. Když se zkusíme jen tak pro zajímavost podívat na začátek třetího diskového oddílu, tak se dozvíme, že byl součástí LVM svazku:
root@stroj:~# file -s /tmp/sdb3-raw-start /tmp/sdb3-raw-start: LVM2 (Linux Logical Volume Manager) , UUID: ghmk6itpklbAExbzBofefSyYQAQ73HD
Obnova LVM svazku
Když jsme se do vyexportovaného souboru podívali editorem, nalezli jsme v něm následující zajímavou část:
vg01 { id = "NE4164-p0aA-WD5n-Hpqm-2P3m-Ukf7-8Ilyeg" seqno = 9 status = ["RESIZEABLE", "READ", "WRITE"] flags = [] extent_size = 8192 max_lv = 0 max_pv = 0 physical_volumes { pv0 { id = "hYaUgw-3vF4-3qoz-d3Yu-rZ5l-KXv6-6UAyjt" device = "/dev/md2" status = ["ALLOCATABLE"] flags = [] dev_size = 1953519872 pe_start = 384 pe_count = 238466 } pv1 { id = "ghmk6i-tpkl-bAEx-bzBo-fefS-yYQA-Q73HDU" device = "/dev/sdc3" status = ["ALLOCATABLE"] flags = [] dev_size = 429545970 pe_start = 384 pe_count = 52434 } } logical_volumes { data { id = "tWtk63-DVNI-UCT4-JBpM-raPt-k7lD-1j6SFs" status = ["READ", "WRITE", "VISIBLE"] flags = [] segment_count = 1 segment1 { start_extent = 0 extent_count = 102400 type = "striped" stripe_count = 1 # linear stripes = [ "pv0", 0 ] } } } } # Generated by LVM2 version 2.02.44 (2009-01-26): Thu Apr 9 16:52:36 2009
Z těchto údajů lze zjistit nejenom, na kterém stroji a kdy byl LVM svazek vytvořen, ale také (podle UUID) zjistit, zda byl diskový oddíl součástí LVM svazku i v okamžiku odpojení. Pak lze přinejmenším část uložených dat obnovit. U výše uvedeného příkladu lze již zběžným pohledem odhalit, že diskový oddíl byl před vytažením disku ze svazku odstraněn, tudíž s největší pravděpodobností již neobsahuje žádná data.
Jak se dostat na diskové oddíly
Systém by si měl většinou při připojení externích disků poradit a pro jednotlivé diskové oddíly vytvořit příslušná zařízení. Někdy, zvláště pokud je prostor na disku nějakým způsobem poškozen nebo pokud jde o pouhý obraz disku vytvořený přes fdisk, si je třeba poradit jinak – při mountu použít tzv. offset. Offsetem se udává, kolik se má při mountu přeskočit. Zjistit, jakou velikost offsetu musíte použít, můžete takto:
root@stroj:~# fdisk -l /dev/sdb Disk /dev/sdb: 250,0 GB, 250 059 350 016 bajtů hlav: 255, sektorů na stopu: 63, cylindrů: 30 401 Jednotky = cylindry po 16065 * 512 = 8 225 280 bajtech Identifikátor disku: 0x5b6ac646 Zařízení Zavádět Začátek Konec Bloky Id Systém /dev/sdb1 1 30401 244196001 c W95 FAT32 (LBA)
root@stroj:~# sfdisk -d /dev/sdb # tabulka rozdělení disku pro /dev/sdb unit: sectors /dev/sdb1 : start= 63, size=488392002, Id= c /dev/sdb2 : start= 0, size= 0, Id= 0 /dev/sdb3 : start= 0, size= 0, Id= 0 /dev/sdb4 : start= 0, size= 0, Id= 0
root@stroj:~# dd if=/dev/sdb bs=512 count=255 skip=63 of=/tmp/sdbs-raw-start 255+0 vstoupivších záznamů 255+0 vystoupivších záznamů 130 560 bajtů (131 kB) zkopírováno, 0,0207372 s, 6,3 MB/s root@stroj:~# file -s /tmp/sdbs-raw-start /tmp/sdbs-raw-start: x86 boot sector, Microsoft Windows 98 Bootloader, code offset 0x5a, OEM-ID "MSWIN4.1", sectors/cluster 64, Media descriptor 0xf8, heads 255, hidden sectors 63, sectors 488392002 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 59611, reserved3 0x800000, serial number 0x4b1a02bd, label: "WD Passport"
root@stroj:~# echo $((63*512)) 32256
root@stroj:~# mount -t vfat /dev/sdb /mnt -o offset=32256
Oprava poškozeného souborového systému
Po zjištění, jaký souborový systém neznámý disk obsahuje, je dobré provést jeho kontrolu. Hovorově se tato kontrola souborového systému nazývá čekování. Tento slangový výraz vychází z anglického výrazu check („ověřit“), ze kterého vycházejí i názvy pro utility, kterými se tato kontrola provádí. Obvykle je totiž v systému najdete pod názvem, který začíná fsck (z angl. filesystem check – ověření souborového systému). Narazíte-li tedy na aplikaci, která má v názvu fsck, půjde vždy s největší pravděpodobností o utilitu, která slouží ke kontrole a opravě souborového systému.
Jelikož pojmenování těchto utilit není zcela jednotné, jsou u Debianu v adresáři /sbin
skripty, které sjednocují volání těchto kontrolních utilit podle následujícího vzoru:
fsck.<typ_souborového systému>
Díky tomu tak nemusíte přemítat, jak se pro onen souborový systém, který potřebujete ověřit, tato utilita jmenuje.
V drtivé většině případů postačí pouhá kontrola, během níž ověřovací utilita sama opraví drobné chybky, které se mohly vyskytnout kupř. při nekorektním vypnutí stroje.
ext2
root@stroj:~# fsck /dev/sda1 fsck 1.41.5 (23-Apr-2009) e2fsck 1.41.5 (23-Apr-2009) /dev/sda1 nebyl čistě odpojen, kontrola vynucena. Průchod 1: Kontroluji inode, bloky a velikosti Průchod 2: Kontroluji strukturu adresářů Průchod 3: Kontroluji dosažitelnost adresářů Průchod 4: Kontroluji počty odkazů Průchod 5: Kontroluji souhrnné informace skupin /dev/sda1: 53/28224 souborů (9,4 % nesouvislých), 21574/112452 bloků
Jak je zřejmé z ukázky, fsck poznal, že jde o souborový systém ext2, který nebyl v minulosti korektně odpojen, a tak provedl kontrolu. U čistého disku s ext2 bez chyb vypadá výpis po kontrole takto:
root@stroj:~# fsck /dev/sda1 fsck 1.41.5 (23-Apr-2009) e2fsck 1.41.5 (23-Apr-2009) /dev/sda1: čistý, 53/28224 souborů, 21574/112452 bloků
reiser4
Kontrola disku u reiser4 je sice „ukecaná“, ale rychlá.
root@stroj:~# umount /dev/sdb1 umount: /media/sdb1: device is busy. (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1)) root@stroj:~# fuser -c /dev/sdb1 root@stroj:~# lsof /dev/sdb1 root@stroj:~# mount -r -o remount /dev/sdb1 root@stroj:~# fsck.reiser4 /dev/sdb1 ******************************************************************* This is an EXPERIMENTAL version of fsck.reiser4. Read README first. ******************************************************************* Fscking the /dev/sdb1 block device. Will check the consistency of the Reiser4 SuperBlock. Will check the consistency of the Reiser4 FileSystem. Continue? (Yes/No): Y ***** fsck.reiser4 started at Tue May 5 19:00:35 2009 Reiser4 fs was detected on /dev/sdb1. Master super block (16): magic: ReIsEr4 blksize: 4096 format: 0x0 (format40) uuid: 7de3bb64-05c6-4bd8-bb4e-a76665fb0000 label: <none> Format super block (17): plugin: format40 description: Disk-format plugin. version: 0 magic: ReIsEr40FoRmAt mkfs id: 0xec510fa flushes: 0 blocks: 78142160 free blocks: 55682233 root block: 441728 tail policy: 0x2 (smart) next oid: 0x12735 file count: 164 tree height: 3 key policy: LARGE CHECKING THE STORAGE TREE Read nodes 65 Nodes left in the tree 65 Leaves of them 36, Twigs of them 28 Time interval: Tue May 5 19:00:51 2009 - Tue May 5 19:00:52 2009 CHECKING EXTENT REGIONS. Read twigs 28 Time interval: Tue May 5 19:00:52 2009 - Tue May 5 19:00:52 2009 CHECKING THE SEMANTIC TREE Found 146 objects (some could be encountered more then once). Time interval: Tue May 5 19:00:52 2009 - Tue May 5 19:00:52 2009 FSCK: repair.c: 550: repair_sem_fini: On-disk used block bitmap and really used block bitmap differ. ***** fsck.reiser4 finished at Tue May 5 19:00:52 2009 Closing fs...done 1 fatal corruptions were detected in FileSystem. Run with --build-fs option to fix them. root@stroj:~# fsck.reiser4 --build-fs /dev/sdb1 ******************************************************************* This is an EXPERIMENTAL version of fsck.reiser4. Read README first. ******************************************************************* Fscking the /dev/sdb1 block device. Will check the consistency of the Reiser4 SuperBlock. Will build the Reiser4 FileSystem. Continue? (Yes/No): Yes ***** fsck.reiser4 started at Tue May 5 19:10:04 2009 Reiser4 fs was detected on /dev/sdb1. Master super block (16): magic: ReIsEr4 blksize: 4096 format: 0x0 (format40) uuid: 7de3bb64-05c6-4bd8-bb4e-a76665fb0000 label: <none> Format super block (17): plugin: format40 description: Disk-format plugin. version: 0 magic: ReIsEr40FoRmAt mkfs id: 0xec510fa flushes: 0 blocks: 78142160 free blocks: 55682233 root block: 441728 tail policy: 0x2 (smart) next oid: 0x12735 file count: 164 tree height: 3 key policy: LARGE CHECKING THE STORAGE TREE Read nodes 65 Nodes left in the tree 65 Leaves of them 36, Twigs of them 28 Time interval: Tue May 5 19:10:05 2009 - Tue May 5 19:10:05 2009 CHECKING EXTENT REGIONS. Read twigs 28 Time interval: Tue May 5 19:10:05 2009 - Tue May 5 19:10:05 2009 LOOKING FOR UNCONNECTED NODES Read nodes 3 Good nodes 3 Leaves of them 2, Twigs of them 1 Time interval: Tue May 5 19:10:06 2009 - Tue May 5 19:10:06 2009 CHECKING EXTENT REGIONS. Read twigs 1 Time interval: Tue May 5 19:10:06 2009 - Tue May 5 19:10:06 2009 INSERTING UNCONNECTED NODES 1. Twigs: done 2. Twigs by item: done 3. Leaves: done 4. Leaves by item: done Twigs: read 1, inserted 0, by item 0, empty 1 Leaves: read 2, inserted 0, by item 2 Time interval: Tue May 5 19:10:08 2009 - Tue May 5 19:10:08 2009 CHECKING THE SEMANTIC TREE FSCK: semantic.c: 705: repair_semantic_lost_prepare: No 'lost+found' entry found. Building a new object with the key 2a:0:ffff. FSCK: semantic.c: 573: repair_semantic_dir_open: Failed to recognize the plugin for the directory [2a:0:ffff]. FSCK: semantic.c: 581: repair_semantic_dir_open: Trying to recover the directory [2a:0:ffff] with the default plugin--dir40. FSCK: obj40_repair.c: 576: obj40_prepare_stat: The file [2a:0:ffff] does not have a StatData item. Creating a new one. Plugin dir40. FSCK: dir40_repair.c: 40: dir40_dot: Directory [2a:0:ffff]: The entry "." is not found. Insert a new one. Plugin (dir40). FSCK: obj40_repair.c: 223: obj40_stat_unix_check: Node (444094), item (2), [2a:0:ffff] (stat40): wrong bytes (0), Fixed to (50). FSCK: obj40_repair.c: 350: obj40_stat_lw_check: Node (444094), item (2), [2a:0:ffff] (stat40): wrong size (0), Fixed to (1). Found 147 objects. Time interval: Tue May 5 19:10:08 2009 - Tue May 5 19:10:08 2009 CLEANING UP THE STORAGE TREE Removed items 0 Time interval: Tue May 5 19:10:08 2009 - Tue May 5 19:10:08 2009 FSCK: repair.c: 677: repair_update: File count 164 is wrong. Fixed to 147. ***** fsck.reiser4 finished at Tue May 5 19:10:08 2009 Closing fs...done The filesystem was mounted RO. It is better to umount and mount it again. FS is consistent.
V případě že na tomto diskovém oddíle je již vše OK, vypadá výsledek kontroly takto:
root@stroj:~# reiser4 /dev/sdb1 ******************************************************************* This is an EXPERIMENTAL version of fsck.reiser4. Read README first. ******************************************************************* Fscking the /dev/sdb1 block device. Will check the consistency of the Reiser4 SuperBlock. Will check the consistency of the Reiser4 FileSystem. Continue? (Yes/No): Yes ***** fsck.reiser4 started at Tue May 5 19:13:02 2009 Reiser4 fs was detected on /dev/sdb1. Master super block (16): magic: ReIsEr4 blksize: 4096 format: 0x0 (format40) uuid: 7de3bb64-05c6-4bd8-bb4e-a76665fb0000 label: <none> Format super block (17): plugin: format40 description: Disk-format plugin. version: 0 magic: ReIsEr40FoRmAt mkfs id: 0xec510fa flushes: 0 blocks: 78142160 free blocks: 55682235 root block: 441728 tail policy: 0x2 (smart) next oid: 0x12763 file count: 147 tree height: 3 key policy: LARGE CHECKING THE STORAGE TREE Read nodes 65 Nodes left in the tree 65 Leaves of them 36, Twigs of them 28 Time interval: Tue May 5 19:13:03 2009 - Tue May 5 19:13:03 2009 CHECKING EXTENT REGIONS. Read twigs 28 Time interval: Tue May 5 19:13:03 2009 - Tue May 5 19:13:03 2009 CHECKING THE SEMANTIC TREE Found 147 objects (some could be encountered more then once). Time interval: Tue May 5 19:13:03 2009 - Tue May 5 19:13:03 2009 ***** fsck.reiser4 finished at Tue May 5 19:13:03 2009 Closing fs...done FS is consistent.
Oprava diskových oddílů virtuálních disků VMware
Používáte-li virtualizaci, může se stát, že narazíte na problém s poškozeným souborovým systémen na virtuálním disku. S uplatněním výše uvedených technik jej můžete opravit, aniž by bylo nutné virtuální stroj spouštět.
Nezapomínejte na vytvoření zálohy!!!
Než začnete s diskem pracovat, vytvořte jeho kopii pomocí konverzního nástroje vmware-vdiskmanager a pomocí mountovací utility vmware-mount zjistěte potřebný offset, tj. od kterého sektoru začíná diskový oddíl, který potřebujete opravit. Dále pak pracujte již pouze s touto kopií.
root@stroj:~# vmware-vdiskmanager -r virtuální_disk.vmdk -t 0 temporary.vmdk root@stroj:~# vmware-mount -p temporary.vmdk Nr Start Size Type Id Sytem -- ---------- ---------- ---- -- ------------------------ 1 63 176652 BIOS 83 Linux 2 176715 514080 BIOS 83 Linux 3 690795 5590620 BIOS 83 Linux
Aby bylo možné pracovat s virtuálním diskem, jako by šlo o kopii disku vytvořenou pomocí utility dd, je třeba připojit virtuální disk jako tzv. flat disk. Po jeho připojení se v přípojném bodě objeví soubor s názvem flat
, se kterým lze dále pracovat.
root@stroj:~# vmware-mount -f temporary.vmdk /přípojný_bod root@stroj:~# ls /přípojný_bod /přípojný_bod/flat
Nyní přichází řada na tzv. loop zařízení. Pro práci s loop zařízeními je určen nástroj losetup. Ten umožňuje jejich vytváření i rušení. Z výše uvedeného výpisu víme, že diský oddíl, který nás zajímá, začíná 690795. sektorem. Obvyklá velikost jednoho sektoru je 512 bajtů, a jelikož se velikost offsetu udává v bajtech, vynásobíme počet sektorů velikostí jednoho sektoru a výslednou hodnotu použijeme jako offset.
root@stroj:~# echo $((690795*512)) 353687040 root@stroj:~# losetup -a root@stroj:~# losetup /dev/loop4 -o 353687040 /přípojný_bod/flat root@stroj:~# file -s /dev/loop4 /dev/loop4: ReiserFS V3.6
S vytvořeným zařízením /dev/loop4
pak již můžeme pracovat jako s normálním blokovým zařízením.
root@stroj:~# fsck --rebuild-tree /dev/loop4 reiserfsck 3.6.21 (2009 www.namesys.com) ************************************************************* ** Do not run the program with --rebuild-tree unless ** ** something is broken and MAKE A BACKUP before using it. ** ** If you have bad sectors on a drive it is usually a bad ** ** idea to continue using it. Then you probably should get ** ** a working hard drive, copy the file system from the bad ** ** drive to the good one -- dd_rescue is a good tool for ** ** that -- and only then run this program. ** ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to reiserfs-list@namesys.com, ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** ************************************************************* Will rebuild the filesystem (/dev/loop4) tree Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes Replaying journal: Done. Reiserfs journal '/dev/loop4' in blocks [18..8211]: 0 transactions replayed ########### reiserfsck --rebuild-tree started at Mon May 25 19:41:49 2009 ########### Pass 0: ####### Pass 0 ####### Loading on-disk bitmap .. ok, 368445 blocks marked used Skipping 8232 blocks (super block, journal, bitmaps) 360213 blocks will be read 0%..pass0: block 98459, item 5: The file [461787 461858] has the wrong mode (?---------), corrected to (----------) ..20%....40%....60%....80%....100% 100032 directory entries were hashed with "r5" hash. "r5" hash is selected Flushing..finished Read blocks (but not data blocks) 360213 Leaves among those 20653 - corrected leaves 1 Objectids found 99612 Pass 1 (will try to insert 20653 leaves): ####### Pass 1 ####### Looking for allocable blocks .. finished 0%....20%....40%....60%....80%....100% Flushing..finished 20653 leaves read 20479 inserted 174 not inserted ####### Pass 2 ####### Pass 2: 0%....20%....40%....60%....80%....100% Flushing..finished Leaves inserted item by item 174 Pass 3 (semantic): ####### Pass 3 ######### rebuild_semantic_pass: The entry [43 400670] ("libt1-5.postrm") in directory [16935 17007] points to nowhere - is removed rebuild_semantic_pass: The entry [43 155815] ("libxfont1.postrm") in directory [16935 17007] points to nowhere - is removed rebuild_semantic_pass: The entry [43 155828] ("libxfont1.md5sums") in directory [16935 17007] points to nowhere - is removed rebuild_semantic_pass: The entry [43 155814] ("libxfont1.postinst") in directory [16935 17007] points to nowhere - is removed rebuild_semantic_pass: The entry [47 23400] ("autotools-dev.md5sums") in directory [16935 17007] points to nowhere - is removed rebuild_semantic_pass: The entry [43 400680] ("libt1-5.md5sums") in directory [16935 17007] points to nowhere - is removed vpf-10680: The directory [16935 17007] has the wrong block count in the StatData (180) - corrected to (179) vpf-10650: The directory [16935 17007] has the wrong size in the StatData (91856) - corrected to (91640) vpf-10670: The file [461787 461858] has the wrong size in the StatData (0) - corrected to (118784) The object [461787 461857] has wrong mode (?---------) - corrected to -rw------- vpf-10670: The file [461787 461857] has the wrong size in the StatData (0) - corrected to (104) vpf-10680: The file [461787 461857] has the wrong block count in the StatData (0) - corrected to (8) The object [461787 461859] has wrong mode (?---------) - corrected to -rw------- vpf-10670: The file [461787 461859] has the wrong size in the StatData (0) - corrected to (1264) vpf-10680: The file [461787 461859] has the wrong block count in the StatData (0) - corrected to (8) The object [461787 461856] has wrong mode (?---------) - corrected to -rw------- vpf-10670: The file [461787 461856] has the wrong size in the StatData (0) - corrected to (352) vpf-10680: The file [461787 461856] has the wrong block count in the StatData (0) - corrected to (8) rebuild_semantic_pass: The entry [34134 18289] ("Template.pm") in directory [34102 34134] points to nowhere - is removed rebuild_semantic_pass: The entry [34134 18507] ("AutoSelect.pm") in directory [34102 34134] points to nowhere - is removed vpf-10680: The file [34134 18256] has the wrong block count in the StatData (8) - corrected to (0) vpf-10650: The directory [34102 34134] has the wrong size in the StatData (712) - corrected to (648) Flushing..finished Files found: 80440 Directories found: 8080 Symlinks found: 5103 Others: 5918 Files with fixed size: 4 Names pointing to nowhere (removed): 8 Pass 3a (looking for lost dir/files): ####### Pass 3a (lost+found pass) ######### Looking for lost directories: Looking for lost files: Flushing..finished Objects without names 7 Files linked to /lost+found 7 Pass 4 - finished Deleted unreachable items 3 Flushing..finished Syncing..finished ########### reiserfsck finished at Mon May 25 19:42:51 2009 ###########
Po opravě disku nezapomeňte zrušit všechna loop zařízení, která pracují s tímto diskem, a teprve pak jej odmountujte.