Zorgen dat Linux niet omkiept

[Katsunami]

Een van de redenen waarom ik vroeger altijd weer van Linux ben afgestapt, is dat het nogal eens kan omkiepen als je niet een distributie zoals Debian Stable, of CentOS draait. Die distro's wil ik echter niet op de desktop, omdat de software vaak te ver achterloopt. Als je Debian Testing, Arch, of Fedora draait, die wel redelijk bleeding edge zijn, zit je dus altijd met de kans dat je systeem omkiept. Dat is me hier te vaak gebeurd in het verleden.

De Nr. 1 reden dat dit gebeurt, is hier eigenlijk altijd een kernel-update. Meestal zijn het de nVidia-kaart en VirtualBox die omkiepen, omdat de kernelmodules niet meer kloppen. (Niet in elke distro kun je de nVida-driver uit hun repo's halen. VirtualBox-OSE uit de RPMFusion repo's voor Fedora heeft problemen met dBus, dus ik draai nu de versie van de Oracle site. Deze pakketten worden meestal iets later bijgewerkt.)

Wat ik nu wil is de kernel, de nVidia-driver en VirtualBox excluden van een upgrade (in welke distributie dan ook). Dan wil ik na een kernel-update wachten totdat de kernel-modules voor de nVidia-kaart en VirtualBox beschikbaar zijn, en dan pas de kernel en deze onderdelen updaten door de exclude tijdelijk op te heffen.

Echter, het zou kunnen zijn dat je dan tijdens de tijd dat de exclude bestaat, een probleem krijgt dat zich naloopt: Kernel kan niet worden bijgewerkt -> Library kan niet worden bijgewerkt -> Applicatie kan niet worden bijgewerkt; of de applicatie wordt toch bijgewerkt en knalt er dan uit omdat de libs te oud zijn omdat de kernel te oud is of iets dergelijks.

