Apt-get upgrade plante à cause d'une mise à jour grub

Support Debian
#1

Bonjour à tous!

Je tente désespérément de mettre à jour ma debian sur un serveur OVH, mais une ise à jour de grub me pose des problèmes.
J’ai une debian wheezy installée sur ce serveur.

Voici ce que j’obtiens avec un apt-get upgrade:

root@***:~# apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 1 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Do you want to continue [Y/n]? Setting up grub-pc (2.02~beta2-22) ... Installing for i386-pc platform. Installation finished. No error reported. Installing for i386-pc platform. grub-install: warning: File system `ext2' doesn't support embedding. grub-install: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.. Installation finished. No error reported. Generating grub configuration file ... Found linux image: /boot/bzImage-3.2.13-xxxx-grs-ipv6-64 /etc/grub.d/06_OVHkernel: line 17: make_system_path_relative_to_its_root: command not found dpkg: error processing grub-pc (--configure): subprocess installed post-installation script returned error exit status 127 Errors were encountered while processing: grub-pc E: Sub-process /usr/bin/dpkg returned an error code (1) root@***:~#

Voici le contenu de mon fichier sources.list

[code]root@***:~# cat /etc/apt/sources.list
deb http://debian.mirrors.ovh.net/debian/ wheezy main
deb-src http://debian.mirrors.ovh.net/debian/ wheezy main

deb http://security.debian.org/ wheezy/updates main
deb-src http://security.debian.org/ wheezy/updates main[/code]

Je ne sais pas vraiment quelle est la prochaine étape pour débloquer la situation :frowning:
Avez-vous des idées?

#2

Grub de debian est-il essentiel ? Le gestionnaire de démarrage ne serait-il pas externe à debian ?

[code]
File: grub.info, Node: File name syntax, Next: Block list syntax, Prev: Device syntax, Up: Filesystem

11.2 How to specify files

There are two ways to specify files, by “absolute file name” and by
"block list".

An absolute file name resembles a Unix absolute file name, using ‘/‘
for the directory separator (not ‘’ as in DOS). One example is
’(hd0,1)/boot/grub/grub.cfg’. This means the file '/boot/grub/grub.cfg’
in the first partition of the first hard disk. If you omit the device
name in an absolute file name, GRUB uses GRUB’s "root device"
implicitly. So if you set the root device to, say, ‘(hd1,1)’ by the
command ‘set root=(hd1,1)’ (*note set::), then ‘/boot/kernel’ is the
same as ‘(hd1,1)/boot/kernel’.[/code]

Les fichiers sont référencés par noms absolus (“absolute file name”) ou par liste de blocs (“block list”).

[code]11.3 How to specify block lists

A block list is used for specifying a file that doesn’t appear in the
filesystem, like a chainloader. The syntax is
’[OFFSET]+LENGTH[,[OFFSET]+LENGTH]…’. Here is an example:

 0+100,200+1,300+300

This represents that GRUB should read blocks 0 through 99, block 200,
and blocks 300 through 599. If you omit an offset, then GRUB assumes
the offset is zero.

Like the file name syntax (*note File name syntax::), if a blocklist
does not contain a device name, then GRUB uses GRUB’s “root device”. So
’(hd0,2)+1’ is the same as ‘+1’ when the root device is ‘(hd0,2)’.[/code]
Block list peut être utilisé lorsque le fichier appelé ne fait pas partie du système de fichiers.

Présentement, le démarrage du système doit reposer sur des fichiers qui ne font pas partie du système de fichiers de debian.
Il faut donc regarder si le démarrage ne dépendrait pas de fichiers hors de la cage debian et se tourner vers OVH. Voir comment OVH gère le démarrage 06_OVHkernel.
Voir le rôle de
/boot/bzImage-3.2.13-xxxx-grs-ipv6-64
Voir les options au lancement

[quote]
/etc/grub.d/06_OVHkernel: line 17: make_system_path_relative_to_its_root: command not found[/quote]
OVHkernel, noyau de chez OVH. Commencer par voir le contenu de /etc/grub.d/06_OVHkernel

