Reboot après mise à jour du noyau

Je ne suis pas d’accord. Qu’est-ce qui te fait dire cela ?
Pour moi, le numéro de version dans le nom du paquet change si l’ABI change. Dans ce cas ce n’est pas une mise à jour du paquet noyau existant qui s’installe avec apt-get upgrade mais un nouveau paquet noyau différent qui ne s’installe pas à la place mais à côté du noyau existant (exemple : 2.6.26-1 à 2.6.26-2) avec un apt-get dist-upgrade, et seulement si le méta-paquet qui dépend de la dernière version disponible est installé.

Salut à tous et merci de me consacrer de votre temps.

Oui mais comment le savoir ? Je suppose, après avoir relu ce topic, que cela se situe dans les changelogs. Mais je viens de regarder là : kernel.org/ , je n’ ai pas la version de mon noyau, on parle bien d’ une version 2.6.32.24 , mais pas du mien qui est je le rappelle un 2.6.32-5-kirkwood .

[quote] Dans tous les cas, il vaut mieux redémarrer dès que possible.
Tout dépend de ce sur quoi porte la mise à jour.
Si elle corrige une faille présente dans l’image du noyau (vmlinuz), il faut redémarrer.
Si elle corrige une faille présente dans un module chargé, il faut le décharger et le recharger. Quand c’est possible, donc pas quand le module est nécessaire au montage de la racine par exemple, sinon il faut redémarrer.
Si on ne sait pas, il faut redémarrer.

Dans tous les cas, il vaut mieux redémarrer dès que possible.
[/quote]
Mais comment font ceux qui ont un uptime de plusieurs mois ? C’ est vrai que j’ai une version testing, mais il doit y avoir quand même des mises à jour qui oblige à rebooter, même en stable. ?

Pour un noyau Debian, il faut regarder le changelog du paquet Debian. Accessible sur le site dans la section “Paquets Debian”. Pour linux-image-2.6.32-5-kirkwood, <http://packages.debian.org/fr/squeeze/linux-image-2.6.32-5-kirkwood>.

Aussi il faut regarder si les correctifs concernent l’architecture. Un correctif pour x86 (i386 ou amd64) ne concerne pas l’architecture armel.

Ils ne sont pas forcément concernés par les correctifs, notamment s’ils ont compilé un noyau juste avec les options nécessaires. Aussi il n’y a pas si longtemps j’utilisais encore le noyau 2.4 sur une machine, et il n’y a pas eu de mise à jour pendant plus de six mois. Ou bien ils peuvent utiliser Ksplice pour patcher le noyau à chaud sans redémarrage. Ou bien ils s’en fichent. Ou bien la machine est isolée. Ce n’est pas parce qu’on est vulnérable qu’on va forcément se faire trouer. La plupart des failles sont locales, donc pas forcément faciles à exploiter depuis l’extérieur sans compte d’utilisateur local.

Je ne suis pas d’accord. Qu’est-ce qui te fait dire cela ?
Pour moi, le numéro de version dans le nom du paquet change si l’ABI change. Dans ce cas ce n’est pas une mise à jour du paquet noyau existant qui s’installe avec apt-get upgrade mais un nouveau paquet noyau différent qui ne s’installe pas à la place mais à côté du noyau existant (exemple : 2.6.26-1 à 2.6.26-2) avec un apt-get dist-upgrade, et seulement si le méta-paquet qui dépend de la dernière version disponible est installé.[/quote]

C’est ce que j’avais cru comprendre, ça me paraissait logique et ça a été conforme aux (rares) fois où j’ai regardé les changelog. Ce que tu dis est également cohérent. Il faudrait vérifier sauf si tu es sur de toi (moi pas plus que ça…)

Je n’ai pas de certitude absolue, mais le passage de la version 2.6.26-1 à 2.6.26-2 a eu lieu à l’occasion de la première révision de lenny (5.0.1) avec un changement d’ABI, et non lors d’une simple mise à jour de sécurité.
http://www.debian.org/News/2009/20090411
http://packages.debian.org/changelogs/pool/main/l/linux-2.6/linux-2.6_2.6.26-25lenny1/changelog#versionversion2.6.26-14

Re,
Donc je viens de regarder le changelog (rubrique journal des modifications, c’ est bien ça ?) : packages.debian.org/changelogs/p … on2.6.32-5 .

Je n’ arrive pas trop à interpréter, apparament on ne parle pas de faille :

