Canonical maakt Meltdown-patches beschikbaar - update

Canonical heeft patches uitgebracht naar aanleiding van de Meltdown- en Spectre-lekken. Er komt geen patch uit voor Ubuntu 17.04, omdat deze versie op 13 januari de status 'end of life' bereikt. Er is een updatepad via versie 17.10.

Canonical heeft updates beschikbaar gemaakt voor Ubuntu-versies 16.04 lts, 17.10 en de hwe- en lts-versies van 14.04. Het is niet mogelijk om de Meltdown-patch via livepatching toe te passen, waardoor een herstart is vereist. Daarnaast zijn ook Ubuntu-patches voor Nvidia-drivers beschikbaar gesteld. Ubuntu is niet de enige distributie die onlangs met updates is gekomen; deze zijn ook te vinden voor Tails in de vorm van versie 3.4. Er is een online overzicht van patches te vinden, dat wordt bijgehouden door Hanno Böck. Intel heeft cpu-microcode vrijgegeven.

Nvidia heeft eerder deze week al patches voor Linux en Windows uitgebracht. Voor Windows-gebruikers met een GeForce-, Quadro- of NVS-gpu maken de patches deel uit van driverversies 390.65 en 386.07, die via de Nvidia-site te downloaden zijn. De Linux-patches zijn te vinden in versies 390.12 en 384.111. Andere getroffen producten van de fabrikant vallen in de Tesla- en Grid-categorieën.

Update, 11 januari: Zoals tweaker Yggdrasil aangeeft, gaat het in deze release alleen om de Meltdown-patches. Mitigations voor Spectre volgen later.

Reacties (70)

[Yggdrasil]

This initial round will address CVE-2017-5754 (aka Meltdown or Variant 3) for x86_64. We will address CVE-2017-5715 and CVE-2017-5753 (aka Spectre or Variant 1 & 2) in a subsequent round.

Als ik het goed begrijp zijn de Spectre kwetsbaarheden dus niet aangepakt in deze patches. Deze komen in een volgende ronde uit.

[Calypso]

Dat was ook mijn gedachte toen ik deze tekst eergisteren las, en ik zie nergens bewijzen die het tegendeel beweren. Dus met andere woorden, deze kernel lijkt alleen de Meltdown problemen aan te pakken; erg jammer, en eigenlijk ook wel triest dat dat niet in 1 keer mee gedaan wordt. Natuurlijk moet er een hoop getest worden, maar het was al een tijdje bekend dat gisteren de problemen geopenbaard zouden gaan worden.

Ik vind persoonlijk de Ubuntu patches gewoon laat komen, valt me erg tegen van ze.

[rbr320]

Spectre is op nog geen enkel systeem gepatcht, niet op Linux, niet op Windows en niet op MacOS. Bovendien zijn de patches die er uiteindelijk gaan komen mitigations en geen fixes. Uiteindelijk is en blijft het een hardware probleem dat niet in software is op te lossen.

Dat Canonical wat laat is met het uitbrengen van hun patches heeft een duidelijke oorzaak. De patch is door het Linux Kernel development team voor kernel 4.15 geschreven. Voor zover ik weet is het ook nog door hen zelf gebackport naar kernel 4.14. Echter worden deze kernel versies in nog geen enkele versie van Ubuntu gebruikt. Canonical heeft dus zelf de patch moeten backporten naar de kernels die ze nog ondersteunen in de diverse versies van Ubuntu die nog niet end-of-life zijn. Zoals je hier kunt lezen gaat het om 7 kernel versies, met elk nog een aantal varianten zoals Low Latency en geoptimaliseerd voor virtual guests. Red Hat/CentOS daarentegen hoeft maar 2 kernels te patchen, die van RHEL/CentOS 6 en RHEL/CentOS 7.

Het is voor Canonical dus simpelweg meer werk en dan hebben we het nog niet eens over issues waar je tegenaan kunt lopen bij het backporten van de patch naar oudere kernel versies.

[AgamemnonZ]

En daarbovenop was er afgesproken dat de kwetsbaarheden op 9 januari pas publiek gemaakt zouden worden (Ubuntu was zelf al eerder ingelicht), maar de informatie kwam al op 3 januari aan het naar boven.

[Kain_niaK]

