Comment rester en stable tout en ayant les derniers noyaux

Trucs et Astuces
#1

Vu que j’ai du répondre à cette question plusieurs fois je mets donc cette petite astuce qui m’a bien aider et que j’ai découvert avec l’aide de MattOTop

Les nouveaux noyaux sont d’abord testés en unstable et ne sont donc pas directement accessible en stable ou testing. Sid étant la version unstable de debian, il peut être difficile de l’utiliser due aux nombreuses mises à jour disponibles régulièrement (risque de bug). Mais, elle possède l’avantage d’avoir les dernières versions des logiciels. Les nouveaux noyaux étant d’abord intégrés sous sid (unstable), il n’est pas forcement obligatoire d’y passer pour avoir les derniers noyaux sortis.

L’astuce consiste en fait à utiliser un moyen de préférer la provenance de certains paquets. Pour cela, il nous faut rajouter un fichier “/etc/apt/preferences” et de modifier notre fichier “/etc/apt/sources.list” afin qu’il prenne toutes les sources disponibles (stable testing et unstable).
Pour le fichier “/etc/apt/preferences” il faut lui préciser les différentes priorités d’install, pour cela nous avons différentes priorités représentées par des nombres :

* 1001 : Le package ne sera jamais remplacé par APT
* 1000 : idem, mais APT refusera d'installer le package si une autre version est déjà présente.
* 990 : Le package ne pourra être remplacé que si une version supérieure est disponible dans la distribution utilisée
* 500 : Toute version du package supérieure à celle présente sera installée.
* 100 : Toute version du package, supérieure ou inférieure, remplacera la version en place
* -1 : On empêche un package (ou une version spécifique) d'être installé.

Un exemple parle en général mieux qu’un long discours

Le fichier /etc/apt/preferences

[code]Package: *
Pin: release a=testing
Pin-Priority: 550

Package: *
Pin: release a=apt-build
Pin-Priority: 990

Package: *
Pin: release a=stable
Pin-Priority: 550

Package: *
Pin: release a=unstable
Pin-Priority: 33

Package: *
Pin: release a=experimental
Pin-Priority: 15

Package: linux-source-2.6.*
Pin: release a=unstable
Pin-Priority: 550

Package: mozilla-firefox
Pin: release a=unstable
Pin-Priority: 550[/code]

Dans cet exemple, la distribution testing est préférée aux autres mais les paquets mozilla-firefox et toutes les nouvelles sources du noyau linux-source-2.6.* seront pris dans les paquets prévus pour Sid. Ainsi, nous restons en testing tout en ayant les dernières sources du kernel et ici du navigateur firefox. Il ne reste plus qu’à recompiler son noyau et le tour est joué.

Le fichier /etc/apt/sources.list

[code]

Stable

deb http://security.debian.org stable/updates main contrib non-free

deb-src http://security.debian.org/ stable/updates main contrib non-free
deb http://ftp.fr.debian.org/debian stable main contrib non-free
deb-src http://ftp.fr.debian.org/debian stable main contrib non-free

Testing

deb http://security.debian.org etch/updates main contrib non-free
deb-src http://security.debian.org/ etch/updates main contrib non-free
deb http://ftp.fr.debian.org/debian etch main contrib non-free
deb-src http://ftp.fr.debian.org/debian etch main contrib non-free

Unstable

deb http://ftp.fr.debian.org/debian unstable main contrib non-free
deb-src http://ftp.fr.debian.org/debian unstable main contrib non-free

#mirroir video et autre http://debian.video.free.fr/
deb ftp://ftp.nerim.net/debian-marillat/ sarge main
deb ftp://ftp.nerim.net/debian-marillat/ etch main

Skype

deb http://download.skype.com/linux/repos/debian/ stable non-free

WINE

deb http://wine.sourceforge.net/apt/ binary/
deb-src http://wine.sourceforge.net/apt/ source/

Package non officiel

deb http://ftp.debian-unofficial.org/debian sarge main contrib non-free restricted
deb-src http://ftp.debian-unofficial.org/debian sarge main contrib non-free restricted