#3

La version de GRUB dans Wheezy est 1.99 alors que visiblement la version qui tente de s’installer est 2.02, correspondant à Jessie. Tu fais une mise à jour de Wheezy ou une mise à niveau vers Jessie ?

Il y a deux opérations très différentes à distinguer dans les messages de post-installation de grub-pc.

  1. L’exécution de [mono]grub-install[/mono] qui a pour but d’installer le chargeur d’amorçage et qui ne provoque ici qu’un warning sans gravité concernant les listes de blocs. Cela se produit notamment lorsqu’on installe l’amorce du chargeur (boot image) dans le secteur d’amorce d’une partition au lieu du secteur d’amorce (MBR) d’un disque. Ce qui est un peu plus surprenant, c’est que juste avant il est rapporté l’installation du chargeur sans erreur ni warning. Il se peut que le paquet grub-pc soit configuré pour installer l’amorce à la fois dans le MBR et dans une partition (superflu). Cela devrait être vérifiable avec [mono]debconf-show grub-pc[/mono].

  2. L’exécution de [mono]update-grub[/mono] qui a pour but de créer un fichier de configuration /boot/grub/grub.cfg pour le chargeur d’amorçage. Cette création fait appel aux scripts présents dans /etc/grub.d/. L’un d’eux, /etc/grub.d/06_OVHkernel, qui ne fait pas partie du paquet Debian grub-pc officiel, provoque une erreur à cause d’une commande ou fonction “make_system_path_relative_to_its_root” qu’il appelle mais ne semble pas exister. Il se peut que cette fonction soit obsolète dans la version de GRUB 2.02.

Comme l’écrit etxeberrizahar, il faudrait regarder ce que contient ce fichier /etc/grub.d/06_OVHkernel.

Un fichier fait forcément partie d’un système de fichiers.
Les listes de blocs sont utilisées pour charger la partie principale du chargeur GRUB (core image) où qu’elle soit, le programme minimaliste de la boot image ne sachant pas lire les systèmes de fichiers. En l’occurrence grub-install proteste quand l’emplacement de la core image est un fichier car l’accès à un fichier par listes de blocs n’est pas robuste, le système de fichiers pouvant déplacer les blocs d’un fichier. En tout cas cela n’a rien à voir avec l’erreur.

#4

Après vérification, la fonction [mono]make_system_path_relative_to_its_root[/mono] est toujours définie dans le fichier /usr/share/grub/grub-mkconfig_lib du paquet grub-common 2.02 et utilisée par plusieurs des scripts contenus dans /etc/grub.d/.

Est-ce que le script /etc/grub.d/06_OVHkernel “source” bien /usr/share/grub/grub-mkconfig_lib ou son lien symbolique /usr/lib/grub/grub-mkconfig_lib ?

#5

Bonjour à vous 2 et merci pour vos réponses.

etxeberrizahar, voici le contenu des fichiers en question:

root@***:~# cat /proc/cmdline BOOT_IMAGE=/boot/bzImage-3.2.13-xxxx-grs-ipv6-64 root=/dev/sda1 ro quiet

[code]root@***:~# cat /etc/grub.d/06_OVHkernel
#!/bin/bash -e

prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
. ${libdir}/grub/update-grub_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[/code]
PascalHambourg, effectivement, après vérification je suis en Jessie… Ma mémoire me joue des tours!
Voici donc plus d’informations sur ma version:

root@***:~# lsb_release -da No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 8.2 (jessie) Release: 8.2 Codename: jessie
J’ai corrigé mon fichier sources.list en conséquence (remplacement des occurences wheezy par jessie) et j’ai retenté une mise à jour, je rencontre toujours la même erreur.

