Замената на јадрото со FIPS ги однесе модулите за Wi-Fi и VPN

Вклучете fips-updates, рестартирајте и машината се враќа без безжичен интерфејс, додека VPN клиентот одбива да стартува зашто му недостига модулот за јадрото. Ништо не било деинсталирано во вообичаената смисла на пакети, и токму затоа повторното инсталирање на клиентот не менува ништо. Машината работи на јадро за кое нејзините драјвери никогаш не биле изградени. Два симптома, една причина, и причината се гледа со една команда.

Што навистина смени рестартот

Ажурирањата по FIPS во Ubuntu Pro инсталираат сертифициран вариант на јадрото и го прават стандарден запис за подигање. Тој вариант е вистинско јадро: се подига, работи и ги стартува услугите што веќе ги имавте. Она што го нема е секој модул изграден за општото јадро, вклучително безжичен драјвер компајлиран надвор од дрвото и тунелски модул доставен преку DKMS. Сетот драјвери се движи со јадрото, не со менаџерот на пакети. Затоа хардверот сѐ уште е тука, а софтверот што зборува со него не е.

Споредете го јадрото што работи со инсталираните пакети пред да отворите било какво мрежно поставување. Низата за верзијата носи ознака што ја нема општото јадро, и тој еден детаљ ги објаснува двата дела што недостасуваат.

Прочитајте го и записот за подигање, зашто машината може да го има сертифицираното јадро инсталирано, а да не го извршува. Во тој случај приказната за модулите е сосема поинаква, и портите и драјверите што сте ги преинсталирале се во ред.

Прочитајте ја состојбата на модулите пред конфигурацијата на клиентот

Модул што не може да се најде и модул што постои но одбива да се вчита се два различни дефекти со различни решенија. modinfo известува кој од двата го имате, а lsmod известува што е вчитано во моментов. Направете го и едното и другото пред да ја допрете конфигурацијата на VPN клиентот, зашто сопствената грешка на клиентот ретко ги раздвојува.

Безжичниот дел бара иста поделба. Интерфејс што никогаш не се појавува упатува на драјверот, додека оној што постои но останува блокиран упатува на rfkill или на менаџерот на мрежа. Двете изгледаат исто во аплет на работната површина и не делат ништо под површината.

Извршете ги проверките на самата машина додека дефектот сѐ уште може да се репродуцира. Излезот прекопиран од друг домаќин не е замена за овој.

uname -r
pro status --all | grep -E 'fips|kernel'
modinfo wireguard 2>&1 | head -3
rfkill list

Кога modinfo воопшто не го наоѓа модулот, повторното инсталирање на пакетот во корисничкиот простор нема да помогне, зашто корисничкиот простор никогаш не бил делот што недостига. Тоа набљудување заштедува еден час мака со пакети и упатува директно на јадрото.

Вратете се назад по ред што ви остава јадро

Ако FIPS бил вклучен по грешка, документираната патека за враќање ја исклучува услугата, ги чисти нејзините пакети и потоа го враќа општото јадро. Редот не е козметика. Чистењето одбива да продолжи кога не наоѓа друго јадро на Ubuntu, зашто отстранувањето на единственото би оставило машина што не може да се подигне. Таа проверка е разликата меѓу враќање и повторна изградба. Таа е и причината зошто редоследот пропаѓа кога општото јадро веќе било отстрането.

Извршете го додека општото јадро е сѐ уште инсталирано, прифатете го предупредувањето за отстранување на јадро и потоа рестартирајте. Потоа потврдете дека не останал ниту еден пакет FIPS во инсталирана состојба и дека јадрото што работи е она што го очекувавте.

На оддалечен домаќин прво обезбедете конзолен или вонпојасен пристап. Отстранувањето на јадро преку SSH е во ред точно до рестартот што не се враќа.

dpkg -l | grep -E 'linux-image|fips'
sudo pro disable fips-updates --purge
sudo apt install --reinstall linux-generic
sudo reboot

Кога сертификацијата е барањето

Враќањето назад е погрешен потег кога сертификацијата е договорна, зашто тогаш машината излегува од конфигурацијата што ја опишува ревизијата. Во тој случај јазот во драјверите е прашање на избор на хардвер: изберете безжичен адаптер чиј драјвер доаѓа со сертифицираното јадро, прифатете машина само со кабел или преместете го тунелот на компонента што сертифицираното јадро веќе ја поддржува.

Изградбата на модул надвор од дрвото во сертифицираното јадро не е неутрално решение. Таа менува што извршува јадрото, и токму тоа својство го опишува сертификацијата.

Запишете ја одлуката со името на сопственикот до неа, зашто барањето само Wi-Fi да работи ќе се врати по неколку месеци со помалку контекст. Кратка белешка сега го спречува истиот спор подоцна.

Проверете го стекот по слоеви по промената

По враќањето или промената на хардверот, проверете од дното нагоре наместо од VPN клиентот надолу. Интерфејсот мора да постои, врската мора да е подигната, резолверот мора да работи и само тогаш тунелот е важен. Секој слој пропаѓа со своја порака, и нивното читање по ред ја држи дијагнозата чесна.

Остаточната DNS состојба од претходното подигање е чест лажен сигнал, затоа прочитајте го резолверот пред да заклучите дека тунелот се расипал.

nmcli device status
ip -brief link
resolvectl status | head -12
systemctl --failed

Ако тунелот сѐ уште пропаѓа откако јадрото се врати, читајте ја фазата што пропаѓа наместо резимето на клиентот. Модул што никогаш не се вчитал, сертификат што го одбила другата страна и акредитив што го одбил серверот се три одделни проблеми, и рестартот нема да ги раздвои наместо вас. Запишете го името на фазата во тикетот, и следниот инженер ќе почне таму каде што вие застанавте.