Mise à jour du noyau Linux, tout en laissant le reste du système tel quel


25

Je suis un utilisateur d'OpenBSD. Dans la FAQ OpenBSD, il est dit:

OpenBSD est un système complet, destiné à être synchronisé. Ce n'est pas un noyau plus des utilitaires qui peuvent être mis à niveau séparément les uns des autres.

Lorsque vous mettez à niveau un système, vous le faites en une seule fois; le noyau et le système de base sont remplacés. Ensuite, vous allez mettre à jour vos packages tiers . Si vous compilez à partir des sources , vous recompilez le noyau et le démarrez. Ensuite, vous reconstruisez le système de base, puis les packages que vous avez installés. Si plus de quelques semaines / mois se sont écoulés depuis la dernière reconstruction de tout, vous devez d'abord installer un instantané et reconstruire à partir de là (si vous suivez la branche CVS la plus récente).

Avoir un noyau désynchronisé, un système de base et / ou des packages tiers est une source potentielle de problèmes et vous empêche plus ou moins d'obtenir une aide sérieuse des listes de diffusion officielles.

Je suis tout à fait d'accord avec ça. En fait, c'est l'une des raisons pour lesquelles j'utilise OpenBSD. Cela fait du système une unité cohérente et il est facile pour moi d'en former un aperçu mental.

À quoi ça ressemble sous Linux? La plupart des Linux que je connais n'ont pas de "système de base" dans le même sens que les BSD, mais plutôt une collection de packages assemblés par le fournisseur de distribution. Un logiciel supplémentaire est ensuite ajouté à cela par un administrateur local de telle sorte que la frontière entre ce qui était là depuis le début et ce qui a été ajouté plus tard est, au mieux, floue.

Linux (en général) n'a-t-il pas un couplage solide du noyau à l'espace utilisateur? Le noyau est mis à jour, pour autant que je sache, comme tout autre logiciel, et cela m'embrouille un peu que cela soit possible. Ajoutez à cela le fait que certains compilent même des noyaux personnalisés (ce qui est déconseillé sur OpenBSD), et ont une multitude de versions de noyau différentes répertoriées dans leurs menus de démarrage.

Qui ou quoi garantit que les différents sous-systèmes d'un système Linux peuvent coopérer les uns avec les autres même s'ils sont mis à jour indépendamment les uns des autres?

La raison pour laquelle je pose la question est qu'un autre utilisateur de ce site m'a demandé si le remplacement du noyau de son système Linux par une version plus récente "serait faisable". Venant du côté d'OpenBSD, je ne pourrais pas dire que oui, ce serait garanti de ne pas casser le système.


J'utilise "Linux" ci-dessus comme raccourci pour "distribution Linux", noyau + utilitaires.


C'est une autre façon de dire qu'OpenBSD n'a qu'une seule distribution. Les multiples entrées du menu grub sur un système Linux standard sont destinées à revenir à un noyau antérieur au cas où le plus récent (généralement) ne peut pas démarrer pour une raison quelconque.
Thorbjørn Ravn Andersen

Réponses:


29

Linus Torvalds a une opinion très forte contre les changements du noyau entraînant des régressions de l'espace utilisateur (voir la question " Le noyau Linux: casser l'espace utilisateur " pour plus de détails).

L'interface entre l'espace utilisateur et le noyau est fournie par des appels système. Les noyaux plus récents peuvent avoir plus d'appels système et des modifications dans ceux qui sortent lorsque ces changements ne cassent pas les applications existantes. Lorsqu'une interface d'appel système a un paramètre d'indicateur, les nouveaux noyaux exposent souvent la nouvelle fonctionnalité avec un nouvel indicateur de bit. De cette façon, le noyau conserve la compatibilité descendante avec les anciennes applications.

Lorsqu'il n'a pas été possible de modifier l'interface existante sans casser l'espace utilisateur, des appels système supplémentaires ont été ajoutés pour fournir la fonctionnalité étendue. C'est pourquoi il existe trois versions de dupet deux versions d' umountappel système.

La politique d'avoir un espace utilisateur stable est la raison pour laquelle les mises à jour du noyau causent rarement des problèmes dans les applications de l'espace utilisateur et vous ne vous attendez généralement pas à des problèmes après la mise à niveau du noyau.

Cependant, la même stabilité d'API n'est pas garantie pour les interfaces du noyau et d'autres détails d'implémentation . Sysfs (on /sys) et procsfs (on /proc/) exposent les détails d'implémentation du noyau sur la configuration d'exécution, le matériel, le réseau, les processus, etc. qui sont utilisés par les applications de bas niveau. Il est possible que ces interfaces changent de manière incompatible entre les versions du noyau s'il y a une bonne raison de le faire. Les modifications tentent toujours de minimiser les incompatibilités si possible et il existe des règles sur la façon dont les applications peuvent utiliser les interfaces de la manière la moins susceptible de provoquer des problèmes. L'impact est également limité car les applications non de bas niveau ne devraient pas utiliser ces interfaces.

@PeterCordes a souligné que si un changement dans procfs ou sysfs casse une application utilisée par vos scripts d'init de distribution, vous pourriez avoir un problème.

Cela dépend quelque peu de la façon dont votre distribution met à jour le noyau (support à long terme ou ligne principale) et même dans ce cas, les problèmes sont relativement rares car les distributions expédient généralement les outils mis à jour en même temps.

@StephenKitt a ajouté que l'espace utilisateur mis à niveau pourrait nécessiter une version plus récente du noyau, auquel cas le système pourrait ne pas être en mesure de démarrer avec l'ancien noyau et que les notes de version de distribution le mentionnent le cas échéant.


1
Il serait utile à long terme d'étendre cette explication avec un résumé de l' interface utilisateur-noyau (alias appels système) car elle explique le mécanisme par lequel les noyaux configurés différemment ne cassent pas les applications.
wallyk

3
Même procfs ( /proc) et sysfs ( /sys) sont maintenus aussi stables que possible, suivant la même politique / philosophie "ne pas casser l'espace utilisateur". En outre, les ioctl()codes sur les fichiers de l'appareil en.wikipedia.org/wiki/Ioctl . Cela va bien au-delà de la simple compatibilité ABI des appels système, mais comme vous le dites quand il y a une bonne raison, les choses changent dans /procet /sys. Il ne cassera pas directement la plupart des programmes, mais s'il brise un programme d'espace utilisateur de bas niveau utilisé par les scripts d'initialisation de votre distribution, vous pourriez avoir un problème. Heureusement, c'est rare.
Peter Cordes

En fait, certains fichiers comme le rfkillcommutateur IIRC ont changé d'emplacement dans certaines mises à niveau du noyau. Donc, /procet /syssont beaucoup moins stables que l'interface syscall. Heureusement, les distributions n'incluent généralement pas de telles mises à niveau du noyau, sauf s'il s'agit d'une mise à niveau de version de distribution majeure.
Ruslan

3
Il y a deux aspects à considérer ici: la mise à niveau du noyau et la mise à niveau de l'espace utilisateur. Grâce à la stabilité ABI du noyau, la mise à niveau du noyau est assez sûre (même avec /procet /syschange généralement - les suppressions prennent des années). Cependant, la mise à niveau de l'espace utilisateur peut nécessiter un nouveau noyau, et vous pouvez vous retrouver avec un système non amorçable si vous n'avez pas un noyau suffisamment nouveau. Les notes de mise à jour de Distro le mentionnent le cas échéant (alors ne mettez pas à jour les distributions à l'aveugle, lisez les notes de mise à jour).
Stephen Kitt

1
Il existe des directives pour les fichiers / proc et / sys et la façon dont l'espace utilisateur doit les lire afin de permettre l'ajout de champs dans les noyaux plus récents. / proc / stat par exemple, ou / proc / meminfo. L'espace utilisateur doit ignorer les champs ajoutés.
Zan Lynx,

11

Le noyau Linux et l'espace utilisateur d'une distribution Linux, qui était historiquement dominé par les outils utilisateur développés par le projet GNU, sont vaguement couplés. C'est en partie par conception, et en partie par nécessité.

Contrairement aux BSD, où le noyau ainsi que l'espace utilisateur de base sont conçus et maintenus ensemble, le noyau Linux et son espace utilisateur ont été développés et sont maintenus par différentes personnes. Il serait donc difficile de les maintenir étroitement couplés, même si la communauté le souhaitait, ce que je ne pense pas.

Et @sebasth fait également remarquer que l'une des principales politiques du projet de noyau Linux est qu'il ne doit pas casser l'espace utilisateur. Ce qui bien sûr est un autre facteur imposant un couplage lâche.

Cependant, il existe encore un certain degré de couplage. Un noyau Linux suffisamment ancien ne fonctionnera pas avec les distributions modernes.


2
@Abigail, c'est un choix, mais une compatibilité ascendante peut être fournie, si l'espace utilisateur implémente des solutions de secours appropriées (même dégradées) pour les fonctionnalités du noyau manquantes. Ce n'est souvent pas souhaitable ni même la peine, certes, mais certains logiciels le font ( glibcpar exemple). (Mais oui, ce n'est pas une promesse de noyau, c'est une promesse d'espace utilisateur.)
Stephen Kitt

7

Ma compréhension est que Linux est le noyau, et tout le reste est accessoire. Vous pouvez certainement mettre à niveau le noyau indépendamment des (nombreux) packages installés, car ils sont généralement liés aux bibliothèques plutôt qu'au noyau lui-même. Vous ne verrez généralement qu'un tel couplage entre les versions du noyau et les pilotes matériels (par exemple les pilotes GPU). Certains logiciels ne sont compatibles qu'avec certaines versions du noyau, mais cela devrait être spécifié dans la documentation individuelle de ces programmes.

Il est assez courant d'avoir deux suites de packages de noyau installées sur un système - le package actuellement utilisé et le package précédemment installé. Lors de la mise à niveau, après vous être assuré que la nouvelle version fonctionne correctement, la plus ancienne peut être supprimée et vous disposez toujours d'une solution de secours connue. Red Hat (et ses cousins), par exemple, doit package-cleanup --oldkernels --count 2le faire automatiquement.


Même quelque chose comme kmod , que vous penseriez aurait besoin d' être lié à la version du noyau, a un peu de marge de manœuvre dans les versions il fonctionnera.
Ignacio Vazquez-Abrams

4

Outre tous les bons arguments ici, je peux ajouter quelques points qui vous aideront.

Nous connaissons déjà la politique de l'équipe du noyau, et en tant que distributions Linux, nous essayons de garder le code source du noyau aussi pur que possible. Cela signifie que chaque fois qu'une vulnérabilité survient ou quelque chose qui nécessite un correctif, nous informons l'équipe du noyau et essayons d'aider avec les correctifs, mais à la fin, la décision finale appartient à l'équipe du noyau.

Certaines distributions ajoutent des correctifs supplémentaires plus que d'autres, mais l'idée est de les conserver telles qu'elles proviennent des développeurs en amont. Évidemment, certains programmes nécessitent une configuration spéciale du noyau, en particulier la virtualisation et des pilotes tiers et généralement, les deux sont utilisés pour fonctionner avec une version spécifique du noyau ou au moins une version pas trop ancienne ... la raison en est qu'ils essaient pour fonctionner avec les dernières fonctionnalités du noyau et à cause de cela, si vous essayez de les exécuter avec un ancien noyau, elles peuvent ne pas fonctionner correctement.

Un élément supplémentaire à garder à l'esprit est que toutes les distributions Linux ont une équipe de responsables, des personnes qui s'assurent que tous les logiciels sont compatibles avec le système. C'est pourquoi presque chaque distribution a une version stable et une version instable. Les développeurs travaillent avec un logiciel "instable" et quand tout est testé, ils le marquent comme stable, seulement après qu'un utilisateur normal peut mettre à jour le package, donc si la personne qui vous a demandé est un utilisateur normal est sûre à 90% que le logiciel est bien testé .

Donc, qui est, la communauté, et quelle devrait être l'approche commune, nous avons besoin de logiciels travaillant ensemble, et non de casser le système, c'est pourquoi nous essayons de suivre certaines normes comme Filesystem Hierarchy Standard .

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.