En nu snap iedereen waarom ze het meltdown genoemd hebben. Het is nog al een hele vervelende bug (of foute implementatie) in CPU's. Moet je je eens voorstellen als je een cloud server huurt die iets met Bitcoin doet en een programma dat op een andere VM draait maar op dezelfde processor kan het geheugen van je Bitcoin programma uitlezen ....

[Corrigan]

Daar is niets triest aan, Spectre update bestaan nog nergens. En de vraag is of dit ook ooit kan.

[Erik-Hendriks]

Dit is volgens mij een patch voor deze exploit. Het probleem met de chips is niet opgelost, je kunt dus een andere exploit schrijven voor dezelfde kwetsbaarheid.
Meltdown is een hardware vulnerability
https://en.m.wikipedia.or...n_(security_vulnerability

[Joshuax8]

Zorg wel dat je kernel 4.4-109 ipv 4.4-108 gebruikt om te voorkomen dat je server/laptop/desktop niet meer boot: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1741934

[Quincy5]

Ik had vanmorgen de auto-update gedaan en nog niet gereboot. Goed dat ik jouw post nog zie, anders had ik misschien ook niet kunnen starten. Ben nu via apt-get dist-upgrade 4.4-109 aan het installeren.

[rbr320]

Als je remote bezig bent vergeet dan ook niet

apt-get purge linux-.*4.4.0-108.*

zodat je zeker weet dat je machine na een reboot niet alsnog probeert de niet werkende kernel te booten.

[mocem]

Vandaag nog een handig script gevonden om meltdown/spectre te testen.
https://www.cyberciti.biz...e-meltdown-vulnerability/

[Reactie gewijzigd door mocem op 25 juli 2024 13:22]

[Chuk]

Vergeet niet dat de meeste OS patches voor deze exploits eerder mitigations zijn en er nog steeds aangeraden wordt om op termijn van CPU te veranderen als je hier 100% safe van wil zijn. Maar voorlopig zijn deze patches your best bet.

[MadEgg]

Het gaat om vrijwel alle CPU's van Intel, inclusief recente. Ik ga niet mijn processor van 1 jaar oud van €400,- vervangen. Microcode is nu juist uitgevonden om bugs in processoren te patchen. Het vereist wel dat de microcode bij elke boot opnieuw wordt ingeladen, maar het is een prima oplossing om niet processoren te deprecaten omdat Intel een fout heeft gemaakt. Als dat wel noodzakelijk zou zijn zouden alle processoren onder garantie vervangen moeten worden.

[Yggdrasil]

Voor zover ik begrepen heb is deze functionaliteit niet via microcode te patchen.

[MadEgg]

Als het niet via microcode te patchen is, neem ik aan dat ik binnenkort een vervangend exemplaar kan aanvragen bij Intel? Er is mij immers 3 jaar fabrieksgarantie beloofd.

[Verwijderd]

Ja, kan je zeker aanvragen; vragen mag altijd.

Maar je gaat niks krijgen van Intel: Intel zegt namelijk dat de CPU's conform specificatie werken. Op de The Register kan je dat volgen. En ook Linus heeft als reactie gezegd "Maar als het conform specificatie werkt, waarom is Intel dan druk bezig"?

[jqv]

Het gaat er niet om wat the register zegt. Het gaat erom wat de Nederlandse wetgeving hierover zegt.
Dat zal nog wel naar voren komen.

En als bepaald kan worden dat de processoren niet goed werken (dus defect zijn), dan zullen de verkopers ervoor moeten zorgen dat de kopers gecompenseerd worden. En dan heb je niets te maken met Intel. Dat is dan het probleem van de verkoper.

[kidde]

Kennelijk is Intels specificatie dat er geen extra controle tussen de ringen is (daardoor kwetsbaar voor Meltdown), en AMD's spec waar die controle er wel is.

Dus de Intel chip heeft een nalatig en kwetsbaar ontwerp, en werkt conform die kwetsbaarheid dus is kwetsbaar voor Meltdown. Als een auto fabrikant een kwetsbaar ontwerp maakt en de airbag drukhouder kan exploderen conform spec, zijn ze nog steeds aansprakelijk voor _alle_ geleden schade!

[Reactie gewijzigd door kidde op 25 juli 2024 13:22]

[MSalters]

Nee - de specificatie zegt er niets over. Dat is precies het probleem; bij gebrek aan formele specificatie hebben de Intel HW engineers andere aannames gemaakt als de Linux en Microsoft SW engineers.

