Redimensionnement partition racine

superjem · Février 21, 2016, 10:06pm

Bonjour,

J’administre un serveur debian (monté en raid 5 matériel) et je m’aperçoit que sa partition racine est trop petite, ce qui fait que je ne peux plus faire de mise-à-jour.

Est-il possible techniquement de réduire la partition home puis agrandir la partition racine sans perte de données ? Si c’est possible, comment dois-je m’y prendre vu la disposition des montages ?

#/ uname -a
Linux nexus47 3.2.0-4-amd64 #1 SMP Debian 3.2.68-1+deb7u5 x86_64 GNU/Linux

/# df -h
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/sda2          462M    373M   66M  85% /
udev                10M       0   10M   0% /dev
tmpfs              770M    448K  769M   1% /run
tmpfs              5,0M       0  5,0M   0% /run/lock
tmpfs              3,0G    4,0K  3,0G   1% /run/shm
/dev/sda1          487M    132K  486M   1% /boot/efi
/dev/sda7          2,7T    204G  2,4T   8% /home
/dev/sda6          369M     31M  320M   9% /tmp
/dev/sda3          6,5G    1,2G  5,0G  20% /usr
/dev/sda4          2,8G    671M  2,0G  26% /var
none               4,0K       0  4,0K   0% /sys/fs/cgroup

Merci pour votre aide.

etxeberrizahar · Février 21, 2016, 10:06pm

Demandons à voir le retour de la commande

/ se trouve en /dev/sda2 et /home se trouve en /dev/sda7.
En supposant que les partitions aient été créées dans l’ordre, entre /dev/sda2 et /dev/sda7, on devrait trouver /dev/sda3, primaire, /dev/sda4 étendue, /dev/sda5 première logique, /dev/sda6, deuxième logique. Cet agencement ne laisse pas la possibilité de transvaser l’espace libéré après /dev/sda7 pour l’inclure à /dev/sda2 sans toucher aux partitions intermédiaires.

Dans un partitionnement classique, dans l’ordre, les partitions /dev/sda2 et /dev/sda7 ne peuvent pas être voisines. Le «trou» après réduction de /dev/sda7 ne pourrait être inclus en /dev/sda2 à moins d’avoir créé un partitionnement tarabiscoté où /dev/sda2 cotoie /dev/sda7 ( c’est à dire où la troisième partition logique survient avant les deux premières logiques /dev/sda5 et /dev/sda6).

Dans un disque de type GPT comme ce semble le cas ici, le problème est le même. Entre /dev/sda2 et /dev/sda7 il devrait y avoir /dev/sda3,/dev/sda4,/dev/sda5,/dev/sda6.
Quoi qu’il en soit, nous voulons voir l’agencement des partitions pour savoir quelles partitions sont voisines.

[quote] [mono]/dev/sda6 369M 31M 320M 9% /tmp
/dev/sda3 6,5G 1,2G 5,0G 20% /usr
/dev/sda4 2,8G 671M 2,0G 26% /var[/mono][/quote]
/tmp est limité chez toi. Quand il est fait appel à /tmp, il suffit de 369 Mo de données pour le saturer.
/var à 2 Go.Ça dépend de ce qu’il faut. On peut trouver ça petit, moyennement petit, pas si petit, suffisant, trop gros …
L’actuel /usr en /dev/sda3 pourrait accueillir la racine.
Changer la racine de /dev/sda2 à /dev/sda3 te permettrait de revoir l’emplacement des données sans avoir à revoir le partitionnement.

PascalHambourg · Février 21, 2016, 10:06pm

Je suppose que c’est la mise à jour du noyau qui ne passe pas, car l’espace libre est inférieur à l’espace occupé par le paquet sur la racine (typiquement 120 à 160 Mo pour le noyau de Jessie). Une “solution” consiste à supprimer le noyau actuel et réinstaller le nouveau. Ça peut faire un peu peur, mais le système peut continuer à fonctionner sans noyau installé si tous les modules nécessaires à son fonctionnement ont été chargés.

Une question : est-ce l’installateur qui a défini automatiquement la taille des partitions en mode assisté ? Ce ne serait pas la première fois qu’il produit un résultat totalement aberrant compte tenu de la taille du disque.

