Ztráta /var - nefunkční APT [vyřešeno]

Založil mattyy1hp, 23. 08. 2014, 16:19:29

Předchozí téma - Další téma

mattyy1hp

Zdravím všechny, mám takový problém se ztrátou /var. Měl jsem oddíly vytvořené na dvou discích tímto způsobem:

/ - SSD (/dev/sda1)
/var - HDD (/dev/sdb1)
/home - HDD (/dev/sdb2)
/tmp - ramdisk (tmpfs)


Včera se mi ale podařilo shodit zapnutý notebook ze stolu. HDD začal okamžitě odcházet, začalo to na 12 vadných sektorech, teď je tam něco kolem 6000. Stihl jsem překopírovat obsah /home (nebo aspoň co šlo) na náhradní disk, který jsem potom dal do notebooku místo toho poškozeného, vytvořil jsem na něm nové /home, nové /var a připojil do /etc/fstab. Systém běhá bez problémů, ale bohužel mě nenapadlo překopírovat i /var.

Ukázalo se, že ve /var/lib/dpkg a /var/lib/aptitude se nachází soubory APT, včetně třeba informací o všech nainstalovaných balících. Takže teď nemůžu aktualizovat a Synaptic ukazuje 0 nainstalovaných balíků. Když se pokusím něco nainstalovat, tak to jde, ale systém chce nainstalovat i základní balíky jako dpkg, sudo apod., které tam dávno jsou. Chci se proto zeptat, jestli je nějaký způsob, jak znovu vygenerovat ty ztracené soubory. Především teda asi "/var/lib/dpkg/status", kde by měla být databáze všech balíků.

Něco se mi podařilo najít tady http://qref.sourceforge.net/Debian/reference/ch-package.en.html v sekci "6.3.5 Rescue system after crashing /var", ale odkazovaný soubor "var.tar.gz" už neexistuje.

Potom taky nad tím v 6.3.4 je popsaná přímo obnova "/var/lib/dpkg/status", ale také bez výsledku:
root@mattyy1hp-laptop:/# ls /usr/share/doc | \grep -v [A-Z] | \grep -v '^texmf$' | \grep -v '^debian$' | \awk '{print $1 " install"}' | \dpkg --set-selections
dpkg: chyba: nelze otevřít soubor ,,/var/lib/dpkg/status" s informacemi o balíku pro čtení: Adresář nebo soubor neexistuje
root@mattyy1hp-laptop:/#


Existuje nějaké řešení? Nechce se mi reinstalovávat a všechny nainstalované balíky si v žádném případě nedokážu vybavit (bylo jich kolem 3200). Děkuji za pomoc.
HP Envy DV6 | Core i7 3630QM | 6GB DDR3 | Geforce GT 630M
Debian GNU/Linux Sid (Unstable) 64bit | Gnome Shell

Roman Horník

Nepovažuju za dobrý mít na zvláštním disku /var (a dále /etc, /sbin, /lib aj.), když je systém na nich závislej, to spíš bych viděl na druhým disku třeba /boot, /tmp (při dostatku RAM nemusí bejt na disku, ale může běžet v RAM v tmpfs), /home a /var/www nebo /srv - to je bezpečný.
Ale jinak - zkus si, když to asi APT neumí (nezkoušel jsem), vytvořit prázdnej soubor /var/lib/dpkg/status, a sice příkazem # touch /var/lib/dpkg/status.
Instalace balíků je o rozbalování souborů a složek do určitejch destinací, občas navíc ve vykonávání nějakejch skriptů. Teď si APT myslí, že nemáš nainstalovaný nic, neexistuje způsob, jak by APT podle souborů a složek zjistil, cos měl nainstalovaný, totiž to měl zapsaný akorát v tý databázi, kterou nemáš. Možností je v běžícím systému nainstalovat systém znovu, všechny balíky, cos tam kdy měl. Neboj se toho, buďto se soubory přepíšou stejnou verzí, nebo novější, když už máš Sida. O nic ale nepřijdeš. Akorát, pokud máš třeba v /atakdále (/etc) vlastní modifikace konfiguráků, dpkg se zeptá, jestli je chceš zachovat, nebo jestli je má nahradit výchozíma. Další výhodu má taková reinstalace v tom, že jestliže jsi přišel dejme tomu o nějakou málo používanou nekritickou knihovnu, nebo jestliže byl nějakej takovej soubor poškozenej, tím se de facto opraví nebo doplní.
Debian Sid/Experimental 64bit + Mate Desktop Environment
* CPU: Intel i5 3570
* GPU: NVIDIA GTX650 1GD5
* MB: Lenovo IH61M
* RAM: 16GiB Deutsche Demokratische Republik 3 @ 1600MHz

