Relancer grub sur un autre noyau en cas de plantage

Bonjour,

J’essais de compiler un nouveau kernel sur une debian etch qui se trouve sur un serveur dédié. J’ai déjà fait un essais et j’ai planté le serveur. Il a fallu que l’hébergeur se déplace au datacenter pour redémarrer la machine.

Apparemment l’erreur était du au fait que les modules à charger lors du boot non pas été trouvés ? (je ne sais d’ailleurs toujours pas pourquoi)

Ceci dit pour éviter ce genre de problème j’ai déjà entendu dire qu’il était possible de booter sur un kernel et que si ce dernier plantait, le pc redémarrait au bout de x secondes sur un autre kernel.

J’ai trouvé une doc dans le manuel de grub mais n’étant pas au top en anglais j’ai quelques doutes sur la manip à réaliser au niveau de la config et comme ca se passe sur un seveur dédié j’aimerai être sur de mon coup avant de tout casser.

La doc est ici:
gnu.org/software/grub/manual … tem-robust

Il y a apparemment 2 méthodes :
Booting once-only
Booting fallback systems

La méthode “Booting fallback systems” semble être la mieux mais la plus compliquée à mettre en oeuvre.

Voici dans l’état actuel (après l’install du nouveau kernel) ce que j’ai dans mon fichier /boot/grub/menu.lst.

title           Debian GNU/Linux, kernel 2.6.20.3-toff
root            (hd0,0)
kernel          /boot/vmlinuz-2.6.20.3-toff root=/dev/sda1 ro
initrd          /boot/initrd.img-2.6.20.3-toff
savedefault

title           Debian GNU/Linux, kernel 2.6.20.3-toff (single-user mode)
root            (hd0,0)
kernel          /boot/vmlinuz-2.6.20.3-toff root=/dev/sda1 ro single
initrd          /boot/initrd.img-2.6.20.3-toff
savedefault

title           Debian GNU/Linux, kernel 2.6.18-4-k7
root            (hd0,0)
kernel          /boot/vmlinuz-2.6.18-4-k7 root=/dev/sda1 ro
initrd          /boot/initrd.img-2.6.18-4-k7
savedefault

title           Debian GNU/Linux, kernel 2.6.18-4-k7 (single-user mode)
root            (hd0,0)
kernel          /boot/vmlinuz-2.6.18-4-k7 root=/dev/sda1 ro single
initrd          /boot/initrd.img-2.6.18-4-k7
savedefault

kernel 2.6.20.3-toff est le kernel que je viens d’installer
kernel 2.6.18-4-k7 qui a été install avec le serveur (celui qui fonctionne)

Est ce quelqu’un pourrait me donner la marche à suivre pour configurer le grub afin qu’il reboot sur kernel 2.6.20.3-toff et que s’il plante il reboot sur le kernel 2.6.18-4-k7.

Avec la doc du Grub j’ai écrit quelque chose mais je ne suis vraiment pas sur de mon coup.

Merci d’avance. :wink:

[quote=“toff”]Bonjour,[/quote]Bonjour.quote="toff"
Apparemment l’erreur était du au fait que les modules à charger lors du boot non pas été trouvés ? (je ne sais d’ailleurs toujours pas pourquoi)[/quote]Ca dépend de comment tu as compilé et installé ton noyau, et de quels modules externes dépend ton boot, mais en général, c’est parcequ’en faisant le make-kpkg buildpackage, tu as oublié de passer --initrdquote="toff"
La doc est ici:
gnu.org/software/grub/manual … tem-robust
Il y a apparemment 2 méthodes :
Booting once-only
Booting fallback systems

La méthode “Booting fallback systems” semble être la mieux mais la plus compliquée à mettre en oeuvre.
[/quote]Oui, mais il ne faut pas exagèrer la complexité: c’est aussi simple que ça en a l’air.[quote=“toff”]Voici dans l’état actuel (après l’install du nouveau kernel) ce que j’ai dans mon fichier /boot/grub/menu.lst.

(...)

kernel 2.6.20.3-toff est le kernel que je viens d’installer
kernel 2.6.18-4-k7 qui a été install avec le serveur (celui qui fonctionne)

