# Forcer l'installation d'un noyau Linux **URL:** \ **Category:** Support Debian\ **Created:** [Novembre 10, 2026, 4:02 UTC](https://www.debian-fr.org/t/forcer-linstallation-dun-noyau-linux/93103 "2026-11-10T16:02:32Z")\ **Posts on this page:** 17\ **Page:** 2
**Author:** ![josephtux](https://www.debian-fr.org/user_avatar/www.debian-fr.org/josephtux/32/3985_2.png) [@josephtux](https://www.debian-fr.org/u/josephtux)\ **Post date:** [Novembre 11, 2026, 11:21 UTC](https://www.debian-fr.org/t/forcer-linstallation-dun-noyau-linux/93103/21 "2026-11-11T11:21:35Z")
Merci à tous, donc, puisque l’installation ne se comporte pas comme attendu, la meilleure (la seule?) solution est une réinstallation, après sauvegarde complète des données. Voici les données de apt policy: ```auto ~$sudo apt policy linux-image-amd64 linux-image-amd64: Installé : 6.12.116-1 Candidat : 6.12.116-1 Table de version : 7.2.12-1~bpo13+1 100 100 http://deb.debian.org/debian` trixie-backports/main amd64 Packages *** 6.12.116-1 500 500 http://security.debian.org/debian-security trixie-security/main amd64 Packages 100 /var/lib/dpkg/status 6.12.107-1 500 500 http://deb.debian.org/debian trixie/main amd64 Packages ~$sudo apt policy linux-headers-amd64 linux-headers-amd64: Installé : 6.12.116-1 Candidat : 6.12.116-1 Table de version : 7.2.12-1~bpo13+1 100 100 http://deb.debian.org/debian trixie-backports/main amd64 Packages *** 6.12.116-1 500 500 http://security.debian.org/debian-security trixie-security/main amd64 Packages 100 /var/lib/dpkg/status 6.12.107-1 500 500 http://deb.debian.org/debian trixie/main amd64 Packages ``` ```auto ``` Est-ce que _systemd-boot_ que recommande Zargos à la place de _Grub_ est une option de l’installeur? comme vous l’avez tous remarqué, il n’est pas recommandé que je sorte de la facilité, de la norme, de la sécurité de base. Je précise que mon installation comporte 2 SSD en dual-boot, dont l’un est encore sous Bookworm (en secours, avant d’être mis à niveau un de ces jours…) ---
**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\ **Post date:** [Novembre 11, 2026, 12:05 UTC](https://www.debian-fr.org/t/forcer-linstallation-dun-noyau-linux/93103/22 "2026-11-11T12:05:49Z")
> [@josephtux](#): > > Je pensais que timeshift permettait justement de rétablir le système qui fonctionnait avant la panne. Oui c’est le cas, si tu as effectué des modifications qui provoque un souci important il est plus utile de revenir en arrière avec Timesshift. > [@Zargos](#): > > ce n’est pas comme ça que ça marche. ta sauvegarde remplace tout le système ou une partie des données. mais coté applicatif soit tu maîtrises tout les fichiers applicatifs nécessaire avec les version nécessaire; on sait que ce n’est pas le cas; soit tu remplaces tout le système. D’où l’intérêt avec ce type de système de sauvegarde d’avoir un claire séparation entre le système et les données. C’est le cas de l’outil Timeshift lorsque l’on se contente comme je l’avais précisé à l’époque de ne prendre ne charge que le système te pas les points de montages ou la partition home. > [@josephtux](#): > > Oui, merci Zargos. Comme je ne maitrise pas, je remplace tout le système et la partition utilisateur minimale (avec les réglages, mais sans les données de travail) et la partition /usr/local/ Donc on n’est bon … > [@dindoun](#): > > tu as un système maintenant impossible à dépanner à distance Qu’est-ce qui te fait dire ça ? > [@josephtux](#): > > donc, puisque l’installation ne se comporte pas comme attendu, la meilleure (la seule?) solution est une réinstallation, après sauvegarde complète des données. C’est à dire ? > [@josephtux](#): > > Est-ce que _systemd-boot_ que recommande Zargos à la place de _Grub_ Surtout pas, reste sur ce que propose Debian de base à moins de réellement en avoir besoin ET maîtrisé une autre techno. > [@josephtux](#): > > le menu qui apparaît est étrangement très différent (après avoir fait un grub update): > > ![IMG_20261110_195141_DRO](https://www.debian-fr.org/uploads/default/original/2X/e/e584e2bb09cf8a153c17d34095ae0abeb031b8d9.jpeg) > > On n’y trouve pas le noyau 6.12.116, et on trouve 6.12.43 désinstallé, > > `$sudo apt search 6.12.43` > `linux-image-6.12.43+deb13-amd64/now 6.12.43-1 amd64 [configuration restante]` > `(none)` > > et 6.12.94 également absent: > > ```bash > $sudo apt search 6.12.9 | egrep 9[45] | egrep -i install > > WARNING: apt does not have a stable CLI interface. Use with caution in scripts. > > linux-image-6.12.95+deb13-rt-amd64/stable-security,now 6.12.95-1 amd64 [installé] > > ``` Si tu as effectué une restauration après coup tes modifications peuvent avoir été annulé, mais vue que tu as deux disque (donc à priori deux possible amorçage et aucune garantie que lors d’une dédinstallation/réinstallation les deux amorçage soit synchronisés … Donc pour commencer que renvoi et pour savoir si tu est en legacy ou en uefi : ```auto ls /sys/firmware/efi ``` Après on regardera si tes deux amorçage sont synchro ce que je doute si je me rappelle comment tu as voulu installé ton systèmes sur les deux disques. ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Novembre 11, 2026, 12:13 UTC](https://www.debian-fr.org/t/forcer-linstallation-dun-noyau-linux/93103/23 "2026-11-11T12:13:51Z")
> [@Clochette](#): > > > [@josephtux](#): > > > > Est-ce que _systemd-boot_ que recommande Zargos à la place de _Grub_ > > Surtout pas, reste sur ce que propose Debian de base à moins de réellement en avoir besoin ET maîtrisé une autre techno. Systemd-boot est proposé par l’installateur Debian 13 Trixie. ---
**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\ **Post date:** [Novembre 11, 2026, 12:33 UTC](https://www.debian-fr.org/t/forcer-linstallation-dun-noyau-linux/93103/24 "2026-11-11T12:33:23Z")
> [@Zargos](#): > > Systemd-boot est proposé par l’installateur Debian 13 Trixie. Proposé, pas par défaut, et il reste bien plus complexe à configuré pour ajouter des systèmes et la partie secure boot et de toute façon impose uefi exclusivement. ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Novembre 11, 2026, 12:41 UTC](https://www.debian-fr.org/t/forcer-linstallation-dun-noyau-linux/93103/25 "2026-11-11T12:41:15Z")
> [@Clochette](#): > > la partie secure boot et de toute façon impose uefi exclusivement. Oui c’est conçu exclusivement pour ça. L’objectif étant de sécuriser le lancement du système, ce que Grub ne pourra jamais faire correctement. Effectivement en Bios Legacy, on peut oublier toute forme de sécurisation efficace avec GRUB. Cela étant systemd-boot fonctionne sans l’activation de Secure Boot. Et avoir Secure Boot et ne pas s’en servir c’est plutot dommage. Quand à l’ajout d’un autre OS c’est plutôt assez simple en fait, il s’agit d’ajouter un fichier de conf dans /boot/efi/loader/entries qui sont quasiment toujours de la même forme. ---
**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\ **Post date:** [Novembre 11, 2026, 1:29 UTC](https://www.debian-fr.org/t/forcer-linstallation-dun-noyau-linux/93103/26 "2026-11-11T13:29:45Z")
> [@Zargos](#): > > Effectivement en Bios Legacy, on peut oublier toute forme de sécurisation efficace avec GRUB. > Cela étant systemd-boot fonctionne sans l’activation de Secure Boot. > Et avoir Secure Boot et ne pas s’en servir c’est plutot dommage. > > Quand à l’ajout d’un autre OS c’est plutôt assez simple en fait, il s’agit d’ajouter un fichier de conf dans /boot/efi/loader/entries qui sont quasiment toujours de la même forme. Ok t’as raison c’est ultra simple et ultra facile du coup t’expliquera à josephtux. maintenant on se recentre sur le support, si tu veux converser sur systemd-boot ouvre un fgil dans pause café 😉 ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Novembre 11, 2026, 1:52 UTC](https://www.debian-fr.org/t/forcer-linstallation-dun-noyau-linux/93103/27 "2026-11-11T13:52:21Z")
Je n’ai fait que te répondre. 😉 Pour @josephtux , soit il supprime tous les noyaux qui posent probl-èmes avec un `apt --purge autoremove`, car `apt autoremove` n’enlève pas tout. Il marque le paquet mais n’enlève pas les fichiers. Et pour enlever, il faut utiliser apt purge . Purger les noyaux devraient relancer la mise à jour des initramfs automatiquement. Par contre le menu grub n’est pas certains d’être à jour. Un `update-grub` est donc nécessaire. Une fois la situation stable, il peut alors faire une mise à jour. Si linux-image-amd64 n’est pas installé, il faut alors l’installer. Ça permet la mise à jour des noyaux. Car si un noyau est taggué en manuel il me semble qu’il ne peut pas être mis à jour sauf par dépendance. Fait tes sauvegardes de données et des configurations critiques (base de données si tu en as, configuration apaches, etc…) Donc si on repart de sa liste, en ayant démarré sur un noyau qui n’est **pas** en **rt** : ```auto apt purge linux-headers-amd64 apt purge linux-image-amd64 apt purge linux-image--rt-amd64 ``` Pour toutes les versions rt. Une fois que c’est fait, `update-grub` puis redémarrer. Une fois démarré, faire ```auto apt update apt install linux-image-amd64 apt install linux-headers-amd64 apt upgrade ``` Ca devrait avoir tout remis en place. ---
**Author:** ![josephtux](https://www.debian-fr.org/user_avatar/www.debian-fr.org/josephtux/32/3985_2.png) [@josephtux](https://www.debian-fr.org/u/josephtux)\ **Post date:** [Novembre 12, 2026, 9:57 UTC](https://www.debian-fr.org/t/forcer-linstallation-dun-noyau-linux/93103/28 "2026-11-12T09:57:24Z")
Encore merci Zargos, j’espère pouvoir démarrer sur un noyau non «rt», et suivre alors votre indication Auparavant, une question: > [@Zargos](#): > > Car si un noyau est taggué en manuel il me semble qu’il ne peut pas être mis à jour N’est-il pas possible de supprimer ce «tag en manuel» , si c’est la cause du problème? ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Novembre 12, 2026, 10:19 UTC](https://www.debian-fr.org/t/forcer-linstallation-dun-noyau-linux/93103/29 "2026-11-12T10:19:36Z")
Si le linux-image-amd64 est correctement installé tu n’auras pas le problème normalement. ---
**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\ **Post date:** [Novembre 12, 2026, 10:39 UTC](https://www.debian-fr.org/t/forcer-linstallation-dun-noyau-linux/93103/30 "2026-11-12T10:39:18Z")
Par curiosité le paquet suivant est-il installé **linux-image-rt-amd64**? Normalement non au vue des noyau présent et non à jour. ---
**Author:** ![josephtux](https://www.debian-fr.org/user_avatar/www.debian-fr.org/josephtux/32/3985_2.png) [@josephtux](https://www.debian-fr.org/u/josephtux)\ **Post date:** [Novembre 12, 2026, 7:56 UTC](https://www.debian-fr.org/t/forcer-linstallation-dun-noyau-linux/93103/31 "2026-11-12T19:56:10Z")
```auto $sudo apt search !$ sudo apt search linux-image-rt-amd64 linux-image-rt-amd64/stable-security 6.12.116-1 amd64 [configuration restante] Linux pour les ordinateurs 64 bits (métapaquet) linux-image-rt-amd64-dbg/stable-security 6.12.116-1 amd64 symboles de débogage pour la configuration Linux rt-amd64 – métapaquet ``` Il semble que non, mais avec une configuration restante ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Novembre 12, 2026, 8:36 UTC](https://www.debian-fr.org/t/forcer-linstallation-dun-noyau-linux/93103/32 "2026-11-12T20:36:45Z")
As-tu bien fait apt purge et non apt remove? Il faut faire apt purge de ces deux paquets et bien regarder s’il y a des erreurs. Et idem pour l’autoremove, il faut faire apt **–purge** autoremove ---
**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\ **Post date:** [Novembre 12, 2026, 9:17 UTC](https://www.debian-fr.org/t/forcer-linstallation-dun-noyau-linux/93103/33 "2026-11-12T21:17:16Z")
> [@josephtux](#): > > Il semble que non, mais avec une configuration restante Pour le savoir je te rapelle que le mieux est la commande policy 😉 ```auto apt policy linux-image-rt-amd64 ``` ---
**Author:** ![grandtoubab](https://www.debian-fr.org/user_avatar/www.debian-fr.org/grandtoubab/32/4505_2.png) [@grandtoubab](https://www.debian-fr.org/u/grandtoubab)\ **Post date:** [Novembre 13, 2026, 7:39 UTC](https://www.debian-fr.org/t/forcer-linstallation-dun-noyau-linux/93103/34 "2026-11-13T07:39:51Z")
Savoir si un paquet est connu de tes sources: apt list | grep linux-image-rt-amd64 linux-image-rt-amd64-dbg/unstable 7.3.4-1 amd64 linux-image-rt-amd64/unstable 7.3.4-1 amd64 Savoir si un paquet est installé: apt list --installed | grep linux-image-rt-amd64 Quand il n’est pas installé, il n’y a pas de retour. Cas d’un paquet installé :apt list --installed | grep linux-image-amd64 linux-image-amd64/unstable,now 7.3.4-1 amd64 [installé] ---
**Author:** ![josephtux](https://www.debian-fr.org/user_avatar/www.debian-fr.org/josephtux/32/3985_2.png) [@josephtux](https://www.debian-fr.org/u/josephtux)\ **Post date:** [Novembre 13, 2026, 10:16 UTC](https://www.debian-fr.org/t/forcer-linstallation-dun-noyau-linux/93103/35 "2026-11-13T10:16:39Z")
> [@Clochette](#): > > `apt policy linux-image-rt-amd64` $sudo apt policy linux-image-rt-amd64 linux-image-rt-amd64: Installé : (aucun) Candidat : 6.12.116-1 Table de version : 7.2.12-1~bpo13+1 100 100 [Index of /debian](http://deb.debian.org/debian) trixie-backports/main amd64 Packages 6.12.116-1 500 500 [Index of /debian-security](http://security.debian.org/debian-security) trixie-security/main amd64 Packages 6.12.113-1 -1 100 /var/lib/dpkg/status 6.12.107-1 500 500 [Index of /debian](http://deb.debian.org/debian) trixie/main amd64 Packages Merci Clochette ---
**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\ **Post date:** [Novembre 13, 2026, 10:50 UTC](https://www.debian-fr.org/t/forcer-linstallation-dun-noyau-linux/93103/36 "2026-11-13T10:50:21Z")
Donc aucun risque qu’un noyau rt soit mis à jour, ce qui confirme l’installation à un moment donnée manuelle. Tu peux donc installé le paquet linux-image-amd64 (attention pas la rt), ce qui peux amener à l’installation d’un noyau à jour (tout dépendra de où tu en es au niveau des noyau installé). Si pas d’installation de nouveau noyau alors il sera temps de procéder à un redémarrage afin de t’assurer de ne plus utiliser un noyau à supprimer et de supprimer ce qui doit l’être. ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Novembre 13, 2026, 3:29 UTC](https://www.debian-fr.org/t/forcer-linstallation-dun-noyau-linux/93103/37 "2026-11-13T15:29:24Z")
> [@grandtoubab](#): > > apt list --installed | grep linux-image-rt-amd64 > > Quand il n’est pas installé, il n’y a pas de retour. Mais si ton paquet a été simplement remove, il est donc non installé, mais les fichiers sont toujours là. n’oubliez pas non plus que les paquets linux-kbuild et linux-base peuvent être des freins en cas de gloubiboulga de ce type. [Page précédente](https://www.debian-fr.org/t/forcer-linstallation-dun-noyau-linux/93103.md?page=1)