Une remarque (mais un peu tard pour toi) : si l’installation avait été faite avec LVM, il aurait été simple de redimensionner les volumes logiques, et cela aurait même pu être fait à chaud sans arrêter le serveur.

Dans le cas présent, à moins que la racine soit en btrfs, deux approches sont envisageables :

réduire une partition qui a de l’espace en reste et déplacer toutes les partitions situées entre celle-ci et la racine pour pouvoir agrandir cette dernière.
réduire la partition /home, recréer une nouvelle partition racine dans l’espace libéré à la fin du disque et y transférer le contenu de l’actuelle. Variante : déplacer la partition racine et l’agrandir. Il y aura éventuellement des modifications à faire dans le chargeur GRUB et /etc/fstab si la nouvelle partition racine n’a pas le même numéro et le même UUID que l’actuelle.

Si tu as la chance que la racine soit en btrfs, tu peux l’agrandir en lui ajoutant une autre partition.

superjem · Février 21, 2016, 10:06pm

Bonjour et merci beaucoup,

#/ parted -l

Disk /dev/sda: 3000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system     Name  Flags
 1      1049kB  512MB   511MB   fat32                 boot, esp
 2      512MB   1012MB  500MB   ext4                  msftdata
 3      1012MB  8012MB  7000MB  ext4                  msftdata
 4      8012MB  11,0GB  3000MB  ext4                  msftdata
 5      11,0GB  18,9GB  7918MB  linux-swap(v1)
 6      18,9GB  19,3GB  400MB   ext4                  msftdata
 7      19,3GB  3000GB  2981GB  ext4                  msftdata

Donc si je comprends bien, si je choisi cette solution, je devrais copier /usr dans la racine, supprimer sda3 puis agrandir sda2. C’est bien ça ?

Effectivement il va falloir que je m’occupe après d’agrandir /tmp, peut-être en réduisant /home s’ils sont contigus ?

[quote=“PascalHambourg”]
Je suppose que c’est la mise à jour du noyau qui ne passe pas, car l’espace libre est inférieur à l’espace occupé par le paquet sur la racine (typiquement 120 à 160 Mo pour le noyau de Jessie)[/quote]
Oui c’est tout à fait ça.

#/ apt-get upgrade
[...]
 Dépaquetage de linux-image-3.16.0-4-amd64 (3.16.7-ckt11-1+deb8u6) sur (3.16.7-ckt11-1+deb8u5) ...
dpkg: erreur de traitement de l'archive /var/cache/apt/archives/linux-image-3.16.0-4-amd64_3.16.7-ckt11-1+deb8u6_amd64.deb (--unpack) :
 impossible de copier les données extraites pour « ./lib/modules/3.16.0-4-amd64/kernel/drivers/net/team/team.ko » vers « /lib/modules/3.16.0-4-amd64/kernel/drivers/net/team/team.ko.dpkg-new » : échec d'écriture (Aucun espace disponible sur le périphérique)
dpkg-deb : erreur : le sous-processus coller a été tué par le signal (Relais brisé (pipe))
Des erreurs ont été rencontrées pendant l'exécution :
 /var/cache/apt/archives/linux-image-3.16.0-4-amd64_3.16.7-ckt11-1+deb8u6_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Quels sont les fichiers que je peux supprimer ? je lance un upgrade juste après tout simplement ?

Je ne sais pas, soit c’est l’installateur soit il y a eu une erreur au moment de la saisie des tailles (Mo au lieu de Go par exemple).

Donc dans cette solution, je copie /tmp, /usr, /var dans sda7 qui contient déjà /home, je supprime sda3, sda4 et sda6 pour libérer de la place et j’agrandi la racine (par la suite je pourrais de nouveau réduire sda7 pour recréer des partitions pour séparer à nouveau sda3, sda4 et sda6 avec la liberté de les agrandir au besoin). C’est bien ça ? Cette solution me semble la plus confortable vis-à-vis de mon niveau en administration.

Cette solution me semble plus risqué à mon niveau.

PascalHambourg · Février 21, 2016, 10:06pm

Non, impossible de copier /usr dans la racine, il n’y a pas assez d’espace libre. Je pense que l’idée était plutôt de fusionner la racine et /usr dans /dev/sda3 et d’en faire la nouvelle racine. Mais cela nécessite des aménagements préalables dans cette partition.

