Serveur dédié bloqué au boot, problème avec IPXE

Bonjour,

A mon avis, tu as un problème d'ordre de boot au niveau de ton serveur.
Il utilise d'abord un disque san donc sans doute externe.

A voir si c'est ton système de fichier qui a un problème de lecture ou si c'est bien la mauvais disque qui est testé.

Bon courage
Captainadmin

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 ?

@jeanr: j'ai un doute, car meme le bootloader (grub) ne se lance pas.

@le_sbraz en effet, serveur à GRA1.
dernier boot le lundi 6 mai (avec appui sur ESC pour débloquer). boot précédent: en février, aucun souci.

En l'état actuel, si je le laisse sans y toucher, il reste bloqué sur l'écran IPXE et ne démarre jamais, malheureusement.

voici le lsblk -f (ici le /boot est sur un raid soft/mdadm en ext3, et le / sur un 2e volume raid1 en ext4)
```
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
sda
├─sda1 linux_raid_member 1.2 rescue.ovh.net:0 bee63f8a-ed23-bc39-f711-c0b340e48e98
│ └─md0 ext3 1.0 ca47cbc0-0c86-45ec-8943-c5480b095223 1,7G 3% /boot
├─sda2 swap 1 f12e2539-ce92-46c2-81b2-04b5ff9ca0c0 [SWAP]
└─sda3 linux_raid_member 1.2 rescue.ovh.net:1 e54d2ffc-487d-aee7-4f6b-b992cb8f2495
└─md1 ext4 1.0 3c5ce9bf-1095-456d-b0d9-be0f3264f5e3 132,6G 2% /
sdb
├─sdb1 linux_raid_member 1.2 rescue.ovh.net:0 bee63f8a-ed23-bc39-f711-c0b340e48e98
│ └─md0 ext3 1.0 ca47cbc0-0c86-45ec-8943-c5480b095223 1,7G 3% /boot
├─sdb2 swap 1 2d05d9b1-1679-413d-b0da-a815587eb635 [SWAP]
└─sdb3 linux_raid_member 1.2 rescue.ovh.net:1 e54d2ffc-487d-aee7-4f6b-b992cb8f2495
└─md1 ext4 1.0 3c5ce9bf-1095-456d-b0d9-be0f3264f5e3 132,6G 2% /
```

- yes, grub bien installé sur les 2 disques. le head -c512 /dev/sda et /dev/sdb fait bien apparaitre
GRUB .Geom.Hard

- pour le bios :
Version: 3.5
Release Date: 11/25/2013

enfin, la version installée initialement, c'etait il y a... 10 ans :)
ca devait etre debian 7

à l'heure actuelle, voici les paquets grub installés sur le serveur:
grub-common
grub-pc
grub-pc-bin
grub2
grub2-common
tous en version 2.06-3~deb11u6

merci :)

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
```

Merci pour les infos et la suggestions.

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.

Je vous tiens au courant d'ici la.

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)
```

Bonsoir,

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..."

Voici à nouveau un screenshot pris à l'instant:


A nouveau, après un reset et appui sur la touche ESC, ça sort du mode IPXE et grub se lance, puis debian.

Une autre idée ?
merci

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.

Je viens de tester 3 autres serveurs avec une carte mère H8SCM et Debian 12. Tous fonctionnent sans problème en bootant sur disque depuis iPXE.

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.

