Vous n'êtes pas identifié(e).
Dernière modification par totoZero7 (02-08-2022 14:27:19)
Hors ligne
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
"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
Dernière modification par totoZero7 (22-06-2022 17:55:41)
Hors ligne
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
-->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
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
Dernière modification par totoZero7 (17-06-2022 02:24:55)
Hors ligne
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.
Est-ce qu'il y a une commande qui afficherait les kernels installés peut-être ?
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.
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
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):
Ensuite on met à jour le grub et on 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
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
Hors ligne
admettons que je 'marque' manuellement un kernel. Si je fais un autoremove ensuite. Le marquage reste à vie ?
Oui, tant que le paquet reste installé.
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
Avec cette autre commande, j'obtiens la précision sur ce qui est installé et ce qui ne l'est pas:
Mais par-contre, je n'ai pas de distinction clair sur si c'est marqué automatique ou manuel
Je dois utiliser 2 commandes distinctes
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
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
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é
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.
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.
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.
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.
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.
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.
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
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.
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
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.
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
Voici ce que j'ai marqué en manuel:
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.
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
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
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
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.
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.
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.
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
Hors ligne