Pour le moment /tmp est largement suffisant. L’agrandir est loin d’être une priorité.

Il n’est pas question de supprimer des fichiers (sinon l’upgrade risque d’être quelque peu perturbé s’il ne trouve pas les anciens fichiers) mais de désinstaller le paquet de l’image du noyau. Comme il ne sera plus installé, l’upgrade ne le réinstallera pas, il faudra passer par un install du même paquet (qui utilisera la dernière version disponible).

Je doute que tu aies fait une erreur de préfixe, car vouloir une racine de 500 Go est peu probable, même sur un disque de 3 To.

Non, je ne parlais pas de copier quoi que ce soit mais de déplacer les partitions entières avec leur contenu. Ce sera très long mais cela évite de faire des copies transitoires

cedric058 · Février 21, 2016, 10:06pm

Bonsoir,

Peut tu nous faire un:

# dpkg -l | grep linux-image*

J’ai déja fais presque pareil mais sans désinstaller le noyau, voir ci-dessous.

[quote=“superjem”] Dépaquetage de linux-image-3.16.0-4-amd64 (3.16.7-ckt11-1+deb8u6) sur (3.16.7-ckt11-1+deb8u5) …
dpkg: erreur de traitement de l’archive /var/cache/apt/archives/linux-image-3.16.0-4-amd64_3.16.7-ckt11-1+deb8u6_amd64.deb (–unpack) :
impossible de copier les données extraites pour « ./lib/modules/3.16.0-4-amd64/kernel/drivers/net/team/team.ko » vers « /lib/modules/3.16.0-4-amd64/kernel/drivers/net/team/team.ko.dpkg-new » : échec d’écriture (Aucun espace disponible sur le périphérique)[/quote]
Sinon tu as la technique du barbare qui a fonctionnée maintes fois chez moi.
Elle n’as jamais faillie. A l’époque j’avais une racine de 300 Mo créer via l’installeur Debian (Je met 500 Mo maintenant).

Elle consiste à faire un peu de place sur la racine, en déplaçant ce qui encombre…, et qui de plus ne serviras plus après la mise à jour du noyau.

Les commandes sont à enchaîner sans redémarrer la machine, sous peine que la machine ne redémarre pas.
Tu peux toujours tester sur une autre machine avant de tenter la manipulation sur ton serveur…

# mv /lib/modules/3*/* /home/user/rep_sauvegarde/
# aptitude update
# aptitude upgrade

Vérifie ensuite si l’ancien noyau a été désinstallé automatiquement, ou si il faut que tu le desinstalle via “aptitude” ou “apt-get”.

PascalHambourg · Février 21, 2016, 10:06pm

Pour Jessie amd64 ? Et cela suffit ? La partition racine de superjem fait justement 500 Mo (465 Mio). Il y a peut-être du nettoyage à faire.

C’est vrai que je viens de regarder sur une installation de Jessie amd64, minimale certe mais le gros des paquets s’installe dans /usr, et les répertoires de la racine n’occupent que 271 Mo. Avec 500 Go il devrait y avoir un peu de marge en comptant les 160 Mo d’espace libre nécessaire pour la mise à jour du noyau.

Et la mise à jour ne tousse pas lors de la phase de suppression des anciens fichiers qui sont censés être présents mais ne le sont plus ?

Tant qu’on ne touche pas à l’image du noyau ni à l’initramfs dans /boot (vmlinuz-* et initrd.img-*), le système devrait démarrer au moins en mode maintenance (rescue), ces deux fichiers contenant tout ce qui est nécessaire. Par contre il pourra manquer le réseau et d’autres fonctionnalités.

Si la mise à jour a réussi, l’ancien noyau a forcément été remplacé par le nouveau. Deux versions d’un même paquet ne peuvent pas être installées simultanément.

cedric058 · Février 21, 2016, 10:06pm

Non, c’était sur une wheezy x86. Le même problème est arrivé avec les updates des noyaux de plus en plus gros.
Actuellement, j’ai 500 Mo de racine (241 Mo à 259 Mo occupé) et un /boot séparré (30 Mo occupé). Je n’ai pas ce souci.

(500 Mo installeur Debian => 487 MiB de “fdisk -l”)

Jamais elle n’a indiqué le moindre problème.

