Changement de noyau ovh et modification du grub

christov · Février 26, 2018, 1:09pm

Je suis en train de changer de noyau sur mon kimsufi ovh

J’ai installé un nouveau noyau 3.16.0-5-amd64 mais je ne démarre pas dessus (toujours sur l’ancien)

Je crois que je dois modifier /etc/default/grub en remplaçant GRUBDEFAULT=0 par GRUBDEFAULT=1 ou un autre chiffre ?

Le résultat de la commande

fgrep menuentry /boot/grub/grub.cfg

me donne

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
  menuentry_id_option=""
export menuentry_id_option
menuentry "Debian GNU/Linux, OVH kernel 2.6.38.2-xxxx-grs-ipv6-64" {
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-7684ec76-7928-4096-864a-8c586edd381e' {
submenu 'Options avanc�es pour Debian GNU/Linux' $menuentry_id_option 'gnulinux-advanced-7684ec76-7928-4096-864a-8c586edd381e' {
	menuentry 'Debian GNU/Linux, avec Linux 3.16.0-5-amd64' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.16.0-5-amd64-advanced-7684ec76-7928-4096-864a-8c586edd381e' {
	menuentry 'Debian GNU/Linux, with Linux 3.16.0-5-amd64 (recovery mode)' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.16.0-5-amd64-recovery-7684ec76-7928-4096-864a-8c586edd381e' {
	menuentry 'Debian GNU/Linux, avec Linux 3.16.0-4-amd64' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.16.0-4-amd64-advanced-7684ec76-7928-4096-864a-8c586edd381e' {
	menuentry 'Debian GNU/Linux, with Linux 3.16.0-4-amd64 (recovery mode)' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.16.0-4-amd64-recovery-7684ec76-7928-4096-864a-8c586edd381e' {

Comme mon noyau est cité dans un submenu, je ne sais pas quoi choisir GRUBDEFAULT=1 , 2, 3 ou 4 ???

J’ai un peu peur d’être bloqué au reboot

Au secours !

Sputnik93 · Février 26, 2018, 2:24pm

Bonjour,

je n’ai pas trouvé comment indiquer à GRUB quelle entrée de sous-menu est à utiliser par défaut, alors pour ce genre de cas de figure je fais comme ça:

- éditer le fichier /etc/default/grub
ajouter la ligne GRUB_DISABLE_SUBMENU="y"
remplacer la valeur de GRUB_DEFAULT par celle qui t’intéresse (dans ton cas ce sera 0 si tu veux le noyau 3.16.0-5, 1 pour ce même noyau mais en mode recovery, etc.)

-exécuter update-grub

cf ce thread sur le forum

christov · Février 26, 2018, 2:50pm

Merci pour cette réponse

je viens d’ajouter

GRUB_DISABLE_SUBMENU="y"

puis update-grub

puis à nouveau j’obtiens fgrep menuentry /boot/grub/grub.cfg

et là j’obtiens

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
  menuentry_id_option=""
export menuentry_id_option
menuentry "Debian GNU/Linux, OVH kernel 2.6.38.2-xxxx-grs-ipv6-64" {
menuentry 'Debian GNU/Linux, avec Linux 3.16.0-5-amd64' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.16.0-5-amd64-advanced-7684ec76-7928-4096-864a-8c586edd381e' {
menuentry 'Debian GNU/Linux, with Linux 3.16.0-5-amd64 (recovery mode)' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.16.0-5-amd64-recovery-7684ec76-7928-4096-864a-8c586edd381e' {
menuentry 'Debian GNU/Linux, avec Linux 3.16.0-4-amd64' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.16.0-4-amd64-advanced-7684ec76-7928-4096-864a-8c586edd381e' {
menuentry 'Debian GNU/Linux, with Linux 3.16.0-4-amd64 (recovery mode)' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.16.0-4-amd64-recovery-7684ec76-7928-4096-864a-8c586edd381e' {

Je pense donc qu’il faut mettre GRUBDEFAULT=1 non ?

Sputnik93 · Février 26, 2018, 2:53pm

Ah oui en effet, je n’avais pas fait attention à la ligne avec le kernel OVH.

christov · Février 26, 2018, 2:55pm

je vais tester, ça me fait bien avancer, un super merci !!!

christov · Février 26, 2018, 3:05pm

zut j’ai parlé trop vite , après avoir rebooté

uname -r
2.6.38.2-grsec-xxxx-grs-ipv6-64

Je reste sur le vieux noyau

Je ne comprends pas ???

Sputnik93 · Février 26, 2018, 3:24pm

Ah tiens.
Fais voir un
grep menuentry /boot/grub/grub.cfg
et un
grep GRUB_DEFAULT /etc/default/grub

pour voir ?

christov · Février 26, 2018, 3:28pm

Ca donne

grep menuentry /boot/grub/grub.cfg

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
  menuentry_id_option=""
export menuentry_id_option
menuentry "Debian GNU/Linux, OVH kernel 2.6.38.2-xxxx-grs-ipv6-64" {
menuentry 'Debian GNU/Linux, avec Linux 3.16.0-5-amd64' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.16.0-5-amd64-advanced-7684ec76-7928-4096-864a-8c586edd381e' {
menuentry 'Debian GNU/Linux, with Linux 3.16.0-5-amd64 (recovery mode)' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.16.0-5-amd64-recovery-7684ec76-7928-4096-864a-8c586edd381e' {
menuentry 'Debian GNU/Linux, avec Linux 3.16.0-4-amd64' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.16.0-4-amd64-advanced-7684ec76-7928-4096-864a-8c586edd381e' {
menuentry 'Debian GNU/Linux, with Linux 3.16.0-4-amd64 (recovery mode)' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.16.0-4-amd64-recovery-7684ec76-7928-4096-864a-8c586edd381e' {

grep GRUB_DEFAULT /etc/default/grub

GRUB_DEFAULT=1

En fait je crois que le resposable est un script d’OVH :

/etc/grub.d/06_OVHkernel

qui oblige à choisir un "bzIma...."

#!/bin/bash -e

prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
. ${libdir}/grub/grub-mkconfig_lib

OS="Debian GNU/Linux"

LINUX_ROOT_DEVICE=${GRUB_DEVICE}

linux=`ls -1 -t /boot/bzImage*64 2>/dev/null | head -n1`
if [[ -n "${linux}" ]]; then
        echo "Found linux image: $linux" >&2
        basename=`basename "${linux}"`
        dirname=`dirname "${linux}"`
        rel_dirname=`make_system_path_relative_to_its_root $dirname`
        version=`echo $basename | sed -e "s,^[^0-9]*-,,g"`
        alt_version=`echo $version | sed -e "s,\.old$,,g"`
        linux_root_device_thisversion="${LINUX_ROOT_DEVICE}"
        initrd="/initrd-iscsi.img"


        cat << EOF
menuentry "${OS}, OVH kernel ${version}" {
EOF
        prepare_grub_to_access_device ${GRUB_DEVICE_BOOT} | sed -e "s/^/\t/"
        cat << EOF
        linux   ${rel_dirname}/${basename} root=${linux_root_device_thisversion} ro ${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}
EOF
        if test -e "${initrd}" ; then
                cat << EOF
        initrd  ${initrd}
EOF
        fi
        cat << EOF
}
EOF

fi

grandtoubab · Février 26, 2018, 3:51pm

Salut

Pour empêcher ce script, retirer les droits d’exécution

chmod -x /etc/grub.d/06_OVHkernel

et regenerer grub

update-grub

c’est ce que j’ai fait pour ne plus voir les lignes memtest

ls -al /etc/grub.d/
total 96
drwxr-xr-x   2 root root  4096 févr. 23 10:21 .
drwxr-xr-x 152 root root 12288 févr. 26 16:28 ..
-rwxr-xr-x   1 root root  9783 oct.  16  2016 00_header
-rwxr-xr-x   1 root root  6258 janv. 22  2016 05_debian_theme
-rwxr-xr-x   1 root root 12474 oct.  17 22:08 10_linux
-rwxr-xr-x   1 root root 11298 juin  23  2017 20_linux_xen
-rw-r--r--   1 root root  1570 sept. 10  2014 20_memtest86+
-rwxr-xr-x   1 root root 12059 oct.  16  2016 30_os-prober
-rwxr-xr-x   1 root root  1418 févr.  5  2016 30_uefi-firmware
-rwxr-xr-x   1 root root   213 sept. 22 16:25 40_custom
-rwxr-xr-x   1 root root   216 déc.  14  2015 41_custom
-rw-r--r--   1 root root   483 déc.  14  2015 README

christov · Février 26, 2018, 5:04pm

Bon en fait avant ta réponse, j’ai juste déplacé le fichier /etc/grub.d/06_OVHkernel

et aïe le serveur ne démarre plus

je suis maintenant en mode rescue, j’ai replacé le fichier pour revenir à l’état initial mais update-grub me renvoie des erreurs …

PascalHambourg · Février 26, 2018, 5:11pm

Quelle bande de bidouilleurs…

Pour spécifier une entrée de sous-menu par défaut, la syntaxe est “1>0” pour le sous-menu en position 1 (donc en 2e) dans le menu principal et l’entrée en position 0 (donc en 1e) dans le sous-menu.

Le script /etc/grub.d/06_OVHkernel ne fait qu’ajouter la ligne menuentry pour le noyau d’OVH dans grub.cfg lors de l’exécution d’update-grub.
Au lieu de faire des grep qui ne donnent qu’une vision partielle, examine directement le contenu de grub.cfg pour voir s’il y a encore des sous-menus. La valeur pour activer une option dans /etc/default/grub est variable selon l’option, parfois c’est “true”, parfois c’est “y”… Voir la documentation sur gnu.org.

A part ça, tu es sûr que la machine peut démarrer avec le noyau Debian standard ?

Pourquoi ne pas plutôt avoir désinstallé memtest ?

christov · Février 26, 2018, 5:15pm

non je ne suis pas sûr en effet, d’ailleurs je ne démarre plus

alors en mode rescue ovh

j’ai remis le fichier /etc/grub.d/06_OVHkernel à sa place

mais je ne peux plus exécuter update-grub

et le noyau ovh est toujours dans /boot mais n’apparait plus dans /boot/grub/grub.cfg

je ne sais plus trop quoi faire

PascalHambourg · Février 26, 2018, 5:27pm

Mais si tu peux. Un chroot sur ton système, montage de /dev, /proc et /sys et exécution de update-grub.

christov · Février 26, 2018, 5:34pm

J’ai essayé ça tout à l’heure

mount /dev/sda1 /mnt/
chroot /mnt/
update-grub

à quel endroit j’aurais du faire mount /dev, /proc et /sys

comme ça ?

 mount /dev/sda1 /mnt/
 chroot /mnt/
 mount -o bind /dev /dev
 mount -o bind /proc /proc 
 mount -o bind /sys /sys
 update-grub

christov · Février 27, 2018, 2:23pm

Bon j’ai réussi à faire le grub update par contre le noyau ovh a disparu …

root@rescue:/# mkdir /mnt/chroot
root@rescue:/# mount /dev/sda1 /mnt/chroot
root@rescue:/# mount --bind /dev/ /mnt/chroot/dev
root@rescue:/# mount -t proc /proc /mnt/chroot/proc
root@rescue:/# mount -t sysfs /sys /mnt/chroot/sys
root@rescue:/# chroot /mnt/chroot

root@rescue:/# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-3.16.0-5-amd64
Found initrd image: /boot/initrd.img-3.16.0-5-amd64
Found linux image: /boot/vmlinuz-3.16.0-4-amd64
Found initrd image: /boot/initrd.img-3.16.0-4-amd64
  No volume groups found

PascalHambourg · Février 26, 2018, 8:06pm

Ça dépend comment tu le fait. Si tu utilises -o bind, tu dois le faire avant le chroot sinon les répertoires d’origine ne sont plus visibles. Si tu les montes comme de nouvelles instances, tu peux le faire avant ou après le chroot.

Comment ça ? Il a disparu du répertoire /boot ou bien juste dans grub.cfg ?
Si c’est juste dans grub.cfg, quand tu as remis /etc/grub.d/06_OVHkernel à sa place tu as vérifié qu’il avait toujours la permission d’exécution ?

christov · Février 27, 2018, 1:30pm

finalement j’ai téléchargé un nouveau noyau

wget ftp://ftp.ovh.net/made-in-ovh/bzImage/old/3.14.51/bzImage-3.14.51-xxxx-grs-ipv6-64
wget ftp://ftp.ovh.net/made-in-ovh/bzImage/old/3.14.51/System.map-3.14.51-xxxx-grs-ipv6-64
wget ftp://ftp.ovh.net/made-in-ovh/bzImage/old/3.14.51/config-3.14.51-xxxx-grs-ipv6-64

puis update-grub

root@rescue:/# mkdir /mnt/chroot
root@rescue:/# mount /dev/sda1 /mnt/chroot
root@rescue:/# mount --bind /dev/ /mnt/chroot/dev
root@rescue:/# mount -t proc /proc /mnt/chroot/proc
root@rescue:/# mount -t sysfs /sys /mnt/chroot/sys
root@rescue:/# chroot /mnt/chroot

root@rescue:/# update-grub

et c’est reparti ! ouf !!

Sputnik93 · Février 27, 2018, 1:18pm

Ah, merci ! J’avais pourtant farfouillé un peu, sans trouver.
(c’est bien “y”, au passage, pour désactiver les sous-menus)

PascalHambourg · Février 27, 2018, 1:44pm

Note qu’on peut remonter /dev sans --bind comme les deux autres depuis qu’il a un type de système de fichiers spécifique, devtmpfs :

mount -t devtmpfs udev /mnt/chroot/dev