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
Echec de boot après mise à jour de kernel sur un Kimsufi
Related questions
- Kimsufi - Reset Root Password
13818
31.05.2022 12:26
- Kimsufi - Rescue Mode
12787
29.06.2018 09:58
- Kimsufi - Mode rescue
11293
31.05.2022 12:22
- NetBoot réseau kernel OVH inaccessible / OVH supprime volontairement et sans prévenir !
11121
21.08.2022 13:37
- Kimsufi - Add SSH keys to Kimsufi Manager
9705
31.05.2022 13:06
- FAQ Je suis déjà client·e Kimsufi et/ou So you Start
9437
15.03.2022 11:30
- Kimsufi - Mon interace Proxmox ne fonctionne pas
9056
31.05.2022 12:07
- FAQ Serveurs dédiés Eco - Les questions que vous vous posez
8835
15.03.2022 11:24
- Kimsufi - Setting up a secondary DNS. I'm stumped!
8700
31.05.2022 13:21
- FreeBSD en CloudInit: marchait en mars, ne marche plus en décembre?
8490
12.12.2025 09:43
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,
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)