logo Debian Debian Debian-France Debian-Facile Debian-fr.org Forum-Debian.fr Debian ? Communautés logo inclusivité

Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#1 15-06-2022 20:07:06

totoZero7
Membre
Distrib. : Debian 11.6 Bullseye
Noyau : 5.10.0-21-amd64
(G)UI : Mate 1.24.1
Inscription : 05-07-2020

[résolu] VirtualBox bug avec le Kernel 5.10.0-15

Titre initial: Vérifier l'état du processeur
Titre modifié: VirtualBox bug avec le Kernel 5.10.0-15


Bonjour,

Je rencontre des choses étranges sous virtualBox, sous 2 système différent (Linux Mint, LMDE):
- Les vidéos en local sautent pendant leur lecture, idem en streaming avec Firefox.
- En voulant installer une extension sur Firefox, Firefox saute.
- Des tremblements comme un brouillage d'écran, apparaissent dans le bas de l'écran.

N'ayant pas fait de gros changements sauf installer les nouveau header de Debian hier (apt-get dist-upgrade), je m’interroge si je n'aurais pas un problème matériel.
Est-il possible de voir l'état du CPU et de diagnostiquer un éventuel problème ?



Edit:
Le problème n'est pas matériel.
Cela est dû avec la mise à niveau du kernel 5.10.0-15-amd64
Solution provisoire: booter avec le kernel de la version antérieur et attendre les correctifs de VirtualBox. (cela devrait fonctionner avec la version 6.1.35r  6.1.36 de VirtualBox)
Pour cela: à l'allumage du PC, dans le grub, sélectionner "advanced options" puis séléctionner la ligne du kernel qui a le chiffre inférieur (version antérieur) j'ai mis celui là "5.10.0-14-amd64"

Edit 2

Cela refonctionne avec la mise à jour 6.1.36 de VirtualBox

Dernière modification par totoZero7 (02-08-2022 14:27:19)

Hors ligne

#2 15-06-2022 20:42:38

Tawal
Membre
Distrib. : Debian Stable à jour
Noyau : amd64
(G)UI : Xfce
Inscription : 25-02-2021

Re : [résolu] VirtualBox bug avec le Kernel 5.10.0-15

Hello,

Si le problème survient que dans VirtualBox, on peut bannir le souci matériel.

"saute" ? ça veut dire quoi ?

Des tremblements comme un brouillage d'écran, apparaissent dans le bas de l'écran

l'écran de quoi ? machine virtuelle ou hôte ?


Comme la science n'est pas infuse, elle se diffuse.
Useless Use of Cat Award
Filenames and Pathnames in Shell: How to do it Correctly
À chaque problème sa solution, à chaque solution son moyen, si pas de moyen, toujours le problème !

Hors ligne

#3 15-06-2022 23:07:52

totoZero7
Membre
Distrib. : Debian 11.6 Bullseye
Noyau : 5.10.0-21-amd64
(G)UI : Mate 1.24.1
Inscription : 05-07-2020

Re : [résolu] VirtualBox bug avec le Kernel 5.10.0-15

"saute" ? ça veut dire quoi ?

ça veut dire, Firefox crash et disparait.
C'est pareil pour le lecteur vidéo qui s'arrete de lui même et disparait.
J'ai aussi vu le Terminal disparaitre une fois.

l'écran de quoi ? machine virtuelle ou hôte ?

De la machine virtuelle. c'est pas facile de le voir car cela survient de temps à autre et c'est très bref. ça se joue sur la largeur de l'application qui est ouverte.
Si c'est une petite fenêtre avec le Terminal, ça sera de sa largeur, si c'est Firefox qui ouvert en grand, idem et ça prend toute la largeur dans ce cas.
J'ai vu aussi une accélération du problème en scrollant avec la souris

J'ai supprimé mon /home et le contenu des VM, ré-importé le tout d'une sauvegarde précédente mais le problème persiste.

Hors ligne

#4 16-06-2022 00:24:48

totoZero7
Membre
Distrib. : Debian 11.6 Bullseye
Noyau : 5.10.0-21-amd64
(G)UI : Mate 1.24.1
Inscription : 05-07-2020

Re : [résolu] VirtualBox bug avec le Kernel 5.10.0-15

Il semble que tu ais raison Tawal sur le fait que ce ne soit pas un problème matériel (post à déplacer du coup) mais un problème de Kernel.
J'ai trouvé ce post (en anglais) qui parle du même problème que moi.
https://forums.linuxmint.com/viewtopic. … 5&t=375667

