Bonjour à tous,
J'ai un ancien serveur dédié chez SYS centos 7 + Plesk …
Suite à une maj yum du kernel … il ne boot plus depuis +1 an …
Donc, j'utilisais NetBoot réseau au lieu de "Boot from hard drive (no netboot)" et cela fonctionnait de nouveau depuis +1 an.
Aujourd'hui, c'est vide dans NetBoot réseau … donc je ne peux plus boot mon serveur dédié …
J'ai essayé de réparer grub … rien à faire, cela ne veut pas fonctionner.
Le serveur ne veut pas démarrer … le support me dit : Le serveur reste bloqué durant la phase de boot sur le message : (no data)
J'ai bien accès à mes data en mode rescue … mais le boot sur HDD est KO.
Dans le NetBoot sur noyau OVH, je ne peux rien faire.
Pourquoi cela n'est plus disponible ?
C'est cauchemardesque …
Réponse du support :
"Nous l'avons retiré depuis juin"
Débrouillez vous en mode rescue …
BRAVO … c'est merveilleux …
Pourquoi n'ai-je pas écouté tout le monde, fuyez OVH !
Il faut vérifier que grub est installé sur le disque.
Et un truc est de recopier bêtement le noyau du mode rescue sur le disque, je l'ai déjà fait, ça marche.
Donc quand je suis en rescue, je récup le noyau et je fais une copie dans /boot de ma partition ?
J'ai deja essayé cela :
Je suis en raid1 soft … centos 7
mount /dev/md1 /mnt
mount -o bind /proc /mnt/proc
mount -o bind /sys /mnt/sys
mount -o bind /dev /mnt/dev
chroot /mnt /bin/bash
grub2-install /dev/sdb (et sda)
grub2-mkconfig -o /boot/grub2/grub.cfg
exit
shutdown -r now
Rien à faire … ko
En supposant que la partition md1 contient bien aussi le /boot :
Plus besoin d'aller dans le chroot mais essayer de faire :
- faire une copie de sauvegarde de /mnt/boot/vmlinuz-xxxx /mnt/boot/vmlinuz-xxxx.BACKUP
- faire une copie de sauvegarde de /mnt/boot/initrd.img-xxxx /mnt/boot/initrd.img-xxxx.BACKUP
Puis recopier celui du mode rescue (hors chroot) :
cp /boot/vmlinuz /mnt/boot/vmlinuz-xxxx
cp /boot/initrd.img /mnt/boot/initrd.img-xxxx
démonté /mnt et reboot en mode normal
Pourtant y a du kernel de dispo de base … et il ne veut pas démarrer …
Generating grub configuration file …
Found linux image: /boot/vmlinuz-3.10.0-1160.76.1.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-1160.76.1.el7.x86_64.img
Found linux image: /boot/vmlinuz-3.10.0-1160.66.1.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-1160.66.1.el7.x86_64.img
Found linux image: /boot/vmlinuz-3.10.0-1160.36.2.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-1160.36.2.el7.x86_64.img
Found linux image: /boot/vmlinuz-3.10.0-1160.24.1.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-1160.24.1.el7.x86_64.img
Found linux image: /boot/vmlinuz-3.10.0-1160.15.2.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-1160.15.2.el7.x86_64.img
J'ai md1 avec boot etc .. et md2 pour les data …
Disk /dev/sda: 279.5 GiB, 300069052416 bytes, 586072368 sectors
Disk model: INTEL SSDSC2BB30
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x9b796445
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 4096 102402047 102397952 48.8G fd Linux raid autodetect
/dev/sda2 102402048 585017343 482615296 230.1G fd Linux raid autodetect
/dev/sda3 585017344 586063871 1046528 511M 82 Linux swap / Solaris
Disk /dev/sdb: 279.5 GiB, 300069052416 bytes, 586072368 sectors
Disk model: INTEL SSDSC2BB30
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xe66525ea
Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 4096 102402047 102397952 48.8G fd Linux raid autodetect
/dev/sdb2 102402048 585017343 482615296 230.1G fd Linux raid autodetect
/dev/sdb3 585017344 586063871 1046528 511M 82 Linux swap / Solaris
Disk /dev/md1: 48.8 GiB, 52427685888 bytes, 102397824 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/md1: 48.8 GiB, 52427685888 bytes, 102397824 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/md2: 230.1 GiB, 247098966016 bytes, 482615168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
sur le rescue, /boot est vide …
A la racine du rescue, il y a peut-être un lien symbolique vers le noyau vmlinuz sinon, il faut chercher, il est forcément là.
Que donne :
> cat /proc/cmdline
rdinit=/sbin/init console=tty0 ramdisk_size=51200 load_ramdisk=1 panic=10 net.ifnames=0 rootfstype=ramfs DATASOURCE=https://1baremetal.snap.mirrors.ovh.net/rescue/fr/rescue-customerbaremetal.snap.mirrors.ovh.net/rescue/fr/rescue-customer METADATA=https://baremetal.eu.ovhapis.com/1.0/metadata-api
C'est un boot réseau avec cloud-init, je n'ai pas creusé comment ça fonctionne.
Sinon, prendre le noyau quelque part sur une machine qui fonctionne en boot disque. De toute façon, centos 7 a l'air vieux, il faudrait tout réinstaller.
Bonjour,
Pourquoi ne pas prendre une nouvelle machine et migrer les applicatifs / datas ?
Pas idéal peut être mais tu résous ton problème de GRUB.
Je comprends, il y a des solutions mais c'est scandaleux le fonctionnement de OVH.
Une migration, cela se prépare …
C'est lamentable d'agir comme ca … je pense que nous ne sommes pas les seuls a se retrouver dans cette situation.
OVH se permet de mettre KO un serveur de prod … car sans avertir, supprime une fonctionnalité que souvent était recommandée d'utiliser pour démarrer un serveur …
C'est SCANDALEUX !
sans avertir, supprime une fonctionnalité que souvent était recommandée d'utiliser pour démarrer un serveur
Pourquoi ne pas prendre une nouvelle machine
Je plussoie, que le network boot était tout un temps mis en avant par OVH.
Ce genre de régression est dure à avaler, surtout si elle est intentionnelle.
Ce qui est "drôle", c'est le nombre de serveurs toujours en netboot et qui ne savent pas encore que le reboot ne va pas marcher.
Ce qui est "drôle",
oui bof
#😢
et pourtant on trouve des documents ça et là
https://1beta.ovhcloud.com/csm/fr-dedicated-servers-kernel-netboot?id=kb_article_view&sysparm_article=KB0015359beta.ovhcloud.com/csm/fr-dedicated-servers-kernel-netboot?id=kb_article_view&sysparm_article=KB0015359
https://1beta.ovhcloud.com/csm/fr-dedicated-servers-get-familiar-with-ovhcloud-control-panel?id=kb_article_view&sysparm_article=KB0026272#interface-serveurbeta.ovhcloud.com/csm/fr-dedicated-servers-get-familiar-with-ovhcloud-control-panel?id=kb_article_view&sysparm_article=KB0026272#interface-serveur
Merci pour votre soutien …
Réponse du support complètement LAMENTABLE :
"Bonjour,
Merci de votre retour, le netboot kernel OVH était un mode de fonctionnement de tests, celui-ci permettait de rapidement tester un kernel géré par OVH.
Cependant, celui-ci n'est pas fait pour rester comme mode de démarrage principale.
Celui-ci est simplement pour diagnostique, le mode de démarrage normal est sur disque dur."
OVH se fout de la gueule du de ses clients !
Il était recommandé pour des raisons de sécurité et de compatibilité avec leurs machines !!! car justement, le kernel propre de certaines distrib installé faisait planter le démarrage car mal encaissé par les machines OVH !
Il y a des posts à ce sujet justement !!!
Ils ont mis en avant régulièrement de boot sur le kernel OVH !!!
C'est SCANDALEUX !
Vous fuyez face à la merde que vous engendrez !
Le support OVH est incompétent !
Il me redirige vers community … bravo le professionnalisme !!!
Je vais rajouter un max d'info .. si quelqu'un peut m'aider à reussir à redemarrer cette saleté de serveur 
Model: ATA INTEL SSDSC2BB30 (scsi)
Disk /dev/sda: 300GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 2097kB 52.4GB 52.4GB primary ext4 boot, raid
2 52.4GB 300GB 247GB primary ext4 raid
3 300GB 300GB 536MB primary linux-swap(v1)
[root@rescue-customer-eu boot]# parted /dev/sdb print
Model: ATA INTEL SSDSC2BB30 (scsi)
Disk /dev/sdb: 300GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 2097kB 52.4GB 52.4GB primary ext4 boot, raid
2 52.4GB 300GB 247GB primary ext4 raid
3 300GB 300GB 536MB primary linux-swap(v1)
[root@rescue-customer-eu boot]# cat /etc/fstab
#
/dev/md1 / ext4 errors=remount-ro 0 1
/dev/md2 /var ext4 defaults,usrquota,grpquota 1 2
/dev/sda3 swap swap defaults 0 0
/dev/sdb3 swap swap defaults 0 0
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts defaults 0 0
Device Boot Start End Blocks Id System
/dev/sda1 * 4096 102402047 51198976 fd Linux raid autodetect
/dev/sda2 102402048 585017343 241307648 fd Linux raid autodetect
/dev/sda3 585017344 586063871 523264 82 Linux swap / Solaris
Disk /dev/sdb: 300.1 GB, 300069052416 bytes, 586072368 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk label type: dos
Disk identifier: 0xe66525ea
Device Boot Start End Blocks Id System
/dev/sdb1 * 4096 102402047 51198976 fd Linux raid autodetect
/dev/sdb2 102402048 585017343 241307648 fd Linux raid autodetect
/dev/sdb3 585017344 586063871 523264 82 Linux swap / Solaris
Disk /dev/md1: 52.4 GB, 52427685888 bytes, 102397824 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/md2: 247.1 GB, 247098966016 bytes, 482615168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes