Vím, že už nějaké zápisky na toto téma vyšly, ale i tak jsem se rozhodl, že se podělím o zkušenost, jak se v systému Fedora Silverblue dají pěkně hledat regrese.

Můj pracovní notebook Dell XPS 13 Plus má IPU6 webkameru od Intelu. Ta stále nemá upstreamové ovladače a proto musím používat balíčky z RPMFusion, které obsahují softwarový stack od Intelu, který fungování webkamery zajišťuje.

V pondělí jsem ale zjistil, že webkamera nefunguje. Minulý týden ještě fungovala a já neměl vůbec představu, co ji mohlo rozbít. Aktualizacím nevěnuji pozornost. Automaticky se připraví a při dalším bootu jsou aplikované. Naštěstí používám Fedora Silverblue, kde se dají problémy hledat pěkně metodou rozdělování intervalu.

Silverblue používá OSTree, což by se ve zkratce dalo označit za git pro operační systém. Každá verze Fedory je jedna větev a jednotlivé snapshoty jsou commity. Systém aktualizujete tak, že se posunujete na novější commity. Upgradujte pak tak, že přepnete na větev s novou verzí. Silverblue vytváří snapshoty denně a jelikož OSTree vám umožňuje se vracet k libovolnému commitu v repozitáři, můžete systém vrátit do stavu k libovolnému datu.

Rozhodl jsem se vracet se do předchozích stavů a zjistit, kdy k regresi došlo. Stáhl jsem si tedy metadata o commitech za posledních 7 dní:

sudo ostree pull --commit-metadata-only --depth 7 fedora fedora/39/x86_64/silverblue

Pak jsem si nechal vypsat seznam commitů, abych zjistil, jaké mají označení a hash:

sudo ostree log fedora:fedora/39/x86_64/silverblue

Následně jsem systém vrátil na začátek minulého týdne:

rpm-ostree deploy 39.20240205.0

Rebootoval jsem a zjistil jsem, že webkamera funguje a něco ji opravdu rozbilo minulý týden. Rozhodl jsem se tedy přepůlit interval a vrátit se do středy:

rpm-ostree deploy 39.20240207.0

Ve středečním snapshotu webkamera už nefungovala. Teď už jen stačilo zjistit, jestli ji rozbila už úterní nebo až středeční aktualizace. Nasadil jsem tedy úterní snapshot:

rpm-ostree deploy 39.20240206.0

Jak jsem zjistil, v něm webkamera ještě fungovala. Rozbila ji tedy středeční aktualizace a potřeboval jsem zjistit, jaké balíčky se v ní změnily. Na identifikaci commitů jsem použil hashe z výpisu výše:

rpm-ostree db diff ec2ea04c87913e2a69e71afbbf091ca774bd085530bd4103296e4621a98fc835 fc6cf46319451122df856b59cab82ea4650e9d32ea4bd2fc5d1028107c7ab912

ostree diff commit from: ec2ea04c87913e2a69e71afbbf091ca774bd085530bd4103296e4621a98fc835
ostree diff commit to: fc6cf46319451122df856b59cab82ea4650e9d32ea4bd2fc5d1028107c7ab912
Upgraded:
kernel 6.6.14-200.fc39 -> 6.7.3-200.fc39
kernel-core 6.6.14-200.fc39 -> 6.7.3-200.fc39
kernel-modules 6.6.14-200.fc39 -> 6.7.3-200.fc39
kernel-modules-core 6.6.14-200.fc39 -> 6.7.3-200.fc39
kernel-modules-extra 6.6.14-200.fc39 -> 6.7.3-200.fc39
llvm-libs 17.0.6-2.fc39 -> 17.0.6-3.fc39
mesa-dri-drivers 23.3.4-1.fc39 -> 23.3.5-1.fc39
mesa-filesystem 23.3.4-1.fc39 -> 23.3.5-1.fc39
mesa-libEGL 23.3.4-1.fc39 -> 23.3.5-1.fc39
mesa-libGL 23.3.4-1.fc39 -> 23.3.5-1.fc39
mesa-libgbm 23.3.4-1.fc39 -> 23.3.5-1.fc39
mesa-libglapi 23.3.4-1.fc39 -> 23.3.5-1.fc39
mesa-libxatracker 23.3.4-1.fc39 -> 23.3.5-1.fc39
mesa-va-drivers 23.3.4-1.fc39 -> 23.3.5-1.fc39
mesa-vulkan-drivers 23.3.4-1.fc39 -> 23.3.5-1.fc39
qadwaitadecorations-qt5 0.1.3-5.fc39 -> 0.1.4-1.fc39
uresourced 0.5.3-5.fc39 -> 0.5.4-1.fc39

Aktualizace kernelu z 6.6 na 6.7 je tady logickým podezřelým. Napsal jsem tedy kolegovi, který se o balíčky s podporou IPU6 webkamer v RPMFusion stará, že kernel 6.7 mi podporu webkamery rozbil. Ten se mě zeptal na model a následně mi odpověděl, že obsahuje Intel VSC čip, který má v 6.7 nově ovladač, ale ten poskytuje také softwarový stack od Intelu v balíčcích z RPMFusion a vzniká konflikt. Požádal tedy správce kernelu ve Fedoře, aby ovladač pro Intel VSC prozatím zakázal. A tahle změna přijde s další aktualizací kernelu.

Dokud aktualizace nedorazí, rozhodl jsem se zůstat na posledním funkčním snapshotu z minulého úterý. A za tímto účelem jsem si ho v OSTree připnul. Jelikož jsem ho měl zrovna nabootovaný, stačilo:

sudo ostree admin pin 0

A to je vše. Jen taková malá ukázka z reálného života, jak se dá v Silverblue najít, kdy a co způsobilo regresi, a jak se dá jednoduše vrátit k verzi systému před touto regresí a zůstat na ní, dokud nedorazí oprava.