Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
Pages : 1
Dernière modification par Nat (08-10-2023 14:06:25)
Hors ligne
Dernière modification par mksmn (16-09-2023 08:35:39)
Debian, c'est bien!
(De retour sous Debian, soyez cool.)
Hors ligne
- est ce un problème de me connecter sur un ancien noyau ? J'ai l'impression que ça fonctionne aussi bien qu'avant, mais peut être y a t il des problèmes de sécurité ou autre à continuer ainsi ?
Les mises à jour d'une même version correspondent souvent à des corrections de sécurité, ceci-dit, ce sont des failles qui le plus souvent n'ont d'impact que pour les serveurs ou si un individu mal intentionné a déjà accès à ton ordi. Donc dans ton cas, ça n'a probablement pas d'impact.
- qu'est ce qui est le mieux, de me connecter sur la version 22 du noyau (5.10.0-22-amd64) ou sur le recovery mode de la 23 (5.10.0-23-amd64) ?
Le recovery n'est pas fait pour une utilisation quotidienne, je te conseille donc plutôt la -22.
- Puis-je me faire aider pour résoudre le problème en l'exposant sur ce forum (et suis je au bon endroit) ? Je serais je crains obligée de partager une capture d'écran car je ne peux faire de copier coller en boot...je suis navrée de commencer par un tel outrage à ours blancs...
La section idéale pour ce genre de problème est la section Système. On y déplacera ton sujet.
Pas de problème bien sûr pour exposer ton problème, ça ne veut malheureusement pas dire que l'on réussira à le résoudre.
Pour récupérer les messages de boot du démarrage d'avant, tu peux faire
Cependant, ça ne fonctionne pas si journalctl n'a pas réussi à écrire le journal sur le disque. Auquel cas la photo et l'ourspolaireicide est la seule alternative à la re-saisie manuelle.
@mksmn: la version du noyau correspond à une version de bullseye
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
est ce un problème de me connecter sur un ancien noyau ?
Oui, c'est un problème de sécurité d'utiliser un noyau contenant des vulnérabilités. A moins d'avoir évalué l'impact de chaque faille sur son cas d'utilisation.
qu'est ce qui est le mieux, de me connecter sur la version 22 du noyau (5.10.0-22-amd64) ou sur le recovery mode de la 23 (5.10.0-23-amd64) ?
Ni l'un ni l'autre car ces deux noyaux sont obsolètes et vulnérables. Le dernier noyau pour bullseye est le -25 qui a été publié il y a presque un mois.
D'autre part tu as dû remarquer que les fonctionnalités du mode recovery étaient limitées (connexion en root seulement, pas d'interface graphique, parfois pas de réseau par défaut...)
M'étonnerait que le message du kernel panic soit enregistré dans les logs, donc photo obligatoire (mais pas besoin d'une résolution délirante).
Dernière modification par raleur (16-09-2023 13:01:13)
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Bonjour et bienvenue,
tu es sur quelle version de debian?
Merci 
!
Debian GNU/Linux 11 (bullseye)
Version de Gnome : 3.38.5
(j'espère que je réponds correctement à la question 
)
le kernel panic fait suite à une mise à jour?
Non. Ce qu'il s'est passé :
(NB: Il est possible que j'ai eu quelque peu auparavant des alertes quant à un espace disque faible sur boot, je ne me souviens plus)
1/ j'ai voulu installé un logiciel "Darktable" via l'interface graphique. Une notification me dit que celui-ci n'a pas été installé. Chose curieuse : je peux ouvrir et utiliser Darktable néanmoins.
2/ J'ai des alertes quant à un "espace disque faible sur boot"
3/ Je crois bien faire en faisant "la seule chose utile que je sais faire sur un terminal face à un problème et que je pense naïvement sans risque, à savoir : "sudo apt-get autoremove". Mon terminal me dit alors des choses curieuses, mais bon, je ne m'inquiète pas, je le sais prolixe (NB: j'ai retrouvé une capture d'écran du terminal ce jour là et je crois bien l'avoir prise à ce moment là, si ça peut aiguiller)
4/ J'éteins mon ordi normalement.
5/ Quand je le rallume, je suis face à un "Kernel panic - not syncing : VFS: Unable to mount root fs on unknown-block (0,0)"
6/ - Les versions du noyau avec lesquels je ne peux pas me connecter sont : Linux 5.10.0-25-amd64 ; Linux 5.10.0-24-amd64 ; Linux 5.10.0-23-amd64
- je peux me connecter avec : Linux 5.10.0-23-amd64 (recovery mode) et en Linux 5.10.0-22-amd64
tu as modifié qqchose au niveau matériel ou logiciel ?
matériel non, logiciel, comme je l'ai dit plus haut
Ah j'oubliais, je ne pense pas que ça importe mais je crois que j'ai ce jour là lamentablement ignoré un message m'invitant à faire des mises à jour et les ai repoussées à plus tard...
Vous en pensez quoi ??
De quelles informations avez-vous besoin pour savoir d'où vient le problème et comment le résoudre ? Est ce utile que j'envoie des captures d'écran ?
Merci merci merci
Dernière modification par Nat (02-10-2023 22:44:02)
Hors ligne
...
devrait le dire ...
{après, si t'as de la place, tu peux aussi installer ncdu et avec ncdu / tu auras la taille du boot (y'a surement un autre moyen
edit ; en fait, j'y pense, avec gnome, tu dois avoir un truc qui s'apelle analyseur de l'espace du disque (ou baobab je crois) qui devrait en graphique te renseigner, sinon du -h /boot devrait le dire aussi sans rien installer de plus...) }
Dernière modification par ubub (03-10-2023 01:14:29)
Hors ligne
Il est possible que j'ai eu quelque peu auparavant des alertes quant à un espace disque faible sur boot
Donc la cause la plus probable d'un kernel panic "VFS: Unable to mount root fs on unknown-block (0,0)" est qu'il n'y avait pas assez de place pour installer l'initramfs (/boot/initrd.img-<version>) du noyau nouvellement installé.
Solution : désinstaller un ancien noyau pour libérer de l'espace, générer l'initramfs manquant avec update-initramfs -u et mettre à jour le menu de GRUB avec update-grub.
Dernière modification par raleur (04-10-2023 15:57:25)
Il vaut mieux montrer que raconter.
Hors ligne
Un truc qui pourrait être utile, c'est de savoir ce que tu as auto-remove , c-à.d. supprimé de manière automatique... ouais, mauvaise croyance que cette commande est anodine
Pour cela, soit c'est écrit sur ta photo, sinon ça doit être possible de trouver l'info dans /var/log/history.log ou /var/log/term.log, si c'est pas encore archivé ...
Y a t il une commande alternative, car j'obtiens "Aucun fichier ou dossier de ce type".
le plus simple est encore de partager ma photo :
Est ce que ça vous parle / semble aller dans le sens de l'hypothèse de @raleur ?
en fait, j'y pense, avec gnome, tu dois avoir un truc qui s'apelle analyseur de l'espace du disque (ou baobab je crois) qui devrait en graphique te renseigner, sinon du -h /boot devrait le dire aussi sans rien installer de plus...) }
Oui, je l'ai regardé à plusieurs reprises mais ça ne me parle pas trop..est ce utile que je le partage ici ?
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Cette copie d'écran est incomplète, il manque le début et la fin.
Ah oui, je suis désolée, je ne l'ai prise que dans un sursaut de conscience, me disant que peut être quelque chose ne se passait pas comme prévu. Je pense bien que c'était suite à mon sudo apt-get autoremove . Je n'ai que ça.
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Suie également tentée de me garder un noyau de secours en plus (le 21), au cas où. J'aurai quand même assez de place pour installer les nouvelles images (24 et 25), non ?
Hors ligne
Espace disque faible sur "boot", le volume n'a lus que 9,7Mo d'espace disque disponible
Pourtant, si j'en suis ce que me montre l'analyseur d'espace de disque, il semble que j'ai gagné 73,1Mo en supprimant l'image .18 (la photo est-elle utile à partager ?)
Bon, je continue...
Hors ligne
ça vous parait cohérent jusque là ?
Hors ligne
Merci de vos retours !
Dernière modification par Nat (07-10-2023 19:09:12)
Hors ligne
Suie également tentée de me garder un noyau de secours en plus (le 21), au cas où. J'aurai quand même assez de place pour installer les nouvelles images (24 et 25), non ?
Mauvaise idée. La preuve par l'exemple. Pour les opérations transitoires nécessitant des fichiers temporaires, à tout moment il faut au minimum l'espace libre correspondant à un noyau (vmlinuz + initrd, soit ~80 Mo) de plus que le nombre de noyaux installés. Il fallait supprimer les trois plus anciens noyaux en même temps pour avoir une chance qu'il y ait suffisamment d'espace pour créer les deux initramfs manquants sans erreur.
C'est très curieux, on me promet 317Mo de libéré avant chaque suppression de noyau, et au final, je ne gagne que 5Mo
La plus grande partie d'un paquet linux-image (les modules) est dans /lib/modules, pas dans /boot. D'autre part l'initramfs est généré, il n'est pas comptabilisé dans la taille du paquet.
Actuellement tu devrais pouvoir démarrer avec les noyaux 23 et 24 dont les initramfs sont présents. Si ce n'est pas le cas, merci de décrire précisément ce qui se passe au démarrage.
Dernière modification par raleur (07-10-2023 19:36:08)
Il vaut mieux montrer que raconter.
Hors ligne
Mauvaise idée. La preuve par l'exemple. Pour les opérations transitoires nécessitant des fichiers temporaires, à tout moment il faut au minimum l'espace libre correspondant à un noyau (vmlinuz + initrd, soit ~80 Mo) de plus que le nombre de noyaux installés. Il fallait supprimer les trois plus anciens noyaux en même temps pour avoir une chance qu'il y ait suffisamment d'espace pour créer les deux initramfs manquants sans erreur
Mince, pardon. Je n'avais pas compris que ce devait être réalisé en une seule commande. Merci de me l'avoir expliqué.
Actuellement tu devrais pouvoir démarrer avec les noyaux 23 et 24 dont les initramfs sont présents. Si ce n'est pas le cas, merci de décrire précisément ce qui se passe au démarrage.
Oui. Je peux maintenant démarrer avec les noyaux 23 et 24.
Merci. C'est déjà ça. Que me conseilles tu / me conseillez vous de faire par la suite, pour le dernier noyau ?
Hors ligne
Dernière modification par raleur (08-10-2023 14:20:15)
Il vaut mieux montrer que raconter.
Hors ligne
. Et ça marche ! Et c'est cool! Merci.
Hors ligne
Pages : 1
