J'ai un serveur dédié (HOST32) depuis 10 ans, avec lequel je n'ai jamais eu de probleme. Il tourne sous debian 11, dispose de 2 disques SSD, sur lesquels le boot loader (grub) est bien installé.
Il ya quelqus jours, apres update de quelques paquets, dont le kernel, et reboot propre du serveur, celui ci n'a pas répondu. Disposant d'un ipmi/kvm, je me connecte et voici ce que le serveur affiche à l'écran
Bonjour @NadiaJ3 , Sauriez-vous me dire à quand remonte le dernier reboot avant que vous rencontriez le problème ? Le 2 avril, nous avons changé le bootloader de Syslinux à iPXE à Gravelines où se situe votre serveur : https://bare-metal-servers.status-ovhcloud.com/incidents/mr1qb7p2q4h5 Il semble que parfois, avec d'anciennes version de GRUB, iPXE se comporte différemment de Syslinux.
D'après votre capture d'écran, iPXE ne bloque pas mais part en erreur. Normalement, après 3 essais, iPXE devrait quitter et vous auriez le même comportement que ce que vous avec avec ESCAPE (fallback sur disque). Est-ce que c'est le cas ?
Pour que je vous aide à faire en sorte qu'iPXE arrive à chaîner proprement : * pouvez-vous me montrer un `lsblk -f` pour que je voie comment est fait le partitionnement ? * est-ce que GRUB est bien installé sur les deux disques (visible avec `for i in /dev/sd?; do echo $i; head -c 512 $i | xxd; done` où on doit voir `GRUB .Geom.Hard`) * quelle est la version du BIOS ? `cat /sys/devices/virtual/dmi/id/bios_version`
Il utilise d'abord un disque san donc sans doute externe.
`sanboot` est la commande utilisée par notre script iPXE pour chaîner sur disque sur les machines en boot legacy, ce n'est pas un dysfonctionnement, voir https://ipxe.org/cmd/sanboot
@NadiaJ3 quel était la version de Debian installée initialement sur le serveur ? Connaissez-vous la version de GRUB actuellement installée ?
Merci pour le retour, je me suis permis de reformatter la sortie de `lsblk` dans le post.
Le BIOS 3.5 est bien la dernière version que l'on propose pour votre carte mère donc je ne vois pas de raisons de creuser de ce côté-là. À mon avis, le problème est lié à la version de GRUB installée sur le MBR qui n'a pas peut-être pas été mise à jour depuis Debian 7. Pouvez- vous essayer de réinstaller GRUB sur les deux MBR ? Le plus simple serait de passer par `dpkg-reconfigure grub-pc` et de sélectionner les disques sda et sdb dans `GRUB install devices`. La sortie devrait montrer `Installation finished` deux fois (une par disque), quelque chose dans ce genre-là : ```text # dpkg-reconfigure grub-pc Installing for i386-pc platform. Installation finished. No error reported. Installing for i386-pc platform. Installation finished. No error reported. Generating grub configuration file … Found linux image: /boot/vmlinuz-5.10.0-29-amd64 Found initrd image: /boot/initrd.img-5.10.0-29-amd64 Found linux image: /boot/vmlinuz-5.10.0-28-amd64 Found initrd image: /boot/initrd.img-5.10.0-28-amd64 done ```
A chaque upgrade majeure ou de grub, j'ai soigneusement refait un grub-install /dev/sda grub-install /dev/sdb
Et ici, lundi dernier également, grub reinstallé pour etre sur que le MBR soit bien à jour. puis reboot, et meme écran montrant le bloquage IPXE.
Par contre, par rapport à d'autres de mes serveur bootant également en bios legacy, je remarque qu'ici il y a en plus le paquet grub2. peut être est ce dernier qui fait une bizarrerie ? Ce soir, lorsque ce sera calme, je le desinstallerai, referai un grub-install sur les 2 disques et essaierai de rebooter le serveur pour vérifier si ça se passe bien.
OK c'est très étonnant dans ce cas. En tout cas, quand `grub-pc` est bien configuré, il s'occupe lui-même de mettre à jour GRUB sur les disques donc ça peut vous éviter le `grub-install` manuel. Pour info, voici ce qu'on a comme packages sur une install Debian 11 toute neuve faite depuis notre image (basée sur l'image cloud proposée par Debian) : ```text # dpkg -l | grep grub ii grub-common 2.06-3~deb11u6 amd64 GRand Unified Bootloader (common files) ii grub-pc 2.06-3~deb11u6 amd64 GRand Unified Bootloader, version 2 (PC/BIOS version) ii grub-pc-bin 2.06-3~deb11u6 amd64 GRand Unified Bootloader, version 2 (PC/BIOS modules) ii grub2-common 2.06-3~deb11u6 amd64 GRand Unified Bootloader (common files for version 2) ```
Après avoir supprimé le paquet grub2, pour avoir juste grub-common grub-pc grub-pc-bin grub2-common j'ai pu faire un dpk-reconfigure grub-pc (selection des 2 disques ssd, puis message comme quoi tout est ok)
Puis j'ai arrété mes services et fait un reboot propre du serveur A nouveau, il arrive sur l'écran ipxe, et se bloque. Il semble qu'une 1e tentative est faite, échoue sur le "could not boot: input/output error" Puis une 2è se lance, et se bloque après "Ntp…"
Merci pour la réponse. Je vais essayer de refaire des tests sur un serveur similaire au votre sur lequel Debian 12 passe bien.
Si on ne trouve pas de solution au niveau logiciel, je vous propose, au choix :
* De lancer une réinstallation de Debian 12 et, si ça ne passe pas, on remplacera une partie du hardware, potentiellement la carte mère (j'imagine que ce n'est pas forcément la solution idéale pour vous). * D'entrer dans le BIOS et de remettre les valeurs par défaut. Peut-être y a-t-il une différence de configuration entre votre serveur et ceux qui fonctionnent bien. * Si ça ne fonctionne pas, de changer le boot order dans le BIOS et mettre le disque avant le PXE. Vous ne pourrez plus démarrer facilement en rescue mais ça vous permettra de booter sur disque sans problème, en attendant une prochaine réinstallation où on trouvera une solution plus pérenne.
hello, ok, merci du retour, et des possibilités. alors peut etre est ce du à la version de grub dans debian 11 ? j'avais de toute façon l'intention de mettre à jour ce serveur de debian 11 à 12. auquel cas il se pourrait que la version grub de debian 12 améliore la situation. Je devrais pouvoir proceder à cette mise à jour dans les jours qui viennent, je vous tiens au courant
Même problème sur notre serveur. Tout fonctionnait bien jusqu'à hier soir après que OVH ait redémarré le serveur. Impossible de le démarrer en mode normal, il restait bloqué sur "Booting from SAN device". Nous n'avons pas trouvé de solutions à part appuyer sur la touche ESC pour démarrer en mode normal. Ca serait bien de former le support OVH qui n'a rien su nous proposer et nous a laissé sans serveur durant toute la journée…
bonjour @LionelA19, bienvenue au club dans mon cas, le support n'a meme pas cherché, et a de suite rejeté la faute sur ma "configuration logicielle".. malgré preuves que non. Par curiosité, quel type de serveur avez vous ? (ici c'est un supermicro H8SCM. ça peut se voir avec la commande "dmidecode -t system") et quel OS installé dessus ? et heureusement que @le_sbraz est la
Oui, quand je dis qu'il a cherché, il m'a fait passer quelques commandes et m'a dit qu'il etudierait. J'ai eu le droit aussi à ma "configuration logicielle". Toujours pas de réponse de leur part à ce jour. Sympa quand on héberge des données essentielles pour les entreprises ! Perso, nous allons installer un autre serveur chez un autre hébergeur pour un PRA. C'est aussi Supemicro avec le product name : "Super Server". Pas d'autres infos affichées… C'est Centos 7.9 qui est installé.
@NadiaJ3 j'ai mal relu vos messages et j'ai supposé que vous aviez une Debian 12. Je vais refaire un test avec Debian 11 mais normalement ça fonctionnait aussi sans problème.
@LionelA19, pouvez-vous me donner un moyen d'identifier votre serveur (le nom de la machine, son ID, sa MAC) ? Je vais me rapprocher des équipes de support pour comprendre pourquoi ils n'ont pas fait le rapprochement avec le changement de bootloader.
@LionelA19 j'ai retrouvé le nom de votre serveur. Pouvez-vous me donner la version du BIOS s'il vous plaît (`cat /sys/devices/virtual/dmi/id/bios_version`) ? C'est une carte mère `X10SDV-TLN4F`, elle doit être plus récente que la `H8SCM`, j'aimerais voir si une mise à jour du BIOS corrige le problème.
Est-ce que vous pouvez s'il vous plaît passer votre serveur en rescue pour que je flashe le BIOS (la 1.1 est très ancienne) ? Je vous contacte en PM pour confirmer le nom du serveur.
@NadiaJ3 Je n'ai toujours pas de problèmes avec Debian 11. Je viens de penser à une chose qui pourrait jouer : est-ce que votre partitionnement est fait avec MBR ? Nos installations récentes utilisent GPT quasiment partout, par exemple sur mon serveur de test : ```text # parted /dev/sda p | grep Table Partition Table: gpt ```