Videolan VLC

deb http://download.videolan.org/pub/videolan/debian sarge main
deb-src http://download.videolan.org/pub/videolan/debian sarge main

Postgresql interface graphique

deb ftp://ftp2.fr.postgresql.org/postgresql/pgadmin3/release/debian testing pgadmin[/code]

Cette astuce fonctionne pour tous les paquets, il est possible, pour ceux ne voulant pas recompiler leur noyau mais d’avoir quand meme le dernier, de remplacer “linux-source-2.6." par "linux-image-2.6.” dans le fichier preferences afin d’avoir directement l’image et ne pas avoir à recompiler.

Tout est une histoire de privilège pour plus d’info voir andesi.org/index.php?node=130

Toutes corrections ou complément d’info est apprécié
et pour ceux qui veulent recompiler leurs kernel forum.debian-fr.org/viewtopic.php?t=1806

#2

A propos des derniers noyaux, j’ai pas encore tout pigé… :blush:

Si par exemple, je fais une recherche des paquets disponibles pour le 2.6.14
Ca me retourne quelque chose comme:

linux-source-2.6.14 - Linux kernel source for version 2.6.14 with Debian patches
linux-tree-2.6.14 - Linux kernel source tree for building Debian kernel images
linux-patch-debian-2.6.14 - Debian patches to version 2.6.14 of the Linux kernel
linux-headers-2.6.14-2-amd64-generic - Header files for Linux kernel 2.6.14 on all x86-64 machines

Bon,on y va dans l’ordre ci-dessus:

linux-source-2.6.14 - Linux kernel source for version 2.6.14 with Debian patches[/b]
Ca, je pense avoir compris … :laughing: : Ce sont les sources du kernel dernier-cri patché à la mode Debian…

linux-tree-2.6.14 - Linux kernel source tree for building Debian kernel images
Et ce machin là, ça sert à quoi ? C’est pas la même chose que les sources citées plus haut ?

linux-patch-debian-2.6.14 - Debian patches to version 2.6.14 of the Linux kernel
Et avec celui-ci, je peux prendre les sources sur kernel.org et les “debianiser” avec ce package ?

linux-doc-2.6.14 - Linux kernel specific documentation for version 2.6.14
Et ce package-ci, il est pas déjà inclu avec le package des sources ?

linux-image-2.6.14-1-amd64-k8 - Linux kernel 2.6.14 image on AMD64 K8 machines
Et pour l’image précompilée, le N° de release “-1”, c’est spécifique à Debian, me semble-il ?

#3

sources et patchs permettent de produire tout ce dont on a besoin:
les sources arrivent déjà patchées, et le paquets de patchs permet soit de dépatcher une partie des patchs debian, ou au contraire d’appliquer les patch debian à un noyau non standard venu de kernel.org (avec make-kpkg debian).
tree est un métapackage qui dépend des deux premiers.
docs est un paquet produit par make-kpkg buildpackage, qui fabrique aussi les headers, mais si les docs sont incluses dans les sources, elles n’y sont pas organisées comme pdans le paquet docs.
pour le -1, tu as raison, c’est debian. Cela signifie qu’il a été compilé avec les sources ‘-1’. même si ca n’apparait pas dans le nom du paquet source (on en est au “-4”), ca apparait dans le nom du paquet binaire.

#4

J’ai modifié le premier topic si vous avez des remarques/corrections n’hésitez pas

#5

Salut à tous,
Et pourquoi utiliser les paquets Debian ?.. Je préfère compiler mes noyaux : ça me fait monter un peu en pression, mais c’est super marrant. Et sans risque puisque si ça plante, on peut toujours démarrer avec l’ancien noyau et supprimer celui qui plante.
J’utilise la méthode d’alexis qui permet d’installer les noyaux fabriqués avec dpkg -i (installer) et de les supprimer (si ça foire) avec dpkg -r !