Voici la configuration de grub-pc:[code]root@***:~# debconf-show grub-pc
grub-pc/kopt_extracted: false
grub2/kfreebsd_cmdline:
grub2/device_map_regenerated:
grub2/force_efi_extra_removable: false

  • grub-pc/install_devices: /dev/disk/by-id/ata-ST31000524AS_9VPBTR9W, /dev/disk/by-id/ata-ST31000524AS_9VPBTR9W-part1
    grub-pc/postrm_purge_boot_grub: false
    grub-pc/install_devices_failed_upgrade: true
    grub-pc/disk_description:
  • grub2/linux_cmdline:
    grub-pc/install_devices_empty: false
    grub2/kfreebsd_cmdline_default: quiet
    grub-pc/partition_description:
    grub-pc/install_devices_failed: false
  • grub-pc/install_devices_disks_changed: /dev/disk/by-id/ata-ST31000524AS_9VPBTR9W, /dev/disk/by-id/ata-ST31000524AS_9VPBTR9W-part1
  • grub2/linux_cmdline_default: quiet
    grub-pc/chainload_from_menu.lst: true
    grub-pc/hidden_timeout: false
    grub-pc/mixed_legacy_and_grub2: true
    grub-pc/timeout: 5[/code]
    Le fichier /etc/grub.d/06_OVHkernel est bien un fichier et non un lien:

root@***:~# file /etc/grub.d/06_OVHkernel /etc/grub.d/06_OVHkernel: Bourne-Again shell script, ASCII text executable

#6

Vu.
Le noyau actif est /boot/bzImage-3.2.13-xxxx-grs-ipv6-64. Comme il n’a pas un nom standard vmlinuz* détecté par le script standard/etc/grub.d/10_linux, le script /etc/grub.d/06_OVHkernel ajouté par OVH a pour rôle de détecter ce noyau et de l’ajouter au fichier de configuration de GRUB lors de l’exécution d’[mono]update-grub[/mono] (via [mono]grub-mkconfig[/mono]).

Cependant ce script est écrit pour les anciennes versions de GRUB car il utilise la bibliothèque /usr/lib/grub/update-grub_lib (lien vers /usr/share/grub/update-grub_lib) qui n’existe plus dans GRUB 2.02. Dans la version 1.99 de Wheezy, ce fichier contenait les lignes suivantes :

[code]. “${datarootdir}/grub/grub-mkconfig_lib”

grub_warn “update-grub_lib is deprecated, use grub-mkconfig_lib instead”[/code]

  1. Source le nouveau fichier [mono]grub-mkconfig_lib[/mono].
  2. Avertit que [mono]update-grub_lib[/mono] est obsolète.

En remplaçant [mono]update-grub_lib[/mono] par [mono]grub-mkconfig_lib[/mono] dans /etc/grub.d/06_OVHkernel, l’erreur devrait disparaître.

Il y a quand même un détail qui me chiffonne : si ce fichier n’existe plus, l’exécution du script devrait se terminer en erreur dès la tentative de sourçage de la bibliothèque, et non lors de l’appel de la fonction…

PS : [mono]debconf-show[/mono] montre bien que le paquet grub-pc est configuré pour installer l’amorce du chargeur dans le MBR du disque (ata-ST31000524AS_9VPBTR9W) et dans le PBR de la partition n° 1 (ata-ST31000524AS_9VPBTR9W-part1) :

Le warning concernant les listes de blocs, qui, je répète, est sans gravité, provient bien de l’installation dans une partition (qui ne sert à rien puisque l’amorce de GRUB est installée dans le MBR du disque mais bon).

#7

Merci PascalHambourg!

J’ai effectué la modification dans le script /etc/grub.d/06_OVHkernel puis relancé l’installation des paquets.
Effectivement, cette fois-ci tout fonctionne :038

root@***:~# apt-get install Reading package lists... Done Building dependency tree Reading state information... Done 0 upgraded, 0 newly installed, 0 to remove and 216 not upgraded. 1 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Setting up grub-pc (2.02~beta2-22) ... Installing for i386-pc platform. Installation finished. No error reported. Installing for i386-pc platform. grub-install: warning: File system `ext2' doesn't support embedding. grub-install: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.. Installation finished. No error reported. Generating grub configuration file ... Found linux image: /boot/bzImage-3.2.13-xxxx-grs-ipv6-64 No volume groups found done

Un grand merci à toi!
Excellente fin de semaine!