Comment s'opère la mise à jour du noyau dans Stretch ? [Etait: Pourquoi linux-headers-`uname r` échoue sur St retch et pas sur Jessie ?]

Le
Olivier
--001a113df77447ca54054ad4de93
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Bonjour,

J'ai installé il y a quelques semaines deux machines sous Stretch ave=
c
l'installeur en vigueur à l'époque. Régulièrement, j'op=
ère sur ces machines
une séquence "apt-get update; apt-get -y upgrade".

Sur chaque machine, j'observe que le noyau est en version 4.8.

J'ai installé ce matin 2 VM (1 en i386, 1 en amd64) à partir de l=
a version
rc2 de l'installeur .
Sur chacune, le noyau est en 4.9.


1. J'imaginai que sur Stretch, une séquence "apt-get update; apt-get -=
y
upgrade" change automatiquement la version du noyau, s'il y a lieu.
En d'autres termes, j'imaginai qu'une machine installée en Janvier, mi=
se à
jour avec "apt-get update; apt-get -y upgrade" aurait exactement les m=
mes
versions de logiciel qu'une nouvelle machine installée le jour mê=
me.
Est-il exact d'imaginer cela ?

2. Si non, existe-t-il une commande "idempotente" (ie qui ne fait rien si
la version du noyau n'a pas changé mais qui fait la mise à jour q=
uand le
noyau a changé) qui apporte ce changement de version ?

Slts

Le 14 mars 2017 à 15:36, Jean-Marc <jean-marc@6jf.be> a écrit :

> Tue, 14 Mar 2017 14:29:57 +0100
> Olivier <oza.4h07@gmail.com> écrivait :
>
> > # uname -r
> > 4.8.0-2-686-pae
> >
> > # apt-get install linux-headers-`uname -r`
> > Lecture des listes de paquets Fait
> > Construction de l'arbre des dépendances
> > Lecture des informations d'état Fait
> > E: Impossible de trouver le paquet linux-headers-4.8.0-2-686-pae
> > E: Couldn't find any package by glob 'linux-headers-4.8.0-2-686-pae'
> > E: Impossible de trouver de paquet correspondant à l'expression
> rationnelle
> > « linux-headers-4.8.0-2-686-pae »
>
> Je viens de faire une recherche sur le site de Debian et il n'existe plus
> que 2 ou 3 paquets pour la version 4.8 et uniquement dans les backports d=
e
> Jessie.
>
> Donc, je pense que c'est normal que apt-get ne puisse pas installer un
> paquet qui n'existe plus.
>
>
> Bien à toi,
>
>
> Jean-Marc <jean-marc@6jf.be>
>

--001a113df77447ca54054ad4de93
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir="ltr"><div><div><div><div><div><div>Bonjour,<br><br></div><div>J=
&#39;ai installé il y a quelques semaines deux machines  sous Str=
etch avec l&#39;installeur en vigueur à l&#39;époque. Réguli=
èrement, j&#39;opère sur ces machines une séquence &quot;apt=
-get update; apt-get -y upgrade&quot;.</div><div><br>Sur chaque machine, j&=
#39;observe que le noyau est en version 4.8.<br></div><br></div>J&#39;ai in=
stallé ce matin 2 VM (1 en i386, 1 en amd64) à partir de la versi=
on rc2 de l&#39;installeur .<br></div>Sur chacune, le noyau est en 4.9.<br>=
<br><br></div>1. J&#39;imaginai que sur Stretch, une séquence &quot;ap=
t-get update; apt-get -y upgrade&quot; change automatiquement la version du=
noyau, s&#39;il y a lieu.<br></div><div>En d&#39;autres termes, j&#39;imag=
inai qu&#39;une machine installée en Janvier, mise à jour avec &=
quot;apt-get update; apt-get -y upgrade&quot; aurait exactement les mê=
mes versions de logiciel qu&#39;une nouvelle machine installée le jour=
même.<br></div>Est-il exact d&#39;imaginer cela ?<br></div><br><div><=
div>2. Si non, existe-t-il une commande &quot;idempotente&quot; (ie qui ne =
fait rien si la version du noyau n&#39;a pas changé mais qui fait la m=
ise à jour quand le noyau a changé) qui apporte ce changement de =
version ?<br><br></div><div>Slts<br></div><div><div><div><div><div><div><di=
v><div class="gmail_extra"><br><div class="gmail_quote">Le 14 mars 2017=
à 15:36, Jean-Marc <span dir="ltr">&lt;<a target="_blank" href==
"mailto:jean-marc@6jf.be">jean-marc@6jf.be</a>&gt;</span> a écrit :<br=
><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex" class="gmail_quote">Tue, 14 Mar 2017 14:29:5=
7 +0100<br>
Olivier &lt;<a target="_blank" href="mailto:oza.4h07@gmail.com">oza.4h0=
7@gmail.com</a>&gt; écrivait :<br>
<span><br>
&gt; # uname -r<br>
&gt; 4.8.0-2-686-pae<br>
&gt;<br>
&gt; # apt-get install linux-headers-`uname -r`<br>
&gt; Lecture des listes de paquets Fait<br>
&gt; Construction de l&#39;arbre des dépendances<br>
&gt; Lecture des informations d&#39;état Fait<br>
&gt; E: Impossible de trouver le paquet linux-headers-4.8.0-2-686-pae<br>
&gt; E: Couldn&#39;t find any package by glob &#39;linux-headers-4.8.0-2-68=
6-pae<wbr>&#39;<br>
&gt; E: Impossible de trouver de paquet correspondant à l&#39;expressi=
on rationnelle<br>
&gt; « linux-headers-4.8.0-2-686-pae »<br>
<br>
</span>Je viens de faire une recherche sur le site de Debian et il n&#39;ex=
iste plus que 2 ou 3 paquets pour la version 4.8 et uniquement dans les bac=
kports de Jessie.<br>
<br>
Donc, je pense que c&#39;est normal que apt-get ne puisse pas installer un =
paquet qui n&#39;existe plus.<br>
<br>
<br>
Bien à toi,<br>
<br>
<br>
Jean-Marc &lt;<a target="_blank" href="mailto:jean-marc@6jf.be">jean-ma=
rc@6jf.be</a>&gt;<br>
</blockquote></div><br></div></div></div></div></div></div></div></div></di=
v></div>

--001a113df77447ca54054ad4de93--
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
daniel huhardeaux
Le #26429107
Le 16/03/2017 à 09:30, Olivier a écrit :
Bonjour,
J'ai installé il y a quelques semaines deux machines sous Stretch
avec l'installeur en vigueur à l'époque. Régulièrement, j'opère sur
ces machines une séquence "apt-get update; apt-get -y upgrade".
Sur chaque machine, j'observe que le noyau est en version 4.8.
J'ai installé ce matin 2 VM (1 en i386, 1 en amd64) à partir de la
version rc2 de l'installeur .
Sur chacune, le noyau est en 4.9.
1. J'imaginai que sur Stretch, une séquence "apt-get update; apt-get
-y upgrade" change automatiquement la version du noyau, s'il y a lieu.
En d'autres termes, j'imaginai qu'une machine installée en Janvier,
mise à jour avec "apt-get update; apt-get -y upgrade" aurait
exactement les mêmes versions de logiciel qu'une nouvelle machine
installée le jour même.
Est-il exact d'imaginer cela ?
2. Si non, existe-t-il une commande "idempotente" (ie qui ne fait rien
si la version du noyau n'a pas changé mais qui fait la mise à jour
quand le noyau a changé) qui apporte ce changement de version ?

C'est le paquet linux-image-[amd64|i386] qui gère. Soit il n'est pas
installé sur les 2 "anciennes" machines, soit il pointe sur le noyau 4.8
Slts
Le 14 mars 2017 à 15:36, Jean-Marc
Tue, 14 Mar 2017 14:29:57 +0100
Olivier
# uname -r
4.8.0-2-686-pae
# apt-get install linux-headers-`uname -r`
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
E: Impossible de trouver le paquet linux-headers-4.8.0-2-686-pae
E: Couldn't find any package by glob 'linux-headers-4.8.0-2-686-pae'
E: Impossible de trouver de paquet correspondant à l'expression