Het gevolg is dat je niemand echt de schuld kan geven. Intel kan gewoon zeggen "ja, jullie namen aan dat het veilig was om kernel pages in de user space page table op te nemen, maar er stond nergens dat dat gegarandeerd veilig was. We snappen dat het sneller is, maar dat is geen excuus."

[kidde]

Totale onzin, het ontwerp is de spec. De fout zit in het ontwerp van Intel, niet in het ontwerp van AMD. De chip werkt volgens het ontwerp. Intel is kwetsbaar, AMD niet.

Dat staat dus wel ergens, namelijk in het ontwerp. Het heeft ook geen drol te maken met Linux of Microsoft aannames, bivendien is het niet eens een aanname maar een besluit: AMD neemt een veilig ontwerp besluit, Intel het onveilige. Daarom heeft Intel het Meltdown probleem en AMD niet, stop daar nou eens omheen te draaien; u herhaalt hier de Intel PR twijfel- en verwarringzaaierij.

[Elefant]

Linus zit fout. Een product moet doen waarvoor het bedoeld is. Je kan het niet afrekenen op misbruik door derden. Elk product is wel te misbruiken. Als een chip rekenfouten maakt dan kan je stellen dat de chip niet naar behoren functioneert. Dat is wel eens gebeurd en die heeft Intel ook vervangen.

Ik ben niet blij met al die onderzoekers die voortdurend maar kwetsbaarheden lopen te publiceren. Daarmee spelen ze die in feite direct door naar criminelen. Inmiddels is wel duidelijk dat onze computers gewoon niet veilig te krijgen zijn en daarom heeft het ook geen zin om steeds kwetsbaarheden te publiceren, want daarmee mee maak je al die mensen kwetsbaar die de patch niet installeren. Bovendien kunnen criminelen de informatie gebruiken om soortgelijke aanvallen te doen. Geef de informatie stilletjes door aan de fabrikanten en dan kunnen die zonder veel ruchtbaarheid een patch ontwikkelen.

[rbr320]

Linus zit fout. Een product moet doen waarvoor het bedoeld is. Je kan het niet afrekenen op misbruik door derden. Elk product is wel te misbruiken. Als een chip rekenfouten maakt dan kan je stellen dat de chip niet naar behoren functioneert. Dat is wel eens gebeurd en die heeft Intel ook vervangen.

Dit issue is dan ook beter te vergelijken met jouw tweede voorbeeld dan met "misbruik door derden". Spectre en Meltdown zijn fundamentele fouten in het ontwerp van de chips. Ze functioneren niet naar behoren want ze stellen software in staat geheugen te lezen waar het helemaal niet bij hoort te kunnen. Linus heeft dus gewoon gelijk.

Ik ben niet blij met al die onderzoekers die voortdurend maar kwetsbaarheden lopen te publiceren. Daarmee spelen ze die in feite direct door naar criminelen. Inmiddels is wel duidelijk dat onze computers gewoon niet veilig te krijgen zijn en daarom heeft het ook geen zin om steeds kwetsbaarheden te publiceren, want daarmee mee maak je al die mensen kwetsbaar die de patch niet installeren. Bovendien kunnen criminelen de informatie gebruiken om soortgelijke aanvallen te doen. Geef de informatie stilletjes door aan de fabrikanten en dan kunnen die zonder veel ruchtbaarheid een patch ontwikkelen.

Als je het hebt over het type onderzoekers dat kwetsbaarheden zomaar koud op iedereen zijn dak gooien dan heb je natuurlijk gelijk, maar met die gasten is niemand in de computer security wereld blij. Gelukkig doen de meeste onderzoekers aan 'responsible disclosure', zoals de mensen bij Google's Project Zero die een van de (vele) partijen waren die deze kwetsbaarheden ontdekt hebben.

[Yggdrasil]

Geef de informatie stilletjes door aan de fabrikanten en dan kunnen die zonder veel ruchtbaarheid een patch ontwikkelen.

Dat is nu ook gebeurd. Maar uiteindelijk moet je wel iets bekend maken zodat zoveel mogelijk systemen gepatcht worden. Als je dat niet doet dan komen criminelen er wél achter wat de bug was (want die zoeken er ook actief naar) maar weten veel mensen niet eens dat ze risico lopen.

Over dit onderwerp is in de open source wereld veel discussie gevoerd en kwam men tot de conclusie dat responsible disclosure de betere keuze is.

[rbr320]

