Un nouveau serveur installé sous proxmox8 fin octobre subie un problème au démarrage ce 1er janvier.
Cela pourrait être lié au nouveau kernel 6.5 et le BMD mais même quand je reboot sur 6.2 le serveur reste bloqué sur "Loading initial ramdisk" - que ce soit en mode normal ou en mode sans échec.
Sur le forum de proxmox:
https://forum.proxmox.com/threads/pve-linux-6-5-11-7-pve-stucks-loading-initial-ramdisk.138157/
Le serveur a été installé sous proxmox 8 depuis l'image d'OVH - il est étrange que le serveur ne boot pas sur la version 6.2.16-19-pve qui semble être la version initiale.
Bonjour,
Tu as essayé de modifier les options du grub ?
Ou de le réinstaller complètement.
Il me semble que c'est un problème de lecture de la partition grub donc le /dev/sda1 généralement
Comme tu dois avoir du raid, il est possible de déplacer le boot vers la /dev/sdb1 (si ce sont le nom des partitions)
Je te conseils de réinstaller le grub, puis de changer le disque de boot éventuellement et si rien ne marche de recommencer l'installation du serveur.
Bon courage et bonne année
Captainadmin
Bonjour,
Pouvez-vous s'il vous plaît m'envoyer en message privé le nom du serveur ? Je vais voir si je reproduis le problème avec du hardware similaire.
m'envoyer en message privé le nom du serveur
Je ne peux pas envoyer de message privé je pense - peut-être je peux vous répondre si vous m'en envoyez un.
Tu as essayé de modifier les options du grub ?
Ou de le réinstaller complètement.
Je ne parvenais pas à accéder au grub (avec le KVM), et je préférais éviter de réinstaller complèment.
En mode rescue, j'ai modifié le grub.cfg pour mettre un timeout <> 0 et à partir de là j'ai pu faire des essais.
Il me semble que c'est un problème de lecture de la partition grub donc le /dev/sda1 généralement
Comme tu dois avoir du raid, il est possible de déplacer le boot vers la /dev/sdb1 (si ce sont le nom des partitions)
Au démarrage il y a un mécanisme avant le grub qui permets de choisir la partition de boot, mais cela ne donnait pas de solution.
Je te conseils de réinstaller le grub, puis de changer le disque de boot éventuellement et si rien ne marche de recommencer l'installation du serveur.
J'ai pu éviter la réinstallation, mais en passant par une réinstallation de grub, une mise à jour du kernel en mode chroot, etc.
Bon courage et bonne année
Captainadmin
Merci, bonne année à vous également.
J'ai passé un bon moment à dépanner cela avant que mon post ici soit même visible.
En post-analyse ce matin je constate que le démarrage n'était pas si bloqué que cela car j'ai pas mal de traces de démarrage dans le journal, mais rien n'était visible sur l'interface et je n'ai pas réussi à me connecter dessus (pb. réseau?). Enfin, je n'ai pas essayé le ssh tout le temps, j'attendais principalement de voir le déroulement du démarrage et le prompt de login sur le KVM.
Il me semble probable qu'il s'agit d'un problème de compatibilité de kernel - en passant par la 6.2.16-20-pve et ensuite la 6.5.11-7-pve j'ai pu rétablir les services.
En résumé j'ai:
- Modifié le grub.cfg pour avoir un délai pour choisir le mode de démarrage;
Sans succès, le kernel précédent ne permettait pas de démarrer.
- Transféré le /boot depuis un PC de test vers le serveur, modifié le grub.cfg - avec une réussite partielle (une trace de boot sur le KVM), sans que cela m'autorisait un accès au système.
- Passé par un 'chroot' depuis le rescue pour reinstaller grub, sans grand succès, puis installé le kernel le plus récent sous 6.2. Je passe des détails - mais j'ai fini par booter et avoir le prompt de login et la possibilité de me connecter à distance. Le grub n'était pas parfaitement installé, mais j'ai pu choisir les images que j'avais aussi copié sous /boot_... .
- Puis j'ai mis à jour le serveur, tenté un démarrage sur la dernière 6.5 qui fonctionne.
- Je n'ai pas tester si l'autre 6.5.11-4-pve fonctionne, ce n'est pas mon objectif.
```bash
# 'lsblk' and 'fdisk -l' can help identify the partitions
export lang=C
export LC_ALL=C.UTF-8
mount /dev/md127 /mnt
mount /dev/md126 /mnt/boot
mount /dev/nvme0n1p1 /mnt/boot/efi
mount --rbind /dev /mnt/dev
mount --rbind /proc /mnt/proc
mount --rbind /sys /mnt/sys
chroot /mnt
# In chroot
# Add loglevel=7 to following in /etc/default/grub
# GRUB_CMDLINE_LINUX_DEFAULT="loglevel=7"
export LC_ALL=C.UTF-8
apt-get install console-setup
dpkg-reconfigure grub-efi-amd64
update-grub
apt-get install pve-kernel-6.2.16-20-pve
proxmox-boot-tool kernel pin 6.2.16-20-pve
grub-install
# However, the reinstallation of grub above is not perfect.
# A copy of /boot to /bootcopy helped during boot
# For some reason /boot was not properly mapped.
# I managed to properly boot by editing the grub boot option
# and changing /boot/ to /bootcopy in the 'linux' and 'initrd' instructions.
cp -Rp /boot /bootcopy
```
Merci pour ces informations,
En ce qui concerne le manque de traces sur le KVM, ça peut être dû au fait que nous configurons la console serial (SOL) en plus de la console tty normale dans `GRUB_CMDLINE_LINUX` (du genre `console=tty0 console=ttyS1,115200n8`). À cause de ça, il arrive que certains messages d'erreur ne s'affichent que dans la console SOL (accessible depuis le site Web à côté du KVM).
Dans tous les cas, vais lancer des installations sur deux de mes serveurs qui une configuration similaire à la votre (`Xeon E-2236` + `P11C-M-10G-2T`) et je vous tiens au courant.
Rien à signaler avec mes deux installations de test. Notre image de Proxmox 8 est à jour ; à l'installation, on est sur le kernel `6.5.11-7-pve`.
N'hésitez pas à répondre si jamais vous avez plus d'informations sur le problème initial.
Merci pour ce retour.
Notre image de Proxmox 8 est à jour ; à l'installation, on est sur le kernel 6.5.11-7-pve.
Quand j'ai installé le serveur fin novembre, la version était 6.2.16-19-pve avec une installation de 6.5.11-4-pve sur le système entretemps (sans redémarrage). Si la 6.5.11-7-pve fonctionne, la 6.5.11-4-pve ne fonctionne peut-être pas.
ça peut être dû au fait que nous configurons la console serial (SOL) en plus de la console tty normale
C'est intéressant à savoir et possible, mais après avoir corrigé le problème (dont regénération du GRUB avec ces options definis sous /etc/defaults/grub* et présents dans le grub.cfg), mais ajout de loglevel=7, j'ai bien des traces sous KVM
Je suggère de le faire mentionner dans le retour fait par l'équipe de support qui s'était visiblement aussi arrêté à ce diagnostique:
```text
Voici les détails de cette opération :
Boot sur interface diagnostique (rescue)
Date 2024-01-01 15:32:04 CET (UTC +01:00), Boot sur interface diagnostique (rescue):
Voici le détail de l'intervention réalisée:
Le serveur reste bloqué durant la phase de boot sur le message :
(Loading initial ramdisk …)
Actions entreprises:
Redémarrage du serveur sur mode 'rescue' (Linux)
Résultat:
Boot OK. Système 'rescue' accessible.
Recommandations:
Configuration/erreur à corriger par le client
```