Serveur distant inaccessible en ssh suite à màj

D’après le contenu de grub.cfg, j’aurais plutôt mis GRUB_DEFAULT=1.
Concernant les erreurs “no such device”, il a peut-être besoin que /proc soit monté dans le chroot ?

Alors, suivant tes conseils j’ai monté :

/procroot@rescue:~# mount -t proc /proc /mnt/md2/procet comme j’avais toujours la même erreur “no such disk” j’ai aussi monté :

/devroot@rescue:~# mount --bind /dev /mnt/md2/dev
/runroot@rescue:~# mount --bind /run /mnt/md2/run
/sysroot@rescue:~# mount -t sysfs /sys /mnt/md2/sys
On vérifie tout ça :root@rescue:/# mount /dev/md2 on / type ext3 (rw,relatime,errors=continue,barrier=1,data=writeback) /dev/md1 on /boot type ext3 (rw,relatime,errors=continue,barrier=1,data=writeback) /proc on /proc type proc (rw,relatime) tmpfs on /dev type tmpfs (rw,relatime,size=10240k,mode=755) tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=197512k,mode=755) /sys on /sys type sysfs (rw,relatime) root@rescue:/#
Et là, du coup la màj de Grub fonctionne correctement :root@rescue:/# update-grub Generating grub.cfg ... Warning: Setting GRUB_TIMEOUT to a non-zero value when GRUB_HIDDEN_TIMEOUT is set is no longer supported. Warning: update-grub_lib is deprecated, use grub-mkconfig_lib instead Found linux image: /boot/bzImage-3.2.13-xxxx-grs-ipv6-64 Found linux image: /boot/vmlinuz-3.2.0-61-generic Found initrd image: /boot/initrd.img-3.2.0-61-generic Found linux image: /boot/vmlinuz-3.2.0-60-generic Found initrd image: /boot/initrd.img-3.2.0-60-generic Found linux image: /boot/vmlinuz-3.2.0-59-generic Found initrd image: /boot/initrd.img-3.2.0-59-generic done root@rescue:/#
Mais malheureusement au 1er reboot, ça marche toujours pas !

Et la valeur de GRUB_DEFAULT (qui se retrouve en “set default” dans grub.cfg) ? Si je compte bien :
0 = noyau OVH
1 = dernier noyau Ubuntu en mode normal
2 = dernier noyau Ubuntu en mode recovery

Or si la machine répond au ping mais n’a aucun service actif, cela pourrait correspondre à un démarrage en mode recovery.

Pour les erreurs « no such disk », je tenterais de générer un fichier mtab. En considérant que tout est bien monté dans le chroot :

EDIT: lu trop vite, j’avais pas vu que t’avais réussi l’install de grub au final :blush:

Sauf erreur, il me semble que maintenant /etc/mtab est un lien symbolique qui pointe vers /proc/mounts (du moins dans Debian). Or le montage de /proc n’a visiblement pas suffi à supprimer le message. Je pense que c’est /dev qui manquait.

[quote=“PascalHambourg”]Et la valeur de GRUB_DEFAULT (qui se retrouve en “set default” dans grub.cfg) ? Si je compte bien :
0 = noyau OVH
1 = dernier noyau Ubuntu en mode normal
2 = dernier noyau Ubuntu en mode recovery

Or si la machine répond au ping mais n’a aucun service actif, cela pourrait correspondre à un démarrage en mode recovery.[/quote]Ben c’est pour ça que j’ai essayé aussi avec set default=“3” dans /mnt/md2/boot/grub/grub.cfg mais ça marche toujours pas.
Je vais essayer d’autres valeurs, on ne sait jamais…

[quote=“PascalHambourg”]Je pense que c’est /dev qui manquait.[/quote]C’est effectivement le montage de /dev qui a supprimé les “no such disk”, mais après j’ai eu des erreurs “device node not found” !
Le montage de /run n’a rien apporté de plus ou de moins, c’est le montage de /sys qui les a supprimé.

Pour info, je me suis basé sur cette doc.

Good news : j’ai de nouveau la main sur mon serveur par ssh en mode normal ! :033

Pour que ça re-fonctionne, j’ai remonté /boot, /proc, /dev, /run et /sys dans le chroot puis j’ai fait une màj :

root@rescue:/# apt-get update && apt-get dist-upgrade

suivie d’une ré-install du serveur openssh :

root@rescue:/# apt-get install --reinstall openssh-server

puis redémarrage en mode normal de la bête et, après un peu moins d’une heure de fsck (je suppose) j’ai reçu deux mails (des scripts /etc/init.d et crontab mis en place précédemment) me prévenant du bon redémarrage du serveur.

Pour info, lors de la màj grub.cfg a été régénéré, alors qu’il n’y a avait que les paquets ifupdown et libxml2 à mettre à jour.
Pourquoi cette régénération, et est-ce elle ou la ré-install (une seconde fois !) d’openssh-server qui a permis que tout re-fonctionne ?
Mystère…

Un grand merci à tous ceux qui m’ont aidé !