V dnešnej časti budeme aktualizovať systém samotný systém. Ukážeme si aké jednoduché to je, aj ako riešiť problémy s nedostatkom diskovej kapacity aj s konfliktami v závislostiach. Na konci dnešnej kapitoly budeme mať systém, ktorému bude k ukončeniu chýbať len čas potrebný na inštaláciu.

V predchádzajúcich častiach sme si ukázali prípravné body aktualizácie. Išlo o nastavenie repozitátov, dosiahnutie konzistentného stavu distribúcie. Následne sme aktualizovali systémy zypper a yast. Dnes sa začneme venovať bodu 4 t.j. samotnej aktualizácii distribúcie. Zopakujme si ešte, že celý proces aktualizácie sa skladá s niekoľkých krokov.

1. Nastavenie nových repozitárov a zrušenie tých , ktoré nie sú ešte dostupné pre novú verziu
2. Synchronizácia stavu s funkčnými repozitármi – dosiahnutie konzistentného stav
3. Aktualizácia nástrojov na správu aktualizácií
   • Zypper
   • Yet Another Setup Tool
4. Aktualizácia distribúcie s využitím nástroja zypper

Zopakujme si , kde sme skončili minule viď obr. 1

Obr. 1 spustenie programu zypper.

Na obr. 1 vidno príkaz zypper dup, ktorý sa vykonáva s právami administrátora. Následne sa obnovia repozitáre, ktoré sa medzičasom zmenili. Ako vidno z obr. 2 išlo len o repozitáre knižnice Qt verzie 4.5. následne sa načíta zoznam nainštalovaného softvéru na počítači a porovná sa so zoznamom verzií v repozitároch. Program zypper sa pokúsi vyriešiť problémy so závislosťami balíkov. Ak niektoré závislosti nevie program zypper vyriešiť ponúkne možnosti vyriešenia užívateľovi. V našom prípade išlo len 10 automaticky neriešiteľných problémov viď obr. 2. Po zozname problémov nám zypper ponúkne riešenie prvého problému.

Keďže máme nainštalovaný 64-bitový systém spolu s knižnicami umožňujúcimi spustenie 32-bitových aplikácií budú sa vyskytovať balíčky s textom „32bit“ v názve a architektúrou „x86_64“. Architektúra balíčka je vždy uvedená na konci názvu balíčka. Tieto balíčky sú práve knižnice na beh 32-bitových aplikácií na 64-bitovom systéme. Ak je to možné, tak je pri nich preferovanou možnosťou riešenia problémov ponechanie zastaranej verzie, ktorá je vo výpise ako „keep obsolete…“. Preferujeme stav, kde je, čím viac týchto možností. Druhou často ponúkanou možnosťou je inštalácia balíčka s inou architektúrou. Je označená ako „Install … despite inferior architecture“. Niekedy môže pomôcť aj táto voľba, no ňou môžeme niektoré 32-bitové programy znefunkčniť.

e to preto, že moderné procesory architektúry x86 už nie sú ani zďaleka kompatibilná (nahrádzajúce, nahraditeľné) s pôvodnými procesormi i8086/8088 spoločnosti Intel z roku 1978. Niektoré inštrukcie starších procesorov sú zrušené a ich číselný kód (OpCODE) využívajú iné inštrukcie s inou funkciou. Je to ešte komplikovanejšie, keďže hlavný výrobcovia Intel (INTegrated ELectronics) a AMD (Advanced Micro Devices) takto odstraňujú a menia rozdielne OPCODE-y. Minoritní výrobcovia (Intel má podiel asi 81% a AMD asi 18% trhu s x86 CPU, Via technologies má podiel okolo 0,75%, zvyšní ešte menej) robia časť zmien podľa Intelu a časť podľa AMD.

Ponúkaná architektúra i586 je podpora procesorov Intel 80586, ktoré sa začali predávať v roku 1994 pod komerčným názvom Pentium, ale aj AMD K5. Toto je neprijateľné pre použitie, na rozdiel od i686 (AMD K6, nx 6×86,…), ktorá je ešte stále podporovaná aj v najnovších procesoroch Intel Core i3, i5 a i7, ktoré sú de facto 801086, ako aj AMD na prichádzajúcej architektúre Bulldozer (K12 alebo 12h family).

Obr. 2 Začiatok aktualizácie

