Debian serveur : démarrage impossible sans écran

Support Debian
#1

Bonjour à tous,

J’ai installé chez moi un petit serveur debian 9.4.0. Je n’ai pas installé de serveur graphique. Lors de mon installation j’ai donc utilisé un câble hdmi pour brancher le serveur sur ma télé et avoir un écran provisoire le temps de finir l’installation et de pouvoir prendre la main en ssh.

Le problème que je rencontre est le suivant :

  • Lorsque je démarre le serveur avec l’écran branché sur ma télé en hdmi 1 et que j’affiche effectivement l’entrée hdmi 1 sur ma télé, il démarre sans pb
  • Lorsque je démarre le serveur avec l’écran branché sur ma télé en hdmi 1 et que j’affiche une autre entrée (hdmi 2 par ex) sur ma télé, il ne démarre pas
  • Lorsque je démarre le serveur sans avoir l’écran de branché, il ne démarre pas non plus

Quand je dis qu’il ne démarre pas je sous entend que je n’arrive pas à me connecter dessus en ssh. Il ne répond d’ailleurs pas aux pings non plus.

Est ce que ce problème parle à quelqu’un? Comment pourrais-je le diagnostiquer plus précisément pour savoir ce qui l’empêche de finir son démarrage?

NB : Je ne suis pas très familier des fichiers logs. Si des infos peuvent être trouvé de ce côté la, merci de me guider un peu :wink:

D’avance merci

#2

Lorsqu’il se lance correctement, tu parviens à t’y connecter en ssh via un autre poste ?

#3

Oui j’ai oublié de le préciser mais effectivement lorsque le démarrage se passe bien je peux me connecter dessus en ssh sans problème.

#4

Sur quel matériel tourne ton serveur ?

Edit : ça pourrait être un problème matériel (carte mère faite pour booter avec un écran) ou bien un réglage du grub.

#5

Je ne pense pas que le problème soit matériel car j’avais déjà un serveur Debian (6.x) a une époque sur cette machine et je n’avais rien changé matériellement depuis.

Par contre en jouant avec les entrées hdmi de ma télé j’ai réussis à revenir sur le serveur au moment du plantage et j’ai pu prendre une photo :
20180408_161838

Alors à moi ça ne me parle pas du tout mais quelqu’un qui connaît bien Debian saura sans doute voir ce qui cloche.

D’après cette capture je pense deviné que l’on est plus dans grub, c’est déjà le démarrage de l’OS si je dis pas de connerie.

#6

En effet c’est l’initramfs (système initial en mémoire), qui a pour fonction de monter le système de fichiers contenant la racine du système. On dirait qu’il ne monte pas la bonne partition, du coup il ne trouve pas divers répertoires et fichiers qui sont censés se trouver dedans. Mais je ne vois pas du tout le rapport avec la présence d’un écran…

A l’invite du shell de l’initramfs, peux-tu exécuter les commandes suivantes (attention QWERTY) :

cat /proc/cmdline # pour voir la valeur du paramètre root=
ls /root          # pour voir le contenu de la partition montée comme racine
mount             # pour voir quelle partition est montée sur /root
#7

Ci dessous le retour des commandes :

20180408_180711

Le problème est identifié par la commande “ls /root” qui montre que c’est un de mes disques dur de données qui est montée à la place de la partition racine…
Le retour de la commande “mount” nous dis pourtant que /dev/sdb1 est montée sur /root ce qui est correct.

C’est comme si sdb désignait un disque dur différent lorsque j’ai un écran de branché. J’avoue que je ne vois pas trop le rapport.

#8

Moi non plus mais une chose est sûre : les noms de périphérique des disques ne sont pas persistants et peuvent changer sans raison d’un démarrage à l’autre. Il faut faire avec, ou plutôt sans, donc utiliser des identifiants persistants comme les UUID ou étiquettes (LABEL), comme cela doit être le cas dans /etc/fstab. Le paramètre root= passé par GRUB (si le chargeur est bien GRUB) devrait être l’UUID.

Démarre avec un écran, vérifie que

  • dans /etc/default/grub la ligne GRUB_DISABLE_LINUX_UUID est bien commentée (#)

  • dans /etc/fstab la racine est bien spécifiée par son UUID

et exécute update-grub pour voir si ça regénère un fichier /boot/grub/grub.cfg correct avec root=UUID=xxx au lieu de root=/dev/sdb1.

#9

Ce pourrait être intéressant de réitérer les commandes quand le lancement fonctionne, histoire de voir si les montages coïncident ou non. On peut envisager qu’un ou plusieurs éléments de ton écran amènent ton ordi à reconnaître un autre disque (étrange mais pas impossible) et décale le nommage des disques (et fait donc foirer le boot). La suggestion de @PascalHambourg est tout à fait pertinente pour ce type de problème.

#10

Dans mon /etc/default/grub la ligne GRUB_DISABLE_LINUX_UUID=true est bien commentée.
Dans /etc/fstab tous les montages sont définis par leur UUID.

Par contre dans /boot/grub/grub.cfg, j’avais des références à /dev/sdb1

J’ai effectué un update-grub et cela à corriger le grub.cfg (je n’ai plus de références à /dev/sdb1)

Et depuis le démarrage se passe maintenant normalement. Avec ou sans écran :slight_smile:

C’est quand même bizarre de devoir exécuter cette commande sur une installation fraîche sur laquelle je n’ai pas encore “bidouiller”.

Cela dit, merci beaucoup à vous deux pour votre aide et votre diagnostique :wink:

#11

Installation fraîche ? Justement il m’est déjà arrivé de constater cette anomalie dans le grub.cfg généré lors de l’installation. Je n’en connais pas la cause.

#12

salut
sous raspberry pi 2 y avait un problème comme ça
il fallait changer un fichier texte, genre mettre 1 à la place de 0
je n’ai pas lu tout le post mais si c’est ça je recherche.

#13

Raspberry Pi, c’est particulier :

  • Si je ne m’abuse, le chargeur d’amorçage n’est pas GRUB mais U-Boot.

  • La racine est sur une partition de la carte SD dont le nom de périphérique /dev/mmcblk* est a priori fixe, donc ce n’est pas gênant.