Reken er maar niet op. Met de software patches die het probleem mitigeren en het feit dat je voor Spectre lokaal toegang tot de pc nodig hebt is de CVSS score flink gedaalt. Daarnaast zullen de meeste thuisgebruikers de nadelige effecten van de patches op performance niet eens merken. Verwacht dus geen terughaalactie.

https://www.forbes.com/si...erabilities/#77628de27d3a

[MadEgg]

Dan ga je al van thuisgebruikers uit. Mijn Xeon workstation- en serverchips worden hierdoor ook getroffen.

[rbr320]

Inderdaad, excuses daarvoor. Toch blijft mijn antwoord hetzelfde. Ga er maar niet vanuit dat je van Intel iets krijgt, behalve het advies om vooral de laatste updates van je OS te installeren. Datzelfde was trouwens het geval geweest als de Meltdown bug specifiek voor AMD of voor ARM was geweest.

[BackBones]

Ja zeker, want ook al geldt dit probleem voor (vrijwel?) elke processor sinds 1994 (of iets in die richting) ze hebben de processors die dit probleem niet hebben naat gewoon al op de plank liggen. /end sarcasm

Ik denk dat het behoorlijk lastig gaat worden om hier ook maar een enkele vorm van claim aan te verbinden. De processors doen gewoon wat ze moeten doen, er is alleen een manier gevonden waardoor iemand KAN inbreken.

Naar mijn idee is dat een beetje hetzelfde als een claim maken omdat er een raam in je auto zit die een dief kan intikken om er dingen uit te jatten. Met het verschil natuurlijk dat bij de toekomstige processors het 'raam' wel dicht getimmerd kan worden.
In de tussentijd werken ze aan een slot voor je, zodat het in ieder geval moeilijker is om in te breken.

[Reactie gewijzigd door BackBones op 25 juli 2024 13:22]

[uiltje]

Dit is geen probleem met de micro-code, het is een probleem in het hele processor ontwerp. Als je de hele speculatieve uitvoering uit zet dan blijft er niets meer van de performance over. Het even patchen van de microcode lijkt me daarom niet van toepassing. Of heb je ergens een referentie dat dit mogelijk is?

Processors zijn relatief nieuw en heel erg complex. Helaas kan je geen 100% zekerheid krijgen als je er eentje aanschaft; sterker nog, ze zijn zo complex dat je zeker bent van bugs. Verder zijn ze een voortborduring op processors uit een tijd dat op dit soort lekken minder werd gelet.

Het laten vervangen van alle processors is natuurlijk onmogelijk, zelfs voor Intel.

[Reactie gewijzigd door uiltje op 25 juli 2024 13:22]

[Rudie_V]

en er nog steeds aangeraden wordt om op termijn van CPU te veranderen als je hier 100% safe van wil zijn

Dan mogen de fabrikanten wel eens duidelijkheid geven wanneer we processors kunnen verwachten die deze bugs niet meer bevatten. Daar horen we niets over terwijl het probleem al sinds juni/juli 2017 bekend is. Ik snap ook wel dat je niet zomaar een processorontwerp aanpast, maar er is al genoeg tijd verstreken om hier meer duidelijkheid over te geven richting het publiek.

[Yggdrasil]

Ik heb artikelen van 'insiders' gelezen (die ik zo even niet kan vinden) waarin zij voorspellen dat het nog een half jaar duurt voordat de eerste aanpassingen in chips zullen verschijnen (dus ongeveer een jaar na de bekendwording) en nog tot vijf jaar voordat echt significante aanpassingen in de ontwerpen gedaan zijn én voor ons beschikbaar zijn.

[Verwijderd]

Je bent dan hoogstens 100% safe voor Meltdown en Spectre. Niet voor andere bugs.

[uiltje]

Spectre en Meltdown zijn geen bugs, het zijn security vulnerabilities. Het is niet zo dat je even een specifiek stukje code kan patchen om de security vulnerability eruit te halen. Het is een beveiligingsfout waarop je aanvallen kan uitvoeren.

In die zin is het wezenlijk anders dan bijvoorbeeld Heartbleed waar er op 1 plek een specifieke controle mist (het ontbreken van bounds checking zou je de algemenere vulnerability kunnen noemen in het geval van Heartbleed).

[Gekke Jantje]

100% safe ben je nooit als je PC verbonden is met het grote internet.

[AJediIAm]