Po vyriešení prvého konfliktu budeme vyzvaní na riešenie ďalšieho problému až do vyriešenia všetkých. Odporúčame riešiť problémy odstránením balíkov s názvom obsahujúcim „devel“. Ide o balíky na vývoj aplikácií a nie sú potrebné pre úspešnú aktualizáciu. Program/balík Gambas je prostredie pre vývoj programov v jazykoch BASIC a Pascal, ktoré som nevyužíval, a tak som ich tiež odstránil. Program viceplus sme ponechali v starej verzii. Toto môžete urobiť pre každý balíček, ktorého názov sa začína na lib, ak nie je iné riešenie. Začiatkom lib sú označené knižnice využívané inými programami. Ich úplné odstránenie môže viesť k znefunkčneniu systému. Preto treba robiť všetko preto, aby sa neodstránili.

Po vyriešení prvých problémov program opäť skontroluje inštaláciu so zohľadnením zvolených riešení. Tieto zmeny môžu spôsobiť ďalšie konflikty. Ak je nových konfliktov viac ako v predchádzajúcom kroku, tak sme problémy riešili zjavne nesprávne. Ak je problémov porovnateľný počet, tak sme tiež nepostupovali správne. V týchto prípadoch radšej prerušme/ukončme program zypper stlačením dvoch kláves <Ctrl> a <C>, čo sa v Unixe značí ako ^C). Pri jeho opätovnom spustení vyriešme niektoré problémy inak. Ak je počet konfliktov oveľa menší ako v predchádzajúcom kroku skúsime ich vyriešiť. Ak vyriešime všetky problémy zobrazí sa výstup z obr. 3

Obr. 3 Sumarizácia inštalácie

Ako vidno na obr. 3, aktualizovaných bude 3580 balíčkov. To znamená, že nová verzia distribúcie obsahuje ich nové verzie. Keďže sme používali aj vývojové repozitáre, ktoré sme v prvej časti seriálu vypli, bude sa deaktualizovať 1119 balíčkov. To znamená, že sa nainštalujú staršie verzie balíčkov, ktoré sú však lepšie odladené. Aktualizáciou a riešením konfliktov sa nainštaluje 243 nových balíčkov, ktoré doteraz neboli nainštalované, a odinštaluje 457 balíčkov, ktoré už neexistujú v novej verzii distribúcie.

Navyše 314 balíčkov bude preinštalovaných, teda bude nainštalovaná rovnaká verzia balíčka, ale zmenená ich konfigurácia. 822 balíčkov zmení dodávateľa, teda repozitár, v ktorom sa nachádzajú. Záver ich zoznamu je nad sumarizáciou, kde je názov balíčka súčasný repozitár a nový repozitár balíčka. Medzi zmenou repozitára a ostatnými operáciami môže byť prekrytie, teda balíček, ktorý mení verziu môže meniť aj repozitár. Prehľad ostatných zmien si pozrieme posunutím posuvníka v pravej časti okna smerom hore. Ako vidno z počítačovej siete sa stiahne takmer 7GiB dát pričom po nainštalovaní bude distribúcia zaberať na disku o 1,8GiB menej ako súčasná verzia distribúcie. Ak sme si istí správnosťou činností, tak potvrdíme zmeny.

Obr. 4 Licenčná zmluva openSUSE 11.4

Ak obsahujú balíky licenčnú zmluvu, ktorú ste ešte neodsúhlasili, tak je Vám ponúknutá. Na obr. 4 je licenčná zmluva na distribúciu openSUSE 11.4 a na obr. 5 je licenčná zmluva na Adobe Flash player.

Obr. 5 Adobe Flash player

Zmluvy majú niekoľko strán a preto sa na novú stránku dostaneme stlačením medzerníka. Zmluvy je potrebné odsúhlasiť, inak sa daný softvér nenainštaluje. Po udelení súhlasu so všetkými zmluvami sa začne inštalácia viď obr. 6

Obr. 6 Odsúhlasenie zmlúv

Odsúhlasenie zmluvy je síce podmienkou inštalácie, ale nezakladá právo softvér používať. Lebo licenčná zmluva na Slovensku platí len, ak má písomnú formu, teda je podpísaná vlastnoručne, alebo zaručeným elektronickým podpisom oboch strán. To sa odsúhlasením nestalo. Svojho času som mal vytlačené a podpísane všetky zmluvy na Open source softvér, ktorý som používal, no pri upratovaní som ich vyhodil.

Obr. 6 ma usvedčuje, že som vykonal dobrovoľný súhlas s licenciou, a teda potvrdenie zmluvy podpisom je len formálny nedostatok. Pri právnom purizme, by som však bol uznaný za užívateľa nelegálneho softvéru, lebo zmluva nie je podpísaná podľa práva SR. Na druhej strane som podmienky preukázateľne akceptoval. Ako vidno z obr. 6 a obr. 7, najskôr sa balíčky sťahujú na pevný disk počítača a až potom sa budú inštalovať. Na obr. 7 je priebeh získavania balíčkov

