Cyfnewid cnewyllyn FIPS aeth â'r modiwlau Wi-Fi a VPN gyda hi

Trowch fips-updates ymlaen, ailgychwynnwch, ac mae'r peiriant yn dychwelyd heb ryngwyneb di-wifr tra bod cleient VPN yn gwrthod cychwyn oherwydd bod ei fodiwl cnewyllyn ar goll. Ni chafodd unrhyw beth ei ddadosod yn yr ystyr pecyn arferol, a dyna pam nad yw ailosod y cleient yn newid dim o gwbl. Mae'r peiriant yn rhedeg cnewyllyn na chafodd ei yrwyr eu hadeiladu ar ei gyfer erioed. Dau symptom, un achos, ac mae'r achos i'w weld mewn un orchymyn.

Beth wnaeth yr ailgychwyn ei newid mewn gwirionedd

Mae diweddariadau FIPS Ubuntu Pro yn gosod amrywiad cnewyllyn ardystiedig ac yn ei wneud yn gofnod cychwyn diofyn. Mae'r amrywiad hwnnw'n gnewyllyn go iawn: mae'n cychwyn, mae'n rhedeg, ac mae'n dechrau'r gwasanaethau oedd gennych eisoes. Yr hyn nad yw'n ei gynnwys yw pob modiwl a adeiladwyd ar gyfer y cnewyllyn cyffredinol, gan gynnwys gyrrwr di-wifr a gyfunwyd y tu allan i'r goeden a modiwl twnnel a ddarperir drwy DKMS. Mae'r set o yrwyr yn symud gyda'r cnewyllyn, nid gyda'r rheolwr pecynnau. Felly mae'r caledwedd yn dal yno ac nid yw'r meddalwedd sy'n siarad ag ef.

Cymharwch y cnewyllyn sy'n rhedeg â'r pecynnau sydd wedi'u gosod cyn agor unrhyw osodiad rhwydwaith. Mae'r llinyn fersiwn yn cario marc nad yw'r cnewyllyn cyffredinol yn ei gael, ac mae'r un manylyn hwnnw'n esbonio'r ddau ddarn sydd ar goll.

Darllenwch y cofnod cychwyn hefyd, oherwydd gall peiriant fod â'r cnewyllyn ardystiedig wedi'i osod heb fod yn ei redeg. Yn yr achos hwnnw mae stori'r modiwlau'n hollol wahanol, ac mae'r porthladdoedd a'r gyrwyr roeddech ar fin eu hailosod yn iawn.

Darllenwch gyflwr y modiwlau cyn ffurfwedd y cleient

Mae modiwl na ellir dod o hyd iddo a modiwl sy'n bodoli ond yn gwrthod llwytho yn ddau fai gwahanol â datrysiadau gwahanol. Mae modinfo yn adrodd pa un sydd gennych, ac mae lsmod yn adrodd beth sydd wedi'i lwytho nawr. Gwnewch y ddau cyn cyffwrdd â ffurfwedd y cleient VPN, oherwydd anaml y mae gwall y cleient ei hun yn eu gwahanu.

Mae angen yr un rhaniad ar y rhan ddi-wifr. Mae rhyngwyneb nad yw byth yn ymddangos yn cyfeirio at y gyrrwr, tra bod un sy'n bodoli ond yn aros wedi'i rwystro yn cyfeirio at rfkill neu at y rheolwr rhwydwaith. Mae'r ddau yn edrych yn union yr un fath mewn apled ar y bwrdd gwaith ac yn rhannu dim o dan yr wyneb.

Rhedwch y gwiriadau ar y peiriant ei hun tra bod y fai yn dal yn atgynhyrchadwy. Nid yw allbwn a lapiwyd o westeiwr arall yn cymryd lle hwn.

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

Pan na all modinfo ddod o hyd i'r modiwl o gwbl, ni fydd ailosod y pecyn gofod defnyddiwr yn helpu, oherwydd nid y gofod defnyddiwr oedd y rhan oedd ar goll erioed. Mae'r sylw hwnnw'n arbed awr o drafferth pecynnau ac yn pwyntio'n syth at y cnewyllyn.