mattyy1hp

No já mám oddělené /var, /tmp a /home právě kvůli SSD, protože tam dochází k zápisům neustále.

Zkusil jsem tvoji radu. Už to vypadalo, že bude vše v pořádku, instalovaly se znova všechny základní balíky. Pak ale nešly zkonfigurovat, protože údajně chyběl debconf. Při jeho instalaci aptitude poškodilo libc6, takže systém začal selhávat a po restartu už jenom kernel panic. Než to nějak dávat dohromady přes livecd, tak jsem radši přeci jen udělal tu čistou instalaci.

I tak, díky moc za ochotu.
HP Envy DV6 | Core i7 3630QM | 6GB DDR3 | Geforce GT 630M
Debian GNU/Linux Sid (Unstable) 64bit | Gnome Shell

Roman Horník

Když pro EXT4 v /etc/fstab použiješ navíc volby discard a commit=360 (číslo je ve vteřinách; měla by to bejt doba, po který dochází k reálnýmu zápisu na disk), a pro swap, kterej taky může klidně běžet na SSD, použiješ volbu discard. Disku tím dost usnadníš život.
Čistou instalaci bych tam ale radši ponechal, totiž rozchozením nekompletně zazálohovaný instalace můžeš strávit i několik dnů a stejně ten výsledek nemusí bejt úplně dokonalej.
Debian Sid/Experimental 64bit + Mate Desktop Environment
* CPU: Intel i5 3570
* GPU: NVIDIA GTX650 1GD5
* MB: Lenovo IH61M
* RAM: 16GiB Deutsche Demokratische Republik 3 @ 1600MHz

mattyy1hp

Discard používam, kvůli TRIMu. Ale o commit jsem vůbec nevěděl, určitě to taky použiju. I když, pokud to chápu správně, ty informace co se mají zapsat se nashromáždí někde v /tmp nebo v RAM a zapíšou se až po určité době, že? Potom se ale zapíše stále stejné množství informací o stejné velikosti a pokryjí stejné množství sektorů na tom SSD, akorát se zpožděním, nebo ne?

Mám to SSD jenom 32GB (na root stačí, sotva ho zaplním z poloviny), takže se ho snažim maximálně šetřit a když vidim třeba soubor /var/log/messages (a další jemu podobný), tak tam se zapisuje přímo extrémě. Proto se mi pořád zdá lepší nechat /var na HDD. I když po téhle zkušenosti jsem si radši napsal takovej jednodušší 200 řádkový script v Bashi, který automaticky podle potřeby umí zálohovat buď celé /var, jenom logy nebo jenom soubory DPKG a APT přes rsync z HDD na SSD. Rsync by mělo umět doplnit do existující zálohy jenom proběhlé změny, takže když ho nastavim přes Cron aby se spouštěl třeba jednou za týden, tak bych se teoreticky mohl vyhnout podobným problémům, kdyby zas odešel HDD a současně snížit zápisy na minimum.

Tu čistou instalaci tam samozřejmě necham.
HP Envy DV6 | Core i7 3630QM | 6GB DDR3 | Geforce GT 630M
Debian GNU/Linux Sid (Unstable) 64bit | Gnome Shell

Roman Horník