Is een dergelijke exclude veilig om te doen, of is het dan bijna gegarandeerd dat ik dan gewoon *andere* problemen ga krijgen met het systeem (bijvoorbeeld omdat applicaties worden bijgewerkt, los van de kernel en/of libraries?

Mijn kennis van hoe Linux werkt als je dit soort dingen doet ontbreekt nog, eerlijk gezegd.

[ Voor 14% gewijzigd door Katsunami op 10-03-2012 04:14 ]

[CyBeR]

Kernels kun je vrijwel altijd holden.

[jan99999]

Ik gebruik ubuntu. Dus alles is hierop gericht.
Nvidia driver, gewoon de driver welke in ubuntu zit gebruiken, dus laatste versie van ubuntu gebruiken.
Dit werkt niet als je een te nieuwe gpu koopt, want dan kent ubuntu deze niet.
Met bovenstaande hoef je noot aan je videokaart te corrigeren bij update's.

Met videokaart die te nieuw is, bij mij nu ook, ubuntu 10.04 met de laatste nvidia videokaart. Hier moest ik van de nvidia site de driver downloaden.
Bij kernel update werkte het niet meer, is normaal.
Met dit opgelost,
sudo apt-get --purge remove nvidia-* in de terminal.
Dan in textmode, de nvidia driver weer installeren. Dat is alles.

Virtualbox, gewoon van de oracle site gebruiken, je krijgt met opstarten van virtualbox een melding als er een nieuwe versie is.
Na een kernel update krijg je ook een foutmelding, en wat je moet doen in de terminal, dus copy naar de terminal, en starten. dat is alles.
Bij gebruik virtualbox in die van de ubuntu server zou je geen foutmelding moeten krijgen, maar ook geen update's.

Dat je na een kernel update, sommige software weer moet aanpassen/installeren in de kernel, is omdat dit sneller werkt(om drivers in de kernel te plaatsen), en je software niet van de originele ubuntu is. Is maar een kleine moeite.

Blokkeren van update's zou ik niet doen.

Voor hulp kun je gewoon hier of bij de nederlandse ubuntu forum. Vaak is google nog beter, en in het engels zoeken.

[ Voor 5% gewijzigd door jan99999 op 10-03-2012 07:05 ]

[ThomVis]

Geen ervaring met VitualBox, maar VMplayer heeft hier ook last van. Als er een kernel upgrade in de lijst staat, deinstalleer ik eerst VMplayer -> Kernel upgrade -> installeer VMplayer.

[Thralas]

Je probleem herken ik; heb er zelf ook meermaals problemen mee gehad, met name in geval van third party kernel modules wil het wel eens stukgaan, vooral bij een bleeding edge distro als Arch.

Zet eerst eens alle thirdparty kernelmodules die je draait op een rij. Je noemde er al een paar; zolang je bv. VirtualBox uit je distro repository draait zou je daar geen problemen moeten ervaren. Proprietary videokaartdrivers (nvidia, ati) zijn wel een behoorlijke issue, maar weinig distros supporten deze in de 'core' repositories, dus dan bestaat inderdaad de kans dat het niet meer werkt. Ik neem aan dat het een weloverwogen keuze is om een proprietary driver te draaien?

Als je echt een proprietary videodriver wilt draaien kun je kernel updates meestal wel nergeren (zoals CyBeR al aangeeft). Een gevolg is dan dat applicaties als VirtualBox mogelijk geen updates krijgen, maar het zou toch echt beperkt moeten zijn tot de packages met third party kernel module dependencies.

In het specifieke geval van Arch kun je ook de linux-lts kernel package (uit de repositories) overwegen. Deze is momenteel frozen op Linux 3.0, en levert als het goed is minder vaak kernelincompatibilityproblemen op.

[Hero of Time]

Wat ik nu wil is de kernel, de nVidia-driver en VirtualBox excluden van een upgrade (in welke distributie dan ook). Dan wil ik na een kernel-update wachten totdat de kernel-modules voor de nVidia-kaart en VirtualBox beschikbaar zijn, en dan pas de kernel en deze onderdelen updaten door de exclude tijdelijk op te heffen.

De versie van VirtualBox is bij hun eigen repo veel eerder dan je distro repo zelf. Als RPMFusion het gaat compilen en in de repo smijt zodra er een release is, ja, dan kan je eerder zijn. Oracle wacht expres een á twee dagen voordat de repo aan de beurt is vanwege server load. De auto-update notifier staat op een langere hold om die reden (een week geloof ik).
Voor nVidia ben je gebonden aan de distro repo of de website zelf en bij het laatste moet je zelf zorgen voor updates.

Wat ik heel vreemd vind aan je topic en TS is dat je aangeeft dat er geen support is van de pakketten die je noemt mbt kernel modules. VB loopt bijna altijd mee, soms een release later als de kernel een grote verandering is of de distro bepaalde 'patches' toe past waardoor de module compilation niet lekker werkt (of de module zelf niet werkt). Je kan ten alle tijden VirtualBox updaten, net als de nVidia drivers, maar je bent zelf verantwoordelijk voor het lezen van de changelog en te besluiten tot upgrade. Lukraak updaten geeft problemen, en dat is niet beperkt tot Linux. Elk OS heeft hier last van.

Kernels kan je holden, maar waarom zou je? Als het niet werkt, dan herstart je toch en selecteer je de vorige kernel om te starten. Heb je geen menu, dan moet je of een toets vasthouden of grub even aanpassen om wel een menu weer te geven.

Ondersteuning van kernel modules komt overigens ook via DKMS. Die zorgt er voor dat elk pakket wat kernel modules gebruikt en is geconfigureerd om 't te gebruiken, netjes nieuwe modules krijgt bij een kernel update. VB en nVidia maken hier gebruik van. Ik draai Debian Sid en als ik een nieuwe kernel krijg, gaat DKMS lekker aan de slag en maakt de nVidia en VirtualBox modules, klaar om geladen te worden. Mocht het niet lukken, dan krijg ik er een melding van bij het installeren (terminal in de gaten houden, ik update niet via een GUI). Als het bij het opstarten niet werkt, om wat voor reden dan ook, wat ik een paar maanden geleden had toen ik kernel 3.2 kreeg, even aanmelden bij de CLI, logs bekijken, herstarten naar oude kernel, googlen en oplossing gevonden. Of gewoon bij de oude kernel bijven.

Ik zie hier een heel drama voor iets kleins wat niet nodig is. Het is niet zoals Windows waarbij je heel veel moeite moet doen om een update ongedaan te maken, zeker als het om de kernel gaat. Je hebt zelfs de optie om alle packages die geïnstalleerd worden te bewaren. Debian (based) doet dit standaard in /var/cache/apt/archives/, deze wordt alleen geleegd als je apt-get clean draait, of aangeeft dat niet beschikbare packages opgeschoond moet worden van je cache. Alleen dan moet je wat meer moeite doen om naar de vorige versie van dat ene pakket te gaan (handmatig downloaden).

Nou moet ik wel zeggen dat ik al lange tijd Linux gebruik en dit allemaal vanzelfsprekend vind. Voor jou zal dit ongetwijfeld anders zijn.

[Katsunami]

Hero Of Time schreef op zaterdag 10 maart 2012 @ 12:05:
Nou moet ik wel zeggen dat ik al lange tijd Linux gebruik en dit allemaal vanzelfsprekend vind. Voor jou zal dit ongetwijfeld anders zijn.

Zelf werk ik af en aan ook al 10 jaar met Linux, maar dat doe ik dus niet full time. Windows heb ik 20 jaar lang full time gebruikt, dus mijn l33t troubleshoot skillz zijn op dat platform veel beter. Linux kan ik installeren, configureren (met wat hulp van Google, om te lezen wat er nou weer veranderd is, vorige week ), maar ik kan het nog niet goed troubleshooten als er iets mis gaat.

Aangezien ik het niet kan gebruiken dat mijn dagelijkse PC plotseling plat gaat, of elke twee weken drastisch geüpgradet moet worden, ben ik dus op zoek naar een manier om dat te voorkomen, totdat ik tijd heb om een upgrade uit te voeren. Een kernelupgrade op het moment van een distro-upgrade elk half jaar (zoals Fedora 16 -> 17) vind ik eigenlijk wel prima. Voor een dergelijke grote upgrade maak ik dan eigenlijk ook altijd een image; dat deed ik ook al onder Windows.

In elk geval iedereen bedankt voor de inzichten. Als iemand anders nog iets toe te voegen heeft, dan hoor ik dat graag

[ Voor 10% gewijzigd door Katsunami op 10-03-2012 13:41 ]

[Zer0]

Katsunami schreef op zaterdag 10 maart 2012 @ 13:40:
Aangezien ik het niet kan gebruiken dat mijn dagelijkse PC plotseling plat gaat, of elke twee weken drastisch geüpgradet moet worden, ben ik dus op zoek naar een manier om dat te voorkomen, totdat ik tijd heb om een upgrade uit te voeren.

Installeer een willekeurige distro en zet automagische updates uit. Doe een handmatige update als je tijd hebt.
Problem solved...

[Borromini]

Ik draai zelf Arch Linux. Naar mijn mening zijn kleinere incrementele upgrades beter en op lange termijn efficiënter dan een gigantische upgrade eens om de zoveel maand (Ubuntu, Fedora, ...) of jaren (Debian).

De sytemen die stabiliteit nodig hebben (mijn HTPC, mijn server, de AppleTV) draaien allemaal op de LTS kernel. Da's een kernel in maintenance mode, meer dan bug en security fixes ga je daar niet in zien. Voor de AMD Catalyst driver heb ik een pakket dat de driver simpelweg on the fly hercompileert wanneer er een kernelupgrade wordt geïnstalleerd (zelfs voor LTS is dat nog met de regelmaat van de klok, jammer genoeg). De enige angel is Xorg, er zijn al een paar devs aan het kwijlen om Xorg 1.12 naar de stabiele repo's te verhuizen (zit nu nog in testing) en je raadt het al: AMD heeft nog geen ondersteuning daarvoor, nVidia natuurlijk wel.

De sleutel hier is regelmatige upgrades, de aankondigingen in het oog houden, en zeker niet upgraden wanneer je je machine nodig hebt (dan moet dat ding immers functioneel zijn en niet doodgaan). Ik heb nog geen enkele herinstallatie moeten doen op mijn systemen.

De devs van Arch zijn natuurlijk die van Debian niet, dus zelfs bij stabiele updates kunnen er nog wat losse eindjes zitten (ondanks de 'brede' userbase lijken er weinig moedigen te zijn die testing willen draaien, ook al is het aantal problemen met testing fors verminderd in vergelijking met de vorige jaren). Langs de andere kant heb je bij Debian niet de flexibiliteit die Arch biedt, dus het blijft een eeuwig dilemma voor mij .

Mijn server, bijvoorbeeld:

# head -1 /var/log/pacman.log 
[2009-12-30 00:25] synchronizing package lists

[ Voor 19% gewijzigd door Borromini op 10-03-2012 16:32 ]