NetBoot réseau kernel OVH inaccessible / OVH supprime volontairement et sans prévenir !

FAPM 2022-08-21 13:37:39 UTC #1

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 ...

Le NetBoot ne marche plus sur les serveurs en RAID ?

FAPM 2022-08-22 10:17:18 UTC #2

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 !

ChristopheGX 2022-08-22 11:08:49 UTC #3

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.

FAPM 2022-08-22 11:20:35 UTC #4

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

ChristopheGX 2022-08-22 11:32:39 UTC #5

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

FAPM 2022-08-22 11:36:23 UTC #6

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

FAPM 2022-08-22 11:39:37 UTC #7

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/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

FAPM 2022-08-22 11:42:55 UTC #8

sur le rescue, /boot est vide ...

ChristopheGX 2022-08-22 11:59:45 UTC #9

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

FAPM 2022-08-22 12:01:00 UTC #10

rdinit=/sbin/init console=tty0 ramdisk_size=51200 load_ramdisk=1 panic=10 net.ifnames=0 rootfstype=ramfs DATASOURCE=https://1660123210-public-ovh-baremetal.snap.mirrors.ovh.net/rescue/fr/rescue-customer METADATA=https://baremetal.eu.ovhapis.com/1.0/metadata-api

ChristopheGX 2022-08-23 07:53:02 UTC #11

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.

TTY 2022-08-23 08:51:02 UTC #12

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.

FAPM 2022-08-23 12:13:17 UTC #13

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 !

Fritz2cat 2022-08-23 13:02:36 UTC #14

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.

ChristopheGX 2022-08-23 13:06:07 UTC #15

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.

Fritz2cat 2022-08-23 13:21:43 UTC #16

oui bof

😢

et pourtant on trouve des documents ça et là

FAPM 2022-08-23 23:02:25 UTC #17

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 !!!!!!!!

FAPM 2022-08-24 00:27:38 UTC #18

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)

FAPM 2022-08-24 00:28:55 UTC #19

[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

FAPM 2022-08-24 00:29:30 UTC #20

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

Propulsé par Discourse, le rendu est meilleur avec le JavaScript activé

OVHcloud Community

Bienvenue sur votre espace communautaire. Posez des questions, recherchez des informations, publiez du contenu et interagissez avec d’autres membres d'OVHcloud Community.