rationnelle
« linux-headers-4.8.0-2-686-pae »

Je viens de faire une recherche sur le site de Debian et il
n'existe plus que 2 ou 3 paquets pour la version 4.8 et uniquement
dans les backports de Jessie.
Donc, je pense que c'est normal que apt-get ne puisse pas
installer un paquet qui n'existe plus.
Bien à toi,
Jean-Marc
Jean-Marc
Le #26429134
--Signature=_Thu__16_Mar_2017_17_42_25_+0100_9Sgc=gvXQB8nlr.h
Content-Type: text/plain; charset=UTF-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Thu, 16 Mar 2017 17:21:45 +0100
Olivier
En d'autres termes, que font les utilisateurs de Stretch, qui comme moi
veulent simplement rester synchrone avec la distribution ?

Tu as essayé :
<sudo apt-get update && sudo apt-get dist-upgrade> ?
Jean-Marc --Signature=_Thu__16_Mar_2017_17_42_25_+0100_9Sgc=gvXQB8nlr.h
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEEWjgcRC0dCXkfm9hQHHLXC3pxPwFAljKwHEACgkQQHHLXC3p
xPyV7BAAlKlF/S0F+Ojnwt9YDZb4s6+SLwdUcuD9qjbAmZarOCaNx52kQLLjnS76
xQF7yP6FMcQe268F0+ho7/5rZV2N/sTtfcZet5ddFZGIL6jvqvoWA33oa0XMljBt
ZwGUyMwh1+vbFoGZRa7p68/vY13dakYJCDVQzuo3Seo2s+aGzWKQs4Lsg7Qc5hu/
dm7+4bWdzjEKnl5nFKuEnBZMxP2SUJSLOTaDpjBO/QhweitIFhE73HFFixgTrhPl
SPzqViXIg7WTFQav559uuaOEaq31xlW1ulePxJRsSowsrpLN4d1sFr7SeiCpYuSP
/bkYxFtJF4FFf8uGzGpeBPvDNvpNnLG3lsaD4VeMY6wqLS+caCthnYC7dUUZewcu
KHGlDBtM/acVoeZGC5MS3WPJLdE3uAyQZZqBMCq2uBZya39ji/MqhSv69PE3lBjp
FngupX3pZBZgiLOO6IcdI2Yqgw/1Vkqln4ZwuvXrb5gfaubBEfjtX5xTXAnfEvaZ
M1quogKJg5ZmwJBMWa6cBFpFU6uQmLOWRR/G0awznPVS+a+EPILUQ3yuLKDXpdZP
X0HgbapGhCx8ing32/j35c7B8Kc0liiwjZm+yOyeBpIw0nB7oGiYwkEBimqK+72I
yJ9yd0Rzm3jk6l4WK2OyKEVbXt8HqPDQi3TevpXqnpSN8TMtO2U =jgts
-----END PGP SIGNATURE-----
--Signature=_Thu__16_Mar_2017_17_42_25_+0100_9Sgc=gvXQB8nlr.h--
Francois Lafont
Le #26429136
On 03/16/2017 05:21 PM, Olivier wrote:
Ce que j'ai du mal à comprendre, c'est pourquoi le passage de 4.8 en 4.9 ne
s'opère pas automatiquement : je n'ai jamais spécifié la version 4.8, j'ai
à l'époque spécifié la version courante qui était la 4.8.
Si la version courante change, je m'attends à ce que mon noyau suive, ni
plus ni moins, ne serait-ce que justement, pour garder la possibilité des
en-têtes si j'en ai envie..

Que donne « dpkg -l | grep linux-image » sur ta machine ?
Normalement, c'est le principe du métapackage linux-image-amd64 de faire
ce que tu dis.
--
François Lafont
maderios
Le #26429137
On 03/16/2017 07:13 PM, Francois Lafont wrote:
On 03/16/2017 05:21 PM, Olivier wrote:
Ce que j'ai du mal à comprendre, c'est pourquoi le passage de 4.8 en 4.9 ne
s'opère pas automatiquement : je n'ai jamais spécifié la version 4.8, j'ai
à l'époque spécifié la version courante qui était la 4.8.
Si la version courante change, je m'attends à ce que mon noyau suive, ni
plus ni moins, ne serait-ce que justement, pour garder la possibilité des
en-têtes si j'en ai envie..