La commande me renvoie 1.1

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
```

Alors en effet, depuis que j'ai ce serveur il a toujours booté en bios legacy et non EFI.
En regardant le partitionnement avec fdisk ou parted, les 2 disques ont bien leur table de partition en MBR :

Il a du etre installé ya 10 ans avec le template par défaut de l'époque, ceci explique cela :)

@NadiaJ3 c'est peut-être là qu'est la différence principale avec nos installations récentes. Il faut savoir que GPT fonctionne presque partout même sur les machines en BIOS legacy. Il faut simplement ajouter une partition de quelques Mo pour GRUB. **Pourtant, je viens de refaire une installation de Debian 11 en forçant l'utilisation de MBR sur mon serveur témoin en H8SCM et je n'ai pas de problème.**

Comme je vous le disais, si vous ne trouvez aucune solution, le mieux est de faire booter le serveur sur disque sans passer par le PXE en attendant une future réinstallation.

@LionelA19 nous avons flashé le BIOS et l'EEPROM de la carte réseau Intel X552/X557 de votre srveur mais le freeze persistait.
Le problème était **l'ordre des disques durs dans le BIOS**. GRUB n'est installé que sur vos deux SSD. Cependant, avant notre intervention, les deux disques mécaniques, notés P2 et P3, étaient placés avant les SSD :



Cette configuration, qui ne posait pas problème avec Syslinux, peut parfois bloquer avec iPXE.

Nous avons avoir mis les SSD, notés P0 et P1, en premier :

C'est difficile à montrer sur une image fixe mais le serveur chaîne bien sur disque depuis iPXE. On ne reste qu'une fraction de secondes sur cet écran, il n'y a plus de freeze et le serveur continue immédiatement sur GRUB :

Merci @le_sbraz pour votre implication et la résolution de ce problème !

Bonsoir,

La piste du partitionnement des disques en mbr/gpt était une bonne idée, mais malheureusement pas la bonne.
Apres avoir redémarré le serveur en rescue, j'ai utilisé gdisk pour convertir la table de partition MBR en GPT sans probleme.
Puis j'ai créé une petite partition de type bios-grub (flag EF02)
Et remonté la partition rootfs, proc/sys/dev, et chroot dedans.
Enfin, refait un grub-install sur chaque disque, et update-grub.
puis tout démonté et rebooté en mode normal.
Désormais, les 2 disques sont partitionnés ainsi:

\# parted /dev/sda print

Model: ATA INTEL SSDSC2BB16 (scsi)
Disk /dev/sda: 160GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
1 2097kB 4194kB 2097kB primary bios_grub
2 2000MB 4000MB 2001MB linux-swap(v1) Linux swap swap
3 4000MB 160GB 156GB Linux RAID raid

Finalement, apres reboot en surveillant ce qui se passe à l'écran, l'ipxe se bloque au meme endroit avec la meme erreur.

Du coup, on va laisser comme ça, au moins je peux intervenir au boot pour qu'il demarre normalement.
Par la suite, vu le serveur veillissant, je pense que je n'aurais d'autre solution que prendre un nouveau serveur plus récent et tout retransferer dessus depuis l'ancien..

La piste du partitionnement des disques en mbr/gpt était une bonne idée, mais malheureusement pas la bonne.

Malheureusement c'était aussi ce que je pensais d'après mes tests. En tout cas, chapeau d'avoir osé la conversion sur une machine en prod :)
Par curiosité, pour créer `bios_grub`, vous avez détruit une de vos partitions de 2 Go, c'est ça ?

En vrai, j'avais au préabable soigneusement préparé l'operation ;)
En réalisant l'operation dans une VM debian 11 pour "simuler" le serveur, avec un partitionnement similaire, boot en BIOS et 2 disques en MBR, avec du raid1.

J'ai pu ainsi voir que cela était faisable, en procédant bien étape par étape.

Et comme ici j'ai 2 disques, j'ai fait d'abord l'operation sur 1 disque, pour voir que tout se passait bien et était conforme, que y'avait assez de place en fin de disque (car GPT inscrit un backup de la table de partitions en fin de disque)
Au pire, le 1er disque aurait perdu ses données, je les avais encore sur le 2e disque, et aui pire du pire sur un backup. on n'est jamais trop prudent ;)
Et c'est la toute la beauté de linux, on peut faire ce genre de chose (en planifiant soigneusement), modifier des partitions, déplacer le rootfs sans tout réinstaller. ce qui donne énormément de souplesse et de solutions en cas de probleme :)

Et oui, j'avais au début de chaque disque une partition pour le /boot en raid1, qui était en fait inutile.
En remettant le dossier /boot sur le rootfs, j'ai pu libérer de la place de debut de disque pour créer la partition bios-grub.

SInon, à ttire de comparaison, j'ai aussi quelques autres serveurs dédiés à GRA, démarrant en mode BIOS, avec 2 ssd sata partitionnés en MBR, qui ont rebooté dans le mois et aucun probleme.
Mais ce ne sont pas des "vieux" supermicro comme celui ci.
Je pense que mon serveur doit être maudit.

Au final, merci beaucoup de votre temps et réponses :)
plus qu'à trouver le temps de prendre un nouveau serveur et migrer dessus.

Bonjour,

je viens relancer ce fil, rencontrant le même problème que @NadiaJ3 et @LionelA19

J'ai également un serveur hébergé chez OVH (SoYouStart précisément) depuis de nombreuses anneés, en debian 8 (Un peu vieille la debian, on sait ^^')

Vendredi il a été, il nous semble brutalement coupé. Les logs ont été interrompus nets en cours d'écriture de ligne, avec même dans les auth.log la présence des caractères "@^" de réservation de lignes. Aucune Kernel Panik n'est visible, c'est pourquoi nous en arrivons à la conclusion que le serveur a été mis hors tension mais OVH ne nous a donné aucune information dans ce sens.

Bref, depuis cette coupure, le serveur ne redémarre plus. Nous avons uniquement pu booter en mode rescue et avons alors fait les vérifications qui s'imposent : intégrité des disques, configuration grub, vérifications des logs, etc. et n'avons rien trouvé du tout.
Aucun log n'a été écrit depuis la coupure initiale, il semblerait que le serveur ne démarre pas du tout.

OVH nous a informé que leur scan matériel n'avait rien révélé et que le problème venait de chez nous. Toutefois, ils nous ont transmis un message d'erreur affiché par le serveur, le fameux "Booting from SAN device 0x80 failed".
Notre serveur n'étant pas éligible à une console KVM, nous sommes complètement bloqués, nous ne pouvons pas appuyer sur la touche échap comme les utilisateurs précédents l'ont fait et n'avons donc pas pu redémarrer notre serveur depuis vendredi.
Nous avons supposé, et espérons, que le problème était peut-être également lié à l'ordre des disques dans le BIOS mais nous ne pouvons pas vérifier cette hypothèse, l'équipe technique ne répondant pas à nos tickets ouverts depuis trois jours et nous renvoyant toujours à la recommandation "Configuration logicielle à corriger par le client".

Est-ce que quelqu'un sait comment nous pourrions vérifier cela de nous-même ? Ou est-ce que quelqu'un a une autre piste ?

Merci d'avance.
MOULIN C.

Bonjour,
Bienvenue dans les galères avec le support OVH... J'espère que @le_sbraz pourra vous aider, il nous a été d'une grande aide, sans lui le support n'aurait pas bougé d'un doigt, il nous renvoyait aussi vers "Configuration logicielle à corriger par le client" :(
Je ne suis pas sûr que ce soit le même problème mais le_sbraz nous a indiqué que le support devait installer un nouveau BIOS qui a réglé le problème.
Il faudrait voir sur la page des incidents si un peut concerner votre serveur : https://www.status-ovhcloud.com et envoyer le lien au Support pour leur montrer que le problème vient d'OVH.
Bon courage !

Bonjour @FabienM43, pouvez-vous me donner le nom, l'ID, l'IP ou la MAC de votre serveur ? Est-ce que vous nous autorisez à intervenir dessus pour regarder si nous parvenons à le faire démarrer sur disque ?
Dans tous les cas, en attendant une éventuelle intervention de notre part, je vous conseillerais de tenter de réinstaller / mettre à jour GRUB sur tous les disques où il doit l'être (donc tous les disques où s'étend le RAID de votre système).

@FabienM43, si le serveur est celui dont la MAC finit par `64`, le dernier commentaire des techniciens indique que la machine démarre bien sur disque mais reste bloquée au login sans ping. Je vous conseille de vérifier les logs depuis le rescue pour essayer de déterminer ce qui pose problème.

Bonjour,

tout d'abord je tiens à vous remercier, @LionelA19 et @le_sbraz pour vos réponses ! Je viens vous donner des nouvelles de notre serveur !

@le_sbraz, vous aviez bien identifié la bonne machine, merci beaucoup d'avoir regardé.

En effet, nous avions eu un message nous notifiant de cette demande de login, mais il était précisé juste au dessus qu'il s'agissait d'un "Boot sur interface diagnostique (rescue)", nous en avons donc conclu qu'il s'agissait simplement de la demande de login à ce mode.

De plus, il nous était impossible de consulter les logs, y compris en rescue pour la simple et bonne raison qu'aucun log n'était produit ^^' Pas de syslog, pas de kernel log rien de rien, de fait, nous en avions déduit que le serveur ne bootait pas du tout.

Toujours est-il que, assez convaincus qu'ici aussi le problème venait de l'ordre du boot, nous avons insisté pour que nos disques soient placés en premier afin de contourner les tentatives IPXE.
Ce jeudi, OVH est finalement intervenu dans ce sens et miracle, tout remarche. Le serveur a parfaitement démarré.

Du coup, notre problème est réglé et nous vous remercions pour votre aide et pour ce fil qui a été d'un grand secours.
Nous sommes tout de même très frustrés car nous avions le bon diagnostic mais nous avons eu du mal à communiquer avec le support et, ce serveur étant critique pour notre activité, nous avons dû passer le week end à travailler pour en remonter un autre ailleurs alors que celui-ci était au final parfaitement fonctionnel.


En tout cas, encore merci pour votre temps !

Bonjour,

J'ai l'impression que j'ai le même problème. je suis sur un dédié SuperMicro avec une CM X10SDV-4AC-TLN2F. Le bios est en version 2.3.V1.
J'ai eu besoin de rebooter le serveur et il reste sur "Booting from SAN device 0x80". Le support clos le ticket car le serveur boot en rescue.
2 jours que je suis dessus...

J'ai tout vérifié, le raid1 soft sur lequel doit booter le serveur comprend /dev/sdc1 et /dev/sdd1. Les smarctl sur les 2 disques /dev/sdc et /dev/sdd sont OK. Le /dev/md0 est clean. Le flag "boot" est présent sur /dev/sdc. Au cas où j'ai ré installé Grub /dev/sdc et /dev/sdd.

Le support peut faire quelques chose où je dois outrepasser le netboot dans le BIOS pour booter directement sur les disques locaux ?

Merci de votre aide.

Bonjour @ThierryF30, pouvez-vous me donner un numéro de ticket ou un moyen d'identifier le serveur en question s'il vous plaît ?
Vous avez deux disques sda et sdb sans bootloader ? Ils sont peut-être en premier dans le boot order. Essayez d'aller dans le BIOS dans les options de boot, dans "Hard Disk Drive BBS Priorities" pour mettre les disques correspondant à sdc et sdd en premier. Si ça ne résout pas le problème, il faudra sûrement bypasser le PXE pour booter directement sur disque comme vous le disiez, ou réinstaller.

Bonjour @le_sbraz. Merci pour vote réponse rapide. Le ticket, entre autre, est le 9896132.
Oui les ssd sda/sdb sont des OSD d'un cluster Ceph. D'ailleurs le support a détecté qu'1 de ces disques est défaillant. Je leur ai laissé le serveur en rescue et demandé à ce qu'il soit changé mais en vain pour l'instant.
Normalement le Bios est censé tenter de booter sur P0,P1,P2,P3 jusqu'à trouver un bootloader. Mais ok demain matin je testerai de modifier la conf du Bios pour mettre P2,P3,Disable,Disable.
J'ai d'autres serveurs qui sont de même génération, Dois-je m'attendre à avoir les mêmes problèmes au prochain reboot ?

Bonjour, le support à fait le nécessaire au niveau du BIOS et le serveur est UP.
Ce fil de discussion est quand même bien utile. Il faudrait inclure cette info dans la base de connaissance du support ça éviterait tellement que tout le monde perde du temps.

Normalement le Bios est censé tenter de booter sur P0,P1,P2,P3 jusqu'à trouver un bootloader. Mais ok demain matin je testerai de modifier la conf du Bios pour mettre P2,P3,Disable,Disable.

Malheureusement, quand iPXE appelle la commande `sanboot --no-describe --drive 0x80`, il semble que ça ne soit pas toujours le cas. Le comportement est souvent différent de ce qui se passerait si on laissait le BIOS choisir sans chaîner en PXE (mais dans ce cas-là, on ne peut pas aiguiller la machine sur disque ou sur rescue).

J'ai l'impression d'avoir un soucis similaire ici :(

Ce matin maintenance électrique à GRA1 dans la baie qui abrite mon serveur, et depuis il ne démarre pas.
Quand je suis à distance via un fenêtre ipmi dans le terminal de mon Mac, je vois qu'il reste bloqué sur ceci :

Supermicro X10SDV-4C-TLN2F BIOS Date:02/13/2018 Rev:1.3

CPU : Intel(R) Xeon(R) CPU D-1521 @ 2.40GHz
Speed : 2.40 GHz
The IMC is operating with DDR4 2133 MHz

Press DEL to run Setup
Press F11 to invoke Boot Menu
Press F12 to boot from PXE/LAN

Que faire ?
Merci pour votre aide ...

Bonjour,

Pour information, j'ai pris un serveur (https://eco.ovhcloud.com/fr/kimsufi/ks-le-2/) il y a 5 jours et je rencontre le même problème ( et je ne peux pas faire escape, il reste bloqué) :

Le serveur etant neuf, la procedure est facilement reproductible.

Boot en rescue debian10 ( pour une raison inconnu, la debian12-rescue ne fonctionne pas) puis :

Je supprime les raids :

mdadm --remove /dev/md2
mdadm --remove /dev/md3

Puis je rejoue une procedure fonctionnelle sur un precedent serveur ovh qui a pour objectif d'attendre une connection ssh pour dechiffrer les disques durs :

 

wipefs -a /dev/sda

2. Create disk layout. It will look like this:

[512MiB boot partition | Remaining space partition] Execute command:

# Create MBR layour
parted -a optimal /dev/sda mklabel msdos
# Create first 512MiB partition
parted /dev/sda -a optimal mkpart primary 0% 1024MiB
# Create partition in remaining disk space
parted /dev/sda -a optimal mkpart primary 1024MiB 100%
# Set first partition as bootable
parted /dev/sda set 1 boot on

Installing necessary packages

Execute command:

apt update && apt install -y cryptsetup lvm2 debian-archive-keyring distro-info

We will use debootstrap for manual installation of Debian.

Go https://deb.debian.org/debian/pool/main/d/debootstrap/?C=M;O=D and download latest debootstrap_X.X.X_all.deb, e.g.:

Execute command:

wget https://deb.debian.org/debian/pool/main/d/debootstrap/debootstrap_1.0.137_all.deb && dpkg -i debootstrap*.deb && rm -f debootstrap*.deb

Creating file systems and encrypted partition 1. Create file system for boot partition.

Execute command:

mkfs.ext4 /dev/sda1

2. Create encrypted volume:

Note: nice explanation about cryptsetup parameters.

Execute command:

cryptsetup -q -s 512 -c aes-xts-plain64 luksFormat /dev/sda2

And enter your passphrase for encryption. 3. Get and write down UUID of encrypted volume - it will be used later.

Execute command:

cryptsetup luksDump /dev/sda2 | grep UUID | awk '{print $2}'

and save string like 86da4dc1-22ca-4dda-b6e3-2cb6840c9330 somewhere 4. Open encrypted volume.

Execute command:

cryptsetup luksOpen /dev/sda2 root

5. Create filesystem on encrypted and opened volume.

Execute command:

mkfs.ext4 /dev/mapper/root

Mount resulting partitions 1. Mount root partition

Execute command:

mount /dev/mapper/root /mnt

2. Mount boot partition

Execute command:

mkdir /mnt/boot && mount /dev/sda1 /mnt/boot

Bootstrap Ubuntu into mounted partitions

Execute command:

debootstrap --arch amd64 stable /mnt https://deb.debian.org/debian

Ps : S'il y a un probleme de clés, rajouter

--no-check-gpg

Mount system partitions before chroot into freshly bootstrapped debian

Execute command:

mount -o bind /dev /mnt/dev
mount -t proc proc /mnt/proc
mount -t sysfs sys /mnt/sys

Chroot into debian

Execute command:

chroot /mnt /bin/bash

Save UUID of encrypted volume into crypttab

<SAVED_UUID> is string we saved earlier, i.e. looks like 86da4dc1-22ca-4dda-b6e3-2cb6840c9330 Execute command:

echo "root UUID=<SAVED_UUID> none luks" > /etc/crypttab

For example, command can looks like: echo “root UUID=78aa5a97-a9c4-4680-9c93-36a2d74f8a51 none luks” > /etc/crypttab Create new fstab

Execute command:

cat << EOF > /etc/fstab
/dev/mapper/root / ext4 defaults,relatime 0 1
/dev/sda1 /boot ext4 defaults,relatime 0 2
EOF

Symlink /proc/mounts

Execute command:

ln -sf /proc/mounts /etc/mtab

Install ifupdown package

Execute command:

apt update && apt install -y netplan.io

Set up network interfaces and hostnames resolution 1. Prepare following variables:

a. <hostname> - hostname for server, for example, myserver b. <domain> - domain for server, for example, example.org 2. Execute command (use variables from 1.):

cat << EOF > /etc/netplan/01-eth0.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: yes
      nameservers:
        search: [MONDOMAINE.com]
        addresses: [9.9.9.9]
EOF

HOSTNAME=MABOX
DOMAIN=MONDOMAINE.com
echo ${HOSTNAME} > /etc/hostname

echo "127.0.1.1 ${HOSTNAME}.${DOMAIN} ${HOSTNAME}" >> /etc/hosts

Set up time zone

Execute command:

echo "UTC" > /etc/timezone
dpkg-reconfigure -f noninteractive tzdata

Set up default package repositories

Execute command:

apt install lsb-release
CODENAME=$(lsb_release --codename --short)
cat > /etc/apt/sources.list << EOF
deb https://deb.debian.org/debian/ $CODENAME main contrib non-free non-free-firmware
deb-src https://deb.debian.org/debian/ $CODENAME main contrib non-free non-free-firmware

deb https://security.debian.org/debian-security $CODENAME-security main contrib non-free non-free-firmware
deb-src https://security.debian.org/debian-security $CODENAME-security main contrib non-free non-free-firmware

deb https://deb.debian.org/debian/ $CODENAME-updates main contrib non-free non-free-firmware
deb-src https://deb.debian.org/debian/ $CODENAME-updates main contrib non-free non-free-firmware
EOF

[Optional] Do not install suggested and recommended packages by default

Execute command:

cat << EOF > /etc/apt/apt.conf.d/999aptsettings
APT::Install-Recommends "0";
APT::Install-Suggests "0";
EOF

Install necessary packages

Note: When question appear where to install bootloader - select /dev/sda device - first one in the list.

Execute command:

apt update && apt install -y busybox console-setup cryptsetup dropbear grub-pc initramfs-tools kbd locales ssh dropbear-initramfs

Set up SSH keys

<PUBLIC_SSH_KEY> variable - is your public ssh key, variable should look like:

Execute command:

PUBLIC_SSH_KEY="ssh-rsa MACLE"
mkdir /root/.ssh && chmod 600 /root/.ssh
echo ${PUBLIC_SSH_KEY} > /root/.ssh/authorized_keys
echo ${PUBLIC_SSH_KEY} > /etc/dropbear/authorized_keys
echo ${PUBLIC_SSH_KEY} > /etc/dropbear/initramfs/authorized_keys

[Optional] Set up password login

Set root password: Execute command:

passwd

end enter your password.

Allow dropbear accept passwords: Execute command:

sed -i 's/local flags=\"Fs\"/local flags=\"F\"/' /usr/share/initramfs-tools/scripts/init-premount/dropbear

cat << EOF > /etc/initramfs-tools/hooks/passwd_hook.sh
#!/bin/sh

PREREQ=""
prereqs()
{
echo "\$PREREQ"
}
case \$1 in
    prereqs)
        prereqs
        exit 0
    ;;
esac

grep -e root /etc/shadow > \${DESTDIR}/etc/shadow
EOF

chmod +x /etc/initramfs-tools/hooks/passwd_hook.sh

Set up network support in bootloader and adjust network interfaces names

Execute command:

Attention mettre peut etre enp4s0 au lieu de eth0

sed -i s/GRUB_CMDLINE_LINUX=\"\"/GRUB_CMDLINE_LINUX=\"net.ifnames=0\ biosdevname=0\ ip=:::::eth0:dhcp\"/g /etc/default/grub

Update grub and initramfs images

Execute command:

update-grub && update-initramfs -u

Exiting chroot

Execute command:

exit
umount /mnt/{boot,dev,proc,sys}
umount /mnt
cryptsetup luksClose root

Booting server back from hard drive

  Click on Netboot button in your server Control Panel.
  Click on Hard disk button in pop-up window.
  Click Next button
  Click Confirm button
  Execute command in still loaded rescue ssh console:

reboot

Bonjour,

Pour information, j'ai pris un serveur (https://eco.ovhcloud.com/fr/kimsufi/ks-le-2/) il y a 5 jours et je rencontre le même problème ( et je ne peux pas faire escape, il reste bloqué) :

Le serveur etant neuf, la procedure est facilement reproductible.

Boot en rescue debian10 ( pour une raison inconnu, la debian12-rescue ne fonctionne pas) puis :

Je supprime les raids :

mdadm --remove /dev/md2
mdadm --remove /dev/md3

Puis je rejoue une procedure fonctionnelle sur un precedent serveur ovh qui a pour objectif d'attendre une connection ssh pour dechiffrer les disques durs :

 

wipefs -a /dev/sda

2. Create disk layout. It will look like this:

[512MiB boot partition | Remaining space partition] Execute command:

# Create MBR layour
parted -a optimal /dev/sda mklabel msdos
# Create first 512MiB partition
parted /dev/sda -a optimal mkpart primary 0% 1024MiB
# Create partition in remaining disk space
parted /dev/sda -a optimal mkpart primary 1024MiB 100%
# Set first partition as bootable
parted /dev/sda set 1 boot on

Installing necessary packages

Execute command:

apt update && apt install -y cryptsetup lvm2 debian-archive-keyring distro-info

We will use debootstrap for manual installation of Debian.

Go https://deb.debian.org/debian/pool/main/d/debootstrap/?C=M;O=D and download latest debootstrap_X.X.X_all.deb, e.g.:

Execute command:

wget https://deb.debian.org/debian/pool/main/d/debootstrap/debootstrap_1.0.137_all.deb && dpkg -i debootstrap*.deb && rm -f debootstrap*.deb

Creating file systems and encrypted partition 1. Create file system for boot partition.

Execute command:

mkfs.ext4 /dev/sda1

2. Create encrypted volume:

Note: nice explanation about cryptsetup parameters.

Execute command:

cryptsetup -q -s 512 -c aes-xts-plain64 luksFormat /dev/sda2

And enter your passphrase for encryption. 3. Get and write down UUID of encrypted volume - it will be used later.

Execute command:

cryptsetup luksDump /dev/sda2 | grep UUID | awk '{print $2}'

and save string like 86da4dc1-22ca-4dda-b6e3-2cb6840c9330 somewhere 4. Open encrypted volume.

Execute command:

cryptsetup luksOpen /dev/sda2 root

5. Create filesystem on encrypted and opened volume.

Execute command:

mkfs.ext4 /dev/mapper/root

Mount resulting partitions 1. Mount root partition

Execute command:

mount /dev/mapper/root /mnt

2. Mount boot partition

Execute command:

mkdir /mnt/boot && mount /dev/sda1 /mnt/boot

Bootstrap Ubuntu into mounted partitions

Execute command:

debootstrap --arch amd64 stable /mnt https://deb.debian.org/debian

Ps : S'il y a un probleme de clés, rajouter

--no-check-gpg

Mount system partitions before chroot into freshly bootstrapped debian

Execute command:

mount -o bind /dev /mnt/dev
mount -t proc proc /mnt/proc
mount -t sysfs sys /mnt/sys

Chroot into debian

Execute command:

chroot /mnt /bin/bash

Save UUID of encrypted volume into crypttab

<SAVED_UUID> is string we saved earlier, i.e. looks like 86da4dc1-22ca-4dda-b6e3-2cb6840c9330 Execute command:

echo "root UUID=<SAVED_UUID> none luks" > /etc/crypttab

For example, command can looks like: echo “root UUID=78aa5a97-a9c4-4680-9c93-36a2d74f8a51 none luks” > /etc/crypttab Create new fstab

Execute command:

cat << EOF > /etc/fstab
/dev/mapper/root / ext4 defaults,relatime 0 1
/dev/sda1 /boot ext4 defaults,relatime 0 2
EOF

Symlink /proc/mounts

Execute command:

ln -sf /proc/mounts /etc/mtab

Install ifupdown package

Execute command:

apt update && apt install -y netplan.io

Set up network interfaces and hostnames resolution 1. Prepare following variables:

a. <hostname> - hostname for server, for example, myserver b. <domain> - domain for server, for example, example.org 2. Execute command (use variables from 1.):

cat << EOF > /etc/netplan/01-eth0.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: yes
      nameservers:
        search: [MONDOMAINE.com]
        addresses: [9.9.9.9]
EOF

HOSTNAME=MABOX
DOMAIN=MONDOMAINE.com
echo ${HOSTNAME} > /etc/hostname

echo "127.0.1.1 ${HOSTNAME}.${DOMAIN} ${HOSTNAME}" >> /etc/hosts

Set up time zone

Execute command:

echo "UTC" > /etc/timezone
dpkg-reconfigure -f noninteractive tzdata

Set up default package repositories

Execute command:

apt install lsb-release
CODENAME=$(lsb_release --codename --short)
cat > /etc/apt/sources.list << EOF
deb https://deb.debian.org/debian/ $CODENAME main contrib non-free non-free-firmware
deb-src https://deb.debian.org/debian/ $CODENAME main contrib non-free non-free-firmware

deb https://security.debian.org/debian-security $CODENAME-security main contrib non-free non-free-firmware
deb-src https://security.debian.org/debian-security $CODENAME-security main contrib non-free non-free-firmware

deb https://deb.debian.org/debian/ $CODENAME-updates main contrib non-free non-free-firmware
deb-src https://deb.debian.org/debian/ $CODENAME-updates main contrib non-free non-free-firmware
EOF

[Optional] Do not install suggested and recommended packages by default

Execute command:

cat << EOF > /etc/apt/apt.conf.d/999aptsettings
APT::Install-Recommends "0";
APT::Install-Suggests "0";
EOF

Install necessary packages

Note: When question appear where to install bootloader - select /dev/sda device - first one in the list.

Execute command:

apt update && apt install -y busybox console-setup cryptsetup dropbear grub-pc initramfs-tools kbd locales ssh dropbear-initramfs

Set up SSH keys

<PUBLIC_SSH_KEY> variable - is your public ssh key, variable should look like:

Execute command:

PUBLIC_SSH_KEY="ssh-rsa MACLE"
mkdir /root/.ssh && chmod 600 /root/.ssh
echo ${PUBLIC_SSH_KEY} > /root/.ssh/authorized_keys
echo ${PUBLIC_SSH_KEY} > /etc/dropbear/authorized_keys
echo ${PUBLIC_SSH_KEY} > /etc/dropbear/initramfs/authorized_keys

[Optional] Set up password login

Set root password: Execute command:

passwd

end enter your password.

Allow dropbear accept passwords: Execute command:

sed -i 's/local flags=\"Fs\"/local flags=\"F\"/' /usr/share/initramfs-tools/scripts/init-premount/dropbear

cat << EOF > /etc/initramfs-tools/hooks/passwd_hook.sh
#!/bin/sh

PREREQ=""
prereqs()
{
echo "\$PREREQ"
}
case \$1 in
    prereqs)
        prereqs
        exit 0
    ;;
esac

grep -e root /etc/shadow > \${DESTDIR}/etc/shadow
EOF

chmod +x /etc/initramfs-tools/hooks/passwd_hook.sh

Set up network support in bootloader and adjust network interfaces names

Execute command:

Attention mettre peut etre enp4s0 au lieu de eth0

sed -i s/GRUB_CMDLINE_LINUX=\"\"/GRUB_CMDLINE_LINUX=\"net.ifnames=0\ biosdevname=0\ ip=:::::eth0:dhcp\"/g /etc/default/grub

Update grub and initramfs images

Execute command:

update-grub && update-initramfs -u

Exiting chroot

Execute command:

exit
umount /mnt/{boot,dev,proc,sys}
umount /mnt
cryptsetup luksClose root

Booting server back from hard drive

  Click on Netboot button in your server Control Panel.
  Click on Hard disk button in pop-up window.
  Click Next button
  Click Confirm button
  Execute command in still loaded rescue ssh console:

reboot

Bonjour Pit,

Est-ce que GRUB est bien installé sur /dev/sda ? Si c'est le cas, vous devriez voir quelque chose comme ça :
# head -c 512 /dev/sda | xxd
[…]
00000180: 4752 5542 2000 4765 6f6d 0048 6172 6420  GRUB .Geom.Hard 
00000190: 4469 736b 0052 6561 6400 2045 7272 6f72  Disk.Read. Error
[…]

Peut-être que le serveur essaie de booter sur /dev/sdb sans essayer /dev/sda. Est-ce qu'une installation Debian lancée par notre système fonctionne correctement ?