[quote=“PascalHambourg”][quote=“cedric058”]
Les commandes sont à enchaîner sans redémarrer la machine, sous peine que la machine ne redémarre pas.[/quote]
Tant qu’on ne touche pas à l’image du noyau ni à l’initramfs dans /boot (vmlinuz-* et initrd.img-*), le système devrait démarrer au moins en mode maintenance (rescue), ces deux fichiers contenant tout ce qui est nécessaire. Par contre il pourra manquer le réseau et d’autres fonctionnalités.[/quote]
Merci de me l’apprendre.

Comme le /boot n’était pas séparré, j’ai déja du virer l’ "initrd.img-" avec /lib/modules/ au début.
Sans problème également pour la mise à jour.
Je ne me suis pas risqué à faire des test de redémarrage de la machine sans ces fichiers.

cedric058 · Février 21, 2016, 10:06pm

On pourrait aussi, déplacer certain fichiers ou dossiers volumineux et utiliser [mono]ln[/mono].

PascalHambourg · Février 21, 2016, 10:06pm

C’est la solution de facilité quand on manque de place dans une partition, mais pas très propre puisqu’elle va à l’encontre de la raison pour laquelle on sépare l’arborescence en plusieurs partitions : bien organiser les fichiers.

D’autre part, la racine est un cas particulier : certains répertoires comme /bin, /etc, /lib* et /sbin sont toujours inclus dans la partition racine car leur contenu doit être disponible avant que les autres partitions soient montées. Les répertoires les plus volumineux sont généralement /lib (contenant les modules du noyau et les bibliothèques de base) qui ne peut être déplacé et /boot (contenant l’image du noyau, l’initramfs et le chargeur d’amorçage) qui peut être déporté sur une partition séparée (modification de /etc/fstab et réinstallation du chargeur d’amorçage nécessaire). Je ne vois guère que le contenu des répertoires /root, /srv et /opt, qui ne contiennent pas de fichiers liés aux paquets Debian, qui pourrait être déplacé et remplacé par des liens symboliques.

superjem · Février 21, 2016, 10:09pm

Un très grand merci à vous pour toutes vos réponses éclairantes !

# dpkg -l | grep linux-image*
ii  linux-image-3.16.0-4-amd64         3.16.7-ckt11-1+deb8u5         amd64        Linux 3.16 for 64-bit PCs
ii  linux-image-3.2.0-4-amd64          3.2.68-1+deb7u5               amd64        Linux 3.2 for 64-bit PCs
ii  linux-image-amd64                  3.16+63                       amd64        Linux for 64-bit PCs (meta-package)

Pour résumer un peu, je pense donc ne pas toucher aux partitions (tailles et déplacements) dans l’immédiat mais «simplement» supprimer le paquet de l’image du noyau pour le réinstaller, dites-moi si je me trompe :

# apt-get purge linux-image-amd64

Puis réinstaller le paquet en faisant une mise-à-jour :

# apt-get update && apt-get upgrade

Est-ce bien cela ?

Encore merci

PascalHambourg · Février 21, 2016, 10:09pm

En lisant les premiers messages il m’avait échappé que deux noyaux sont installés, le 3.2 de Wheezy (Debian 7), qui est actif d’après la sortie de [mono]uname -a[/mono], et le 3.16 de Jessie (Debian 8), que tu essaies de mettre à jour d’après la sortie d’[mono]apt-get upgrade[/mono].

Petite question sournoise : pourquoi démarres-tu avec le noyau 3.2 de Wheezy sur un système Jessie ? D’autant plus que par défaut c’est le noyau le plus récent qui devrait démarrer, donc le noyau 3.16. En tout cas tu peux sans risque désinstaller le 3.16 puisqu’il n’est pas actif.

Autre possibilité : si tu peux démarrer avec le noyau 3.16 et n’as plus besoin du noyau 3.2, tu peux juste désinstaller ce dernier pour gagner de l’espace libre.

En revanche désinstaller linux-image-amd64 seul n’avancerait à rien car c’est juste un méta-paquet qui dépend de la plus récente version de noyau disponible.

superjem · Février 21, 2016, 10:09pm