Outre le fait qu’on apprend plein de choses sur la configuration du noyau (mais cela ne se fait qu’au prix de recompilations nombreuses pour cause de kernel panic !), on finit par bien connaître sa machine et donc à supprimer toutes les options inutiles du noyau, ou à les charger en modules pour ne pas l’alourdir…

J’ai mis plusieurs semaines à bien maîtriser la compilation mais à présent, ça roule !

Et, cerise sur le gâteau, on peut se payer le luxe d’utiliser le TOUT dernier noyau dispo sur kernel.org, ce qui est mon cas.
Joel

#6

[quote]J’utilise la méthode d’alexis qui permet d’installer les noyaux fabriqués avec dpkg -i (installer) et de les supprimer (si ça foire) avec dpkg -r !

Outre le fait qu’on apprend plein de choses sur la configuration du noyau (mais cela ne se fait qu’au prix de recompilations nombreuses pour cause de kernel panic !), on finit par bien connaître sa machine et donc à supprimer toutes les options inutiles du noyau, ou à les charger en modules pour ne pas l’alourdir… [/quote]
Tu peux faire la m^ chose avec une image Debian.
J’ai installé le 2.6.16 en paquet Debian sur ma Sid et je le configure ensuite à la mode “Ricardo”.
Si j’ai un problème, je peux aussi revenir à l’ancien noyau.

#7

[quote=“mirus”]Salut à tous,
Et pourquoi utiliser les paquets Debian ?.. Je préfère compiler mes noyaux : ça me fait monter un peu en pression, mais c’est super marrant. Et sans risque puisque si ça plante, on peut toujours démarrer avec l’ancien noyau et supprimer celui qui plante.[/quote]Parce qu’il sont fait pour ça si tu préfère compiler fait le à la méthode debian voir forum.debian-fr.org/viewtopic.php?t=1806[quote=“mirus”]
J’utilise la méthode d’alexis qui permet d’installer les noyaux fabriqués avec dpkg -i (installer) et de les supprimer (si ça foire) avec dpkg -r !
[/quote]C’est tout aussi faisable avec la méthode préciser dans ce post ainsi que dans celui auquel je fait référence[quote=“mirus”]
Outre le fait qu’on apprend plein de choses sur la configuration du noyau (mais cela ne se fait qu’au prix de recompilations nombreuses pour cause de kernel panic !), on finit par bien connaître sa machine et donc à supprimer toutes les options inutiles du noyau, ou à les charger en modules pour ne pas l’alourdir…[/quote]Je ne vois pas trop la différence entre recompiler un noyau avec les sources debian et recompiler son noyau avec les sources de kernel.org mis a part le fait que c’est plus chiant à faire avec celle trouvé sur kernel.org car[quote=“MattOTop”][quote=“fsoumil”][quote=“MattOTop”]non: les sources de kernel.org sont à éviter, car elles ne sont pas préparées pour debian. Il faut les charger avec apt-get.
[/quote]
En quoi ces sources posent problèmes ? C’est toujours celles-là que j’utilisent et je n’ai jamais eu de problème…[/quote]
comme il est dit dans “Debian Linux Kernel HandBook” ( kernel-handbook.alioth.debian.org/ch-source.html ), la fabrication des sources debian noyaux sont patchées en plusieurs étapes:
1/prune-non-free, qui supprimme les parties sous license douteuse et les mets dans des paquetages à part (ca, c’est un peu precautionneux, et ca peut etre génant, mais bon),
2/installation de patchs variés spécifique debian, qui comblent des failles, OU FOURNISSENT DES FONCTIONNALITES SPECIFIQUES ESSENTIELLES POUR DEBIAN.
En fait, c’est cette dernière étape qui rend spécifique le noyau debian. Il y a des patchs “de sécurité” dont on peu se passer, mais il y a parfois des patchs essentiels pour la logique debian, comme le patch cramfs, qui est désormais intègré au noyaux kernel.org, mais qui a longtemps été nécessaire au bon fonctionnement des outils d’initrd debian.
Ca n’empêche pas de trouver des solutions “à la main” qui permettent de compiler des noyaux avec les sources kernel.org, mais autant rester en sources debian, que les equipes debian-kernel ne bossent pas pour rien… :laughing:[/quote]Voila pourquoi il faut éviter les sources de kernel.org apres si tu fait le nécessaire pour que ca fonctionne en patchant tant mieux mais tu t’embette vraiment pour rien puisque c’est déjà fait par l’équipe debian

