Echec de boot après mise à jour de kernel sur un Kimsufi
... / Echec de boot après mise ...
BMPCreated with Sketch.BMPZIPCreated with Sketch.ZIPXLSCreated with Sketch.XLSTXTCreated with Sketch.TXTPPTCreated with Sketch.PPTPNGCreated with Sketch.PNGPDFCreated with Sketch.PDFJPGCreated with Sketch.JPGGIFCreated with Sketch.GIFDOCCreated with Sketch.DOC Error Created with Sketch.
Question

Echec de boot après mise à jour de kernel sur un Kimsufi

by
PierreT6
Created on 2023-09-04 15:29:22 (edited on 2024-09-04 11:03:47) in Serveurs Dédiés Eco

Hello,

Mon KS, installé initialement sous **Ubuntu 16.04 LTS** tourne sur un kernel OVH **4.9.120-xxxx-std-ipv6-64**.

J'ai récemment upgradé mon installation jusqu'en **Ubuntu 22.04 LTS**, j'ai été surpris de voir que le kernel n'avait pas été mis à jour. J'ai donc fait une mise en jour en installant le metapackage "linux-generic" qui m'a installé le **kernel 5.15**.

Au reboot, le serveur ne revient pas en ligne... J'ai donc du rebooter en mode rescue-customer, monter le filesystem et faire pointer grub sur l'ancien kernel. De retour sur l'ancien kernel, le serveur boot à nouveau.

Dans les log, aucune trace de la tentative de boot sur kernel 5.15...

Quelqu'un aurait-il une idée de ce qui pourrait expliquer ce non-boot ?

Merci


8 Replies ( Latest reply on 2023-09-05 15:33:39 by
PierreT6
)

Bonjour,

vous avez fait quoi comme manipulation/commandes très exactement ?

Car de mémoire avec les installation OVH avec noyau OVH il y a plusieurs choses à faire pour repasser sur le noyau de la distribution.

Cordialement, janus57

J'ai fait un simple
**apt update**
suivi d'un
**apt install linux-generic**

Bonjour,

il n'y a pas un fichier custom OVH dans "/etc/grub.d/" ?

Cordialement, janus57

Si, il y a un fichier **06_OVHkernel** mais il est déprécié, voici son contenu :

"#!/bin/bash
"# This script was formerly used to push existing "bzImage" files on top of grub's kernel list.
"# As Kernels are now provided in vmlinux format as .deb package, this is not needed anymore,
"# so this script is now functionally void, and disabled (chmod -x) by default.

">&2 echo "NOTICE: /etc/grub.d/06_OVHkernel is deprecated and can be safely removed."
"exit 0

Bonjour,

que donne ces commandes après l'installation du noyau de la distribution :
[code]
update-grub -v
[/code]
[code]
grep -Hni 'menuentry' /boot/grub/grub.cfg
[/code]
[code]
cat /etc/default/grub
[/code]

Cordialement, janus57

Bonjour Janus,

Merci pour ton aide,
La menuentry avait bien été créée correctement pour le nouveau kernel :

/boot/grub/grub.cfg:32:if [ x"${feature_menuentry_id}" = xy ]; then
/boot/grub/grub.cfg:33: menuentry_id_option="--id"
/boot/grub/grub.cfg:35: menuentry_id_option=""
/boot/grub/grub.cfg:38:export menuentry_id_option
/boot/grub/grub.cfg:155:menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-a035f9f5-2ee6-4946-9d0f-0d390488ddfa' {
/boot/grub/grub.cfg:172:submenu 'Advanced options for Ubuntu' $menuentry_id_option 'gnulinux-advanced-a035f9f5-2ee6-4946-9d0f-0d390488ddfa' {
/boot/grub/grub.cfg:173: menuentry 'Ubuntu, with Linux 5.15.0-82-generic' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.15.0-82-generic-advanced-a035f9f5-2ee6-4946-9d0f-0d390488ddfa' {
/boot/grub/grub.cfg:192: menuentry 'Ubuntu, with Linux 5.15.0-82-generic (recovery mode)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.15.0-82-generic-recovery-a035f9f5-2ee6-4946-9d0f-0d390488ddfa' {
/boot/grub/grub.cfg:210: menuentry 'Ubuntu, with Linux 4.9.120-xxxx-std-ipv6-64' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.9.120-xxxx-std-ipv6-64-advanced-a035f9f5-2ee6-4946-9d0f-0d390488ddfa' {
/boot/grub/grub.cfg:229: menuentry 'Ubuntu, with Linux 4.9.120-xxxx-std-ipv6-64 (recovery mode)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.9.120-xxxx-std-ipv6-64-recovery-a035f9f5-2ee6-4946-9d0f-0d390488ddfa' {

Coté /etc/default/grub, pas de surprise non plus. Il avait bien la valeur GRUB_DEFAULT=0 pour booter sur le nouveau kernel, comme tu le veras, j'ai changé cette valeur pour forcer l'ancier kernel et pouvoir à nouveau booter mon kimsufi.

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
# info -f grub -n 'Simple configuration'

#GRUB_DEFAULT=0
GRUB_DEFAULT='gnulinux-advanced-a035f9f5-2ee6-4946-9d0f-0d390488ddfa>gnulinux-4.9.120-xxxx-std-ipv6-64-advanced-a035f9f5-2ee6-4946-9d0f-0d390488ddfa'
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="noquiet nosplash net.ifnames=0 biosdevname=0"
GRUB_CMDLINE_LINUX=""

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
GRUB_DISABLE_LINUX_UUID="true"

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

Coté /var/log/syslog ou dmesg, je ne vois aucune ligne de log sur le nouveau kernel... je vois que les logs s'arrêtent au moment où je veux rebooter sur le nouveau kernel et recommencent une fois que j'ai forcé le boot à nouveau sur l'ancier kernel. Rien n'est logué au niveau du kernel 5.15.

J'ai également tenté d'installer sur linux-generic-hwe-22.04 qui installe alors un kernel 6.2, mais je rencontre exactement le même souci. J'ai la conviction qu'il doit y avoir un message d'erreur affiché dans grub à la tentative de boot qui pourrait certainement m'aider à mieux comprendre ce qui se passe, malheureusement, pas de possibilité de savoir lequel... à moins que tu penses à un truc auquel je ne pense pas ?

Merci,

Pierre

Bonjour,

Perso je le laisserais sur le nouveau kernel et s'il ne ping pas et que vous n'avez pas désactivé le monitoring OVH un technicien interviendra physique et si message d'erreur il y a alors il vous sera indiqué.

Cordialement, janus57

Merci pour la suggestion, je ne savais pas qu'on pouvait faire ça.
Je tente le coup. Je te partagerai les infos et/ou la solution si je la trouve.

c'est tt le soucis quand on a des offres sans ipmi...
La config à l'air assez ancienne, ne serait ce pas + simple de louer un nouveau serveur et de l'install "from scratch" avec une version à jour puis d'y migrer les services ?

Oui en effet, il s'agit d'un produit entrée de gamme. Et pour ce prix là, je ne me plain pas.

J'imagine que réinstaller complètement le serveur avec un template récent en Ubuntu 22.04 serait une autre solution possible. Mais j'aimerais ne pas jeter le bébé trop vite avec l'eau du bain. J'aimerais comprendre la source du problème et le régler.

Bonjour,

Le problème est que sur un serveur sans KVM vous allez perdre un temps phénoménal à avoir des logs.

Et surtout qu'entre temps OVH à arrêter d'installer la distribution Ubuntu avec un kernel custom car ils ce sont fait taper sur les doigts par canonical.

Cordialement, janus57

En effet.

si je n'ai pas de solution, je vais finir par réinstaller Ubuntu 22.04 depuis un template. Au vu de ce que tu décris, on peut supposer qu'il viendra désormais avec un kernel standard et récent.

Bonjour,


on peut supposer qu'il viendra désormais avec un kernel standard et récent.


De mémoire ils ont plus le choix si le template porte le nom ubuntu sinon canonical dégaine l'action en justice.

Cordialement, janus57

Je pensais à passer directement sur un nouveau serveur...
Vous aurez probablement une config bien + performante à un prix équivalent.

En réalité, je bénéficie d'un ancien tarif promo qui est reconduit.
J'ai donc un prix plus intéressant que le prix actuel du même serveur. (et je n'ai pas besoin d'une meilleure config)

Replies are currently disabled for this question.