Bingo ! La mémoire me revient (alors que je n’ai pas encore attaqué le champagne…) : j’ai (cru) mettre à jour il y a quelques temps le serveur qui était en wheezzy pour le passer en jessie. J’ai donc modifié sources.list en changeant wheezy par jessie puis en faisant apt-get update && apt-get upgrade && apt-get dist-upgrade puis reboot.

Comment ce fait-il que le système utilise toujours le noyau de wheezy ? Un truc m’échappe, j’ai oublié quelque chose lors de la mise à jour de 7 vers 8 ?

PascalHambourg · Février 21, 2016, 10:09pm

Le répertoire /boot contient-il bien deux fichiers vmlinuz-3.16* et initrd.img-3.16* ?
Quels sont les noyaux présents dans le menu de démarrage du chargeur d’amorçage et quel est le noyau par défaut ?
Quel est le gestionnaire d’amorçage ? GRUB, LILO, autre ?
Si GRUB, que contient /etc/defaut/grub et qu’affiche [mono]grub-mkconfig[/mono] (en root) ?
Si LILO, qu’affiche [mono]lilo -t[/mono] ?

superjem · Février 21, 2016, 10:09pm

oui :

# ls -l /boot total 36046 -rw-r--r-- 1 root root 157726 oct. 11 22:50 config-3.16.0-4-amd64 -rw-r--r-- 1 root root 129281 oct. 11 21:32 config-3.2.0-4-amd64 drwxr-xr-x 3 root root 4096 janv. 1 1970 efi drwxr-xr-x 5 root root 6144 nov. 3 11:30 grub -rw-r--r-- 1 root root 14701555 nov. 3 12:40 initrd.img-3.16.0-4-amd64 -rw-r--r-- 1 root root 11164139 oct. 29 13:03 initrd.img-3.2.0-4-amd64 -rw-r--r-- 1 root root 2672227 oct. 11 22:50 System.map-3.16.0-4-amd64 -rw-r--r-- 1 root root 2114657 oct. 11 21:32 System.map-3.2.0-4-amd64 -rw-r--r-- 1 root root 3112848 oct. 11 22:50 vmlinuz-3.16.0-4-amd64 -rw-r--r-- 1 root root 2842880 oct. 11 21:29 vmlinuz-3.2.0-4-amd64

Les noyaux par ordre dans /boot/grub/grub.cfg :

menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-2d7c6526-1466-4da6-bd85-57eb35552891' {
submenu 'Options avancées pour Debian GNU/Linux' $menuentry_id_option 'gnulinux-advanced-2d7c6526-1466-4da6-bd85-57eb35552891' {
  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-2d7c6526-1466-4da6-bd85-57eb35552891' {
  menuentry 'Debian GNU/Linux, with Linux 3.16.0-4-amd64 (sysvinit)' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.16.0-4-amd64-init-sysvinit-2d7c6526-1466-4da6-bd85-57eb35552891' {
  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-2d7c6526-1466-4da6-bd85-57eb35552891' {
  menuentry 'Debian GNU/Linux, avec Linux 3.2.0-4-amd64' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.2.0-4-amd64-advanced-2d7c6526-1466-4da6-bd85-57eb35552891' {
  menuentry 'Debian GNU/Linux, with Linux 3.2.0-4-amd64 (sysvinit)' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.2.0-4-amd64-init-sysvinit-2d7c6526-1466-4da6-bd85-57eb35552891' {
  menuentry 'Debian GNU/Linux, with Linux 3.2.0-4-amd64 (recovery mode)' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.2.0-4-amd64-recovery-2d7c6526-1466-4da6-bd85-57eb35552891'

Et l’index par défaut dans /etc/default/grub :

GRUB_DEFAULT=0

Donc je pense que le noyau utilisé par défaut est le 3.16.0-4-amd64 pourtant uname -a me renvoi :

C’est donc grub2.

# cat /etc/default/grub 
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

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=""

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

# grub-mkconfig 
Création du fichier de configuration GRUB…
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  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="0"
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
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod ext2
set root='hd0,gpt3'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt3 --hint-efi=hd0,gpt3 --hint-baremetal=ahci0,gpt3 --hint='hd0,gpt3'  8d345bd8-ced1-4841-a788-4b246924944b
else
  search --no-floppy --fs-uuid --set=root 8d345bd8-ced1-4841-a788-4b246924944b
fi
    font="/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=fr_FR
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=-1
else
  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
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
  set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
Image Linux trouvée : /boot/vmlinuz-3.16.0-4-amd64
Image mémoire initiale trouvée : /boot/initrd.img-3.16.0-4-amd64
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-2d7c6526-1466-4da6-bd85-57eb35552891' {
  load_video
  insmod gzio
  if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
  insmod part_gpt
  insmod ext2
  set root='hd0,gpt2'
  if [ x$feature_platform_search_hint = xy ]; then
    search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 --hint='hd0,gpt2'  2d7c6526-1466-4da6-bd85-57eb35552891
  else
    search --no-floppy --fs-uuid --set=root 2d7c6526-1466-4da6-bd85-57eb35552891
  fi
  echo  'Chargement de Linux 3.16.0-4-amd64…'
  linux /boot/vmlinuz-3.16.0-4-amd64 root=UUID=2d7c6526-1466-4da6-bd85-57eb35552891 ro  quiet
  echo  'Chargement du disque mémoire initial…'
  initrd  /boot/initrd.img-3.16.0-4-amd64
}
submenu 'Options avancées pour Debian GNU/Linux' $menuentry_id_option 'gnulinux-advanced-2d7c6526-1466-4da6-bd85-57eb35552891' {
  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-2d7c6526-1466-4da6-bd85-57eb35552891' {
    load_video
    insmod gzio
    if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
    insmod part_gpt
    insmod ext2
    set root='hd0,gpt2'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 --hint='hd0,gpt2'  2d7c6526-1466-4da6-bd85-57eb35552891
    else
      search --no-floppy --fs-uuid --set=root 2d7c6526-1466-4da6-bd85-57eb35552891
    fi
    echo  'Chargement de Linux 3.16.0-4-amd64…'
    linux /boot/vmlinuz-3.16.0-4-amd64 root=UUID=2d7c6526-1466-4da6-bd85-57eb35552891 ro  quiet
    echo  'Chargement du disque mémoire initial…'
    initrd  /boot/initrd.img-3.16.0-4-amd64
  }
  menuentry 'Debian GNU/Linux, with Linux 3.16.0-4-amd64 (sysvinit)' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.16.0-4-amd64-init-sysvinit-2d7c6526-1466-4da6-bd85-57eb35552891' {
    load_video
    insmod gzio
    if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
    insmod part_gpt
    insmod ext2
    set root='hd0,gpt2'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 --hint='hd0,gpt2'  2d7c6526-1466-4da6-bd85-57eb35552891
    else
      search --no-floppy --fs-uuid --set=root 2d7c6526-1466-4da6-bd85-57eb35552891
    fi
    echo  'Chargement de Linux 3.16.0-4-amd64…'
    linux /boot/vmlinuz-3.16.0-4-amd64 root=UUID=2d7c6526-1466-4da6-bd85-57eb35552891 ro  quiet init=/lib/sysvinit/init
    echo  'Chargement du disque mémoire initial…'
    initrd  /boot/initrd.img-3.16.0-4-amd64
  }
  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-2d7c6526-1466-4da6-bd85-57eb35552891' {
    load_video
    insmod gzio
    if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
    insmod part_gpt
    insmod ext2
    set root='hd0,gpt2'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 --hint='hd0,gpt2'  2d7c6526-1466-4da6-bd85-57eb35552891
    else
      search --no-floppy --fs-uuid --set=root 2d7c6526-1466-4da6-bd85-57eb35552891
    fi
    echo  'Chargement de Linux 3.16.0-4-amd64…'
    linux /boot/vmlinuz-3.16.0-4-amd64 root=UUID=2d7c6526-1466-4da6-bd85-57eb35552891 ro single 
    echo  'Chargement du disque mémoire initial…'
    initrd  /boot/initrd.img-3.16.0-4-amd64
  }
