unmerged-bin

dnes 19:02 | Přečteno: 189× | Za vším hledej Linux

A co s tím.

Nepatřím mezi ty, kterým se stýská po spouštění linuxových služeb přes Sysv-rc skripty, i když mi paralelní spouštění procesů, které sebou přineslo systemd, zpočátku komplikovalo život. Protože pro sendvičový systém je hotové požehnání. Už nemusím udržovat pro různé konfigurace specifické verze skriptů, protože symlinky, přes které se služby spouští, jsou v ultratenkých konfiguračních vrstvách, které lze po libosti kombinovat, jako je tomu u stroje D.

Diagnostika v prostředí disklessu

~$ systemctl status
..
~$ systemctl --failed
..

Patří mezi základní diagnostické příkazy co používám, když zjišťuje kde může být problém.

~# cat /run/sandwich
..
~# less /run/nfsroot
..
~# ip addr show
..
~# cat /proc/cmdline
..
~# cat /proc/version
..

Jsou ty ostatní, které lze použít i v ramdisku, když se do spuštěného systému nedá přihlásit, nebo když kernel během spouštění začne panikařit:

1. Vypíše seznam vrstev ze kterých je složen sendvič, který byl namountován (v ramdisku) na přípojný bod /root. Pokud některá z nich chybí, může být chyba buď v konfiguračním souboru, nebo exportu. Proto je třeba zjistit, zda-li není chyba v konfiguraci.
2. Konfigurační soubor se stahuje na základě různých faktorů, ale na klientské stanici je vždy uložen jako tenhle soubor, proto je důležité záhlaví.
3. Hostname přiděluje DHCP server, ale pokud takový konfigurák na serveru není, stáhne se obecná konfigurace podle IPv4 adresy brány.
4. Nejvyšší prioritu však má atribut name=, předaný jako parametr jádra.
5. Nejčastější chybou která se stává, je zavedení jiné verze jádra než je potřeba. Tuhle informaci předává GRUB2. Proto je potřeba v prvé řadě zkontrolovat, jestli se natáhlo správné jádro a správný ramdisk.

Sjednocení adresářů

Přes systemctl a journalctl se řeší prkotiny, závislé většinou na konkrétní HW konfiguraci, takže ani nevím, kdy jsem poprvé zaregistroval ve výpisu řádek na kterém se zobrazuje iritující žluté Tainted: unmerged-bin Na webu jsem se dočetl, že souvisí se slučováním adresářů do /usr/bin, ale State: running svítil zeleně, tak jsem to víc neřešil.

Dostal jsem se k tomu až teď, protože mě to otravné žluté oznámení začalo iritovat už během přípravy nového base vrstvy systému pro laborky, instalované přes cdebootstrap. Očekával jsem že v rámci trixie už tuhle trivialitu vyřešili, ale očividně ne. Tak jsem si udělal malou rekapitulaci stavu na strojích, s nimiž jsem měl poslední dobou co do činění, a setřídil ji podle verze systemd:

  systemd: 252.36-1~deb12u1
   CGroup: /

A:~# ls -ald {/bin,/sbin,/usr/sbin,/usr/bin}
lrwxrwxrwx 1 root root   7 Mar 26  2025 /bin -> usr/bin
lrwxrwxrwx 1 root root   8 Mar 26  2025 /sbin -> usr/sbin
drwxr-xr-x 1 root root 148 Apr 28  2020 /usr/bin
drwxr-xr-x 1 root root 100 Apr  9  2025 /usr/sbin

  systemd: 257.9-1~deb13u1
   CGroup: /

B:~# ls -ald {/bin,/sbin,/usr/sbin,/usr/bin}
lrwxrwxrwx 1 root root     7  9. čec  2025 /bin -> usr/bin
lrwxrwxrwx 1 root root     8  9. čec  2025 /sbin -> usr/sbin
drwxr-xr-x 1 root root 42714 15. kvě 16.38 /usr/bin
lrwxrwxrwx 1 root root     3 27. bře 21.41 /usr/sbin -> bin

  systemd: 257.13-1~deb13u1
  Tainted: unmerged-bin
   CGroup: /

C:~# ls -ald {/bin,/sbin,/usr/sbin,/usr/bin}
lrwxrwxrwx 1 root root     7  2. čec  2025 /bin -> usr/bin
lrwxrwxrwx 1 root root     8  2. čec  2025 /sbin -> usr/sbin
drwxr-xr-x 1 root root 37074 23. čen 13.28 /usr/bin
drwxr-xr-x 1 root root  6308 23. čen 13.25 /usr/sbin

  systemd: 257.13-1~deb13u1
   CGroup: /

D:~# ls -ald {/bin,/sbin,/usr/sbin,/usr/bin}
lrwxrwxrwx 1 root root   7 Jun 10 13:58 /bin -> usr/bin
lrwxrwxrwx 1 root root   7 Jul  8 08:32 /sbin -> usr/bin
drwxr-xr-x 1 root root 148 Apr 28  2020 /usr/bin
lrwxrwxrwx 1 root root   3 Jul  8 08:46 /usr/sbin -> bin

  systemd: 261~rc1-1
  Tainted: unmerged-bin
   CGroup: /