Que donne « dpkg -l | grep linux-image » sur ta machine ?
Normalement, c'est le principe du métapackage linux-image-amd64 de faire
ce que tu dis.

Bonjour
Il faut quand même admettre que chez Debian, la manière de nommer les
noyaux n'est pas claire et même trompeuse.
Sur Stretch
dpkg -l | grep linux-image
ii linux-image-4.9.0-2-amd64 4.9.13-1
amd64 Linux 4.9 for 64-bit PCs
(signed)
ii linux-image-amd64 4.9+79
amd64 Linux for 64-bit PCs
(meta-package)
Que vient faire ce '4.9+79' concernant le '4.9.13'? Mystère...
Avec d'autres distributions, tout ce qui concerne le même noyau porte le
même numéro. Le pire, ce sont les entrées de Grub où ne sont pas
mentionnées les versions de noyaux... On ne sait jamais où on en est
mais bon, c'est Debian... :)
--
Maderios
Francois Lafont
Le #26429158
Bonsoir,
On 03/16/2017 07:55 PM, maderios wrote:
Il faut quand même admettre que chez Debian, la manière de nommer les
noyaux n'est pas claire et même trompeuse. Sur Stretch dpkg -l | grep
linux-image ii linux-image-4.9.0-2-amd64
4.9.13-1 amd64 Linux 4.9 for
64-bit PCs (signed) ii linux-image-amd64
4.9+79 amd64 Linux for 64-bit
PCs (meta-package)

Voilà et moi par exemple sur ma Jessie j'ai ça :
ii linux-image-3.16.0-4-amd64 3.16.39-1+deb8u2 amd64
ii linux-image-amd64 3.16+63 amd64
linux-image-amd64 est un métapackage, ie il ne contient pour ainsi dire
rien ou presque comme on peut le voir avec « dpkg -L linux-image-amd64 ».
Son rôle est d'avoir une dépendance d'un paquet linux-image-W.X.Y-Z-amd64
qui lui contiendra bien un noyau Linux.
Quand le paquet linux-image-amd64 est mis à jour, c'est en fait juste
sa dépendance qui va changer et tirer avec lui l'installation d'une
nouvelle version du noyau Linux.
Si on désinstalle le package linux-image-amd64, globalement on ne
supprime rien mais on risque de passer à côté d'un changement de
numéro de version du noyau. Perso, je verrais bien le PO se trouver
dans cette situation où le paquet linux-image-amd64 n'est pas
installé.
Que vient faire ce '4.9+79' concernant le '4.9.13'? Mystère... Avec
d'autres distributions, tout ce qui concerne le même noyau porte le
même numéro. Le pire, ce sont les entrées de Grub où ne sont pas
mentionnées les versions de noyaux... On ne sait jamais où on en est
mais bon, c'est Debian... :)