Image Linux trouvée : /boot/vmlinuz-3.2.0-4-amd64
Image mémoire initiale trouvée : /boot/initrd.img-3.2.0-4-amd64
  menuentry 'Debian GNU/Linux, avec Linux 3.2.0-4-amd64' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.2.0-4-amd64-advanced-2d7c6526-1466-4da6-bd85-57eb35552891' {
    load_video
    insmod gzio
    if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
    insmod part_gpt
    insmod ext2
    set root='hd0,gpt2'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 --hint='hd0,gpt2'  2d7c6526-1466-4da6-bd85-57eb35552891
    else
      search --no-floppy --fs-uuid --set=root 2d7c6526-1466-4da6-bd85-57eb35552891
    fi
    echo  'Chargement de Linux 3.2.0-4-amd64…'
    linux /boot/vmlinuz-3.2.0-4-amd64 root=UUID=2d7c6526-1466-4da6-bd85-57eb35552891 ro  quiet
    echo  'Chargement du disque mémoire initial…'
    initrd  /boot/initrd.img-3.2.0-4-amd64
  }
  menuentry 'Debian GNU/Linux, with Linux 3.2.0-4-amd64 (sysvinit)' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.2.0-4-amd64-init-sysvinit-2d7c6526-1466-4da6-bd85-57eb35552891' {
    load_video
    insmod gzio
    if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
    insmod part_gpt
    insmod ext2
    set root='hd0,gpt2'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 --hint='hd0,gpt2'  2d7c6526-1466-4da6-bd85-57eb35552891
    else
      search --no-floppy --fs-uuid --set=root 2d7c6526-1466-4da6-bd85-57eb35552891
    fi
    echo  'Chargement de Linux 3.2.0-4-amd64…'
    linux /boot/vmlinuz-3.2.0-4-amd64 root=UUID=2d7c6526-1466-4da6-bd85-57eb35552891 ro  quiet init=/lib/sysvinit/init
    echo  'Chargement du disque mémoire initial…'
    initrd  /boot/initrd.img-3.2.0-4-amd64
  }
  menuentry 'Debian GNU/Linux, with Linux 3.2.0-4-amd64 (recovery mode)' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.2.0-4-amd64-recovery-2d7c6526-1466-4da6-bd85-57eb35552891' {
    load_video
    insmod gzio
    if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
    insmod part_gpt
    insmod ext2
    set root='hd0,gpt2'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 --hint='hd0,gpt2'  2d7c6526-1466-4da6-bd85-57eb35552891
    else
      search --no-floppy --fs-uuid --set=root 2d7c6526-1466-4da6-bd85-57eb35552891
    fi
    echo  'Chargement de Linux 3.2.0-4-amd64…'
    linux /boot/vmlinuz-3.2.0-4-amd64 root=UUID=2d7c6526-1466-4da6-bd85-57eb35552891 ro single 
    echo  'Chargement du disque mémoire initial…'
    initrd  /boot/initrd.img-3.2.0-4-amd64
  }
}

### END /etc/grub.d/10_linux ###

### BEGIN /etc/grub.d/20_linux_xen ###

### END /etc/grub.d/20_linux_xen ###

### BEGIN /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_os-prober ###

### BEGIN /etc/grub.d/30_uefi-firmware ###
Adding boot menu entry for EFI firmware configuration
menuentry 'System setup' $menuentry_id_option 'uefi-firmware' {
  fwsetup
}
### END /etc/grub.d/30_uefi-firmware ###

### 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 ###
fait

Encore merci Pascal pour ton aide précieuse.

PascalHambourg · Février 21, 2016, 10:09pm

Tout me semble correct. La vérification finale serait de redémarrer et voir ce qui apparaît dans le menu de GRUB (noyaux listés et choix par défaut).
As-tu vraiment redémarré la machine après l’installation du nouveau noyau ?

superjem · Février 21, 2016, 10:09pm

[quote=“PascalHambourg”]Tout me semble correct. La vérification finale serait de redémarrer et voir ce qui apparaît dans le menu de GRUB (noyaux listés et choix par défaut).
As-tu vraiment redémarré la machine après l’installation du nouveau noyau ?[/quote]

Effectivement pascal, j’ai rebooté le serveur qui a bien démarré sur le kernel le plus récent.
J’ai ensuite pu faire une mise à jour du système et maintenant tout semble ok !

Je ne vais pas pour le moment augmenter la taille de la partition racine, je le ferai si j’en ai vraiment besoin.
Merci à vous tous de m’avoir guidé et appris plein de choses

Par contre je me suis aperçu que l’un de mes disques raid (matériel) n’était pas visible au boot et j’ai donc le message «degraded» qui s’affiche mais ceci est un autre sujet…