[RESOLU] Erreur lors de la MAJ du noyau sur Etch

Support Debian
#1

J’ai un serveur sur Etch, j’ai essayé de mettre à jour le noyau et voilà l’erreur qui m’est retournée :

Setting up linux-image-2.6.18-6-686 (2.6.18.dfsg.1-18etch4) ... Running depmod. Finding valid ramdisk creators. Using mkinitramfs-kpkg to build the ramdisk. Not updating initrd symbolic links since we are being updated/reinstalled (2.6.18.dfsg.1-18etch1 was configured last, according to dpkg) Not updating image symbolic links since we are being updated/reinstalled (2.6.18.dfsg.1-18etch1 was configured last, according to dpkg) Could not find postinst hook script [update-grub]. Looked in: '/bin', '/sbin', '/usr/bin', '/usr/sbin' dpkg: error processing linux-image-2.6.18-6-686 (--configure): subprocess post-installation script returned error exit status 2 Errors were encountered while processing: linux-image-2.6.18-6-686 E: Sub-process /usr/bin/dpkg returned an error code (1) A package failed to install. Trying to recover: Setting up linux-image-2.6.18-6-686 (2.6.18.dfsg.1-18etch4) ... Running depmod. Finding valid ramdisk creators. Using mkinitramfs-kpkg to build the ramdisk. Not updating initrd symbolic links since we are being updated/reinstalled (2.6.18.dfsg.1-18etch1 was configured last, according to dpkg) Not updating image symbolic links since we are being updated/reinstalled (2.6.18.dfsg.1-18etch1 was configured last, according to dpkg) Could not find postinst hook script [update-grub]. Looked in: '/bin', '/sbin', '/usr/bin', '/usr/sbin' dpkg: error processing linux-image-2.6.18-6-686 (--configure): subprocess post-installation script returned error exit status 2 Errors were encountered while processing: linux-image-2.6.18-6-686

Ce qui est bizard c’est qu’il tente un update-grub alors que c’est lilo le bootloader.

Si quelqu’un a une piste, je le remercie d’avance :wink:

#2

quelqu’un a une idée ?

#3

J’ai modifié le /etc/kernel-img.conf.

J’ai remplacé les lignes suivantes :

do_bootloader = no postrm_hook = update-grub postinst_hook = update-grub

par celle-la :

L’upgrade passe.

A voir lors du prochain reboot.

#4

Oui, je crois que le noyau suppose que c’est grub, les scripts sont mal foutus pour ça…

#5

Et du coup le fichier de conf de lilo n’est pas mis à jour ^^.

Ce qui est bizard c’est qu’il n’y a pas le nom explicite de l’image à booter dedans :

[code]default=Linux

image=/vmlinuz
label=Linux
read-only

restricted

alias=1

    initrd=/initrd.img

image=/vmlinuz.old
label=LinuxOLD
read-only
optional

restricted

alias=2

    initrd=/initrd.img.old[/code]
#6

Donc : obligé de bouger des liens symboliques à la main.

Ce qui est bizarre c’est qu’il a mis la nouvelle version sur le old :

vmlinuz -> boot/vmlinuz-2.6.18-5-686 vmlinuz.old -> boot/vmlinuz-2.6.18-6-686

Il n’y a plus qu’a inverser ^^.

#7

Bon la machine ne boot plus, je me retrouve sur une console initramfs.

J’essaye de réparer depuis un live-cd, mais vu que le disque est en LVM je n’arrive pas a le monter, si quelqu’un veut bien me filer un coup de main c’est cool.

Edit : et le LVM est sur un raid1 logiciel

#8

arg ! ça me fait *****. Si sa continue je vais lander ma procédure de restauration (ce serveur est en prod)

#9

[quote=“themorice”]Donc : obligé de bouger des liens symboliques à la main.

Ce qui est bizarre c’est qu’il a mis la nouvelle version sur le old :

vmlinuz -> boot/vmlinuz-2.6.18-5-686 vmlinuz.old -> boot/vmlinuz-2.6.18-6-686

Il n’y a plus qu’a inverser ^^.[/quote]
Tu as mis à jour les liens des initrd aussi ?

Ces liens symboliques m’ont tellement emmerdé pour diverses raisons que je ne m’en sers plus ; je mets à jour lilo.conf à la main avec les chemins directs des fichiers dans /boot.

#10

Non je n’avais pas mis à jour les liens initrd :cry:
et je viens de lancer ma procédure de reconstruction du serveur :neutral_face:

Merci pour ton aide Pascal, je vais regarder ça quand j’aurai finis la restoration.

#11

Donc si je comprends bien lilo a associé le nouveau noyau avec l’ancien initrd et vice versa, et forcément ça marche beaucoup moins bien.

Comme j’évite les initrd autant que possible avec mes noyaux persos, il arrive que sur une machine cohabitent des noyaux Debian avec initrd et les miens sans initrd. Et lorsqu’on installe un noyau avec initrd après un noyau avec initrd ou vice versa, la gestion des liens symboliques est si mal adaptée à cette situation qu’il est à peu près certain que ça va foirer au prochain redémarrage !

Au moins avec les chemins directs en dur dans lilo.conf, on évite ce genre de problèmes, et notamment l’installation d’un nouveau noyau ne peut pas planter le démarrage des noyaux précédents qui marchaient, ce qui laisse une solution de repli.

#12

Tout à fait d’accord, merci beaucoup, je vais passer le binse en résolut.