Selon son auteur (si j'ai bien compris), ce serait le changement de noyau du système vers la version 5.10.120-1 qui en serait la cause des dysfonctionnements dans VirtualBox et c'est étrangement ce que j'ai modifié ces dernières 24h.
J'ai donc fait la même chose et j'ai les même symptômes.

Selon les log de Virtualbox, il n'y a pas eu de mise à jour depuis le 22 mars 2022. Donc je vais être bloqué si je ne modifie pas le kernel vers une version antérieur.
https://www.virtualbox.org/wiki/Changelog

Par-contre, je ne sais pas comment faire pour remettre le noyau d'avant, d'autant plus que j'ai effectué un apt autoremove.
Du coup je remanie ma question.
Comment mettre le kernel d'avant (je ne sais pas quelle version c'était) sans faire de dégâts ?

Dernière modification par totoZero7 (22-06-2022 17:55:41)

Hors ligne

#5 16-06-2022 08:02:52

raleur
Membre
Inscription : 03-10-2014

Re : [résolu] VirtualBox bug avec le Kernel 5.10.0-15

totoZero7 a écrit :

e ne sais pas comment faire pour remettre le noyau d'avant, d'autant plus que j'ai effectué un apt autoremove


En principe autoremove conserve le noyau précédent. Tous les noyaux installés sont disponibles dans le sous-menu "advanced options" de GRUB.
S'il a vraiment été désinstallé mais non purgé, il reste sa configuration dans /lib/modules. qui te donne la version. Cela devrait être 5.10.0-14-<archi>.

Dernière modification par raleur (16-06-2022 08:43:05)


Il vaut mieux montrer que raconter.

Hors ligne

#6 16-06-2022 11:21:54

Croutons
Membre
Distrib. : Debian12
Noyau : Linux 6.1.0-13-amd64
(G)UI : Fluxbox(NakeDeb)
Inscription : 16-12-2016

Re : [résolu] VirtualBox bug avec le Kernel 5.10.0-15

Hello
les addtions invités correspondant a ta version de virtualbox sont il installé sur ta machine Virtuel

-->les cahiers du debutant<--      WikiDF-->Découvrir les principales commandes Linux<-- 
L' expérience, c'est le nom que chacun donne à ses erreurs. Oscar Wilde

En ligne

#7 16-06-2022 21:45:10

totoZero7
Membre
Distrib. : Debian 11.6 Bullseye
Noyau : 5.10.0-21-amd64
(G)UI : Mate 1.24.1
Inscription : 05-07-2020

Re : [résolu] VirtualBox bug avec le Kernel 5.10.0-15

Qui, entre ces 2 suites de chiffres, est le kernel ?, dans la commande suivante:

uname -a

Linux debM 5.10.0-15-amd64 #1 SMP Debian 5.10.120-1 (2022-06-09) x86_64 GNU/Linux

5.10.0-15 ou 5.10.120-1 ?

Si je lis le "man uname", ça dit que mon 5.10.0-15 est la révision et 5.10.120-1 est le noyau
Mais si je vais sur le site https://wiki.debian.org/KernelFAQ ça donne la commande "uname -r" pour obtenir son noyau (qui est celui de la révision dans le man). Je suis perdu.
Ou sinon, c'est quoi la différence entre ces 2 suites de chiffres ?


Ensuite, je suis allé sur https://www.kernel.org/ afin de connaitre la version antérieur de mon noyau, mais je ne trouve même pas l'actuel et ne sais pas comment trouver par moi-même, la version antérieur.
Est-ce qu'il y a une commande qui afficherait les kernels installés peut-être ? ou un lien sur debian.org ? car je n'ai pas trouvé.


Dans le grub, il semble qu'il n'y ait que la version précédente, et pas celles d'encore avant. Ceci dit, ça me suffit. C'est juste une simple observation.
En revanche, cela pourrait être un problème si une nouvelle version de kernel arrivait alors que VirtualBox n'aurait toujours pas fait le correctif.

J'ai donc testé, je peux booter sur la version antérieur en un clic à partir du grub > option avancée, c'est facile. J'ai récupéré le comportement normal de mes machines virtuelles. Merci raleur.
Mais comment garder cette version antérieur du kernel, de manière permanente (si ce n'est pas trop compliqué) ? car je suis obligé de faire attention à chaque boot, et de sélectionner celui que je veux.


@Croutons
oui oui tout est bon de ce côté.

Dernière modification par totoZero7 (16-06-2022 21:46:12)

Hors ligne

#8 17-06-2022 02:09:54

totoZero7
Membre
Distrib. : Debian 11.6 Bullseye
Noyau : 5.10.0-21-amd64
(G)UI : Mate 1.24.1
Inscription : 05-07-2020

Re : [résolu] VirtualBox bug avec le Kernel 5.10.0-15

Apparemment le problème est constaté, depuis au moins le 6 juin 2022, sur le forum de virtualBox
https://forums.virtualbox.org/viewtopic … 7&t=106071

Selon le commentaire de "fth0" dans cet autre post, la nouvelle version 6.1.35r151864, qui est actuellement en test, devrait fonctionner avec le nouveau noyau.
Donc la solution provisoire est de mettre le kernel d'avant ou la version test de virtualbox (je ne sais pas comment ça fonctionne car c'est un .run) ou d'attendre la future version de virtualbox 6.1.35r....