Dat hangt er natuurlijk van af waar de CPU voor gebruikt wordt. Voor een intern systeem waar alleen vertrouwde gebruikers toegang tot hebben zou een software patch goed genoeg kunnen zijn.

[droner]

Worden die OS patches straks eigenlijk overbodig zodra Intel (en AMD) patches uitgerold worden, weet iemand dat?

[JohanNL]

Simpel gezegd: Nee, je hebt ze beide nodig.
En daarmee is het daadwerkelijke probleem nog niet opgelost maar je bent tot zo ver veilig totdat iemand deze patches weet te cracken en weer gebruik weet te maken van dit lek in de processorarchitectuur.
Een echte oplossing laat dus nog op zich wachten omdat Intel dit lek echt moet dichten '' diep in '' de processor.
Je zult dan een nieuwe processor moeten kopen, de huidige Intel processoren tot terug in 1995 zijn allemaal kwetsbaar dus zul je moeten wachten als je weer voor Intel wilt gaan.

[Reactie gewijzigd door JohanNL op 25 juli 2024 13:22]

[Daedeloth]

Wat heeft AMD hiermee te maken?

[KingFrogzz]

Alle niet-Ryzen processors van AMD zijn ook getroffen

[JohanNL]

Ryzen is wel getroffen, echter enkel door Spectre.
Waarom het bij Ryzen niet zo erg blijkt te zijn is omdat je een bepaalde functie aan moet hebben staan in de bios, die standaard uit staat ( ben de naam even kwijt ) en je fysieke toegang nodig hebt om überhaupt hiervan gebruik te maken.

Een stuk minder erg dus en aangezien alle andere Intel processoren wel vatbaar zijn voor Meltdown kan ik mij voorstellen dat dit Intel veel omzet gaat kosten ten goede van AMD totdat Intel nieuwe processoren uit brengt die deze kwetsbaarheid niet meer hebben.

[MSalters]

De "bios feature" in kwestie is eBPF JIT, wat een Linux kernel feature is. Om die te enablen moet je een boot optie meegeven.

"JIT" is een Just In Time compiler - Linux kan een user-defined packet filter compileren naar machine code. Het probleem is nu dat die gecompileerde code ook misbruik kan maken van Spectre. De structurele oplossing hier is een fix in de JIT compiler, en die gaat nauwelijks performance impact hebben op legitieme packet filters.

[ELD]

Niet door Meltdown en alleen voor spectre variant 1.

[uiltje]

En Spectre is ook voor AMD Ryzen een probleem, ware het niet dat er voor Spectre niet direct een patch beschikbaar is. Daarvoor is de vulnerability te algemeen.

[2TheMaks]

Wat 'OS patches' genoemd worden is slechts een mitigation voor bepaalde (bekende) attack-vectors die de Spectre en Meltdown vulnerabilities in CPU's (Intel/AMD/ARM) exploiteren.

Ofwel: de 'OS patches' verkleinen de attack surface, maar lossen geen bugs/vulnerabilities op.

[kaa-ching]

Is Canonical laat?
Red Hat heeft allang patches...

[Mei]

Ik hoor net van een collega bij Canonical dat patches van andere distro's blijkbaar wat bijwerkingen hadden, en dat Canonical daarom besloten had de tijd te nemen voor extra testing.

[AJediIAm]

Ik vind van niet. Er zijn nog geen gevallen van misbruik bekend en je kan beter een goede patch uitbrengen dan een overhaaste patch met bugs.

[MiesvanderLippe]

Met de username van Ubuntu is het ook wel iets belangrijker dat alles goed werkt. Zeker na het Lenovo debakel van laatst.

[Dorank]

Dus ubuntu moet securer werken dan redhat, ongeacht dat redhat een distro is voor professioneel gebruik!

Debian heeft al meerdere patches uitgerolt. Ubuntu is niet veel meer dan een snapshot van Debian/testing of unstable, vanwaar deze vetraging?

[xxxneoxxx]

Ik denk dat je userbase bedoelt?

[KingFrogzz]

Maar als versie 17.04 op 13 januari end-of-life is, dan zou hij tót het zover is toch ondersteund moeten worden?

[latka]