Jo, soubory před zápisem zůstanou v RAM. Vůbec se toho častějšího {zá|pře}pisu na SSD neboj, jednak to není shit jako flashka a jednak interní logika provádí {zá|pře}pisy pokaždý na jiný místo, aby se paměťový buňky moc neošoupaly. Dyť na obyčejnou 16G SDHC flashku (tenkrát stála trojnásobek toho, za kolik mám SSD, a to mám na SSD kapacitu čtyřnásobnou)) jsem fotil a natáčel 4 roky, než začaly umírat paměťový buňky, a to byly desetitisíce fotek a stovky videí, často jsem ty nedobrý promazával, takže k přepisům docházelo často. SSD mívaj rezervní bloky, kdyby náhodou k umírání došlo, a to umírání neprobíhá lavinovým tempem jako když dojde k mechanickýmu poškození povrchu ploten a hlaviček magnetickýho disku. Jestliže nevytvoříš oddíly na celým disku, ale necháš tam pár stovek mega / jednotek giga volnejch, nezformátovanejch, poslouží to jako další rezerva.
Co se Ti do /var/log/messages tak extrémně připisuje? Dyť já tam mám 91 řádků, z toho asi 70 spáchala kamerka, to už syslog je mnohem větší. A ani to nevadí, dochází tam k připisování, tedy to starý na disku zůstane neměnný, ale jednou za čas se k tomu něco připíše, což je neškodný.
K poškození paměťových buněk může dojít prakticky akorát při zápisu, ale, jak je tomu snad u všech paměťovejch médií, při zápisu probíhá verifikace, tedy ověřování. Jestliže dojde k chybě, dojde k relokaci záznamu na zdravý místo a to poškozený se dále nebude používat.
Fakt se nemáš čeho bát ;)
Debian Sid/Experimental 64bit + Mate Desktop Environment
* CPU: Intel i5 3570
* GPU: NVIDIA GTX650 1GD5
* MB: Lenovo IH61M
* RAM: 16GiB Deutsche Demokratische Republik 3 @ 1600MHz

Yontalcar

Citace od: Roman Horník kdy 23. 08. 2014, 19:14:52
neexistuje způsob, jak by APT podle souborů a složek zjistil, cos měl nainstalovaný, totiž to měl zapsaný akorát v tý databázi, kterou nemáš.
to by právě měl dělat ten příkaz
# ls /usr/share/doc | grep -v [A-Z] | grep -v '^texmf$' | grep -v '^debian$' | awk '{print $1 " install"}' | dpkg --set-selections
bo každý balík obsahuje složku /usr/share/doc/název_balíku, ale asi to chcíplo na neexistenci /var/lib/dpkg/status
ale samozřejmě to není úplně spolehlivý a udělal bych potom
# aptitude reinstall ~i
nebo stejně udělal novou instalaci

Citace od: mattyy1hp kdy 25. 08. 2014, 20:25:59
Discard používam, kvůli TRIMu. Ale o commit jsem vůbec nevěděl, určitě to taky použiju. I když, pokud to chápu správně, ty informace co se mají zapsat se nashromáždí někde v /tmp nebo v RAM a zapíšou se až po určité době, že? Potom se ale zapíše stále stejné množství informací o stejné velikosti a pokryjí stejné množství sektorů na tom SSD, akorát se zpožděním, nebo ne?
Pokud se ten soubor v mezičase změní/smaže, tak se na disk vůbec nedostane

Jinak nezapomeňme, že data se dělí na:
a) zálohovaná
b) předem ztracená

/var/lib/dpkg je dobrým kandidátem na zálohu, bo /var/lib/dpkg/info/*.md5sums umožňuje kontrolu nainstalovaných souborů (nejlépe pomocí prográmku debsums)
NB: ASUS X53U; Debian GNU/Linux Sid amd64 (KDE4)


Jen dvě věci jsou nekonečné - vesmír a lidská hloupost. Tím prvním si ovšem nejsem tak jist. - Albert Einstein

mattyy1hp

Po pár dnech mám ve /var/log/messages přes 272 000 řádek. Většinu provádí Conky a gnome-session ( "unknown variable" v podstatě i několikrát za vteřinu - na to se ještě podívam ). A není to jedinný soubor, kam se neustále zapisuje. Takže na umístění /var na SSD si vážně netroufam :)
Necham to takhle s tím zálohovacím scriptem, který mi bude jednou za pár dní synchronizovat /var/lib/dpkg, /var/lib/aptitude a /var/lib/apt n SD kartu kterou mam v notebooku strčenou pořád a nepoužívám ji. Kdyby se to stalo znovu, tak akorát rsyncnu tu zálohu opačným směrem.

Ještě jednou díky za ochotu i vysvětlení některých věcí.
HP Envy DV6 | Core i7 3630QM | 6GB DDR3 | Geforce GT 630M
Debian GNU/Linux Sid (Unstable) 64bit | Gnome Shell