Portál AbcLinuxu, 6. května 2025 01:03
1.6.2007 13:45
| Přečteno: 1616×
| Za vším hledej Linux
|
Minule jsem vyjádřil pochybnost nad tím, zda tohle moje dráždění hada bosou nohou bude mít nějaké pokračování, a jak se zdá asi bude ještě nejmíň jedno, protože jsem se stále ještě nedostal k přislíbené kompilaci instalaci vmware a ovladačů ATI. V tomto kuse se rozmazávám o problémech s balíčky.
Jak už bylo zmíněno minule, základem úspěchu je bezproblémový kompilátor odpovídající pokud možno tomu s nímž bylo kompilováno jádro. Ale jak ukázala moje zkušenost posledních dnů, někdy může vězet záludná chyba tam, kde byste ji čekali ze všeho nejmíň. Pokud se tedy chcete vyhnout řešení nepříjemných problémů způsobených aktualizací klíčových balíků naučte se používat nastavení "politiky".
Pokud chcete používat Debian unstable, musíte přijmout fakt, že občas může vzniknout nějaký problém a instalačními balíky a ty nejčastější byste se měli naučit řešit. Hned zkraje bych však chtěl dát jednu dobrou radu: Odkládejte si stažené instalační balíky někam stranou a nemažte je. Mohou se hodit..
Mezi nejčastější problémy lze zařadit selhávající aktualizaci. Často se stává, že během generování indexu pro repository ještě do ní nejsou uploadnuté všechny balíky1), nebo naopak, vygenerovaný index byl zkopírován do cílové repository dřív než balík2). Obvykle stačí zkusit aktualizaci o něco později, až jsou do repository uploadnuty všechny balíky pro které je vygenerován index, nebo až je vygenerován nový index.
Občas se však stává, že některý balík "visí" aniž by jej bylo možno aktualizovat delší čas. Nejprve si ověřte zda chybějící balík není v jiné repository, pro kterou máte nastavenu nižší prioritu3). Pokud ani tam není, tak se jej můžete pokusit rekompilovat za zdrojového balíčku. Rekompilace ale může pochopitelně selhat, a to nejčastěji z těchto důvodů:
Někdy je to chybou v kódu aplikace, kterou "maitainer" balíku sice opravil, zkompiloval binární balíček, ale již opomněl vytvořit také příslušný zdrojový balík, takže se vám rekompilace nemusí podařit celá ale výsledkem je pouze část balíků.
Stává se také, že si "maintainer" balíku neověřil, že je pro kompilaci jeho balíku vyžadována knihovna co není standardní součástí distribuce pro kterou je balík určen.
U některých balíků se mohou stát problémem i nedbale uvedené závislosti. A to tehdy, pokud si "maintainer" neověřil, že některý ze závislých balíků má již změněné jméno. Někdy však dojde k nahrazení některého ze závislých balíčků novou - jinak označenou - verzí časem. V takovém případě většinou stačí opravit příslušný záznam před samotnou rekompilací rozbaleného zdrojového balíku v souboru debian/control
Samozřejmě že u balíků z experimentalu se mohou také objevit i jiné chyby. Ale konec konců je to přeci experimental, ne? 
Většinu z nich lze s trochou zkušeností odhalit a jejich reportováním můžete pomoci maintainerovi s opravou. Bohužel někdy je upozorňování maitainera srovnatelné s příslovečným házením hrachu na zeď (typicky problém s českými UTF-8 locales pro libc6-2.5 knihovnu na amd64)
Čas od času se stane, že do distribuce prosákne i vyloženě vadný balík, který se pak stane příčinou záhadných problémů, než na něj kápnete vy, nebo někdo jiný. Chyba může být specifická pro určitou platformu, tzn. že se může projevovat jen na určité architektuře, takže než se na ni přijde může docela trvat. Také se může stát,že se poškodí některý soubor na vašem disku, aniž byste to vůbec tušili. A to je přesně ta chvíle kdy se hodí odložené balíky, neboť vadný balík můžete přeinstalovat, nebo nainstalovat zpátky na starší bezproblémovou verzi. V poslední době jsem si takhle užil s balíkem module-init-tools verze 3.3-pre11-1_amd64.deb, který způsoboval problém se souborem insmod. Pokud byl spuštěn bez plné cesty, skončilo zavedení jaderného modulu chybou, jinak byl v pořádku. Vcelku drobná lapálie, ale díky ní mi nešly zkompilovat moduly pro vmware a já jako moula kompiloval jádro stokrát jinak, neboť mi vmware tvrdil něco o rozdílné verzi kompilovaného modulu a jádra. Teprve až mě napadlo zkusit si vypsat help pro příkaz "ismod" a na mě vyskočila tahle chyba se segfaultem...
unstable:~# insmod [14317011.288298] insmod[9280]: segfault at 0000000000000000000 rip 00002afd70f2d27b rsp 00007fff39e10a08 error 4 Neoprávněný přístup do paměti (SIGSEGV) unstable:~# /sbin/insmod Usage: /sbin/insmod filename [args]... jsem pojal podezření. Takže jsem je přeinstaloval zpět na verzi
3.3-pre4-2_amd64.deb a jako mávnutím kouzelného proutku vše opět fungovalo jak má.
Mohl jsem celou záležitost odbýt zafixováním funkčního balíku pomocí politiky, ale nedalo mi to a kouknul jsem se jestli něco o té chybě nenajdu na webu. A taky že jo. Stačilo pak přidat jeden patch k balíku, rekompilovat novější balík je už ok4.
Poznámky na okraj:
1, V tomto případě APT o požadovaném balíku ještě nemá žádnou informaci, přestože se tento již v repository vyskytuje. To se může stát v případě že je pro web nasdílena výchozí repository, pro kterou se index generuje.
2, Tato varianta se vyskytuje zpravidla u mirrorů. Ačkoliv APT nabízí balík k aktualizaci, v repository se ještě nevyskytuje a při pokusu o jeho stažení APT skončí chybou.
3, Nastavení priority je dáno jednak nastavením politiky, ale také pořadím zdroje v souboru sources.list (repository která je v tomto souboru umístěna "výš" má vyšší přednost).
4, Pokud chcete, tak si zkompilovaný binární balík pro amd64 můžete stáhnout ev. sami rekompilovat ze zdrojového balíčku, který je rovněž přiložen.
Tiskni
Sdílej:
1.6.2007 21:38
houska | skóre: 41
| blog: HW
4.6.2007 09:26
houska | skóre: 41
| blog: HW
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.