3 dagen voor EOL een major patch doorvoeren? Wie gaat die dan installeren? Alleen de doorlooptijd voor een regressietest van een patch van deze omvang duurt al meer dan 3 dagen. Nog los ervan dat het geen LTS release is en deze versie voor thuisgebruikers is die updaten niet erg vinden. Die groep is ook vrij klein (die zitten allang op 17.10). Dus ik snap het wel. Maar het is niet correct volgens de letter van de wet. Aan de andere kant: IT is al duur zat.

[Nardon]

Goed punt, maar het is (als ik het zo lees) een redelijk complexe patch. Ik snap hun afweging wel aangezien ze zo snel mogelijk die bijgewerkte kernels voor elke release moeten uitgeven. Is het het dan waard om voor 3 dagen nog moeite in te stoppen?

Puur kijkend naar wat ze beloofd hebben heb je helemaal gelijk, maar als je kijkt naar strategie snap ik dat ze 17.04 skippen. De meeste gebruikers zijn ook al gemigreerd naar 17.10

[Verwijderd]

Ubuntu brengt zowel Short term (ieder half jaar) als Long term (iedere paar jaar) support versies uit.

De meeste mensen die de short term gebruiken die doen sowieso ieder een upgrade naar de volgende short term release. Ik gebruik al ruime tijd geen ubuntu meer, maar volgens mij moet dat kunnen via synaptic package manager.

Voor de mensen die het van Ubuntu afgeleide Mint gebruiken, deze support loopt tot april 2019, of april 2021 afhankelijk van de versie die je hebt.
https://www.linuxmint.com/download_all.php

[kuurtjes]

Gelijk heb je!

[ruftman]

Jammer dat mijn Intel processor ouder dan 5 jaar is en Asus vooralsnog geen patches voor het bijbehorende moederbord gaat uitbrengen. Aangenomen dat ik niet de enige ben met oudere hardware, worden hiermee wereldwijd meer dan genoeg gebruikers mee in de kou gezet.

Aan de andere kant heb ik begrepen dat, om misbruik van de lekken te kunnen maken, een hacker eerst op de een of andere manier toegang moet krijgen tot de computer.
Klopt het dan dat zolang er geen vage mailtjes worden geopend en de software up to date is (de patch voor Windows, recente Firewall en een bijgewerkte virusscanner) het risico al behoorlijk verminderd is?

[svennd]

Exploiten kan via javascript code, ads/infected website is voldoende.

[ruftman]

Ok bedankt voor de info. Een virusscanner kan dat niet voldoende ondervangen?

[SilentLucidity]

Een virusscanner kan die exploits ondervangen, maar zoals altijd is het natuurlijk een kat en muis spel. Een simpel programma dat niet als virus word herkend kan er dus al bij, en dat is niet te patchen.

[N8w8]

De uitgebrachte microcode, is voor de Pentium 1(!) en jonger dus dat is het probleem niet.
iig Linux ondersteunt wel microcode updates (los van de firmware), dus in theorie kan dat ook vanuit Windows. Als zo veel mensen getroffen zijn, wordt dat mss ook voor Windows ontwikkeld.

edit: Whoeps, dat zeg ik verkeerd. Het uitgebrachte ucode _pakket_ bevat idd ucode voor alles vanaf de P1, alleen hebben ze in dat pakket blijkbaar alleen de ucode vanaf Haswell geupdate (de ucode voor mijn Ivybridge is iig ongewijzigd zie ik).

[Reactie gewijzigd door N8w8 op 25 juli 2024 13:22]

[RobinJ1995]

NVidia drivers? Zijn GPUs ook affected dan?

[SilentLucidity]

Waarschijnlijk wel, een GPU heeft ook een processing unit in zich...

[RobinJ1995]

Ja, maar ook zijn eigen geheugen toch?

[SilentLucidity]

Jazeker, maar dat is dan toch ook uit te lezen?

[TonnyTonny]

Ja, en daarnaast kan de GPU ook via de PCIe bus ook rechtstreeks bij het systeem-RAM.
En daar zit met name het probleem.

[rikster]

Wow, dat is snel! Vanmorgen constateerde ik dat 4.4.0-108 buggy was en nu is 109 er al. Ik ga 'm meteen testen.

Getest: werkt naar behoren op HP Microserver Gen8, Celeron G1610T.

[Reactie gewijzigd door rikster op 25 juli 2024 13:22]

[Verwijderd]

Mooizo!

Jij weet dus nu hoe het moet?

Laat de rest dan s.v.p. ook even weten met welke apt-get commandoś dat kan worden gedaan vanuit een eerdere kernel die nog wel werkt?