Ewch yn ôl mewn trefn sy'n gadael cnewyllyn i chi

Os cafodd FIPS ei alluogi ar gam, mae'r llwybr adfer dogfennol yn analluogi'r gwasanaeth, yn glanhau ei becynnau ac yna'n adfer y cnewyllyn cyffredinol. Nid yw'r drefn yn un addurnol. Mae'r glanhau'n gwrthod parhau pan na all ddod o hyd i gnewyllyn Ubuntu arall, oherwydd byddai tynnu'r unig un yn gadael peiriant na all gychwyn. Y gwiriad hwnnw yw'r gwahaniaeth rhwng camu'n ôl ac ailadeiladu. Dyma hefyd y rheswm y mae'r dilyniant yn methu pan fo'r cnewyllyn cyffredinol eisoes wedi'i dynnu.

Rhedwch ef tra bod y cnewyllyn cyffredinol yn dal wedi'i osod, derbyniwch y rhybudd am dynnu cnewyllyn, ac yna ailgychwynnwch. Yna cadarnhewch nad oes unrhyw becyn FIPS yn aros yn y cyflwr gosodedig a bod y cnewyllyn sy'n rhedeg yr un roeddech yn ei ddisgwyl.

Ar westeiwr o bell, trefnwch fynediad consol neu all-fand yn gyntaf. Mae tynnu cnewyllyn dros SSH yn iawn hyd at yr ailgychwyn nad yw'n dychwelyd.

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

Pan fo'r ardystiad yn ofyniad

Camu'n ôl yw'r cam anghywir pan fo'r ardystiad yn gontractiol, oherwydd yna mae'r peiriant yn gadael y ffurfweddiad y mae'r archwiliad yn ei ddisgrifio. Yn yr achos hwnnw mae'r bwlch gyrrwr yn gwestiwn o ddewis caledwedd: dewiswch addasydd di-wifr y mae ei yrrwr yn dod gyda'r cnewyllyn ardystiedig, derbyniwch beiriant â chebl yn unig, neu symudwch y twnnel i gydran y mae'r cnewyllyn ardystiedig yn ei chefnogi'n barod.

Nid yw adeiladu modiwl y tu allan i'r goeden i mewn i'r cnewyllyn ardystiedig yn ddatrysiad niwtral. Mae'n newid yr hyn y mae'r cnewyllyn yn ei weithredu, a dyna'n union yr eiddo y mae'r ardystiad yn ei ddisgrifio.

Cofnodwch y penderfyniad gydag enw'r perchennog wrth ei ochr, oherwydd bydd y cais i wneud i'r Wi-Fi weithio'n unig yn dychwelyd mewn ychydig fisoedd â llai o gyd-destun. Mae nodyn byr nawr yn atal yr un ddadl yn ddiweddarach.

Gwiriwch y pentwr mewn haenau ar ôl y newid

Ar ôl y camu'n ôl neu'r newid caledwedd, gwiriwch o'r gwaelod i fyny yn lle o'r cleient VPN i lawr. Rhaid i'r rhyngwyneb fodoli, rhaid i'r cyswllt fod i fyny, rhaid i'r datryswr weithio, a dim ond wedyn y mae'r twnnel yn bwysig. Mae pob haen yn methu â'i neges ei hun, ac mae eu darllen mewn trefn yn cadw'r diagnosis yn onest.

Mae cyflwr DNS dros ben o'r cychwyn blaenorol yn bositif ffug cyffredin, felly darllenwch y datryswr cyn dod i'r casgliad bod y twnnel wedi torri.

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

Os bydd y twnnel yn dal i fethu unwaith y bydd y cnewyllyn yn ôl, darllenwch y cam sy'n methu yn lle llinell grynodeb y cleient. Mae modiwl na lwythwyd byth, tystysgrif a wrthodwyd gan y cyfoed a chredensial a wrthodwyd gan y gweinydd yn dri phroblem ar wahân, ac ni fydd ailgychwyn yn eu gwahaniaethu ar eich rhan. Cofnodwch enw'r cam yn y tocyn, a bydd y peiriannydd nesaf yn dechrau lle gwnaethoch chi stopio.