[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Pb d'évolution système vers la branche instable.



Le 27/04/2010 14:22, David Prévot a écrit :
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 27/04/2010 06:59, Patrice Pillot a écrit :
Le 26/04/2010 18:19, David Prévot a écrit :
Le 26/04/2010 10:51, michael.van-nieuwenhoven@laposte.net a écrit :
En consultant les archives, je n'ai pas trouvé de réponse analogue...

Probablement parce que le message d'erreur est suffisamment explicite.

[...]
Please upgrade your kernel before or while upgrading udev.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(et la suite)

... qui est tout aussi importante :
« you can force the installation of this version of udev, WHICH DOES NOT
WORK WITH YOUR RUNNING KERNEL AND WILL BREAK YOUR SYSTEM AT THE NEXT
REBOOT by creating the /etc/udev/kernel_upgrade file. »

Michael est bloqué par le fait que le noyau qu'il veut installer a
une dépendance sur une version de udev [...]

Ce n'est pas tout à fait exact : le noyau ne dépend pas d'udev (on peut
même se passer complètement d'udev).

J'aurai dû être plus précis c'est vrai mais cette remarque n'est elle non plus pas tout à fait exacte ;-) : le noyau dépend d'initramfs et c'est initramfs qui dépend d'udev et je ne vois donc pas comment on peut se passer d'udev avec les paquets Debian livrés par défaut - mais je rate peut-être une étape.

Lors d'un full-upgrade aptitude va donc essayer d'installer les versions les plus récentes de ces deux paquets et l'utilisateur se retrouver dans la situation de Michael. Pour ne pas rentrer dans la boucle décrite dans mon précédent message, il est vrai qu'on peut aussi bloquer udev dans sa version et n'installer que le noyau, puis rebooter, puis continuer l'upgrade, c'est cette décomposition que proposait David et que je n'avais pas bien comprise. Dans le cas de

Michael, il me semble qu'il sera cependant plus simple de créer le fichier /etc/udev/kernel_upgrade et de faire un full-upgrade car une fois que le paquet récent d'udev est dans le cache de dpkg il devient difficile de faire machine arrière...

Dans la perspective de la release de squeeze, la solution proposée par David est incontestablement plus sûre (et effectivement je crois me souvenir que ça avait été le cas lors du passage de sarge à etch) mais combien de personnes liront les notes de versions...


Reply to: