Aktualizace linuxového systému za běhu

Aktualizace linuxové distribuce je vždy ožehavá záležitost, protože se můžete dostat do stavu, kdy to nepůjde tam, ani zpět. Proto…

Než se pustíte do aktualizace

Vezměte do ruky papír a tužku, abyste si mohli…

1. Udělat poznámky o stávající instalaci. Teprve po důkladném zmapování celého systému, kdy bude jasné:
   • jaká bloková zařízení se používají,
   • jaké jsou na nich souborové systémy a případné subvolume,
   • na jaké přípojné body jsou namountované,
   • jakou má stroj konfiguraci sítě,
   • jestli používá také sdílené adresáře nebo ne,…

   Zkrátka až budete mít poznamenáno vše, co byste mohli dodatečně potřebovat, můžete přikročit k dalšímu bodu, kterým je:

2. Aktualizace systému, nebo zcela nová instalace na jiné blokové zařízení, nebo do jiného subvolume v rámci lokálního souborového systému Btrfs, pomocí aplikace cdebootstrap.

Prostudujte jak funguje váš balíčkovací systém

To, jak dopadne aktualizace za běhu, záleží na tom, jak kvalitní je balíčkovací systém aktualizované distribuce. Balíčkovací systém Debianu APT (Advanced Package Tools), byl navržen velice dobře, protože pracuje s různými stavy balíku a proces instalace přeruší dřív, než nastane tzv. „dependency hell”.

To v jakém stavu se balík nachází lze ihned vidět podle dvojice (či trojice) znaků na začátku řádku, použijete-li na příkazové řádce dpkg -l. A pomocí utility grep tak můžete z výpisu snadno a rychle odfiltrovat z výpisu to co vás zajímá.

Popis všech stavů, ve kterých se může DEB balíček ocitnout je na prvních třech řádcích výpisu dpkg -l | head -3. Jenže to má háček, pokud používáte lokalizovanou konzoli, protože překlad anglických výrazů do češtiny učinil kdosi bez toho, že by si byl vědom toho, co vlastně překládá:

Požadované=Neznámé/Instalovat/Odinstalovat/Vyčistit/Podržet
| Stav=Ne/Instalován/Konfigurační soubory/Rozbalen/Nezkonfigurován/Nekompletní
| instalace/Očekávané spouštěče/Nevyřízené spouštěče
|/ Chyba?=(nic)/Nutná přeinstalace (Stav,Chyba: velké písmeno=chyba)

Originální anglický text se vám zobrazí pokud použijete předtím příkaz unset LANG:

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)

Stavy, zvýrazněné v popisu velkými písmeny se obvykle zobrazují (až na výjimky) malými písmeny, a jsou popsané v následující tabulce:

Požadovaný stav balíku (Desired)			Aktuální stav balíku (Status)
Neznámý	u	n	Nenainstalovaný
Nainstalovaný	i	i	Nainstalovaný a zkonfigurovaný
Odinstalovaný	r	c	Odinstalovaný, ale konfigurace k balíku je zachovaná
Kompletně odinstalovaný	p	U	Nerozbalený
Nezkonfigurovaný	h	F	Konfigurační proces nebyl z nějakého důvodu dokončen
		h	Instalační proces byl z nějakého důvodu přerušen
		W	Instalační proces čeká na to, až bude dokončena instalace balíku, na kterém je závislý
		t	Na dokončení instalace balíčku závisí jiný balík

Za určitých okolností, se může objevit ještě třetí znak R, který signalizuje, že některý ze souborů z balíku byl poškozen, a tak musí být balík reinstalován.

Obvykle se balík vyskytuje v některém z následujících stavů:

1. Balík je k dispozici, nenainstalován : Lze stáhnout informace o závislostech nutných pro instalaci balíku a před jeho vlastní instalací doplnit chybějící balíky. Takový balík se ve výpisu dpkg vůbec nezobrazuje.
2. Balík je k dispozici, nainstalován, ale nezkonfigurován : Balík je stažen na lokální disk, rozbalený do dočasné pozice a čeká na konfiguraci. Teprve po úspěšné konfiguraci jsou přepsány z dočasné pozice do systému. Řádek takové balíku začíná iF
3. Balík je nainstalován a zkonfigurován : Soubory z balíku jsou zavedeny v systému a konfigurační soubory odpovídajícím způsobem nastaveny. Řádek takové balíku začíná ii
4. Balík je odinstalován, ovšem konfigurační soubory zůstaly zachovány : Během odebrání balíku zůstávají konfigurační soubory zachovány. Tím pádem při aktualizaci (nebo opětné instalaci) systém konfigurační soubory nepřepisuje, ale nabídne více možností, mezi jinými úpravu stávajících. Řádek takové balíku začíná rc
5. Balík je kompletně odinstalován : Balík je odinstalován včetně konfiguračních souborů. Takový balík se ve výpisu dpkg vůbec nezobrazuje.

S těmito stavovými kódy pracovala aplikace aptitude, kterou v současné době nahradil apt, který zastřešuje specializované nástroje s nimiž APT pracuje: dpkg – který pracuje s nainstalovanými balíky apt-get – který pracuje s repozitářem instalačních balíků a nástrojem dpkg apt-cache – který pracuje se seznamy balíků které lze nainstalovat stroj:~# apt-cache search ^meld meld - graphical tool to diff and merge files stroj:~# apt search ^meld Řadí se… Hotovo Fulltextové hledání… Hotovo meld/testing 3.22.1-1 all graphical tool to diff and merge files

Aktualizace systémové vrstvy disklessu

Původní postup, uvedený na této stránce, byl sepsán v lednu 2011, kdy v rámci disklessové infrastruktury DCE ještě nebyl nasazen souborový systém Btrfs, který umožňuje snapshotování na úrovni souborového systému přes Btrfs a neexistoval nástroj systemd-nspawn. U fyzického stroje se tehdy systém instaloval na logické diskové oddíly vytvořené v rámci LVM nad softwarovým MD RAIDem. A k přepnutí do kopie systémového adresáře, určené k aktualizaci se přepínalo přes chroot, stejným způsobem, jak je uvedeno níže.

Jsou dvě možnosti, jakým způsobem lze aktualizovat obsah vrstev sdílených přes NFS.

Ale nejbezpečnější je to v prostředí disklessového virtuálu, poněvadž ten lze v případě nutnosti vzdáleně natvrdo restartovat.

Drobné úskalí představuje pouze to, že mezi systémovým adresářem, sdíleným přes NFS není jenom zapisovatelná vrstva v RAM, ale také jiné vrstvy, bez kterých by aktualizace nemusela být realizovatelná.

Chceme-li tedy aktualizovat systémovou vrstvu sdílenou přes NFS, je potřeba v prvé řadě udělat její snapshot a NFS export upravit tak, aby na stroji, přes který ji budeme aktualizovat, byla dostupná v RW módu.

Následně nastartujeme příslušný virtuál a jdeme na věc.

1. Po přihlášení, si příslušnou vrstvu namountujeme na /mnt, přes NFSv3, s parametrem nolock

# mount -t nfs 192.168.136.6:/srv/105/trixie /mnt

2. a, Máme-li nainstalovaný balík systemd-containers, můžeme si práci zjednodušit tím, že příslušný adresář spustíme v kontejneru:

# systemd-nspawn -D /mnt

Po spuštění budeme upozorněni, že jsme vstoupili do kontejneru, z něhož lze vyskočit přes klávesovou zkratku Ctrl + pravá hranatá závorka a v promptu příkazové řádky se zobrazí jako kořen mnt. A příkaz mount, ukáže že na „kořeni” už není navěšený původní overlay, ale nový, s kořenem v adresáři /run/host/os-release.

2. b, Ale za určitých okolností můžeme z prekérní situace vybruslit, když na to půjdeme tradiční cestou přes chroot. Postupujeme při tom takto:

# mount /dev /mnt/dev -o bind
# mount /proc /mnt/proc -o bind
# mount /sys /mnt/sys -o bind

V tuto chvíli již můžeme zavolat chroot, ale není od věci ještě připojit nové zařízení pts, aby nám nezhavaroval instalační proces nějakého balíku kvůli tomu, že nedostupné konzole.

# mount -t devpts none /mnt/dev/pts -o ptmxmode=0666,newinstance
# chroot /mnt

Na první pohled se nestane nic, ale příkaz mount prozradí, že je na „kořeni” místo původního sendviče navěšený rovnou adresář sdílený přes NFS.

Při použití systemd-nspawn jsem narazil konkrétně na problém s aktualizací knihovny libc6, kdy instalační proces zůstal viset – nejspíš kvůli tomu, že systemd s tou knihovnou pracuje. Po přepnutí přes chroot, stačilo tenhle balík a balíky závislé zkonfigurovat, a po vyskočení z chrootu bylo možné pokračovat v aktualizaci přes systemd-nspawn

3. V tuhle chvíli můžeme konečně přistoupit k aktualizaci balíků. Buď přes apt:

root@mnt:~# apt update
…
root@mnt:~# apt full-upgrade
…
root@mnt:~# apt autoremove

Nebo přes apt-get:

root@mnt:~# apt-get update
…
root@mnt:~# apt-get dist-upgrade
…
root@mnt:~# apt-get autoremove

4. Pokud jsme použili pouze systemd-nspawn, můžeme ukončit práci a kontejner vypnout příkazem exit. V případě, že jsme použili chroot, je potřeba po vyskočení ještě korektně odmountovat pts zařízení a následně i nabindované adresáře:

# umount /mnt/dev/pts 
# umount /mnt/dev
# umount /mnt/proc
# umount /mnt/sys

5. Teprve pak můžeme systémový adresář sdílený přes NFS odmountovat a po zkopírování jádra a vygenerovaného ramdisku na TFTP server, upravit záznam v rámci zavaděče GRUB (je-li to nutné kvůli navýšení verze jádra) a udělat reboot. Kontrolu verze jádra lze provést, ještě před ukončením práce v kontejneru takto:

root@mnt:~# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.6.13-amd64
root@mnt:~# dpkg -l | grep linux-image
ii linux-image-6.6.13-amd64 ...

Jak vidno v tomto případě k navýšení verze jádra nedošlo, takže není potřeba nic měnit. Změny v ramdisku se obvykle týkají jen aplikací v něm spuštěných. Po přepnutí do adresáře připojeného přes NFS už se použijí aktualizované soubory. Jaké verze jádra jsou k dispozici, lze zjistit přes:

root@mnt:~# apt search linux-image

6. Za určitých okolností se ovšem může stát, že se aktualizací systémové vrstvy spuštěný systém rozbije a tím pádem přestane fungovat, nejenom systemctl, ale i jiné řídící příkazy. V takovém případě si lze pomoci vynuceným restartem:

# echo b > /proc/sysrq-trigger 

O tom, že aktualizace proběhla v pořádku se přesvědčíme snadno tím, že zkusíme v restartovaném disklessu udělat nad adresářem, který překryl overlay. Bude-li vše aktuální, apt oznámí že je vše „up to date”