Est ce quelqu’un pourrait me donner la marche à suivre pour configurer le grub afin qu’il reboot sur kernel 2.6.20.3-toff et que s’il plante il reboot sur le kernel 2.6.18-4-k7.
[/quote]C’est pas du tout normal, il n’est pas complet: ou sont les commentaires qui sont essentiels sous debian au bon fonctionnement d’update-grub et dans lesquels tout se configure ?[quote=“toff”]
Avec la doc du Grub j’ai écrit quelque chose mais je ne suis vraiment pas sur de mon coup.
Merci d’avance. :wink:[/quote]
Le principe du fallback est:

  • un default saved pour rebooter sur le dernier noyau choisi,
  • une solution de repli sur des entrées de noyaux que tu sais “sûres” (attention ça commence à zéro et les entrées single comptent), fallback n0 n1 …
  • un savedefault dans chacune des entrées de noyau…

avec un menu.lst debian normal, aprés un premier passage d’update-grub il suffit donc juste de rajouter une ligne fallback vers les bons noyaux aprés la ligne timeout.

Petite remarque: le noyau 2.6.20 n’etant pas disponible en debian j’imagine que tu as récupèré un noyau kernel.org, et pour de multiple raisons, je le déconseille sur une machine personelle, alors je ne parles même pas d’un serveur en production. Il faut vraiment avoir un besoin particulier pour installer ce noyau là qui fait une grosse differente avec le 2.6.18 sur une debian.

Merci pour ces explications mattotop.

Je reprends dans l’ordre.
Lors de mon premier essais pour compiler le kernel j’avais bien mis l’option “–initrd” dans la commande “make-kpkg”.

Ensuite concernant le fichier /boot/grub/menu.lst tu as raison, j’ai mis uniquement la partie qui concerne les différents OS à charger.

Le voici en entier (dsl d’encombrer le thread):

Comme tu l’as dit, faut pas exagérer concernant la complexité de “fallback”. Entre le moment ou j’ai posté ma question et maintenant, j’ai repris la doc et j’ai (je pense) compris comment fonctionnait l’option savedefault. C’est surtout ca qui me posait problème avec “default saved”.

J’ai donc comme tu peux le voir modifier mon fichier menu.lst de la façon ci dessus et ensuite, j’ai fait un “grub-set-default 0” pour indiquer à l’ami Grub d’utiliser le nouveau noyau en premier pour le prochain boot.

Je pense que ca doit-être correct.? (j’ai pas encore essayé) :unamused:

Mince je ne savais pas pour le noyau… J’ai l’habitude de red-hat et je découvre debian (et grub d’ailleur).

Bon faut donc que je récupère le dernier kernel en mettant à jour mon fichier Sources.list, etc, etc…
Arff j’ai passé une plombe à le configurer… Lol… Bon ben je recommence…

oui et non.
c’est correct pour rebooter, mais ça va sauter au prochain update-grub.
sauves ton menu.lst, refais un update-grub, et reparts de ce que tu obtiens pour ajouter la ligne fallback AVANT la ligne "### BEGIN AUTOMAGIC KERNELS LIST "

comment as tu créé ton noyau (ligne make-kpkg complète) ?
qu’as tu dans /lib/modules ?
Tu sais qu’il y a fusion entre le PATA et le SATA à partir du 2.6.19 et que tu as des chances que tes disques qui s’appelaient hdX s’appellent ensuite sdX aprés passage en 2.6.20 ?

[quote]qu’as tu dans /lib/modules ?
[/quote]

j’ai 2 repertoires:
2.6.18-4-k7
2.6.20.3-toff

[quote]oui et non.
c’est correct pour rebooter, mais ça va sauter au prochain update-grub.
sauves ton menu.lst, refais un update-grub, et reparts de ce que tu obtiens pour ajouter la ligne fallback AVANT la ligne "### BEGIN AUTOMAGIC KERNELS LIST "
[/quote]

En fait ce noyau sera le noyau par défaut et je veux rebooter le seveur une seule fois en utilisant ce système afin de vérifier si le nouvel kernel fonctionne.

Cet hébergeur n’a pas de système permettant de faire des reboot en hard sur des noyaux génériques (réseau). Il faut donc que je puisse reprendre la main sur le serveur si le nouveau noyau ne tourne pas…
Autrement le gars qui s’occupe des dépannages est sans arrêt obligé d’aller au data center pour redémarrer la machine.