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 ...
NetBoot réseau kernel OVH inaccessible / OVH supprime volontairement et sans prévenir !
Sujets apparentés
- FAQ Je suis déjà client·e Kimsufi et/ou So you Start
2665 
15.03.2022 11:30
- Kimsufi - Reset Root Password
2409 31.05.2022 12:26
- Kimsufi - Mode rescue
2399 31.05.2022 12:22
- Kimsufi - Rescue Mode
2026 29.06.2018 09:58
- Kimsufi - Installer vm windows avec proxmox et acces réseau
1996 31.05.2022 12:38
- Kimsufi - Mon interace Proxmox ne fonctionne pas
1639 31.05.2022 12:07
- FAQ Serveurs dédiés Eco - Les questions que vous vous posez
1369 15.03.2022 11:24
- Kimsufi - Setting up a secondary DNS. I'm stumped!
1305 31.05.2022 13:21
- Kimsufi - Jeu de clé SSH dans le manager
1252 31.05.2022 14:15
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 !
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.
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
[root@rescue-customer-eu boot]# cat /boot/grub2/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub2-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
set pager=1
if [ -s $prefix/grubenv ]; then
load_env
fi
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
else
set default="${saved_entry}"
fi
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi
export menuentry_id_option
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
terminal_output console
if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
set timeout=5
fi
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/00_tuned ###
set tuned_params=""
set tuned_initrd=""
### END /etc/grub.d/00_tuned ###
### BEGIN /etc/grub.d/01_users ###
if [ -f ${prefix}/user.cfg ]; then
source ${prefix}/user.cfg
if [ -n "${GRUB2_PASSWORD}" ]; then
set superusers="root"
export superusers
password_pbkdf2 root ${GRUB2_PASSWORD}
fi
fi
### END /etc/grub.d/01_users ###
### BEGIN /etc/grub.d/06_OVHkernel ###
### END /etc/grub.d/06_OVHkernel ###
### BEGIN /etc/grub.d/10_linux ###
menuentry 'CentOS Linux (3.10.0-1160.76.1.el7.x86_64) 7 (Core)' --class centos --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.10.0-1160.76.1.el7.x86_64-advanced-d89595f1-afdd-43ec-bcf8-8263dea3916d' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod part_msdos
insmod diskfilter
insmod mdraid09
insmod ext2
set root='mduuid/991c4276e219d766a4d2adc226fd5302'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint='mduuid/991c4276e219d766a4d2adc226fd5302' d89595f1-afdd-43ec-bcf8-8263dea3916d
else
search --no-floppy --fs-uuid --set=root d89595f1-afdd-43ec-bcf8-8263dea3916d
fi
linux16 /boot/vmlinuz-3.10.0-1160.76.1.el7.x86_64 root=/dev/md1 ro net.ifnames=0
initrd16 /boot/initramfs-3.10.0-1160.76.1.el7.x86_64.img
}
menuentry 'CentOS Linux (3.10.0-1160.66.1.el7.x86_64) 7 (Core)' --class centos --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.10.0-1160.66.1.el7.x86_64-advanced-d89595f1-afdd-43ec-bcf8-8263dea3916d' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod part_msdos
insmod diskfilter
insmod mdraid09
insmod ext2
set root='mduuid/991c4276e219d766a4d2adc226fd5302'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint='mduuid/991c4276e219d766a4d2adc226fd5302' d89595f1-afdd-43ec-bcf8-8263dea3916d
else
search --no-floppy --fs-uuid --set=root d89595f1-afdd-43ec-bcf8-8263dea3916d
fi
linux16 /boot/vmlinuz-3.10.0-1160.66.1.el7.x86_64 root=/dev/md1 ro net.ifnames=0
initrd16 /boot/initramfs-3.10.0-1160.66.1.el7.x86_64.img
}
menuentry 'CentOS Linux (3.10.0-1160.36.2.el7.x86_64) 7 (Core)' --class centos --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.10.0-1160.36.2.el7.x86_64-advanced-d89595f1-afdd-43ec-bcf8-8263dea3916d' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod part_msdos
insmod diskfilter
insmod mdraid09
insmod ext2
set root='mduuid/991c4276e219d766a4d2adc226fd5302'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint='mduuid/991c4276e219d766a4d2adc226fd5302' d89595f1-afdd-43ec-bcf8-8263dea3916d
else
search --no-floppy --fs-uuid --set=root d89595f1-afdd-43ec-bcf8-8263dea3916d
fi
linux16 /boot/vmlinuz-3.10.0-1160.36.2.el7.x86_64 root=/dev/md1 ro net.ifnames=0
initrd16 /boot/initramfs-3.10.0-1160.36.2.el7.x86_64.img
}
menuentry 'CentOS Linux (3.10.0-1160.24.1.el7.x86_64) 7 (Core)' --class centos --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.10.0-1160.24.1.el7.x86_64-advanced-d89595f1-afdd-43ec-bcf8-8263dea3916d' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod part_msdos
insmod diskfilter
insmod mdraid09
insmod ext2
set root='mduuid/991c4276e219d766a4d2adc226fd5302'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint='mduuid/991c4276e219d766a4d2adc226fd5302' d89595f1-afdd-43ec-bcf8-8263dea3916d
else
search --no-floppy --fs-uuid --set=root d89595f1-afdd-43ec-bcf8-8263dea3916d
fi
linux16 /boot/vmlinuz-3.10.0-1160.24.1.el7.x86_64 root=/dev/md1 ro net.ifnames=0
initrd16 /boot/initramfs-3.10.0-1160.24.1.el7.x86_64.img
}
menuentry 'CentOS Linux (3.10.0-1160.15.2.el7.x86_64) 7 (Core)' --class centos --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.10.0-1160.15.2.el7.x86_64-advanced-d89595f1-afdd-43ec-bcf8-8263dea3916d' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod part_msdos
insmod diskfilter
insmod mdraid09
insmod ext2
set root='mduuid/991c4276e219d766a4d2adc226fd5302'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint='mduuid/991c4276e219d766a4d2adc226fd5302' d89595f1-afdd-43ec-bcf8-8263dea3916d
else
search --no-floppy --fs-uuid --set=root d89595f1-afdd-43ec-bcf8-8263dea3916d
fi
linux16 /boot/vmlinuz-3.10.0-1160.15.2.el7.x86_64 root=/dev/md1 ro net.ifnames=0
initrd16 /boot/initramfs-3.10.0-1160.15.2.el7.x86_64.img
}
### END /etc/grub.d/10_linux ###
### BEGIN /etc/grub.d/20_linux_xen ###
### END /etc/grub.d/20_linux_xen ###
### BEGIN /etc/grub.d/20_ppc_terminfo ###
### END /etc/grub.d/20_ppc_terminfo ###
### BEGIN /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_os-prober ###
### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
### END /etc/grub.d/40_custom ###
### BEGIN /etc/grub.d/41_custom ###
if [ -f ${config_directory}/custom.cfg ]; then
source ${config_directory}/custom.cfg
elif [ -z "${config_directory}" -a -f $prefix/custom.cfg ]; then
source $prefix/custom.cfg;
fi
### END /etc/grub.d/41_custom ###
[root@rescue-customer-eu boot]# ls -l
total 133760
-rw-r--r-- 1 root root 153596 Feb 3 2021 config-3.10.0-1160.15.2.el7.x86_64
-rw-r--r-- 1 root root 153596 Apr 8 2021 config-3.10.0-1160.24.1.el7.x86_64
-rw-r--r-- 1 root root 153596 Jul 21 2021 config-3.10.0-1160.36.2.el7.x86_64
-rw-r--r-- 1 root root 153619 May 18 18:06 config-3.10.0-1160.66.1.el7.x86_64
-rw-r--r-- 1 root root 153619 Aug 10 18:25 config-3.10.0-1160.76.1.el7.x86_64
drwxr-xr-x 3 root root 4096 Jun 10 2015 efi
drwxr-xr-x 2 root root 4096 Dec 14 2015 grub
drwx------ 5 root root 4096 Aug 21 20:26 grub2
-rw------- 1 root root 13605188 Jul 25 2021 initramfs-3.10.0-1160.15.2.el7.x86_64.img
-rw------- 1 root root 13615314 Aug 16 03:33 initramfs-3.10.0-1160.24.1.el7.x86_64.img
-rw------- 1 root root 13614325 Apr 8 03:42 initramfs-3.10.0-1160.36.2.el7.x86_64.img
-rw------- 1 root root 13615818 Aug 16 03:33 initramfs-3.10.0-1160.66.1.el7.x86_64.img
-rw------- 1 root root 13603993 Aug 21 21:26 initramfs-3.10.0-1160.76.1.el7.x86_64.img
-rw------- 1 root root 11517013 Aug 3 2018 initramfs-3.14.32-xxxx-std-ipv6-64.img
-rw-r--r-- 1 root root 320678 Feb 3 2021 symvers-3.10.0-1160.15.2.el7.x86_64.gz
-rw-r--r-- 1 root root 320684 Apr 8 2021 symvers-3.10.0-1160.24.1.el7.x86_64.gz
-rw-r--r-- 1 root root 320757 Jul 21 2021 symvers-3.10.0-1160.36.2.el7.x86_64.gz
-rw-r--r-- 1 root root 320651 May 18 18:06 symvers-3.10.0-1160.66.1.el7.x86_64.gz
-rw-r--r-- 1 root root 320674 Aug 10 18:25 symvers-3.10.0-1160.76.1.el7.x86_64.gz
-rw------- 1 root root 3617071 Feb 3 2021 System.map-3.10.0-1160.15.2.el7.x86_64
-rw------- 1 root root 3618342 Apr 8 2021 System.map-3.10.0-1160.24.1.el7.x86_64
-rw------- 1 root root 3620596 Jul 21 2021 System.map-3.10.0-1160.36.2.el7.x86_64
-rw------- 1 root root 3621999 May 18 18:06 System.map-3.10.0-1160.66.1.el7.x86_64
-rw------- 1 root root 3622646 Aug 10 18:25 System.map-3.10.0-1160.76.1.el7.x86_64
-rw-r--r-- 1 root root 2973727 Nov 29 2016 System.map-3.14.32-xxxx-std-ipv6-64
-rwxr-xr-x 1 root root 6769256 Feb 3 2021 vmlinuz-3.10.0-1160.15.2.el7.x86_64
-rwxr-xr-x 1 root root 6773352 Apr 8 2021 vmlinuz-3.10.0-1160.24.1.el7.x86_64
-rwxr-xr-x 1 root root 6777448 Jul 21 2021 vmlinuz-3.10.0-1160.36.2.el7.x86_64
-rwxr-xr-x 1 root root 6777448 May 18 18:06 vmlinuz-3.10.0-1160.66.1.el7.x86_64
-rwxr-xr-x 1 root root 6781544 Aug 10 18:25 vmlinuz-3.10.0-1160.76.1.el7.x86_64
J'ai fait :
[root@rescue-customer-eu boot]# grub2-install /dev/sdb
Installing for i386-pc platform.
Installation finished. No error reported.
[root@rescue-customer-eu boot]# grub2-install /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.
Enfin :
[root@rescue-customer-eu boot]# grub2-mkconfig -o /boot/grub2/grub.cfg
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
done
Bonjour,
c'est un serveur qui dispose d'un IPMI/KVM ?
Cordialement, janus57
Bonjour,
Bien sur, à la demande ... le KVM IP est facturé 25,00€ HT la journée par OVH ...
Bonjour,
Ah il fait encore partie de cette série de serveur...
Perso je ferais une VM en mode rescue qui va utiliser les 2 disques du serveur pour avoir une visualisation de la séquence de boot.
Exemple pour installer une ISO sans accès KVM/IPMI : https://www.emaxilde.net/posts/2021/07/25/installer-un-serveur-dedie-sans-acces-kvm-ou-ipmi.html
P.S. méthode déjà utilisée pour réparer un upgrade de PVE6 à PVE7 (Raid1 via ZFS) et une seconde fois après un changement de carte mère qui avez laissé le boot en erreur.
Cordialement, janus57
Merci beaucoup pour cette solution mais je ne digère les pratiques scandaleuses de OVH.
Bonjour,
Perso je ne fait pas confiance à ce genre de solution, donc mes serveurs ont toujours boot sur leur disques comme ça ne je suis pas dépendant de OVH pour savoir si les serveurs vont reboot.
Cordialement, janus57
Vous résumez parfaitement ...
Ne jamais faire confiance à OVH ...
Travailler avec un fournisseur avec lequel "on ne sait jamais si son serveur va redémarrer" car ils ont pris l'initiative, "sans prévenir" et "sans accompagner" de supprimer une fonctionnalité mise en avant par eux même dans un temps précédent ... c'est tout simplement scandaleux.
On se rappelle tous de l'incendie du DC de OVH
_OVH menacé d'une action collective suite à l'incendie de son data center_
https://www.journaldunet.com/web-tech/cloud/1499203-six-choses-qu-ovh-ne-dit-pas-sur-l-incendie-de-ses-datacenters-a-strasbourg/
Made in OVH ... pitoyable.
@OVH :
**Ayez le cran de publier publiquement le nombre de vos serveurs qui tournent encore sur le kernel OVH ...**
Qui, n'oublions pas l'argument pitoyable du support OVH, je cite :
_"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."_
Bonjour,
avez-vous un backup de ces répertoires et fichiers avant le plantage ?
/boot/
/etc/grub.d/
/etc/default/grub
/etc/default/grub.d
bonjour @Fritz2cat
Malheureusement non car ca remonte à + 1 an ...
C'est suite à un yum update ...
Pourtant, les images des kernel dispo dans /boot sont vieux ... 2021 ...
Je ne comprends pas :(
PS : j'insiste à trouver une solution car je sais très bien que d'autres seront confrontés à cette situation donc j'espère trouver une solution afin d'aider à mon tour ...
root@rescue:/etc/grub.d# ls -l
total 72
-rwxr-xr-x 1 root root 9424 Mar 23 2015 00_header
-rwxr-xr-x 1 root root 6058 Mar 23 2015 05_debian_theme
-rwxr-xr-x 1 root root 12261 Mar 23 2015 10_linux
-rwxr-xr-x 1 root root 11082 Mar 23 2015 20_linux_xen
-rwxr-xr-x 1 root root 11692 Mar 23 2015 30_os-prober
-rwxr-xr-x 1 root root 1416 Mar 23 2015 30_uefi-firmware
-rwxr-xr-x 1 root root 214 Mar 23 2015 40_custom
-rwxr-xr-x 1 root root 216 Mar 23 2015 41_custom
-rw-r--r-- 1 root root 483 Mar 23 2015 README
/etc/grub.d/ => vide
/etc/default/grub
[root@rescue default]# ls -l
total 12
-rw-r--r-- 1 root root 385 Feb 4 2021 grub
-rw-r--r-- 1 root root 1756 May 18 17:54 nss
-rw-r--r-- 1 root root 119 Aug 6 2019 useradd
[root@rescue default]# cat grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
# under any circumstances, keep net.ifnames=0!
# http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
GRUB_CMDLINE_LINUX="net.ifnames=0"
GRUB_DISABLE_RECOVERY="true"
GRUB_DISABLE_LINUX_UUID="true"
Vous êtes bien dans votre chroot, j'espère ?
Le grub du rescue ne nous intéresse pas.
Je n'ai pas de centos7 sous le coude, juste du debian en versions 10 et 11.
Dans un Debian 10: /etc/default/grub (uniquement les lignes qui ne sont pas en commentaires)
GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="noquiet nosplash"
GRUB_CMDLINE_LINUX="rootdelay=10 rootdelay=10"
GRUB_DISABLE_LINUX_UUID="true"
Donc pour plus de sécurité, montez-vous une machine virtuelle CentOS7 chez vous et récupérez ces fichiers vitaux, adaptez les UUID si nécessaire, après je vous renvoie à "internet" sinon je vais dire des bêtises...
Je suis bien en chroot pourtant :
GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX=""
Ce n'est pas possible ... je suis sur Centos 7 ...
J'ai l'impression qu'il me balance les infos du rescue ...
Oui, en chroot effectivement
Bonjour,
si cela peut aider, voici ce que donne un CentOS7 sorti d'installation OVH (j'ai un serveur SYS qui sert à rien, je viens de le réinstaller) :
[code]
[root@nsXXXXXX ~]# ls -alh /boot/
total 144M
dr-xr-xr-x. 5 root root 4.0K Aug 24 18:34 .
dr-xr-xr-x. 17 root root 262 Aug 24 18:34 ..
-rw-r--r--. 1 root root 150K Mar 31 2020 config-3.10.0-1127.el7.x86_64
-rw-r--r--. 1 root root 151K Aug 10 16:25 config-3.10.0-1160.76.1.el7.x86_64
drwxr-xr-x. 3 root root 17 Apr 22 2020 efi
drwxr-xr-x. 2 root root 39 Aug 22 02:07 grub
drwx------. 5 root root 119 Aug 24 18:31 grub2
-rw-------. 1 root root 45M Apr 22 2020 initramfs-0-rescue-cab9605edaa5484da7c2f02b8fd10762.img
-rw------- 1 root root 24M Aug 24 18:31 initramfs-3.10.0-1127.el7.x86_64.img
-rw-------. 1 root root 11M Aug 22 02:07 initramfs-3.10.0-1127.el7.x86_64kdump.img
-rw------- 1 root root 24M Aug 24 18:31 initramfs-3.10.0-1160.76.1.el7.x86_64.img
-rw------- 1 root root 15M Aug 24 18:34 initramfs-3.10.0-1160.76.1.el7.x86_64kdump.img
-rw-r--r--. 1 root root 313K Mar 31 2020 symvers-3.10.0-1127.el7.x86_64.gz
-rw-r--r--. 1 root root 314K Aug 10 16:25 symvers-3.10.0-1160.76.1.el7.x86_64.gz
-rw-------. 1 root root 3.5M Mar 31 2020 System.map-3.10.0-1127.el7.x86_64
-rw-------. 1 root root 3.5M Aug 10 16:25 System.map-3.10.0-1160.76.1.el7.x86_64
-rwxr-xr-x. 1 root root 6.5M Apr 22 2020 vmlinuz-0-rescue-cab9605edaa5484da7c2f02b8fd10762
-rwxr-xr-x. 1 root root 6.5M Mar 31 2020 vmlinuz-3.10.0-1127.el7.x86_64
-rw-r--r--. 1 root root 167 Mar 31 2020 .vmlinuz-3.10.0-1127.el7.x86_64.hmac
-rwxr-xr-x. 1 root root 6.5M Aug 10 16:25 vmlinuz-3.10.0-1160.76.1.el7.x86_64
-rw-r--r--. 1 root root 172 Aug 10 16:25 .vmlinuz-3.10.0-1160.76.1.el7.x86_64.hmac
[root@nsXXXXXX ~]# ls -alh /etc/grub.d/
total 84K
drwx------. 2 root root 182 Aug 22 02:06 .
drwxr-xr-x. 81 root root 8.0K Aug 24 18:33 ..
-rwxr-xr-x. 1 root root 8.5K May 20 12:58 00_header
-rwxr-xr-x. 1 root root 1.1K Mar 21 2019 00_tuned
-rwxr-xr-x. 1 root root 232 May 20 12:58 01_users
-rwxr-xr-x. 1 root root 11K May 20 12:58 10_linux
-rwxr-xr-x. 1 root root 11K May 20 12:58 20_linux_xen
-rwxr-xr-x. 1 root root 2.5K May 20 12:58 20_ppc_terminfo
-rwxr-xr-x. 1 root root 11K May 20 12:58 30_os-prober
-rwxr-xr-x. 1 root root 214 May 20 12:58 40_custom
-rwxr-xr-x. 1 root root 216 May 20 12:58 41_custom
-rw-r--r--. 1 root root 483 May 20 12:58 README
[root@nsXXXXXX ~]# cat /etc/default/grub
GRUB_TIMEOUT=1
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL="serial console"
GRUB_SERIAL_COMMAND="serial"
GRUB_DISABLE_RECOVERY="true"
GRUB_DISABLE_LINUX_UUID="false"
GRUB_TERMINAL_OUTPUT=""
GRUB_ENABLE_BLSCFG=false
GRUB_CMDLINE_LINUX="rd.auto crashkernel=auto vga=normal nomodeset rdloaddriver=raid1"
GRUB_PRELOAD_MODULES="diskfilter mdraid1x"
[root@nsXXXXXX ~]# uname -a
Linux nsXXXXXX .ip-xx-xx-xx.eu 3.10.0-1160.76.1.el7.x86_64 #1 SMP Wed Aug 10 16:21:17 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
[/code]
Cordialement, janus57
[root@rescue /]# ls -alh /boot/
total 131M
dr-xr-xr-x 5 root root 4.0K Aug 21 21:26 .
dr-xr-xr-x 18 root root 4.0K Aug 24 02:15 ..
-rw-r--r-- 1 root root 150K Feb 3 2021 config-3.10.0-1160.15.2.el7.x86_64
-rw-r--r-- 1 root root 150K Apr 8 2021 config-3.10.0-1160.24.1.el7.x86_64
-rw-r--r-- 1 root root 150K Jul 21 2021 config-3.10.0-1160.36.2.el7.x86_64
-rw-r--r-- 1 root root 151K May 18 18:06 config-3.10.0-1160.66.1.el7.x86_64
-rw-r--r-- 1 root root 151K Aug 10 18:25 config-3.10.0-1160.76.1.el7.x86_64
drwxr-xr-x 3 root root 4.0K Jun 10 2015 efi
drwxr-xr-x 2 root root 4.0K Dec 14 2015 grub
drwx------ 5 root root 4.0K Aug 24 20:01 grub2
-rw------- 1 root root 13M Jul 25 2021 initramfs-3.10.0-1160.15.2.el7.x86_64.img
-rw------- 1 root root 13M Aug 16 03:33 initramfs-3.10.0-1160.24.1.el7.x86_64.img
-rw------- 1 root root 13M Apr 8 03:42 initramfs-3.10.0-1160.36.2.el7.x86_64.img
-rw------- 1 root root 13M Aug 16 03:33 initramfs-3.10.0-1160.66.1.el7.x86_64.img
-rw------- 1 root root 13M Aug 21 21:26 initramfs-3.10.0-1160.76.1.el7.x86_64.img
-rw------- 1 root root 11M Aug 3 2018 initramfs-3.14.32-xxxx-std-ipv6-64.img
-rw-r--r-- 1 root root 314K Feb 3 2021 symvers-3.10.0-1160.15.2.el7.x86_64.gz
-rw-r--r-- 1 root root 314K Apr 8 2021 symvers-3.10.0-1160.24.1.el7.x86_64.gz
-rw-r--r-- 1 root root 314K Jul 21 2021 symvers-3.10.0-1160.36.2.el7.x86_64.gz
-rw-r--r-- 1 root root 314K May 18 18:06 symvers-3.10.0-1160.66.1.el7.x86_64.gz
-rw-r--r-- 1 root root 314K Aug 10 18:25 symvers-3.10.0-1160.76.1.el7.x86_64.gz
-rw------- 1 root root 3.5M Feb 3 2021 System.map-3.10.0-1160.15.2.el7.x86_64
-rw------- 1 root root 3.5M Apr 8 2021 System.map-3.10.0-1160.24.1.el7.x86_64
-rw------- 1 root root 3.5M Jul 21 2021 System.map-3.10.0-1160.36.2.el7.x86_64
-rw------- 1 root root 3.5M May 18 18:06 System.map-3.10.0-1160.66.1.el7.x86_64
-rw------- 1 root root 3.5M Aug 10 18:25 System.map-3.10.0-1160.76.1.el7.x86_64
-rw-r--r-- 1 root root 2.9M Nov 29 2016 System.map-3.14.32-xxxx-std-ipv6-64
-rwxr-xr-x 1 root root 6.5M Feb 3 2021 vmlinuz-3.10.0-1160.15.2.el7.x86_64
-rw-r--r-- 1 root root 172 Feb 3 2021 .vmlinuz-3.10.0-1160.15.2.el7.x86_64.hmac
-rwxr-xr-x 1 root root 6.5M Apr 8 2021 vmlinuz-3.10.0-1160.24.1.el7.x86_64
-rw-r--r-- 1 root root 172 Apr 8 2021 .vmlinuz-3.10.0-1160.24.1.el7.x86_64.hmac
-rwxr-xr-x 1 root root 6.5M Jul 21 2021 vmlinuz-3.10.0-1160.36.2.el7.x86_64
-rw-r--r-- 1 root root 172 Jul 21 2021 .vmlinuz-3.10.0-1160.36.2.el7.x86_64.hmac
-rwxr-xr-x 1 root root 6.5M May 18 18:06 vmlinuz-3.10.0-1160.66.1.el7.x86_64
-rw-r--r-- 1 root root 172 May 18 18:06 .vmlinuz-3.10.0-1160.66.1.el7.x86_64.hmac
-rwxr-xr-x 1 root root 6.5M Aug 10 18:25 vmlinuz-3.10.0-1160.76.1.el7.x86_64
-rw-r--r-- 1 root root 172 Aug 10 18:25 .vmlinuz-3.10.0-1160.76.1.el7.x86_64.hmac
[root@rescue /]# ls -alh /etc/grub.d/
total 92K
drwx------ 2 root root 4.0K May 21 03:44 .
drwxr-xr-x 109 root root 12K Aug 20 21:12 ..
-rwxr-xr-x 1 root root 8.5K May 20 14:58 00_header
-rwxr-xr-x 1 root root 1.1K Mar 21 2019 00_tuned
-rwxr-xr-x 1 root root 232 May 20 14:58 01_users
-rwxr--r-- 1 root root 2.3K Nov 29 2016 06_OVHkernel
-rwxr-xr-x 1 root root 11K May 20 14:58 10_linux
-rwxr-xr-x 1 root root 11K May 20 14:58 20_linux_xen
-rwxr-xr-x 1 root root 2.5K May 20 14:58 20_ppc_terminfo
-rwxr-xr-x 1 root root 11K May 20 14:58 30_os-prober
-rwxr-xr-x 1 root root 214 May 20 14:58 40_custom
-rwxr-xr-x 1 root root 216 May 20 14:58 41_custom
-rw-r--r-- 1 root root 483 May 20 14:58 README
[root@rescue /]# ls -alh /etc/grub.d/
total 92K
drwx------ 2 root root 4.0K May 21 03:44 .
drwxr-xr-x 109 root root 12K Aug 20 21:12 ..
-rwxr-xr-x 1 root root 8.5K May 20 14:58 00_header
-rwxr-xr-x 1 root root 1.1K Mar 21 2019 00_tuned
-rwxr-xr-x 1 root root 232 May 20 14:58 01_users
-rwxr--r-- 1 root root 2.3K Nov 29 2016 06_OVHkernel
-rwxr-xr-x 1 root root 11K May 20 14:58 10_linux
-rwxr-xr-x 1 root root 11K May 20 14:58 20_linux_xen
-rwxr-xr-x 1 root root 2.5K May 20 14:58 20_ppc_terminfo
-rwxr-xr-x 1 root root 11K May 20 14:58 30_os-prober
-rwxr-xr-x 1 root root 214 May 20 14:58 40_custom
-rwxr-xr-x 1 root root 216 May 20 14:58 41_custom
-rw-r--r-- 1 root root 483 May 20 14:58 README
[root@rescue /]# cat /etc/default/grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
# under any circumstances, keep net.ifnames=0!
# http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
GRUB_CMDLINE_LINUX="net.ifnames=0"
GRUB_DISABLE_RECOVERY="true"
GRUB_DISABLE_LINUX_UUID="true"
J'ai C/C :
[root@nsXXXXXX ~]# cat /etc/default/grub
GRUB_TIMEOUT=1
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL="serial console"
GRUB_SERIAL_COMMAND="serial"
GRUB_DISABLE_RECOVERY="true"
GRUB_DISABLE_LINUX_UUID="false"
GRUB_TERMINAL_OUTPUT=""
GRUB_ENABLE_BLSCFG=false
GRUB_CMDLINE_LINUX="rd.auto crashkernel=auto vga=normal nomodeset rdloaddriver=raid1"
GRUB_PRELOAD_MODULES="diskfilter mdraid1x"
Cela ne change rien
J'ai reussi à la relancer !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
J'ai laissé 1 kernel dans /boot ... j'ai fait le ménage ...
Puis j'ai lancé :
`dracut --mdadmconf --fstab --add="mdraid" --add-drivers="raid1" -f /boot/initramfs-XXXXXX.img XXXXXX`
Un grand merci aux personnes de community qui m'ont gentiment aidé ! contrairement à un support OVH qui ne vaut absolument RIEN !
Je vous invite grandement à quitter OVH.
Via cette expérience ... j'espère que cela fera prendre conscience à nombreux d'entre vous de quitter OVH.
Je reste stupéfait par le comportement du "support" OVH.
**_"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."_**
L'esquive magistrale ... alors que c'est totalement FAUX !
Prochainement, je vais migrer cette machine ailleurs.
Je pense qu'il faut privilégier les hosteur de plus petite taille sur lesquels, nous pouvons compter car il y a cette **capacité à prendre en compte le coté humain, l'accompagnement ... l'aide et la satisfaction d'un client final.**
Tout l'opposé de OVH aujourd'hui.
Félicitations !
Je suis +très+ content pour vous.
@FabL
cc: pour @janus57 @TTY @ChristopheGX ayant pris part à la conversation
Je regrette que OVH ne soit pas intervenu dans cette conversation.
Pour démontrer le piètre contrôle qualité qui me surprendra toujours, il y a toujours ce mail qui est envoyé lors d'un reboot en rescue:
> Si vous pensez avoir identifié l'origine du problème et souhaitez
> redémarrer votre serveur normalement, vous devez configurer le
> 'netboot' de votre serveur sur le disque dur ou sur un noyau OVH:
> http://guides.ovh.com/KernelNetboot/ puis rebooter votre serveur
> en SOFT (évitez de rebooter via le manager).
> Vous trouverez des informations complémentaires dans notre guide:
> http://guides.ovh.com/ModeRescue/
Ces 2 liens sont cassés et interceptés sur la home page https://docs.ovh.com/fr/ qui évidemment ne dit plus rien sur le Netboot.
Renseignement pour OVH:
X-Ovh-Template: mozg/fr/pass_rescue-pro.model
Bonjour,
perso j'irais plus loin :
08/06/2022 - 19/06/2022 : annonce de l'upgrade du système de netboot : https://bare-metal-servers.1ovhcloud.com/incidents/086ryx1snt4povhcloud.com/incidents/086ryx1snt4p
[quote]
Start time : 08/06/2022 08:53 UTC
End time : 20/07/2022 08:53 UTC
Service impact : None
Service improvement : As part of our continuous improvement of our infrastructure, we will be doing an upgrade maintenance on server Netboot.
Posted 2 months ago. Jul 19, 2022 - 23:05 UTC
[/quote]
16/06/2022-21/06/2022 - annonce de l'enlèvement du netboot sur noyau OVH : https://bare-metal-servers.1ovhcloud.com/incidents/gz80gt4637n1ovhcloud.com/incidents/gz80gt4637n1
[quote]
Scheduled
Start time : 21/06/2022 11:00 UTC
End time : 21/06/2022 11:15 UTC
Service impact : None
Service improvement : We are removing the possibility of booting with OVH kernel as this solution is not maintained anymore.
Posted 3 months ago. Jun 16, 2022 - 00:39 UTC
[/quote]
Cordialement, janus57
J'ai un serveur kimsufi qui n'a pas été rebooté depuis près d'un an. Je n'en étais pas conscient, mais il tourne sur un kernel OVH. Netboot ou pas ? Probablement...
root@k3:~# uname -a
Linux k3 4.19.62-mod-std-ipv6-64-rescue #828825 SMP Tue Jul 30 13:54:49 UTC 2019 x86_64 GNU/Linux
root@k3:~# uptime
08:27:48 up 311 days, 13:09, 1 user, load average: 0.04, 0.06, 0.01
root@k3:~# cat /etc/debian_version
10.11
root@k3:/boot# ls -l
total 28425
-rw-r--r-- 1 root root 115365 Nov 16 2021 config-4.19-ovh-xxxx-std-ipv6-64
drwxr-xr-x 5 root root 1024 Sep 12 06:07 grub
-rw-r--r-- 1 root root 9555763 Nov 17 2021 initrd.img-4.19-ovh-xxxx-std-ipv6-64
-rw-r--r-- 1 root root 4949747 Nov 16 2021 System.map-4.19-ovh-xxxx-std-ipv6-64
-rw-r--r-- 1 root root 14483616 Nov 16 2021 vmlinuz-4.19-ovh-xxxx-std-ipv6-64
root@k3:/boot# df /boot
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 498532 41614 426659 9% /boot
Ce serveur est un debian 9 que j'ai upgradé en debian 10 il y a un certain temps, mais je trouve les kernels custom OVH dans mon /boot.
Ca semble bien être une partition sur mon /dev/sda et non un boot PXE ou similaire...
J'avoue ne pas être trop rassuré en cas de reboot.
J'ai le même cas sur un dédié OVH
Ce que j'ai surtout du mal à avaler, c'est que j'ai l'impression que cela c'est fait en douce... Le minimum aurai été de prévenir les clients bare metal
Bonjour,
après perso je m'en fou dans le sens ou je l'ai jamais utilisé pour raisons :
1 - c'est une "boite noir" qui boot votre serveur (à ma connaissance OVH ne diffusez pas le code du noyau et/ou les modifs faite dessus) => non acceptable
2 - le serveur dépendrai alors de l'état de santé de l'infra de netboot OVH => non acceptable
Cordialement, janus57
Hello à tous,
Le site status a été privilégié comme canal de communication pour informer les clients.
J'ai toutefois bien noté votre souhait d'obtenir ce type d'informations par e-mail également. Je transmets cela aux équipes concernées.
@Fritz2cat, j'ai bien transmis les informations au service concerné pour prise en compte et pour qu'une mise à jour de l'e-mail soit effectuée.
^FabL
Bonsoir Monsieur,
je me trouve confronté au même problème. Faut-il taper cette commande en mode rescue ? Si oui j'imagine qu'il faut /boot... à par example /mnt/boot.... ?
Merci par avance pour votre aide.