E:~# ls -ald {/bin,/sbin,/usr/sbin,/usr/bin}
lrwxrwxrwx 1 root root     7 10. srp  2025 /bin -> usr/bin
lrwxrwxrwx 1 root root     8 10. srp  2025 /sbin -> usr/sbin
drwxr-xr-x 1 root root 35588 25. kvě 21.57 /usr/bin
drwxr-xr-x 1 root root  5814 25. kvě 21.19 /usr/sbin


  systemd: 260.1-1
  Tainted: unmerged-bin
   CGroup: /

F:~# ls -ald {/bin,/sbin,/usr/sbin,/usr/bin}
lrwxrwxrwx 1 root root     7 20. pro  2022 /bin -> usr/bin
lrwxrwxrwx 1 root root     8 20. pro  2022 /sbin -> usr/sbin
drwxr-xr-x 1 root root 34856  1. dub 22.56 /usr/bin
drwxr-xr-x 1 root root  8324  1. dub 22.56 /usr/sbin

  systemd: 261.1-2
   CGroup: /

G:~$ ls -ald {/bin,/sbin,/usr/sbin,/usr/bin}
lrwxrwxrwx 1 root root      7 26. zář  2022 /bin -> usr/bin
lrwxrwxrwx 1 root root      7  3. čec 17.42 /sbin -> usr/bin
drwxr-xr-x 1 root root 100666  3. čec 17.20 /usr/bin
lrwxrwxrwx 1 root root      3  3. čec 17.51 /usr/sbin -> bin

A – bylo disklessové trixie s 6.5 jádrem, spuštěné loni na jaře
B – je trixie s jádrem 6.12.73+deb13, aktualizované letos na jaře
C – je disklessové trixie s jádrem 6.12.43+deb13, aktualizované loni na podzim
D – je disklessové trixie s jádrem 6.12.86+deb13
E – je forky (sid) s jádrem 7.0.9+deb14, který je na mém domácím desktopu
F – je forky (sid) s jádrem 6.19.8+deb14, který je na mé domácí SSH bráně
G – je forky (sid) s jádrem 6.8.12 co mám na notebooku

Když se ta hláška objevila prvně, přecházel jsem z bookwormu na trixie, což bylo v době, kdy jsem řešil stroj A. Ale stačilo nasypat obsah z adresářů z / do adresářů v /usr, vyrobit symlinky a byl klid.

Podruhé jsem se s ní setkal, při aktualizaci stroje B, kterou jsem začal před aktualizací stroje C, ale dokončil až po ní. Udělal jsem to samé co u stroje A, ale tentokrát to nestačilo. Bylo potřeba do /usr/bin přesunou i obsah /usr/sbin, aby byl systemctl spokojený, proto ty symlinky odkazují /sbin → /usr/sbin → bin

Stroje C, E a F sjednocení teprve čeká. Na experimenty mám stroj G, a když po jeho aktualizaci na mne opět žlutě zasvítilo to iritující oznámení, přistoupil jsem ihned ke sjednocení.

Je zajímavé, že dokud na něm ty symlinky byly stejně jako na stroji B, tak to systemd najíždělo rychleji. Ale když jsem upravil symlink /sbin tak, aby vedl rovnou na /usr/bin, začal ten systemd při startu nějak dlouho přemýšlet. Nicméně nakonec vždy nastartuje, byť s menší prodlevou, takže to dál neřeším.

Proč má smysl u disklessu ty adresáře sjednotit?

Základem stroje D je ten bootstrapovaný stable trixie o kterém jsem už hovořil. Je to base disklessová vrstva, obložená vrstvami iscsi a docker, okořeněná obecnou vrstvou config. Stejnou vrstvu bude využívat i aktualizovaný laboratorní systém určený pro výuku. Díky tomu, že už byla sjednocena se bude zbytek instalovat správně. Pokud bych to neudělal, sypaly by apt ty binárky podle toho, jakou mají uvedenou cestu v balíku.

Problém by tak mohly představovat staré vrstvy, které ještě nejsou sjednoceny, ale pokud je strčím v rámci sendviče až pod „chleba” – to je ta base vrstva – ty symlinky adresáře přerazí.

Sjednocení za běhu

Bylo nutné u virtuálního stroje B, kde nemám přístup na úložiště, pokud ten stroj neběží, ale stejným způsobem jsem řešil i stroj G.

1. Nejdřív jsem nakopíroval obsah z adresářů /bin, /sbin a /usr/sbin do adresáře /bin
2. Pak jsem adresáře /bin, /sbin a /usr/sbin postupně přejmenoval a vyrobil místo nich symlinky
3. Teprve po rebootu, když bylo vše OK, jsem je zrušil.

       

Obrázky

Komentáře