hop, petit ajout
Il y a un ticket d'incident ouvert sur virtualbox
En bas de cette page, une note datant du 2022-06-14, donne 2 liens: 1 vers le (.run) pour le logiciel, et un autre en (.iso) pour les guest additions.


Je modifie le titre de mon post de "Vérifier l'état du processeur" pour "VirtualBox bug avec le Kernel 5.10.0-15"

Dernière modification par totoZero7 (17-06-2022 02:24:55)

Hors ligne

#9 17-06-2022 08:00:44

raleur
Membre
Inscription : 03-10-2014

Re : [résolu] VirtualBox bug avec le Kernel 5.10.0-15

totoZero7 a écrit :

5.10.0-15 ou 5.10.120-1 ?


5.10.0-15 est la version "apparente" du noyau, qui entre dans le nom des paquets Debian du noyau : linux-image-5.10.0-15-amd64... C'est aussi la version de l'ABI pour les modules.
5.10.120 est la version réelle des sources du noyau amont à partir desquelles le noyau est construit.
5.10.120-1 est la version des paquets Debian du noyau.

totoZero7 a écrit :

Est-ce qu'il y a une commande qui afficherait les kernels installés peut-être ?


dpkg -l linux-image-*



totoZero7 a écrit :

cela pourrait être un problème si une nouvelle version de kernel arrivait


Si tu ne fais pas d'autoremove, le noyau ne sera pas supprimé. Tu peux aussi le marquer comme installé manuellement avec apt-mark.

apt-mark manual linux-image-5.10.0-14-amd64



totoZero7 a écrit :

je peux booter sur la version antérieur en un clic à partir du grub > option avancée


Tu peux définir le noyau précédent par défaut dans /etc/default/grub. GRUB_DEFAULT="x>y" où "x" est le numéro d'ordre du sous-menu dans le menu principal et "y" est le numéro d'ordre du noyau dans le sous-menu, les deux à partir de 0.

Dernière modification par raleur (18-06-2022 08:23:43)


Il vaut mieux montrer que raconter.

Hors ligne

#10 18-06-2022 00:42:56

totoZero7
Membre
Distrib. : Debian 11.6 Bullseye
Noyau : 5.10.0-21-amd64
(G)UI : Mate 1.24.1
Inscription : 05-07-2020

Re : [résolu] VirtualBox bug avec le Kernel 5.10.0-15

raleur a écrit :

Tu peux définir le noyau précédent par défaut dans /etc/default/grub. GRUB_DEFAULT="x>y" où x est le numéro d'ordre du sous-menu dans le menu principale et y est le numéro d'ordre du noyau dans le sous-menu, les deux à partir de 0


Waaa comment je me suis pris la tête pour comprendre cette simple phrase. J'ai effectué au moins 10 reboot (avec une VM sinon je me serais suicidé) avant de capter, en m'aidant en plus de ce tuto sur ubuntu-fr.org

Du coup, je donne une explication remixée pour noob comme moi:

Booter sur le kernel d'avant, (de manière permanente):

nano /etc/default/grub

# '0' est la valeur par defaut
GRUB_DEFAULT=0

# Pour booter sur l'ancien kernel, mettre à la place
GRUB_DEFAULT="1>2"


Ensuite on met à jour le grub et on reboot:

update-grub

reboot


Explication sur les chiffres:
Le chiffre donne la position de la ligne à sélectionner dans la liste du menu (du grub).
    (0 = la première ligne, 1 = la deuxième ligne, 2 = la troisième ligne, etc.)

Premier menu, pour choisir le premier chiffre (qui est 1):
0 correspond à la ligne du  boot normal - (celui par défaut)
1 correspond à la ligne de "Advenced options" - (on choisit celui là)

Ensuite, on va dans le sous-menu (de "Advenced options"), pour choisir le deuxième chiffre (qui est 2 dans notre configue)
0 correspond au kernel actuel
1 correspond au kernel actuel (recovery mode)
2 correspond au kernel juste avant
3 correspond au kernel juste avant (recovery mode)

Donc premier menu (1) = "Advenced options"
et le sous-menu (2) = kernel juste avant



Opération réussi, je marque en résolu.
Merci raleur et la communauté


Sur cette sauvegarde ré-importé rapidement, je pense que je n'avais pas fait d'autoremove. Ceci s'explique sur le fait que je n'ai pas rencontré de problème dans cette manipulation.
- Mais du coup, faut-il, par précaution, éviter de faire des autoremove afin de laisser un kernel antérieur de libre en cas de malaise ?

Dernière modification par totoZero7 (22-06-2022 18:04:54)

Hors ligne

#11 18-06-2022 08:35:14

raleur
Membre
Inscription : 03-10-2014

Re : [résolu] VirtualBox bug avec le Kernel 5.10.0-15

totoZero7 a écrit :

faut-il, par précaution, éviter de faire des autoremove afin de laisser un kernel antérieur


Normalement cela ne devrait pas être nécessaire. puisque autoremove n'enlève pas le noyau précédent.
Habituellement, on démarre avec le dernier noyau installé N. Si on installe un noyau N+1, autoremove ne supprime pas le noyau N tant qu'on n'installe pas un noyau N+2. Par contre pour garder le noyau N après l'installation du noyau N+2, il faudra le marquer comme installé manuellement ou éviter de faire des autoremove.


Il vaut mieux montrer que raconter.

Hors ligne

#12 18-06-2022 23:27:50

totoZero7
Membre
Distrib. : Debian 11.6 Bullseye
Noyau : 5.10.0-21-amd64
(G)UI : Mate 1.24.1
Inscription : 05-07-2020

Re : [résolu] VirtualBox bug avec le Kernel 5.10.0-15

ça répond à mon interrogation. Même si je mets le nouveau qui aurait la grippe, je peux avoir au moins celui qui est juste avant. à la limite c'est amplement suffisant.

Mais comme je suis gourmand de savoir, admettons que je 'marque' manuellement un kernel. Si je fais un autoremove ensuite. Le marquage reste à vie ?
Dis autrement, si je veux 'démarquer' celui que j'ai marqué, pour faire du nettoyage. Comment m'y prendre ?

Hors ligne

#13 19-06-2022 19:35:52

raleur
Membre
Inscription : 03-10-2014

Re : [résolu] VirtualBox bug avec le Kernel 5.10.0-15

totoZero7 a écrit :

admettons que je 'marque' manuellement un kernel. Si je fais un autoremove ensuite. Le marquage reste à vie ?


Oui, tant que le paquet reste installé.

totoZero7 a écrit :

si je veux 'démarquer' celui que j'ai marqué, pour faire du nettoyage. Comment m'y prendre ?


Avec apt-mark auto. Mais tu peux aussi bien désinstaller directement le paquet plutôt que le marquer auto et faire un autoremove.

PS : en réalité, ce sont les paquets installés automatiquement qui sont marqués comme tels. Les paquets installés manuellement n'ont pas de marque. Donc marquer comme "manuel" consiste en fait à supprimer la marque "auto".

Dernière modification par raleur (19-06-2022 19:37:58)


Il vaut mieux montrer que raconter.

Hors ligne

#14 19-06-2022 23:04:28

totoZero7
Membre
Distrib. : Debian 11.6 Bullseye
Noyau : 5.10.0-21-amd64
(G)UI : Mate 1.24.1
Inscription : 05-07-2020

Re : [résolu] VirtualBox bug avec le Kernel 5.10.0-15

Au message #9, ta commande (dpkg -l linux-image-*) ne donne pas les paquets installés précisément. Je ne sais pas ce quelle donne exactement. Elle donne la liste complète des images installés et désinstallés, mais mélangé.


Dans une VM
J'obtiens tous ces paquets avec la commande

