Aggiornamento del kernel Linux, lasciando il resto del sistema così com'è

Sono un utente OpenBSD. Nelle FAQ di OpenBSD dice:

OpenBSD è un sistema completo, destinato a essere sincronizzato. Non è un kernel più utility che possono essere aggiornati separatamente.

Quando aggiorni un sistema, lo fai in una volta sola; il kernel e il sistema di base sono sostituiti. Quindi vai e aggiorna i tuoi pacchetti di terze parti . Se si compila dal sorgente , si ricompila il kernel e lo si avvia. Quindi ricostruisci il sistema di base e quindi i pacchetti che hai installato. Se sono trascorse più di un paio di settimane / mesi dall'ultima ricostruzione di tutto, devi prima installare un'istantanea e ricostruire da lì (se stai seguendo il ramo CVS più recente).

Avere un kernel non sincronizzato, un sistema di base e / o pacchetti di terze parti è una potenziale fonte di problemi e più o meno ti squalifica dal ricevere qualsiasi aiuto serio dalle mailing list ufficiali.

Sono abbastanza d'accordo con questo. In effetti, questo è uno dei motivi per cui utilizzo OpenBSD. Rende il sistema un'unità coerente e mi rende facile formarne una visione mentale.

Com'è su Linux? La maggior parte dei Linux di cui sono a conoscenza non ha un "sistema di base" nello stesso senso dei BSD, ma piuttosto una raccolta di pacchetti assemblati dal fornitore di distribuzione. Un ulteriore software viene quindi aggiunto a questo da un amministratore locale in modo tale che il confine tra ciò che era lì dall'inizio e ciò che è stato aggiunto in seguito è, nella migliore delle ipotesi, sfocato.

Linux (in generale) non ha un forte accoppiamento kernel-spazio utente? Il kernel è aggiornato, per quanto ne so, come qualsiasi altro pacchetto software, e mi confonde leggermente che ciò sia assolutamente possibile. Aggiungete a ciò il fatto che alcuni compilano persino kernel personalizzati (che è sconsigliato su OpenBSD) e hanno una moltitudine di varie versioni del kernel elencate nei loro menu di avvio.

Chi o cosa garantisce che i vari sottosistemi di un sistema Linux siano in grado di cooperare tra loro anche se vengono aggiornati indipendentemente l'uno dall'altro?

Il motivo per cui lo sto chiedendo è perché un altro utente su questo sito mi ha chiesto se sostituire il kernel nel suo sistema Linux con una versione più recente "sarebbe fattibile". Venendo dal lato OpenBSD delle cose, non potrei dire che sì, questo sarebbe garantito per non rompere il sistema.

Uso "Linux" sopra come abbreviazione di "distribuzione Linux", kernel + utility.

Linus Torvalds ha un'opinione molto forte contro i cambiamenti del kernel con conseguenti regressioni dello spazio utente (per i dettagli, vedere la domanda " Il kernel Linux: rompere lo spazio utente ").

L'interfaccia tra userspace e kernel è fornita dalle chiamate di sistema. I kernel più recenti possono avere più chiamate di sistema e modifiche all'uscita da quelle quando tali modifiche non interrompono le applicazioni esistenti. Quando un'interfaccia di chiamata di sistema ha un parametro flag, i nuovi kernel spesso espongono la nuova funzionalità con un nuovo bit flag. In questo modo il kernel mantiene la retrocompatibilità con le vecchie applicazioni.

Quando non è stato possibile modificare l'interfaccia esistente senza interrompere lo spazio utente, sono state aggiunte ulteriori chiamate di sistema che forniscono la funzionalità estesa. Questo è il motivo per cui ci sono tre versioni dupe due versioni della umountchiamata di sistema.

La politica di avere uno spazio utente stabile è il motivo per cui gli aggiornamenti del kernel raramente causano problemi nelle applicazioni dello spazio utente e in genere non ci si aspetta problemi dopo l'aggiornamento del kernel.

Tuttavia, la stessa stabilità dell'API non è garantita per le interfacce del kernel e altri dettagli di implementazione . Sysfs (on /sys) e procsfs (on /proc/) espongono i dettagli dell'implementazione del kernel su configurazione di runtime, hardware, rete, processi ecc. Che vengono utilizzati da applicazioni di basso livello. È possibile che tali interfacce cambino in modo incompatibile tra le versioni del kernel se c'è una buona ragione per farlo. Le modifiche tentano ancora di minimizzare le incompatibilità, se possibile, e ci sono regole su come le applicazioni possono utilizzare le interfacce in un modo meno probabile che causi problemi. L'impatto è anche limitato perché le applicazioni non di basso livello non dovrebbero usare queste interfacce.

@PeterCordes ha sottolineato che una modifica a procfs o sysfs interrompe un'applicazione utilizzata dagli script init delle tue distribuzioni, potresti avere un problema.

Ciò dipende in parte dal modo in cui la distribuzione aggiorna il kernel (supporto a lungo termine o mainline) e anche in questo caso i problemi sono relativamente rari in quanto le distribuzioni solitamente inviano gli strumenti aggiornati contemporaneamente.

@StephenKitt ha aggiunto che lo spazio utente aggiornato potrebbe richiedere una versione più recente del kernel, nel qual caso il sistema potrebbe non essere in grado di avviarsi con il vecchio kernel e che le note di rilascio della distribuzione menzionano questo quando appropriato.

Il kernel Linux e lo spazio utente di una distribuzione Linux, che storicamente era dominata da strumenti utente sviluppati dal progetto GNU, sono liberamente associati. In parte questo è di progettazione, e in parte è per necessità.

A differenza dei BSD, in cui il kernel e lo spazio utente di base sono progettati e gestiti insieme, il kernel Linux e il suo spazio utente sono stati sviluppati e gestiti da persone diverse. Quindi tenerli ben accoppiati insieme sarebbe difficile, anche se la comunità lo desiderasse, cosa che non credo.

E @sebasth sottolinea anche che una delle principali politiche del progetto del kernel Linux è che non deve interrompere lo spazio utente. Che ovviamente è un altro fattore che impone un accoppiamento lento.

Tuttavia, esiste ancora un certo grado di accoppiamento. Un kernel Linux sufficientemente vecchio non funzionerà con le distribuzioni moderne.

La mia comprensione è che Linux è il kernel e tutto il resto è accessorio. Puoi sicuramente aggiornare il kernel indipendentemente da (molti) pacchetti installati, poiché sono generalmente legati alle librerie piuttosto che al kernel stesso. In genere vedrai solo un tale accoppiamento tra le versioni del kernel e i driver hardware (ad esempio i driver GPU). Alcuni software sono compatibili solo con alcune versioni del kernel, ma ciò dovrebbe essere specificato nella documentazione individuale di tali programmi.

È piuttosto comune avere due suite di pacchetti kernel installate su un sistema: il pacchetto attualmente utilizzato e il pacchetto precedentemente installato. Durante l'aggiornamento, dopo aver verificato che la nuova versione funzioni correttamente, la più vecchia può essere rimossa e si ha ancora un fallback noto e sicuro. Red Hat (e i suoi cugini), per esempio, deve package-cleanup --oldkernels --count 2farlo automagicamente.

Oltre a tutti i buoni argomenti qui, posso aggiungere alcuni punti che aiuteranno.

Conosciamo già la politica del team del kernel e, come distribuzioni Linux, proviamo a mantenere il codice sorgente del kernel il più puro possibile. Ciò significa che, ogniqualvolta si presenta una vulnerabilità o qualcosa che necessita di una patch, informiamo il team del kernel e proviamo ad aiutare con le patch, ma alla fine la decisione finale viene dal team del kernel.

Alcune distribuzioni aggiungono patch extra più di altre, ma l'idea è di mantenerla come viene dagli sviluppatori upstream. Ovviamente, ci sono alcuni programmi che richiedono una speciale configurazione del kernel, in particolare la virtualizzazione e i driver di terze parti e di solito, entrambi sono usati per lavorare con una versione specifica del kernel o almeno una versione non troppo vecchia ... il motivo è che provano per funzionare con le ultime funzionalità del kernel e per questo motivo, se si tenta di eseguirle con un vecchio kernel, potrebbero non funzionare correttamente.

Un ulteriore elemento da tenere a mente è che tutte le distribuzioni Linux hanno un team di manutentori, persone che assicurano che tutto il software sia compatibile con il sistema. Ecco perché quasi ogni distribuzione ha una versione stabile e instabile. Gli sviluppatori lavorano con software "instabile" e quando tutto viene testato lo contrassegnano come stabile, solo dopo che un utente normale può aggiornare il pacchetto, quindi se la persona che ti ha chiesto è un utente normale è sicuro al 90% che il software è ben testato .

Quindi chi è, la comunità e quindi quale dovrebbe essere l'approccio comune, abbiamo bisogno che il software funzioni insieme e non rompa il sistema, ecco perché proviamo a seguire alcuni standard come Filesystem Hierarchy Standard .