Obr. 7 Priebeh získavania balíčkov.

Obr. 8 Problém pri získavaní balíčkov

Počas sťahovania môžu nastať chyby ako vidno z obr. 8. Mohlo ísť o chybu spojenia, a tak sme skúšali pokračovať napr. aj vynechaním balíčka viď obr. 9.

Obr. 9 Problém pri získavaní balíčkov druhá časť

Ako vidno zmena nepomohla. Po tejto skúsenosti sme prerušili aktualizáciu a začali zisťovať príčinu. Najskôr sme sa pokúsili o opätovnú inštaláciu viď obr 10.

Obr. 10 Opätovná inštalácia

Po neúspešnom opakovaní inštalácie sme získali podozrenie, či sa nezaplnil niektorý oddiel pevného disku. Ako vidno z obr 11. tak sme sa nemýlili. Išlo o oddiel často sa meniacich súborov (often varying files) pripájaný do adresára /var.

Obr. 11 Zaplnenie oddielu pevného disku

Obr. 12 Podrobnosti o zaplnení oddielu

Následne sme zisťovali príkazom „du -sh ./*“ v adresári /var, koľko zaberajú jednotlivé adresáre na oddiele „VAR“. Ako vidno z obr. 12, najviac mesta zaberal adresár cache. Druhý najviac zaberajúci adresár bol adresár záznamov o činnosti systému tzv,. logov (/var/log). Najskôr sme sa teda pokúsili vyprázdniť tento adresár, keďže na aktualizáciu nepotrebuje tieto záznamy a po reštarte systému sa záznamy opätovne vytvoria a navyše budú obsahovať len nové záznamy. Na vymazanie sme použili nástroj Midnight Commander (Polnočný veliteľ) viď. obr. 13. Týmto krokom sa uvoľnilo asi 1,2GiB miesta viď obr. 14.

Obr. 13 Podrobnosti o zaplnení oddielu

Obr. 14 Podrobnosti o zaplnení oddielu po uvoľnení miesta

Po tomto kroku sme sa pokúsili opäť spustiť aktualizáciu. Inštalácia opäť zlyhala na nedostatku miesta a tak sme použili „trik“ Adresár /var/cache sme premiestnili na oddiel /home a vytvorili sme symbolický odkaz na tento adresár do adresára /var ako adresár s menom cache. Týmto sa nový adresár tváril ako pôvodný, ale „zmestilo“ sa do neho oveľa viac dát, lebo bol na oddiele, kde bolo viac ako 30GiB voľného miesta.

Trik je to preto, lebo do adresára /var/cache sa umiestňovali súbory balíčkov aktualizácie pred ich inštaláciou. Po tejto zmene už problém nenastal a po dokončení sťahovania súborov, ktoré trvalo asi dve hodiny sa začalo s odinštaláciou nepotrebných balíkov viď obr 15, po ktorej nasledovalo inštalácia , aktualizácia a deaktualizácia balíkov viď obr. 16.

Obr. 15 Deinštalácia balíčkov

Obr. 16 Koniec deinštalácie a inštalácia balíčkov

V tejto časti sme ukázali, ako spustiť inštaláciu, a že jedinými závažnými problémami môže byť nedostatok miesta na disku a nesprávne riešenie problémov so závislosťami balíkov. Prvý problém zvýraznila zmena nastavenia, keďže v predchádzajúcej verzii bolo nastavenie také, že sa balíčky po získaní zo siete ihneď inštalovali, ale nastavenie sa počas prípravy aktualizácie zmenilo tak, že sa najskôr získali všetky balíčky a až potom inštalovali.

Preto nebolo možné použiť metódu odstraňovania balíčkov počas inštalácie, lebo by došlo k rovnakému javu, teda zaplneniu oddielu v rovnakom stave sťahovania balíčkov. Keďže najjednoduchšou možnosťou je uvoľnenie miesta na disku, pokúsili sme sa o to. No uvoľneného miesta nebolo dostatok a tak sa inštalácia dostala do rovnakého stavu nedostatku diskovej kapacity, aj keď v neskoršom štádiu. Druhou možnosťou je premiestenie adresára s balíčkami, ktoré ešte neboli inštalované na oddiel s vyššou kapacitou. Toto problém vyriešilo. Na budúce dokončíme inštaláciu a ukážeme si bežiaci systém.

Poďakovanie:

Táto práca bola podporovaná Agentúrou na podporu výskumu a vývoja na základe zmluvy č. VMSP-II-0034-09