dpkg -l linux-image-*

Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder
| État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé/W=attend-traitement-déclenchements
|/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais)
||/ Nom                                  Version      Architecture Description
+++-====================================-============-============-=====================================
rc  linux-image-5.10.0-10-amd64          5.10.84-1    amd64        Linux 5.10 for 64-bit PCs (signed)
un  linux-image-5.10.0-10-amd64-unsigned <aucune>     <aucune>     (aucune description n'est disponible)
rc  linux-image-5.10.0-11-amd64          5.10.92-2    amd64        Linux 5.10 for 64-bit PCs (signed)
un  linux-image-5.10.0-11-amd64-unsigned <aucune>     <aucune>     (aucune description n'est disponible)
ii  linux-image-5.10.0-12-amd64          5.10.103-1   amd64        Linux 5.10 for 64-bit PCs (signed)
un  linux-image-5.10.0-12-amd64-unsigned <aucune>     <aucune>     (aucune description n'est disponible)
ii  linux-image-5.10.0-13-amd64          5.10.106-1   amd64        Linux 5.10 for 64-bit PCs (signed)
un  linux-image-5.10.0-13-amd64-unsigned <aucune>     <aucune>     (aucune description n'est disponible)
ii  linux-image-5.10.0-15-amd64          5.10.120-1   amd64        Linux 5.10 for 64-bit PCs (signed)
un  linux-image-5.10.0-15-amd64-unsigned <aucune>     <aucune>     (aucune description n'est disponible)
rc  linux-image-5.10.0-5-amd64           5.10.26-1    amd64        Linux 5.10 for 64-bit PCs (signed)
un  linux-image-5.10.0-5-amd64-unsigned  <aucune>     <aucune>     (aucune description n'est disponible)
rc  linux-image-5.10.0-7-amd64           5.10.40-1    amd64        Linux 5.10 for 64-bit PCs (signed)
un  linux-image-5.10.0-7-amd64-unsigned  <aucune>     <aucune>     (aucune description n'est disponible)
rc  linux-image-5.10.0-8-amd64           5.10.46-5    amd64        Linux 5.10 for 64-bit PCs (signed)
un  linux-image-5.10.0-8-amd64-unsigned  <aucune>     <aucune>     (aucune description n'est disponible)
rc  linux-image-5.10.0-9-amd64           5.10.70-1    amd64        Linux 5.10 for 64-bit PCs (signed)
un  linux-image-5.10.0-9-amd64-unsigned  <aucune>     <aucune>     (aucune description n'est disponible)
rc  linux-image-5.9.0-4-amd64            5.9.11-1     amd64        Linux 5.9 for 64-bit PCs (signed)
un  linux-image-5.9.0-4-amd64-unsigned   <aucune>     <aucune>     (aucune description n'est disponible)
ii  linux-image-amd64                    5.10.120-1   amd64        Linux for 64-bit PCs (meta-package)
un  linux-image-generic                  <aucune>     <aucune>     (aucune description n'est disponible)



Avec cette autre commande, j'obtiens la précision sur ce qui est installé et ce qui ne l'est pas:

dpkg --get-selections |grep linux-image-*

linux-image-5.10.0-10-amd64     deinstall
linux-image-5.10.0-11-amd64     deinstall
linux-image-5.10.0-12-amd64     install
linux-image-5.10.0-13-amd64     install
linux-image-5.10.0-15-amd64     install
linux-image-5.10.0-5-amd64      deinstall
linux-image-5.10.0-7-amd64      deinstall
linux-image-5.10.0-8-amd64      deinstall
linux-image-5.10.0-9-amd64      deinstall
linux-image-5.9.0-4-amd64     deinstall
linux-image-amd64       install



Mais par-contre, je n'ai pas de distinction clair sur si c'est marqué automatique ou manuel
Je dois utiliser 2 commandes distinctes

apt-mark showauto |grep linux-image-      # Liste les paquets (linux-image-*) installés marqués automatiquement
apt-mark showmanuel |grep linux-image-      # Liste les paquets (linux-image-*) installés marqués manuellement



Du coup, cela signifie quoi que l'on puisse voir tous ces paquets non installés (dpkg --get-selections |grep linux-image-*) ?
- que ces paquets sont tous présent mais désinstallés, donc que l'on peut les réinstaller à tout moment ? si oui comment ?
         j'ai une sous-question, si c'est le cas qu'ils soient présent, cela sert à quoi de les désinstaller alors que les paquets sont présent et peuvent être réinstallé, quel est l'intérêt ?
- c'est juste une information du passé de l'histoire de ce système ? et/ou de leur configuration qui restent, comme tu en fais mention au message #5 ?
En même temps, si la configuration reste (qui prend de la place je présume), c'est pour laisser la possibilité de réinstaller les paquets, donc les paquets doivent être présent, si on est logique.


Est-ce que c'est le fait d'avoir marqué le kernel manuellement qui a provoqué son apparition visible dans le sous-menu du grub ? (Du coup, marquer qqch, le rend visible...).
ou alors c'est autre chose, car il me semble ne pas l'avoir vu dans advenced options la première fois, et ensuite, après l'avoir marqué "manuellement", le voir apparaître dans le grub.


La concrètement, j'aimerais essayer de remettre le kernel linux-image-5.10.0-11-amd64 qui est affiché comme désinstallé. Comment dois-je m'y prendre ?

Hors ligne

#15 20-06-2022 06:40:07

smolski
quasi...modo
Lieu : AIN
Distrib. : backports (buster) 10
Noyau : Linux 4.19.0-8-amd64
(G)UI : gnome
Inscription : 21-10-2008

Re : [résolu] VirtualBox bug avec le Kernel 5.10.0-15

Un post privé peut peut-être t'aider :
https://debian-facile.org/utilisateurs: … rnel-linux

J'suis pas assez calé en la matière pour le faire dans le détail.

Force et courage ! big_smile

saque eud dun (patois chtimi : fonce dedans)

Hors ligne

#16 20-06-2022 08:15:45

raleur
Membre
Inscription : 03-10-2014

Re : [résolu] VirtualBox bug avec le Kernel 5.10.0-15

totoZero7 a écrit :

ta commande (dpkg -l linux-image-*) ne donne pas les paquets installés précisément. Je ne sais pas ce quelle donne exactement.


Elle rapporte la liste des paquets connus de dpkg, installés ou non, pas forcément installables. L'état de chaque paquet est indiqué par les 2 ou 3 caractères en début de ligne, dont la signification est décrite au dessus de la liste.
ii = installé
rc = désinstallé et encore configuré (purger pour déconfigurer)
un = non installé

totoZero7 a écrit :

je n'ai pas de distinction clair sur si c'est marqué automatique ou manuel


dpkg ne s'occupe pas de ça. C'est apt qui gère.

totoZero7 a écrit :

voir tous ces paquets non installés (dpkg --get-selections |grep linux-image-*) ?
- que ces paquets sont tous présent mais désinstallés


Oui, il sont indiqués "rc" par dpkg -l. Il n'en reste plus que l'état dans dpkg et les fichiers de configuration.

totoZero7 a écrit :

donc que l'on peut les réinstaller à tout moment ?


Pas forcément, car ils peuvent ne plus être disponibles dans les sources. dpkg ne connaît que l'état local des paquets, pas leur état dans les dépôts qui est du ressort d'apt.

totoZero7 a écrit :

c'est juste une information du passé de l'histoire de ce système ? et/ou de leur configuration qui restent


On peut dire ça.

totoZero7 a écrit :

si la configuration reste (qui prend de la place je présume), c'est pour laisser la possibilité de réinstaller les paquets


C'est surtout pour conserver la même configuration en cas de réinstallation du paquet.

smolski a écrit :

Est-ce que c'est le fait d'avoir marqué le kernel manuellement qui a provoqué son apparition visible dans le sous-menu du grub ?


Pas du tout, aucun rapport.

totoZero7 a écrit :

j'aimerais essayer de remettre le kernel linux-image-5.10.0-11-amd64 qui est affiché comme désinstallé.


Il faut vérifier s'il est encore présent dans le cache d'apt /var/cache/apt/archives/ ou disponible dans les sources d'apt avec apt-cache policy. Sinon il faudra aller le chercher sur snapshot.debian.org.
Pour quoi faire ?


Il vaut mieux montrer que raconter.

Hors ligne

#17 20-06-2022 10:05:41

totoZero7
Membre
Distrib. : Debian 11.6 Bullseye
Noyau : 5.10.0-21-amd64
(G)UI : Mate 1.24.1
Inscription : 05-07-2020

Re : [résolu] VirtualBox bug avec le Kernel 5.10.0-15

Ah c'est là qu'ils sont cachés les paquets désinstallés.
Je viens d'aller y jeter un oeil et tous les paquets linux-images-* sont là ! C'est étrange car je fais très souvent des apt autoremove, à chaque fois que j'ai un message qui me suggère de le faire (généralement après avoir effectué un apt-get dist-upgrade de mémoire).
Qu'est-ce que je n'ai pas compris avec autoremove ? je pensais qu'il supprimait les paquets désinstallés automatiquement.
Pourquoi les paquets linux-images et linux-header sont encore là ?


totoZero7 a écrit :
    j'aimerais essayer de remettre le kernel linux-image-5.10.0-11-amd64 qui est affiché comme désinstallé.

- Pour quoi faire ?



En fait, c'est juste pour faire un test afin de comprendre le principe de réinstaller un paquet désinstallé, qui est caché dans la machine (dans var de ce que je découvre), histoire de savoir le faire tout court. Ça aurait pu être un tout autre paquet, c'est juste que ça tombe sur lui aujourd'hui vu que la discussion tourne dessus.

Donc, tous les .deb dans le var/cache... sont des paquets d'installations ok.
Je viens de tester une installation et ça fonctionne, c'est trop magique.

sudo dpkg -i /var/cache/apt/archives/linux-image-5.10.0-11-amd64_5.10.92-2_amd64.deb


Du coup, mon expérience est effectuée.

Disons que à travers cette expérience", j'essaye de comprendre un peu plus le fonctionnement de la machine et c'est vraiment pas facile de chercher par soi-même car la plupart du temps c'est un langage et une structure pour initié, limite incompréhensible (comme le lien de ssmolski), pour les noobs comme moi, quand, pire, ce ne n'est pas en anglais ! Du coup, "je montre" comme dit le dicton XD.

Hors ligne

#18 20-06-2022 12:15:37

raleur
Membre
Inscription : 03-10-2014

Re : [résolu] VirtualBox bug avec le Kernel 5.10.0-15

totoZero7 a écrit :

Ah c'est là qu'ils sont cachés les paquets désinstallés.


Tu parles de /var/cache/apt/archives/ ? C'est le cache des paquets téléchargés par apt, rien à voir avec les paquets désinstallés.

totoZero7 a écrit :

tous les paquets linux-images-* sont là ! C'est étrange car je fais très souvent des apt autoremove


apt autoremove désinstalle les paquets marqués installés automatiquement devenus inutiles, aucun rapport avec le cache des paquets téléchargés. C'est apt clean ou autoclean qui efface le cache de paquets.


Il vaut mieux montrer que raconter.

Hors ligne

#19 01-08-2022 12:45:32

totoZero7
Membre
Distrib. : Debian 11.6 Bullseye
Noyau : 5.10.0-21-amd64
(G)UI : Mate 1.24.1
Inscription : 05-07-2020

Re : [résolu] VirtualBox bug avec le Kernel 5.10.0-15

Quand je fais un "apt-get upgrade", cela me propose de faire un apt autoremove sur une image qui est marquée en manuel.
Je pensais que les images marquées manuellement n'étaient pas touchées par autoremove

sudo apt-get upgrade

Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
Lecture des informations d'état... Fait      
Calcul de la mise à jour... Fait
Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires :
  linux-headers-5.10.0-14-amd64 linux-headers-5.10.0-14-common
Veuillez utiliser « sudo apt autoremove » pour les supprimer.



Voici ce que j'ai marqué en manuel:

apt-mark showmanual |grep linux-image-

linux-image-5.10.0-14-amd64
linux-image-5.10.0-15-amd64
linux-image-amd64



Autre chose, j'avais marqué en manuel l'image 13 et elle n'y figure pas. Il semble qu'elle est disparue de l'affichage après un autoremove.
J'ai une trace du marquage en manuel (dans mon historique de commandes) et d'un autoremove par la suite.


Idem sur mon SSD cloné qui a quelques différences avec mon SSD principale, car j'ai pas tout fait de la même manière.

SSD@cloné:/# apt-mark showauto |grep linux-image-

linux-image-5.10.0-11-amd64
linux-image-5.10.0-15-amd64


SSD@cloné:/# apt-mark showmanual |grep linux-image-

linux-image-5.10.0-13-amd64
linux-image-5.10.0-14-amd64
linux-image-amd64


SSD@cloné:/# apt-get upgrade

Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
Lecture des informations d'état... Fait      
Calcul de la mise à jour... Fait
Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires :
  linux-headers-5.10.0-11-amd64 linux-headers-5.10.0-11-common linux-headers-5.10.0-13-amd64
  linux-headers-5.10.0-13-common linux-image-5.10.0-11-amd64
Veuillez utiliser « sudo apt autoremove » pour les supprimer.
Les paquets suivants ont été conservés :
  linux-headers-amd64 linux-image-amd64




Est-ce que j'ai mal compris quelque-chose sur le marquage manuel ou est-ce qu'il y a autre chose à faire pour ne pas que autoremove touche les noyaux choisis en manuel ?

Hors ligne

#20 01-08-2022 14:28:42

raleur
Membre
Inscription : 03-10-2014

Re : [résolu] VirtualBox bug avec le Kernel 5.10.0-15

Je ne vois aucune incohérence. Les paquets marqués en manuel sont linux-image-* alors que les paquets proposés à la suppression automatique sont linux-headers-*.

Il vaut mieux montrer que raconter.

Hors ligne

#21 01-08-2022 17:38:28

totoZero7
Membre
Distrib. : Debian 11.6 Bullseye
Noyau : 5.10.0-21-amd64
(G)UI : Mate 1.24.1
Inscription : 05-07-2020

Re : [résolu] VirtualBox bug avec le Kernel 5.10.0-15

Comment je me casse les dents avec ce topic.

Quelle est la différence entre linux-image et linux-headers ?
Le fait de supprimer un linux-header-X, impact-il un linux-image-X ?

Hors ligne

#22 01-08-2022 19:18:25

raleur
Membre
Inscription : 03-10-2014

Re : [résolu] VirtualBox bug avec le Kernel 5.10.0-15

linux-image contient le noyau compilé. linux-headers contient les en-têtes du noyau, une partie des sources du noyau nécessaires à la compilation de modules externes comme ceux de virtualbox pour cette version spécifique du noyau.
Supprimer linux-headers n'impacte pas directement linux-image mais seulement la capacité de compiler un module externe pour cette version du noyau.

Il vaut mieux montrer que raconter.

Hors ligne

#23 02-08-2022 16:05:04

totoZero7
Membre
Distrib. : Debian 11.6 Bullseye
Noyau : 5.10.0-21-amd64
(G)UI : Mate 1.24.1
Inscription : 05-07-2020

Re : [résolu] VirtualBox bug avec le Kernel 5.10.0-15

raleur a écrit :

Supprimer linux-headers n'impacte pas directement linux-image mais seulement la capacité de compiler un module externe pour cette version du noyau


Je ne comprends pas vraiment ce que cela veut dire et implique (compiler, module externe...), c'est déjà le niveau au dessus pour moi.
Mais de ce que j’interprète, le fait de supprimer un header x (qui correspondrait à version du header x ou tout cela s'imbrique ? ) pourrait avoir un impacte sur quelques chose d'autre comme virutalbox.

Donc, la question que je me pose c'est:
Est-ce qu'il est préférable, par précaution, si je décide de garder un linux-image-x de ne pas supprimer le linux-header-x du même chiffre, et est-ce que le marquer en manuel de la même manière suffit ? car j'ai observé qu'il y avait 2 headers.

linux-headers-5.10.0-8-common
linux-headers-5.10.0-8-amd64

Je viens de faire un test, en marquant le "linux-headers-5.10.0-8-amd64" seulement en manuel,  et le "linux-headers-5.10.0-8-common" n’apparaît plus ensuite dans la proposition de désinstallation quand je fait un apt-get upgrade.

Hors ligne

#24 02-08-2022 19:02:46

raleur
Membre
Inscription : 03-10-2014

Re : [résolu] VirtualBox bug avec le Kernel 5.10.0-15

totoZero7 a écrit :

Je ne comprends pas vraiment ce que cela veut dire et implique (compiler, module externe...)


"Compiler" consiste à transformer le code source d'un programme (texte écrit et lisible par les humains) en code binaire exécutable par le processeur.
Le noyau et la plupart des programmes sont compilés. On les appelle des binaires exécutables. A l'opposé, les scripts sont des programmes écrits dans un langage qui est exécuté par un interpréteur (le shell bash, perl, python...) et non directement le processeur.

Un paquet linux-image-$version est le résultat de la compilation des sources du noyau contenues dans le paquet linux-source-$version. Il se compose principalement de binaires qui sont l'image du noyau /boot/vmlinuz qui est la partie principale lancée par le chargeur d'amorçage, et de modules /lib/modules/$version/... assurant diverses fonctions (pilotes, systèmes de fichiers...) qui sont chargés à la demande.

totoZero7 a écrit :

Mais de ce que j’interprète, le fait de supprimer un header x (qui correspondrait à version du header x ou tout cela s'imbrique ? ) pourrait avoir un impacte sur quelques chose d'autre comme virutalbox.


En effet. Virtualbox a besoin de modules du noyau qui ne sont pas inclus dans le paquet linux-image mais fournis sous forme de code source qu'il faut compiler pour chaque version particulière du noyau. C'est pour cela qu'ils sont appelés modules externes. Pour pouvoir faire l'interface avec une version particulière du noyau, le compilateur a besoin de définitions contenues dans les en-têtes de cette version du noyau, fournis par le paquet linux-headers-$version.

totoZero7 a écrit :

Est-ce qu'il est préférable, par précaution, si je décide de garder un linux-image-x de ne pas supprimer le linux-header-x du même chiffre, et est-ce que le marquer en manuel de la même manière suffit ?


Oui.

totoZero7 a écrit :

en marquant le "linux-headers-5.10.0-8-amd64" seulement en manuel,  et le "linux-headers-5.10.0-8-common" n’apparaît plus ensuite dans la proposition de désinstallation


Normal puisque linux-headers-5.10.0-8-amd64 dépend de linux-headers-5.10.0-8-common. Le premier contient les en-têtes spécifiques à la variante amd64 alors que le second contient les en-têtes communs à toutes les variantes.


Il vaut mieux montrer que raconter.

Hors ligne

#25 02-08-2022 20:37:46

totoZero7
Membre
Distrib. : Debian 11.6 Bullseye
Noyau : 5.10.0-21-amd64
(G)UI : Mate 1.24.1
Inscription : 05-07-2020

Re : [résolu] VirtualBox bug avec le Kernel 5.10.0-15

Question probablement pourrie

Si j'utilise le noyau linux version 16 avec le paquet headers version 16 mais que VirtualBox ait besoin des modules du headers de la version 14 pour fonctionner correctement, et que ce headers version 14 est installé et marqué sur mon pc. Est-ce que VirtualBox utilisera ce headers version 14 avec le noyau 16 ?
Ou est-ce que chaque headers n'est compatible qu'avec leur même version de noyau ?

Dit autrement, est-ce qu'on peut cumuler différentes versions headers avec un seul noyau ?

Hors ligne

Pied de page des forums