Bonjour,
J'ai démarré mon fixe ce matin, comme d'habitude.
Or, que je démarre avec le noyau 5.10.16-1-default ou 5.10.14-1-default ou en mode recovery pour les deux noyaux considérés, j'ai Tumbleweed qui s'affiche (jusque là c'est OK), puis, au bout d'un certain temps (env. 1 mn) j'ai ce message :
You are un emergency mode. After logging in, type "journactl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" or "exit" to boot into default mode.
Donnez le mot de passe du superutilisateur pour la maintenance 'ou appuyez sur Ctrl et D pour continuer) :
- Ctrl D ne donne rien. L'ordinateur tourne en rond et reste sur un curseur clignotant.
- journalctl -xb ne m'apprend rien (tout est au vert), sinon qu'il est brutalement interrompu.
- quand au reste, ben je reboote et reviens à la même problématique.
Une idée pour se dépatouiller de çà ?
Merci !
Bonjour,
Tu as déjà démarré correctement sur chacun de ces noyaux ?
Tu as vérifié l'espace disque disponible ?
as tu réussi à te mettre en root?
@jtro : oui j'ai pu entrer le mdp root et me connecter à l'invite. De cette façon j'ai pu lancer les commandes "jourlnalctl -xb" et suivantes.
@chalu :
- noyau 5.10.14 : aucun problème jusqu'à ce que j'éteigne mon ordi hier soir. Tout allait bien. Mode graphique (Nvidia) ok. Mémoire et espace disque sans problème.
- noyau 5.10.16 : aucun problème si je puis dire car mode graphique (Nvidia) foire. Cela arrive de temps en temps ; les pilotes arrivent moins vite que les maj du kernel. Idem mémoire et espace disque.
J'ai aussi lancé la commande :
systemctl --failed
Cette dernière ne me retourne rien. Et un
systemctl reset-failed
suivi d'un reboot me renvoie dans mes cordes.
tu es en btrfs? si c'est le cas tu retournes sur un snapshot précédent; tu peux aussi lancer un zypper dup...
Non, ext4. Donc pas de snapshoot.
J'ai tenté le zypper dup. Sans succès. Il pédale dans la semoule puis revient à l'invite "Emergency mode".
Alors je vais peut-être (sans doute ? :)) ) dire une énormité mais il me semble que tu peux utiliser tumbleweed-cli même si tu es en ext4 ?
https://review.tumbleweed.boombatower.com/about.html
https://github.com/boombatower/tumbleweed-cli
Je pense comprendre que tu changes les dépôts (c'est réversible) et que ça te permet de revenir à un snapshot plus ancien de façon à avoir un système "équilibré", chaque snapshot fournissant les paquets compilés pour être ensemble. Alors je ne sais pas si ça peut te permettre de t'en sortir ?
Autre idée : passer au driver nouveau avec ta carte nvidia ?
Pour la connexion internet, j'imagine que tu dois être en ethernet pour que ça puisse fonctionner
Je n'ai pas trouvé si tumbleweed-cli fonctionne avec ext4. Mais l'idée est intéressante. Je ne connaissais pas (ou alors çà ne m'a pas marqué). Comme je ne peux rien installer à priori, cela ne va pas me tirer d'affaire quant à présent.
Soit j'arrive à trouver ce qui "merdoie", soit je fais une réinstall.
Je viens de voir qu'il y a une mise à jour des pilotes Nvidia. Autant profiter de toutes les possibilités offertes même si nouveau conviendrait pour la majorité des cas. Donc, dès que je serais opérationnel je passerais sur le noyau 5.10.16 avec le dernier pilote Nvidia.
Sinon,dans les temps lointains où je bidouillais, je passais par un chroot pour régler ce genre de problèmes à l'aide d'un live cd.
Il y a aussi l'option du cd supergrubdisk,mais là ça m'a l'air d'être un problème de pilote vidéo et je ne suis pas certain que SGBD puisse régler ce problème. Par contre en chroot tu peux passer sur le pilote nouveau.
Désinstaller le pilote propriétaire nvidia ne suffit pas pour repasser à nouveau ?
Peut être mais apparemment il n'a aucun accès à sa suse? Pour le changement de pilote graphique , je ne sais pas comment faire,ayant toujours eu des pilotes libres radeon ou des intel.
Bonjour,
J'ai eu ça aussi et c'était lié au pilote Nvidia pas à jour...
Pour passer en Nouveau il faut désinstaller les pilote Nvidia et mettre un "verrou" dessus (je sais plus le terme exact qui empêche de l'installer)
Quand ça m'est arrivé je suis passé en root en console lorsque demandé puis j'ai tapé Yast dans la console et j'avais Yast tout bleu en console et j'ai pu faire les manip...
Espérant que ça aide
Amicalement
Philippe
Hou qu'il est embêté notre mirliton-tontaine!!
Vu mon expérience, là, il perd du temps,
re-installer et le problème serait déjà réglé.
Ça, c'est mon expérience dans ces cas-là.
Je plussoie ( comme ils disent sur les forums.. :D )
oui mais là,il n'arrive pas apparemment à se connecter sauf en mode rescue,d'où l'idée du chroot avec un live cd
En mode rescue, on ne peut pas supprimer de paquet ? Au début du fil il semble pouvoir faire des commandes.
je n'ai jamais utilisé le mode rescue.Il doit exister une doc pour ça?
Pour passer en chroot,voilà ce que je fais: https://doc.ubuntu-fr.org/chroot
Bonjour à tous !
Du nouveau sous le soleil ! J'ai résolu mon affaire mais je me suis cassé les dents !
@Chalu : n'ayant plus d'accès à la partie graphique et restant en Emergency mode, le fait de passer à nouveau n'aurait rien changé pour moi, dans ce cas précis.
@moniroje : j'ai bien pensé à réinstaller l'OS mais çà m'embêtait quelque peu. J'aurais peut-être gagné du temps, effectivement. Mais je suis têtu et pour cette fois, çà a payé ! ;)
@Philoupes et @Chalu : mon problème de pilote est aussi résolu ce jour avec la mise à jour du pilote Nvidia et du noyau. De ce côté là çà baigne aussi ! 8)
Bon, passons à la résolution.
J'ai pensé en revue tout ce que j'avais fait la veille, avant d'éteindre l'ordi. Rien de particulier, mes notes et recherches historiques et généalogiques, un peu de codage pour le site web de mon asso (où rien ne fonctionne comme je veux, mais c'est une autre histoire... J'ai qu'à me mettre sérieusement au Javascript ! :-* ) et... j'ai tenté d'accéder à un disque dur de data appartenant à ma fille pour voir si je pouvais récupérer ses précieuses données. Pas de chance, çà cliquette à mort, le disque n'est pas vu. Ceci dit, j'ai tenté de monter le disque (
mount /dev/sdc), sans succès. J'ai donc retiré le DD de son dock et ai éteint l'ordi. Et c'est là la clé de mon infortune !
Notre openSUSE est susceptible. Si, si !
Un coup de chance que je regarde le fstab car, autrement, je me serais résolu à faire une réinstall.
La tentative avortée du montage du DD a inscrit une ligne dans /etc/fstab relative à sdc. Et notre cher OS y a perdu son latin car je n'ai pas (mea culpa!) démonté le disque en question, pensant, à tort, que le disque n'étant pas reconnu, je n'avais aucun besoin de lancer une quelconque commande.
J'ai viré la ligne supplémentaire inscrite dans le fstab , et après avoir sauvegardé ledit fichier, j'ai rebooté. Et miracle ! Retour à la vie ! Retour dans ma session graphique sous l'ancien noyau (5.10.14), mises à jour dont le pilote Nvidia et YOUPI 8) 8) 8) tout est redevenu normal !!! Sauf pour le DD en rideau :'( c'eut été trop beau !
Je mets donc, ô joie ! le sujet en résolu, le DD fautif (faut bien trouver un bouc émissaire) au pilon et termine ici ma prose !
Merci à tous !
Je pense que c'est possible, mais je n'ai pas tenté.
Dans mes recherches de soluce, j'ai lancé un
zypper dup, histoire de voir. Mauvaise idée, il se proposait de virer beaucoup de choses car n'accédant pas à certains fichiers. J'ai pas trop pigé et ai annulé l'opération. Et j'ai été bien inspiré sur ce coup là, je crois.
J'ai trouvé çà :
- https://fr.opensuse.org/SDB:Utiliser_le_syst%C3%A8me_de_r%C3%A9cup%C3%A9ration (https://fr.opensuse.org/SDB:Utiliser_le_syst%C3%A8me_de_r%C3%A9cup%C3%A9ration)
- https://en.opensuse.org/SDB:Rescue_system_on_disk (https://en.opensuse.org/SDB:Rescue_system_on_disk)
- https://doc.opensuse.org/documentation/leap/startup/html/book-opensuse-startup/cha-trouble.html (https://doc.opensuse.org/documentation/leap/startup/html/book-opensuse-startup/cha-trouble.html)