[quote=“mirus”]J’ai mis plusieurs semaines à bien maîtriser la compilation mais à présent, ça roule !
[/quote]Ce n’est pas franchement compliquer mais il faut du temps pour connaitre toutes les options nécessaires a notre matériel[quote=“mirus”]Et, cerise sur le gâteau, on peut se payer le luxe d’utiliser le TOUT dernier noyau dispo sur kernel.org, ce qui est mon cas.
Joel[/quote]je te renverrai au post de MattOTop ci-dessus. Tu recompile ton kernel c’est bien mais fait le à la méthode debian sur une debian ce qui en aucun cas t’empeche de l’ajouter ou de le virer avec dpkg.
apres une installation du dernier kernel-image je peux le retirer si j’en ai envie
apres une installation des sources compilation de celles-ci pour mon architecture je peux tres bien les retirers si j’en ai envie aussi.
Ta méthode n’apporte rien de spécifique mis à part quelques soucis en plus lors de la recompilation du kernel avec les sources sur kernel.org pourquoi faire simple quand on peux faire compliquer :slightly_smiling:

#8

Comment se passe l’installation d’un kernel-image?
Bien! :laughing:
Non je veux dire:
Est-ce que l’ancien noyau est conservé, au boot suivant on choisit le noyau voulu dans grub (ou lilo)? Ou est-ce que le noyau est remplacé et au boot suivant il ne reste que le nouveau noyau et le noyau de secour?

Est-ce qu’a la suite du changement de noyau il faudra mettre à jour beaucoup de paquets ou est-ce que cela ne change rien pour les paquets installés?

#9

L’installation est la même que pour les sources c’est juste le nom du paquet qui change. Sinon l’install se passe bien :slightly_smiling:

L’ancien noyau est effectivement conservé une autre entrée est ajouté a grub automatiquement pour lilo normalement aussi mais il se peut d’etre obligé de le faire manuellement. Il n’y a pas de remplacement :wink:

Les seuls paquets à mettre à jour seraient ceux des différents modules que tu utilise avec le noyau mais en ce qui concerne les autres non pas de modifications.

#10

j’ajouterais que la mise à jour de grub ne se fait pas forcément automatiquement (ça dépend de la configuration du post-install hook dans la config de /etc/kernel-img.conf).
Si le nouveau noyau n’apparait pas, un update-grub fera la mise à jour de grub.
Pour lilo, il suffit de reliloter: par défaut, les entrées linux et linux-old utilisent des liens symboliques pointant ver le dernier et l’avant dernier noyau installé, et ces liens sont mis à jour lors de l’install du paquet noyau.

#11

Qu’est-ce qu’il se passera si j’essaye de redemarrer sur l’ancien noyau après avoir mis les modules à jour?

#12

Qu’est-ce qu’il se passera si j’essaye de redemarrer sur l’ancien noyau après avoir mis les modules à jour?[/quote]
Les deux installs sont séparées tu disposes des modules des deux noyaux en parallèle. Le nouveau noyau ne touche à rien de l’ancien.

#13

Qu’est-ce qu’il se passera si j’essaye de redemarrer sur l’ancien noyau après avoir mis les modules à jour?[/quote]
Les deux installs sont séparées tu disposes des modules des deux noyaux en parallèle. Le nouveau noyau ne touche à rien de l’ancien.[/quote]

A ce sujet, je me suis toujours demandé si c’etait logique d’avoir un seul /etc/modules (ou plus généralement /etc/mod*) , alors que c’est dependant du noyau&modules lancé. J’aurai bien vu tout /etc/mod* aussi dans /lib/modules, un par noyau.

#14

En parlant des images kernel et tout…

C’est quoi la difference entre les kernel-header et les kernel-image ?