FIPS-kärnbytet tog Wi-Fi- och VPN-modulerna med sig

Slå på fips-updates, starta om, och maskinen kommer tillbaka utan trådlöst gränssnitt medan VPN-klienten vägrar starta eftersom dess kärnmodul saknas. Ingenting avinstallerades i vanlig paketbemärkelse, och det är därför ominstallation av klienten inte ändrar någonting alls. Maskinen kör en kärna som dess drivrutiner aldrig byggdes för. Två symtom, en orsak, och orsaken syns i ett enda kommando.

Vad omstarten faktiskt bytte

FIPS-uppdateringarna i Ubuntu Pro installerar en certifierad kärnvariant och gör den till standardstartpost. Den varianten är en riktig kärna: den startar, den körs och den startar de tjänster du redan hade. Det den inte innehåller är varje modul byggd för den generiska kärnan, inklusive en trådlös drivrutin kompilerad utanför trädet och en tunnelmodul som levereras via DKMS. Drivrutinsuppsättningen flyttar med kärnan, inte med pakethanteraren. Så hårdvaran finns kvar och programvaran som talar med den gör det inte.

Jämför den körande kärnan med de installerade paketen innan du öppnar någon nätverksinställning. Versionssträngen bär en markering som den generiska kärnan inte har, och den enda detaljen förklarar båda de saknade delarna.

Läs också startposten, eftersom en maskin kan ha den certifierade kärnan installerad utan att köra den. I så fall är modulhistorien helt annorlunda, och de portar och drivrutiner du var på väg att installera om är i ordning.

Läs modulstatusen före klientkonfigurationen

En modul som inte kan hittas och en modul som finns men vägrar laddas är två olika fel med olika åtgärder. modinfo rapporterar vilken du har, och lsmod rapporterar vad som är laddat just nu. Gör båda innan du rör VPN-klientens konfiguration, eftersom klientens eget fel sällan skiljer dem åt.

Den trådlösa delen behöver samma uppdelning. Ett gränssnitt som aldrig dyker upp pekar på drivrutinen, medan ett som finns men förblir blockerat pekar på rfkill eller på nätverkshanteraren. De två ser likadana ut i en skrivbordsapplet och delar ingenting under ytan.

Kör kontrollerna på maskinen själv medan felet fortfarande går att återskapa. Utdata inklistrad från en annan värd ersätter inte denna.

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

När modinfo inte hittar modulen alls hjälper det inte att installera om användarrymdspaketet, eftersom användarrymden aldrig var den saknade delen. Den observationen sparar en timme av paketkrångel och pekar rakt på kärnan.

Rulla tillbaka i en ordning som lämnar dig en kärna

Om FIPS slogs på av misstag inaktiverar den dokumenterade återställningsvägen tjänsten, rensar bort dess paket och återställer sedan den generiska kärnan. Ordningen är inte kosmetisk. Borttagningen vägrar fortsätta när den inte hittar en annan Ubuntu-kärna, eftersom att ta bort den enda skulle lämna en maskin som inte startar. Den kontrollen är skillnaden mellan en återrullning och en ombyggnad. Det är också anledningen till att sekvensen misslyckas när den generiska kärnan redan har tagits bort.

Kör den medan den generiska kärnan fortfarande är installerad, acceptera varningen om att ta bort en kärna och starta om efteråt. Bekräfta sedan att inget FIPS-paket finns kvar i installerat tillstånd och att kärnan som körs är den du förväntade dig.

På en fjärrvärd, ordna konsol- eller out-of-band-åtkomst först. Att ta bort en kärna över SSH är okej ända fram till den omstart som inte kommer tillbaka.

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

När certifieringen är kravet

Att rulla tillbaka är fel drag när certifieringen är avtalsbunden, eftersom maskinen då lämnar den konfiguration som revisionen beskriver. I så fall är drivrutinsglappet en fråga om hårdvaruval: välj en trådlös adapter vars drivrutin levereras med den certifierade kärnan, acceptera en maskin med bara kabel, eller flytta tunneln till en komponent som den certifierade kärnan redan stöder.

Att bygga en modul utanför trädet in i den certifierade kärnan är inte en neutral lösning. Det ändrar vad kärnan utför, och det är precis den egenskap som certifieringen beskriver.

Skriv ned beslutet med ägarens namn bredvid, eftersom begäran att bara få Wi-Fi att fungera kommer tillbaka om några månader med mindre kontext. En kort anteckning nu förhindrar samma diskussion senare.

Kontrollera stacken lager för lager efter ändringen

Efter återrullningen eller hårdvaruändringen, verifiera nedifrån och upp i stället för från VPN-klienten och ned. Gränssnittet måste finnas, länken måste vara uppe, resolvern måste fungera, och först då spelar tunneln roll. Varje lager misslyckas med sitt eget meddelande, och att läsa dem i ordning håller diagnosen ärlig.

Kvarvarande DNS-tillstånd från föregående start är en vanlig falsk positiv, så läs resolvern innan du drar slutsatsen att tunneln gick sönder.

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

Om tunneln fortfarande misslyckas när kärnan är tillbaka, läs det steg som misslyckas i stället för klientens sammanfattningsrad. En modul som aldrig laddades, ett certifikat som motparten avvisade och en inloggningsuppgift som servern nekade är tre separata problem, och en omstart skiljer dem inte åt för dig. Skriv stegets namn i ärendet, och nästa ingenjör börjar där du slutade.