[code] [ Ben Hutchings ]

  • sfc: Apply fixes from 2.6.33-rc3
  • ath5k: Fix eeprom checksum check for custom sized eeproms
    (Closes: #563136)

[ maximilian attems ]

  • topconfig unset USB_ISP1362_HCD FTBFS on armel and useless.
    (closes: #564156)
  • topconfig set PATA_ATP867X, PATA_RDC, SND_CS5535AUDIO, PM_RUNTIME,
    ATA_VERBOSE_ERROR, RTC_DRV_WM831X, RTC_DRV_PCF2123, RTC_DRV_AB3100,
    SND_HDA_PATCH_LOADER, DEVTMPFS (closes: #560040).
  • [x86] set RTL8192E, TOPSTAR_LAPTOP, I2C_SCMI.
  • Explicitly disable diverse staging drivers.
    [/code]

Ce qui est noté concerne bien la mise à jour qui a du tombé ce week end en ce qui me concerne ?
Merci pour votre patience.

C’est le bon journal, mais tu n’as pas cherché la bonne version. Tu as confondu la version du noyau et la version du paquet.

La version du noyau est celle qui apparaît dans le nom du paquet binaire, et qui est affichée par la commande uname -r lorsque le noyau est actif. Exemple : 2.6.32-5-kirkwood. Elle contient la version de base du noyau (2.6.26), la version de l’ABI (-5) et le “genre” représentatif des options de compilation (-kirkwood).

La version du paquet est… la version du paquet binaire et du paquet source dont il est issu, comme n’importe quel paquet Debian. Ele est constituée de la version de base du noyau et d’un numéro d’ordre. Elle figure entre parenthèses à la suite du nom du paquet sur le site packages.debian.org, dans la section “version” de la sortie d’apt-cache show et dpkg -p…

Le nom du fichier .deb combine les deux versions : linux-image-<version.noyau><version.paquet>.deb

Dans ton cas, la dernière version du paquet linux-image-2.6.32-5-kirkwood est 2.6.32-25. On peut voir dans le journal de cette version un certain nombre de lignes avec CVE-xxxx-yyyy, qui sont les références des annonces de sécurité. Il faut les examiner pour vérifier si elles s’appliquent à son cas.

Quelques exemples :

  • drm/i915: Sanity check pread/pwrite (CVE-2010-2962)
    Si ta machine n’a pas un contrôleur graphique Intel i915, tu n’es pas concerné.

  • GFS2: Fix writing to non-page aligned gfs2_quota structures (CVE-2010-1436)
    Si tu n’utilises pas le système de fichiers GFS2, tu n’es pas concerné.

  • ALSA: prevent heap corruption in snd_ctl_new() (CVE-2010-3442)
    Si tu n’utilises pas ALSA (audio), tu n’es pas concerné.

  • sctp: Fix out-of-bounds reading in sctp_asoc_get_hmac() (CVE-2010-3705)
    Si tu n’utilises pas le protocole SCTP, tu n’es pas concerné.

Etc. Dans le doute, tu redémarres.

Tu veux dire ici : packages.debian.org/changelogs/p … /changelog , il y a bien une modification faite le 14 Octobre, et qui comporte les éléments dont tu fais références.

Oui. Cette modification a changé la version du paquet (2.6.32-25), mais pas la version du noyau (2.6.32-5-kirkwood).

[quote]Oui. Cette modification a changé la version du paquet (2.6.32-25), mais pas la version du noyau (2.6.32-5-kirkwood).

[/quote]

Merci de m’ avoir appris cette notion que j’ ignorais…

Je viens seulement de pouvoir me connecter, le forum avait quelques problèmes ce soir, je regarderai mieux demain la totalité des modifications. Certaines sont évidentes, d’ autres un peu moins, mais la plupart semble ne pas me concerner.

Bonne soirée !

Salut,
Dans les Changelogs il y a pas mal de choses visiblement qui ne me concernent pas, mais d’ autres… Je ne vais pas vous embéter à chaque fois, dans le doute je vais rebooter. Mais cela me servira les prochaines fois, peut etre que dans une prochaine mise à jour, il me sera plus facile d’ y voir plus clair, et que cela m’ évitera un reboot inutile.

Encore merci pour votre aide, bonne soirée !

Bonsoir,
Je refais appel à vous.

Je lance un aptitude -s dist-upgrade et j’ obtiens parmis les mises à jour :

Je regarde le changelog : packages.debian.org/changelogs/p … /changelog
Mais je ne vois rien concernant la modification…

Pourquoi ?

Hello,
Je me réponds à moi même, peut etre que l’ on est passé à la version 2.6.32.27, c’ est pour cela qu’ il n’ y avait rien dans les logs précités…