Faut reconnaître que la nomenclature des numéros de version, c'est
un peu compliqué parfois, même si dans les grandes lignes ça correspond
souvent à quelque chose de simple comme (c'est le premier exemple que
m'est venu sous ma Jessie) :
python3-minimal => 3.4.2-2
qui signifie que le paquet est basé sur la version 3.4.2 du programme
upstream (ie Python3 en l'occurrence ici) et "-2" correspond au numéro
de révision du paquet. Après, ça peut être plus compliqué que ça et il
y a de la doc ici par exemple :
https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
Après, pour le « 4.9+79 » du package linux-image-amd64, c'est vrai
que c'est pas super clair. On peut imaginer que le 4.9 correspond
à la version du noyau qui se cache derrière le métapackage (jusque
là je me mouille pas trop). Quant au "+79", j'ai bien l'impression
qui'l est incrémenté tout simplement à chaque mise à jour du paquet
linux-image-amd64. On peut s'en rendre compte en parcourant son
changelog :
zcat /usr/share/doc/linux-image-amd64/changelog.gz | less
Par exemple lors du passage du noyau 3.13 à 3.14, ce numéro est
tout simplement passé de 56 à 57. Mais oui, dans le détail, la
nomenclature des numéros de version c'est un peu compliqué.
--
François Lafont
Jean-Marc
Le #26429210
--Signature=_Fri__17_Mar_2017_10_34_27_+0100_frEBnf6J4Nll4wC7
Content-Type: text/plain; charset=UTF-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Fri, 17 Mar 2017 10:26:49 +0100
Olivier salut,
$ sudo apt-get -s dist-upgrade
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Calcul de la mise à jour... Fait
Les paquets suivants ont été installés automatiquement et ne sont plus
nécessaires :
bijiben libsofia-sip-ua-glib3 libsofia-sip-ua0 telepathy-rakia
Veuillez utiliser « sudo apt autoremove » pour les supprimer.
Les NOUVEAUX paquets suivants seront installés :
firmware-linux-free gnome-calendar irqbalance libopenmpt0 libpgm-5.2-0
libproxy1-plugin-gsettings
libproxy1-plugin-networkmanager libsaxonhe-java
linux-image-4.9.0-2-686-pae
Les paquets suivants seront mis à jour :
gnome gnome-core gstreamer1.0-libav libavdevice57 libavfilter6
libavformat57 libgegl-0.3-0 libopencv-calib3d2.4v5
libopencv-core2.4v5 libopencv-features2d2.4v5 libopencv-flann2.4v5
libopencv-highgui2.4-deb0 libopencv-imgproc2.4v5
libopencv-objdetect2.4v5 libopencv-video2.4v5 libxmlbeans-java libzmq5
linux-image-686-pae
18 mis à jour, 9 nouvellement installés, 0 à enlever et 0 non mis à jour.
Si j'en crois ce qui précède, linux-image n'est pas mis à jour par
dist-upgrade.

Si tu regardes attentivement, tu verras linux-image-686-pae dans la liste d es paquets qui seront mis à jour et linux-image-4.9.0-2-686-pae dans l a liste des nouveaux paquets.
Je pensais que c'est ce que tu voulais.
Jean-Marc --Signature=_Fri__17_Mar_2017_10_34_27_+0100_frEBnf6J4Nll4wC7
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEEWjgcRC0dCXkfm9hQHHLXC3pxPwFAljLraMACgkQQHHLXC3p
xPw4Dg/9FRhPnObIkJ+Il1vksgO3QQN1HDVbVA2F+0UHWeaf9wW5vUAUH5GDWb+4
y8Hdbu+J1f7+YuSSPWZbCipQK6U/aJBVUp7L8VV0Ryy+ng2qHK6pp6xn7KZHzDqD
/GltckpPtWBA2mT1jy5F5MYuThigfNjzG53LwffGI1v4ooV/O1gOJp5zTpl3oXs7
8pUQEHL6+0qf/WWzae4/FGIXo1o3bppF1JYJwI3PjU+5zGmbxHLQWEzWc8j6u+t9
Pvxj2j8SXLfHYRdi5dKe5Q3M+jy/EC/YdtWED2B1bHTNR5twmcdxhZfAjsosq2TH
gigDwihdcmaAUTuYXhGJ0fJvPiFq346ufv/hPK4LkNrsE4TF4Iba8Vo6i5iyo9R/
bx6C/sHx/g5FboiY/bQiUIeWsCM75XgGcLZp1pdOunYx1FHPykcqlnBPRaErr2q0
5iRAVdYUqR+PHwzOeQpojV/Iy6pD9145TNNNi99wdi9eCcTMO9AiWu0X/CGDwWlr
m+TXsnrCaFBTdaiu6KE1pVmD43QVgG7RL1hNNyK/eBsRNWwVFCn2dmntqhFLc/uq
RyqVzCzN14IoEdRbVPdHPPoO3odKumwCWU4fiu03ScwsSrFMkpE5kgDMrHXx6vrF
AAv1OLa3uDpCEBPdgS3ENfv+jeXhUVIhdeSRegB+JYNjw/L5bOs =t0bw
-----END PGP SIGNATURE-----
--Signature=_Fri__17_Mar_2017_10_34_27_+0100_frEBnf6J4Nll4wC7--
Publicité
Poster une réponse
Anonyme