[quote=“PengouinPdt”]C’est un bogue qui a l’air d’être récurrent …
bugs.debian.org/cgi-bin/bugreport.cgi?bug=670172
Un des conseils - pertinent - est de revenir à un kernel précédent ![/quote]
Ok, je regarderai ça demain. Merci pour ton aide.
Je suis sur un portable. Je n’ai plus rien de brancher en USB et toujours impossible de retirer le module nls_base…
Teste en basculant sur un noyau précédent, histoire de vérifier si tu montes ou pas 
++
je dois forcément passer par la case compilation ou il y a plus simple ?
C’est-à-dire ?
Cela sous-tend que tu as supprimé tous les précédents kernels ?!
Cela suffit-il pour le vérifier ?
# ls -lrt /boot/vmlinuz-2.6.32-*
-rw-r--r-- 1 root root 2194688 10 mai 14:23 /boot/vmlinuz-2.6.32-5-486
-rw-r--r-- 1 root root 2303584 10 mai 14:25 /boot/vmlinuz-2.6.32-5-686
EDIT : Ne devrais-je pas retrouver les anciens noyaux dans les dépots avec synaptic comme sur une ubuntu par ex ? J’ai regardé, je n’ai rien trouvé…
Je me souviens avoir travaillé sur l’optimisation de mon système (gain de place) il y a quelques mois grâce à l’excellent billet se trouvant dans Trucs et astuces. Il semblerait que j’ai paramétré mon système pour qu’il dégage les anciens noyaux à l’installation du nouveau, chose que je ne fais pas en général (je garde toujours l’avant dernier en cas de pb).
Quelques précisions pour comprendre
La machine sur laquelle est installée ma debian est un portable Asus qui a plus de 10 ans et j’ai dû composer avec certaines contraintes pour le moderniser. Le disque dur d’origine en IDE faisait 40Go. J’ai fait une upgrade à 160Go mais pour installer un dualboot ( ancienne configuration avec XP qui n’a plus cours aujourd’hui), j’ai dû créer une partition /boot de 100Mo en tête de disque pour contenir mes fichiers de démarrage linux, le Bios (de 2002) étant incapable de lire au delà d’un certain nombre de Go.
Je ne connais pas exactement cette limite, peut-être 10Go, peut-être 20. Cela signifie que si j’installe un premier système sur les 30 premiers Go du hdd sans prendre de précaution particulière (partitionnement classique / , / home , swap )et que j’enquille le second OS sur le restant du disque, il me sera impossible de le lancer…
Ceci étant dit, la partition /boot de 100Mo a vite fait de se remplir au fur et à mesure des mises à jour et c’est la raison pour laquelle j’ai dû automatiser la procédure de retrait de fichiers d’anciens noyaux.
Aujourd’hui je n’ai qu’une squeeze sur ce portable, mais rien ne dit que demain, je ne chercherais pas à faire un dualboot avec une autre distro ou simplement une autre version de debian. D’où le maintien de ce partitionnement…
Bref revenons à nos moutons.
Comment réinstaller la version antérieure du noyau pour faire au plus simple ?
S’il s’avère que ce bug est lié à la mise à jour du noyau et que cela n’est pas résolu avec le noyau 3.2 sur Wheezy, c’est à désespérer^^
# uname -a
Linux l3c1 2.6.32-5-686 #1 SMP Wed Jan 12 04:01:41 UTC 2011 i686 GNU/Linux
Comme je te l’ai dit cette erreur vient du noyau, tu ne peux pas la résoudre sans changer de noyau.
cette option semble faire consensus et je m’y rallie sans pb.
Pourquoi dans synaptic je n’ai pas la liste des anciens noyaux comme dans les dépôts ubuntu par ex ?
Mon questionnement n’est plus de l’ordre du quoi faire, mais du comment 
[quote=“milediou”]cette option semble faire consensus et je m’y rallie sans pb.
Pourquoi dans synaptic je n’ai pas la liste des anciens noyaux comme dans les dépôts ubuntu par ex ?
Mon questionnement n’est plus de l’ordre du quoi faire, mais du comment [/quote]
Ce que tu dois comprendre, c’est que ce bogue ne touche pas toutes les versions d’un même noyau…
Preuve en est les différents posts du bogue précité… Apparemment, les développeurs n’arrivent pas à le recréer, voire à comprendre pourquoi - si j’ai bien compris -…
Bref, cela n’explique pas pourquoi en effet dans synaptic, tu n’as pas les différentes versions de kernel existantes pour ta version de Debian …
Fais-nous un copier-coller de ton sources.list…
Voici :
[code]# cat /etc/apt/sources.list
deb http://ftp.fr.debian.org/debian/ squeeze main contrib non-free
deb http://security.debian.org/ squeeze/updates main contrib non-free
deb http://mozilla.debian.net/ squeeze-backports iceweasel-release
[/code]
[quote=“milediou”]# uname -a
Linux l3c1 2.6.32-5-686 #1 SMP Wed Jan 12 04:01:41 UTC 2011 i686 GNU/Linux[/quote]
Tu es sûr d’avoir complètement redémarré le système ? Visiblement, c’est toujours un (très) ancien noyau (janvier 2011) qui est actif. Le dernier noyau, correspondant à la date de /boot/vmlinuz-2.6.32-5-686, devrait afficher la date du 10 mai 2013.
Si tu as bien redémarré, alors il faut regarder du côté du chargeur d’amorçage pour voir où il va chercher l’image du noyau /boot/vmlinuz-2.6.32-5-686, parce qu’apparemment il charge une vieille image. Il se peut que le même problème affecte aussi l’initramfs (/boot/initrd.img-2.6.32-5-686) car il contient le module nls_base qui est chargé à partir de l’initramfs et non de la racine.
Tu as évoqué des problèmes de place sur /boot, regarde aussi de ce côté.
[quote=“PengouinPdt”]C’est un bogue qui a l’air d’être récurrent …
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=670172[/quote]
Ce rapport de bug date de plus d’un an, a été fermé et concernait un noyau 3.2 alors que milediou a un noyau 2.6.32. J’ai exactement le même noyau suite à la mise à jour de sécurité récente, et je n’ai pas le bug.
Normal : d’autres modules déjà chargés, notamment usbcore dont dépend tout l’USB, en dépendent. Pour le décharger, il faut tous les décharger avant, donc perdre l’USB notamment (dur si clavier en USB et pas d’accès réseau type SSH pour ouvrir une console à distance).
Le symbole utf8s_to_utf16s_new dont le module vfat a besoin est normalement fourni par le module nls_base. On peut vérifier si c’est bien le cas :
Si ce n’est pas le cas, il y a un GROS problème.
Ensuite on peut vérifier si depmod -a l’a bien enregistré lors de l’installation du noyau :
et si la dépendance entre les modules vfat et nls_base a bien été enregistrée :
modinfo vfat
grep vfat /lib/modules/$(uname -r)/modules.dep
Si ce n’est pas le cas, tu peux essayer de regénérer les dépendances entre modules en exécutant depmod.
Oui mon capitaine ! Le portable est arrêté tous les soirs donc depuis le 10 mai, cela fait un nb conséquent de redémarrage. Donc quand tu fais un ‘uname -a’ chez toi, tu as bien la date du 10 mai qui apparait ? Bizarre…
recherche des entrées ‘vmlinuz’ sur mon disque
# locate vmlinuz
/vmlinuz
/boot/vmlinuz-2.6.32-5-686
contenu du dossier /boot
# ls -ilhs /boot
total 25M
727714 116K -rw-r--r-- 1 root root 109K 10 mai 14:24 config-2.6.32-5-486
727690 116K -rw-r--r-- 1 root root 109K 10 mai 14:25 config-2.6.32-5-686
842133 4,0K drwxr-xr-x 3 root root 4,0K 19 mai 00:45 grub
1005654 8,5M -rw-r--r-- 1 root root 8,5M 19 mai 00:44 initrd.img-2.6.32-5-486
727687 8,5M -rw-r--r-- 1 root root 8,5M 18 mai 20:55 initrd.img-2.6.32-5-686
727668 168K -rw-r--r-- 1 root root 162K 19 oct. 2010 memtest86+.bin
727667 168K -rw-r--r-- 1 root root 164K 19 oct. 2010 memtest86+_multiboot.bin
727708 1,2M -rw-r--r-- 1 root root 1,2M 10 mai 14:24 System.map-2.6.32-5-486
727712 1,3M -rw-r--r-- 1 root root 1,3M 10 mai 14:25 System.map-2.6.32-5-686
727713 2,1M -rw-r--r-- 1 root root 2,1M 10 mai 14:23 vmlinuz-2.6.32-5-486
1005651 2,3M -rw-r--r-- 1 root root 2,2M 10 mai 14:25 vmlinuz-2.6.32-5-686
fichier grub.cfg
[code]# cat /boot/grub/grub.cfg
if [ -s $prefix/grubenv ]; then
load_env
fi
set default=“0"
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 {
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
}
insmod part_msdos
insmod ext2
set root=’(hd0,msdos4)‘
search --no-floppy --fs-uuid --set 7e406713-3ff4-44ca-846d-e997f022ccb9
if loadfont /usr/share/grub/unicode.pf2 ; then
set gfxmode=640x480
load_video
insmod gfxterm
fi
terminal_output gfxterm
insmod part_msdos
insmod ext2
set root=’(hd0,msdos4)'
search --no-floppy --fs-uuid --set 7e406713-3ff4-44ca-846d-e997f022ccb9
set locale_dir=($root)/boot/grub/locale
set lang=fr
insmod gettext
set timeout=10
insmod part_msdos
insmod ext2
set root=’(hd0,msdos4)'
search --no-floppy --fs-uuid --set 7e406713-3ff4-44ca-846d-e997f022ccb9
insmod png
if background_image /usr/share/images/desktop-base/spacefun-grub.png; then
set color_normal=light-gray/black
set color_highlight=white/black
else
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
fi
menuentry ‘Debian GNU/Linux, avec Linux 2.6.32-5-686’ --class debian --class gnu-linux --class gnu --class os {
insmod part_msdos
insmod ext2
set root=’(hd0,msdos4)'
search --no-floppy --fs-uuid --set 7e406713-3ff4-44ca-846d-e997f022ccb9
echo 'Chargement de Linux 2.6.32-5-686 …'
linux /boot/vmlinuz-2.6.32-5-686 root=UUID=7e406713-3ff4-44ca-846d-e997f022ccb9 ro quiet
echo 'Chargement du disque mémoire initial …‘
initrd /boot/initrd.img-2.6.32-5-686
}
menuentry ‘Debian GNU/Linux, avec Linux 2.6.32-5-686 (mode de dépannage)’ --class debian --class gnu-linux --class gnu --class os {
insmod part_msdos
insmod ext2
set root=’(hd0,msdos4)'
search --no-floppy --fs-uuid --set 7e406713-3ff4-44ca-846d-e997f022ccb9
echo 'Chargement de Linux 2.6.32-5-686 …'
linux /boot/vmlinuz-2.6.32-5-686 root=UUID=7e406713-3ff4-44ca-846d-e997f022ccb9 ro single
echo 'Chargement du disque mémoire initial …'
initrd /boot/initrd.img-2.6.32-5-686
}
menuentry “Memory test (memtest86+)” {
insmod part_msdos
insmod ext2
set root=’(hd0,msdos4)‘
search --no-floppy --fs-uuid --set 7e406713-3ff4-44ca-846d-e997f022ccb9
linux16 /boot/memtest86+.bin
}
menuentry “Memory test (memtest86+, serial console 115200)” {
insmod part_msdos
insmod ext2
set root=’(hd0,msdos4)‘
search --no-floppy --fs-uuid --set 7e406713-3ff4-44ca-846d-e997f022ccb9
linux16 /boot/memtest86+.bin console=ttyS0,115200n8
}
menuentry “Memory test (memtest86+, experimental multiboot)” {
insmod part_msdos
insmod ext2
set root=’(hd0,msdos4)‘
search --no-floppy --fs-uuid --set 7e406713-3ff4-44ca-846d-e997f022ccb9
multiboot /boot/memtest86+_multiboot.bin
}
menuentry “Memory test (memtest86+, serial console 115200, experimental multiboot)” {
insmod part_msdos
insmod ext2
set root=’(hd0,msdos4)'
search --no-floppy --fs-uuid --set 7e406713-3ff4-44ca-846d-e997f022ccb9
multiboot /boot/memtest86+_multiboot.bin console=ttyS0,115200n8
}
if [ -f $prefix/custom.cfg ]; then
source $prefix/custom.cfg;
fi
[/code]
C’est ce qui m’interroge ! Pourquoi n’y a t’il pas davantage de monde affecté par ce bug depuis le 10 mai ?
[code]# depmod -n /lib/modules/$(uname -r)/kernel/fs/nls/nls_base.ko
kernel/fs/nls/nls_base.ko:
alias symbol:load_nls nls_base
alias symbol:unregister_nls nls_base
alias symbol:register_nls nls_base
alias symbol:unload_nls nls_base
alias symbol:utf8_to_utf32 nls_base
alias symbol:utf32_to_utf8 nls_base
alias symbol:utf8s_to_utf16s nls_base
alias symbol:load_nls_default nls_base
alias symbol:utf8s_to_utf16s_fixed nls_base
alias symbol:utf16s_to_utf8s nls_base
[quote]Ensuite on peut vérifier si depmod -a l’a bien enregistré lors de l’installation du noyau :
et si la dépendance entre les modules vfat et nls_base a bien été enregistrée :[/quote]
# modinfo vfat
filename: /lib/modules/2.6.32-5-686/kernel/fs/fat/vfat.ko
author: Gordon Chaffee
description: VFAT filesystem support
license: GPL
depends: fat,nls_base
vermagic: 2.6.32-5-686 SMP mod_unload modversions 686
# grep vfat /lib/modules/$(uname -r)/modules.dep
kernel/fs/fat/vfat.ko: kernel/fs/fat/fat.ko kernel/fs/nls/nls_base.ko
je crois que la confusion vient du fait que j’ai une partition /boot ET un dossier /boot sous la racine de ma partition système. Mon chargeur de démarrage doit s’emmêler les pinceaux et pointer sur le mauvais noyau.
Je viens de m’en rendre compte en installant un autre noyau ( 2.6.32-5-486 ) et en l’intégrant au menu de démarrage.
[code]# cat /boot/grub/grub.cfg
if [ -s $prefix/grubenv ]; then
load_env
fi
set default=“0”
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 {
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
}
insmod part_msdos
insmod ext2
set root=’(hd0,msdos4)’
search --no-floppy --fs-uuid --set 7e406713-3ff4-44ca-846d-e997f022ccb9
if loadfont /usr/share/grub/unicode.pf2 ; then
set gfxmode=640x480
load_video
insmod gfxterm
fi
terminal_output gfxterm
insmod part_msdos
insmod ext2
set root=’(hd0,msdos4)’
search --no-floppy --fs-uuid --set 7e406713-3ff4-44ca-846d-e997f022ccb9
set locale_dir=($root)/boot/grub/locale
set lang=fr
insmod gettext
set timeout=10
insmod part_msdos
insmod ext2
set root=’(hd0,msdos4)’
search --no-floppy --fs-uuid --set 7e406713-3ff4-44ca-846d-e997f022ccb9
insmod png
if background_image /usr/share/images/desktop-base/spacefun-grub.png; then
set color_normal=light-gray/black
set color_highlight=white/black
else
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
fi
menuentry ‘Debian GNU/Linux, avec Linux 2.6.32-5-686’ --class debian --class gnu-linux --class gnu --class os {
insmod part_msdos
insmod ext2
set root=’(hd0,msdos4)’
search --no-floppy --fs-uuid --set 7e406713-3ff4-44ca-846d-e997f022ccb9
echo ‘Chargement de Linux 2.6.32-5-686 …’
linux /boot/vmlinuz-2.6.32-5-686 root=UUID=7e406713-3ff4-44ca-846d-e997f022ccb9 ro quiet
echo ‘Chargement du disque mémoire initial …’
initrd /boot/initrd.img-2.6.32-5-686
}
menuentry ‘Debian GNU/Linux, avec Linux 2.6.32-5-686 (mode de dépannage)’ --class debian --class gnu-linux --class gnu --class os {
insmod part_msdos
insmod ext2
set root=’(hd0,msdos4)’
search --no-floppy --fs-uuid --set 7e406713-3ff4-44ca-846d-e997f022ccb9
echo ‘Chargement de Linux 2.6.32-5-686 …’
linux /boot/vmlinuz-2.6.32-5-686 root=UUID=7e406713-3ff4-44ca-846d-e997f022ccb9 ro single
echo ‘Chargement du disque mémoire initial …’
initrd /boot/initrd.img-2.6.32-5-686
}
menuentry ‘Debian GNU/Linux, avec Linux 2.6.32-5-486’ --class debian --class gnu-linux --class gnu --class os {
insmod part_msdos
insmod ext2
set root=’(hd0,msdos4)’
search --no-floppy --fs-uuid --set 7e406713-3ff4-44ca-846d-e997f022ccb9
echo ‘Chargement de Linux 2.6.32-5-486 …’
linux /boot/vmlinuz-2.6.32-5-486 root=UUID=7e406713-3ff4-44ca-846d-e997f022ccb9 ro quiet
echo ‘Chargement du disque mémoire initial …’
initrd /boot/initrd.img-2.6.32-5-486
}
menuentry ‘Debian GNU/Linux, avec Linux 2.6.32-5-486 (mode de dépannage)’ --class debian --class gnu-linux --class gnu --class os {
insmod part_msdos
insmod ext2
set root=’(hd0,msdos4)’
search --no-floppy --fs-uuid --set 7e406713-3ff4-44ca-846d-e997f022ccb9
echo ‘Chargement de Linux 2.6.32-5-486 …’
linux /boot/vmlinuz-2.6.32-5-486 root=UUID=7e406713-3ff4-44ca-846d-e997f022ccb9 ro single
echo ‘Chargement du disque mémoire initial …’
initrd /boot/initrd.img-2.6.32-5-486
}
menuentry “Memory test (memtest86+)” {
insmod part_msdos
insmod ext2
set root=’(hd0,msdos4)’
search --no-floppy --fs-uuid --set 7e406713-3ff4-44ca-846d-e997f022ccb9
linux16 /boot/memtest86+.bin
}
menuentry “Memory test (memtest86+, serial console 115200)” {
insmod part_msdos
insmod ext2
set root=’(hd0,msdos4)’
search --no-floppy --fs-uuid --set 7e406713-3ff4-44ca-846d-e997f022ccb9
linux16 /boot/memtest86+.bin console=ttyS0,115200n8
}
menuentry “Memory test (memtest86+, experimental multiboot)” {
insmod part_msdos
insmod ext2
set root=’(hd0,msdos4)’
search --no-floppy --fs-uuid --set 7e406713-3ff4-44ca-846d-e997f022ccb9
multiboot /boot/memtest86+_multiboot.bin
}
menuentry “Memory test (memtest86+, serial console 115200, experimental multiboot)” {
insmod part_msdos
insmod ext2
set root=’(hd0,msdos4)’
search --no-floppy --fs-uuid --set 7e406713-3ff4-44ca-846d-e997f022ccb9
multiboot /boot/memtest86+_multiboot.bin console=ttyS0,115200n8
}
if [ -f $prefix/custom.cfg ]; then
source $prefix/custom.cfg;
fi
[/code]
le truc c’est que cette nouvelle entrée n’apparaît pas dans mon menu de démarrage malgré un ‘update-grub’ 
# update-grub
Generating grub.cfg ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-2.6.32-5-686
Found initrd image: /boot/initrd.img-2.6.32-5-686
Found linux image: /boot/vmlinuz-2.6.32-5-486
Found initrd image: /boot/initrd.img-2.6.32-5-486
Found memtest86+ image: /boot/memtest86+.bin
Found memtest86+ multiboot image: /boot/memtest86+_multiboot.bin
done
Rien d’anormal du côté des modules, depmod et modinfo.
Par contre, tu as écrit que tu avais une partition de boot séparée de 100 Mo en début de disque. Dans la sortie de fdisk on voit bien une partition /dev/sda3 amorçable de 100 Mo en début de disque, mais elle n’est pas mentionnée dans /etc/fstab, et donc, je suppose, pas montée sur /boot. D’autre part dans grub.conf tout fait référence à la 4e partition qui semble être la partition racine et non à une partition /boot séparée.
Je me demande donc si le grub et le noyau actifs ne seraient pas dans cette partition /dev/sda3 qui n’est pas référencée par ton système et donc pas mise à jour. Monte-là sur /mnt pour voir son contenu. Si c’est bien le cas, tu as deux options : soit réinstaller grub pour qu’il prenne en compte le /boot de la partition racine, soit remonter la partition /dev/sda3 en tant que /boot après y avoir transféré le contenu du répetoire /boot de la racine.
Ce qui pourrait confirmer que le grub, son grub.cfg et les noyaux disponibles qui sont utilisés au démarrage ne sont pas ceux qui se trouvent dans le répertoire /boot de la racine mais sur une autre partition, non montée.
Bon je crois que l’on est sur la bonne voie 
Montage de la partition /boot en tête de disque
# mount /dev/sda3 /mnt/boot
Visu du contenu
# ls -ilhs /mnt/boot
total 13M
18074 110K -rw-r--r-- 1 root root 109K 12 janv. 2011 config-2.6.32-5-686
4017 7,0K drwxr-xr-x 3 root root 7,0K 18 févr. 2012 grub
10046 8,2M -rw-r--r-- 1 root root 8,2M 19 févr. 2011 initrd.img-2.6.32-5-686
11 12K drwx------ 2 root root 12K 18 janv. 2011 lost+found
15 174K -rw-r--r-- 1 root root 173K 3 mai 2011 memtest86+.bin
17 176K -rw-r--r-- 1 root root 175K 3 mai 2011 memtest86+_multiboot.bin
18073 1,3M -rw-r--r-- 1 root root 1,3M 12 janv. 2011 System.map-2.6.32-5-686
10044 2,3M -rw-r--r-- 1 root root 2,2M 12 janv. 2011 vmlinuz-2.6.32-5-686
Donc en conclusion ça fait plus de deux ans que je fais des mises à jour de noyau et je suis toujours sur la version de 2011 ! 
Mon chargeur de démarrage pointe sur la partition /boot alors que les mises à jour se font dans le dossier /boot de la racine.
C’était logique.
Si tu recopies les fichiers /boot/2.6.32 et /boot/grub/grub.cfg de la racine sur la partition de boot (sans /boot/), et la remontes sur /boot dans /etc/fstab, tout devrait revenir dans l’ordre au redémarrage.
Comme un rayon de soleil perce les nuages, je file dehors pour en profiter et te laisse gérer.
Je regarde ça de suite.
Je te remercie pour ta patience… et tous les autres bien évidement !
Je repasse dès qu’il y a du nouveau
Keep in touch
dans /boot:
faire:
root@alpha30:/boot# grep VFAT config-3.8.5-20130514
root@alpha30:/boot#
A+
JB1
La discussion a montré que milediou utilise un noyau Debian précompilé qui inclut le module vfat et que la présence de ce module a déjà été établie par d’autres moyens (message d’erreur du noyau, lsmod…).
Par contre le silence de milediou m’inquiète un peu… J’espère que ma suggestion n’a pas cassé le démarrage du système.
Au passage, je recommande d’identifier la partition à monter sur /boot dans /etc/fstab par son UUID comme les autres partitions et non par son nom de périphérique /dev/sda3, qui est susceptible de varier. Par exemple il suffit qu’un clé USB ou un autre disque soit présent au démarrage et détecté avant le disque système, et paf, il devient sda à la place de sda. L’UUID peut être retrouvé avec la commande blkid, ou en regardant le nom du lien symbolique dans /etc/disk/by-uuid/ qui pointe vers /dev/sda3.
Et plutôt que de copier grub.cfg, je pense qu’il serait plus propre de le regénérer avec update-grub (ou grub-update, je ne sais jamais) une fois les fichiers des noyaux copiés et la partition remontée sur /boot.