Redemarrage serveur dedié (mode rescue activé))

Bonjour,

Bref, j'ai vu qu'on pouvait faire un netboot sur Ovh en bootant sur le "reseau"

cela n'existe plus et était déprécié depuis plusieurs années.

Que il faudrait se connecter en KVM pour vérifier c'est quoi le message d'erreur.

Cordialement, janus57

cela n'existe plus et était déprécié depuis plusieurs années.

Que il faudrait se connecter en KVM pour vérifier c'est quoi le message d'erreur.

Cordialement, janus57

Il faut probablement essayer de réinstaller grub...
Pas tjrs évident en rescue et l'uefi n'aide pas il me semble...

Je n'ai pas eu à faire ce genre de manip depuis des années...
En fait c'est même qque chose d'exceptionnel...
Mais il faudrait voir en kvm le message exact au boot.
Et ensuite bah une recherche de doc pour essayer de corriger...

Bonjour,

C'est le serveur sur lequel je suis intervenu hier ?
Le problème est résolu maintenant ?

Captainadmin

Captainadmin

Bonjour Jean,

Je suis dans un cas potentiellement similaire.
Avec un kimsufi avec un disque de 2 TB, je suis toujours en netboot et ça tient tant que je ne change pas le réglage... mais pour combien de temps ?

~# uname -a
Linux k3.____.eu 4.19.62-mod-std-ipv6-64-rescue #828825 SMP Tue Jul 30 13:54:49 UTC 2019 x86_64 GNU/Linux
~# cat /etc/debian_version
10.13
~# dpkg -l |grep -i grub
ii grub-common 2.06-3~deb10u3 amd64 GRand Unified Bootloader (common files)
ii grub-pc 2.06-3~deb10u3 amd64 GRand Unified Bootloader, version 2 (PC/BIOS version)
ii grub-pc-bin 2.06-3~deb10u3 amd64 GRand Unified Bootloader, version 2 (PC/BIOS modules)
ii grub2-common 2.06-3~deb10u3 amd64 GRand Unified Bootloader (common files for version 2)

fdisk -l
Disk /dev/sda: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: HGST HUS726020AL
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x3f78dd73

Device Boot Start End Sectors Size Id Type
/dev/sda1 * 4096 1050623 1046528 511M 83 Linux
/dev/sda2 1050624 42008575 40957952 19.5G 83 Linux
/dev/sda3 42008576 50395135 8386560 4G 82 Linux swap / Solaris
/dev/sda4 50395136 3907029167 3856634032 1.8T 83 Linux

/# mount
/dev/sda2 on / type ext4 (rw,relatime,errors=remount-ro)
...
/dev/sda1 on /boot type ext4 (rw,relatime,errors=remount-ro)
/dev/sda4 on /home type ext4 (rw,relatime,errors=remount-ro)

:/etc/grub.d# ls -ltr
total 88
-rw-r--r-- 1 root root 483 Jun 12 2019 README
-rwxr-xr-x 1 root root 214 Jun 12 2019 40_custom
-rw-r--r-- 1 noderig noderig 372 Mar 22 2020 06_OVHkernel
-rwxr-xr-x 1 root root 215 Aug 1 2022 41_custom
-rwxr-xr-x 1 root root 1372 Aug 1 2022 30_uefi-firmware
-rwxr-xr-x 1 root root 12910 Aug 1 2022 30_os-prober
-rwxr-xr-x 1 root root 14180 Aug 1 2022 20_linux_xen
-rwxr-xr-x 1 root root 14123 Aug 1 2022 10_linux
-rwxr-xr-x 1 root root 6260 Aug 1 2022 05_debian_theme
-rwxr-xr-x 1 root root 10046 Aug 1 2022 00_header

(aussi bien 41_custom que 06_OVH sont fonctionnellement vides)

/boot/grub# grep -i ovh /boot/grub/grub.cfg
echo 'Loading Linux 4.19-ovh-xxxx-std-ipv6-64 ...'
linux /vmlinuz-4.19-ovh-xxxx-std-ipv6-64 root=/dev/sda2 ro noquiet nosplash
initrd /initrd.img-4.19-ovh-xxxx-std-ipv6-64
menuentry 'Debian GNU/Linux, with Linux 4.19-ovh-xxxx-std-ipv6-64' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.19-ovh-xxxx-std-ipv6-64-advanced-dafd7667-40d3-4e89-b65f-a3379d15dd78' {
echo 'Loading Linux 4.19-ovh-xxxx-std-ipv6-64 ...'
linux /vmlinuz-4.19-ovh-xxxx-std-ipv6-64 root=/dev/sda2 ro noquiet nosplash
initrd /initrd.img-4.19-ovh-xxxx-std-ipv6-64
menuentry 'Debian GNU/Linux, with Linux 4.19-ovh-xxxx-std-ipv6-64 (recovery mode)' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.19-ovh-xxxx-std-ipv6-64-recovery-dafd7667-40d3-4e89-b65f-a3379d15dd78' {
echo 'Loading Linux 4.19-ovh-xxxx-std-ipv6-64 ...'
linux /vmlinuz-4.19-ovh-xxxx-std-ipv6-64 root=/dev/sda2 ro single
initrd /initrd.img-4.19-ovh-xxxx-std-ipv6-64

Je me demande si je prends des risques à booter sur le noyau local, car après je ne pourrai plus sélectionner le netboot qui n'est évidemment plus proposé dans le manager.

Merci d'avance de tes conseils :)

Le problème est résolu et mon serveur tourne à nouveau.
Cette opération ne m'inspirait pas du tout confiance pourtant je me débrouille à peu près.
Grand merci à capitainAdmin.

Le mieux c'est de forcer l'installation de ton grub et de le configurer correctement.
Je sais pas si c'est le meme probleme mais globalement les problèmes de démarrage sont toujours lié à un probleme de configuration grub.

update-grub2
grub-install

Ce sont les 2 commandes principales que tu peux tester, en vérifiant que le /boot est bien monté

Bon courage

update-grub2
grub-install

Ce sont les 2 commandes principales que tu peux tester

Bonjour Jean,

root@k3:~# update-grub2
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.19-ovh-xxxx-std-ipv6-64
Found initrd image: /boot/initrd.img-4.19-ovh-xxxx-std-ipv6-64
done

ce qui correspond bien au kernel qui se trouve dans /boot (mais pas exactement celui qui tourne (4.19.62-mod-std-ipv6-64-rescue)

root@k3:/boot# grub-install /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.

Hop je vais rebooter d'abord sur le noyau netboot, puis sur le HD.

[Edit: Succès total. Merci Jean ! ça m'a fait du bien d'avoir un avis qui correspondait à ce que j'aurais voulu faire]