Vous n'êtes pas identifié(e).
Pages perso : feh, omegat, udisks, passerelle, schroot vraiment transparent
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Pages perso : feh, omegat, udisks, passerelle, schroot vraiment transparent
Hors ligne
Dans /etc/grub.d/10_linux il est possible de définir la variable "ubuntu_recovery" à 1
La variable $ubuntu_recovery est utilisée ailleurs dans le script, attention à d'éventuels effets de bord.
existe-t-il une variable système qui fournit le résultat de "uname -r" ?
/proc/version, mais il faut trier un peu.
Il vaut mieux montrer que raconter.
Hors ligne
nomodeset désactive toute prise en charge du matériel graphique par le noyau (pour nvidia par exemple => nouveau.modeset=0 => désactive uniquement le matériel "nvidia"
tu te retrouve en mode minimal (sans bureau ) avec un une définition vesa (ou vga) , un peu comme le menu de l' EFI . A l'invite de connexion avec xorg , tu aura le driver de X
de plus selon ton gpu le noyau demande peut être un firmware
le mode "recovery" tu est en mode maintenance ou tu va jusqu'au bureau ?
je vais démarrer en mode "recovery" pour vérifier quelque chose
Dernière modification par anonyme (23-07-2021 13:25:26)
un extrait de X dans les même condition
en mode recovery avec nomodeset (même comportement )
un peu d' explication et sur quel matériel
pour moi
ps: avec nomodeset , les DRM du gpu ne sont pas charger (firmware)
pourquoi ce titre ? " nomodeset uniquement en mode recovery"
et en mode normal ça fonctionne avec "nomodeset"
si j' essaie de comprendre , tu veut trouver un endroit ou mettre l'option "nomodeset" de façon permanente pour le mode de démarrage en recovery ?
ps: ça n'explique pas l'écran noir
remarque : j'ai tester avec la touche "e" a l 'invite de grub (mode non permanent )
donc avec nouveau. Avec raleur plus haut nous avons le même étonnement, le nomodeset c'est juste en recovery, sinon pas de serveur X en mode normal; ce qui oblige d'ailleurs à rebooter si on est en recovery.
C'est différent sur ta machine c'est le noyau qui gère en mode normal et pas un driver. Par contre je connais pas bien le truc mais tu as FBDEV qui crée une section; c'est le noyau qui gère ça ?
Pour répondre à l'essai avec ubuntu_recovery=1 pas de dommages collatéraux visibles...pour l'instant.
Dernière modification par phlinux (23-07-2021 15:10:36)
Pages perso : feh, omegat, udisks, passerelle, schroot vraiment transparent
Hors ligne
KMS (modeset du noyau ) est actif , mais c'est le driver de X qui est utiliser
pour Wayland il est impératif de laisser le noyau configurer le gpu
toi tu n'a pas de log de X , mais tu peu rechercher sur le syslog ce qui touche a la carte graphique
pour "ubuntu_recovery=1" je connais pas
je pourrais pas te donner la date et la version du noyau ou KMS (modeset ) a été mit en place dans le noyau , mais j'ai connu en console (serveur) un affichage basic (écriture très grosse)
alors que maintenant le mode natif de l'écran est pris en charge au chargement du noyau (même avant) , ça pose problème si un écran 4K , écriture très petite
mais bon un écran 4k sur un serveur pas convenable.
ps: c'est net , en mode serveur l'affichage est gros avec "nomodeset" alors qu il est correct selon le type d' écran que tu a connecter sur ta carte .
teste ceci dans /etc/default/grub
un update-grub pour le prendre en charge
idem si pas correct pour revenir en situation normale (supprimer l'option)
je connais pas assez bien les subtilités du mode "recovery" , mais a priori tu a la solution sur ton #3 , que je vais tester
e nomodeset c'est juste en recovery, sinon pas de serveur X en mode normal; ce qui oblige d'ailleurs à rebooter si on est en recovery.
Je n'ai rien compris à cette phrase. Qu'entends-tu par "pas de serveur X en mode normal" et pourquoi faut-il rebooter si on est en mode recovery ?
Merci d'expliquer ce qui se passe
- en mode normal sans nomodeset
- en mode normal avec nomodeset
- en mode recovery sans nomodeset
- en mode recovery avec nomodeset
avec ubuntu_recovery=1 pas de dommages collatéraux visibles...pour l'instant.
"Pour l'instant" ? Pas besoin d'attendre je ne sais quoi, les effets autres que l'ajout de "nomodeset" dans les paramètres du mode recovery sont immédiatement visibles dans le grub.cfg généré. Il suffit de comparer les fichiers générés avec 0 et 1.
Dernière modification par raleur (24-07-2021 13:20:01)
Il vaut mieux montrer que raconter.
Hors ligne
Pages perso : feh, omegat, udisks, passerelle, schroot vraiment transparent
Hors ligne
Pages perso : feh, omegat, udisks, passerelle, schroot vraiment transparent
Hors ligne
Pas de N7600GS sous le coude ?
Si, mais c'est une AGP et il faudrait que je remonte une machine autour, et je ne connais pas ta configuration matérielle (écran, mode de connexion) ni logicielle (pilote nouveau ou nvidia, configuration de Xorg, gestionnaire de connexion...) donc à quoi bon ?
en mode normal sans nomodeset : ça fonctionne correctement (ne me demandes pas d'expliquer "correctement")
Et comment que je vais demander ce que tu entends par correctement, qu'est-ce que tu crois !
Tu ouvres une session en console puis tu démarres X, ou bien un gestionnaire de connexion graphique se lance automatiquement ?
- en mode normal avec nomodeset : ça arrive au prompt de login mais le serveur X ne se lance pas (message d'erreur genre "no screen found").
Ce serait bien d'indiquer le message exact plutôt que "genre". Si la configuration de ton serveur X a besoin de KMS, c'est normal qu'il ne fonctionne pas avec nomodeset.
- en mode recovery sans nomodeset : c'est le cas décrit au #1, le boot démarre bien, mais ça perd la carte au bout d'un moment ("no signal detected").
"Ça perd la carte" ne veut rien dire pour moi.
"No signal detected" est une information importante que tu n'avais pas communiquée jusqu'ici.
"au bout d'un moment", c'est combien de temps ?
Ce qui peut laisser penser que le nomodeset ne s'applique pas depuis le départ du boot.
nomodeset s'applique au chargement du pilote KMS du noyau.
ça arrive correctement au prompt du recovery. Mais comme indiqué dans ma phrase le reboot est obligatoire quand on a fini de bricoler, car le nomodeset ne convient pas au serveur X.
Mais si, il suffit de décharger le module et le recharger en forçant modeset=1.
Je me trompe ou tu as une configuration manuelle pour Xorg ?
C'est d'ailleurs indiqué dans un message quand on arrive au prompt du recovery.
Qu'est-ce qui est indiqué exactement ? Jamais vu de message relatif à nomodeset en mode recovery.
"Pour l'instant" ?: j'émets des réserves
Des réserves à quel sujet ? Je répète : si tu veux savoir si ubuntu_recovery=1 a d'autres effets sur grub.cfg que d'ajouter "nomodeset" au démarrage en mode recovery, tu peux le vérifier immédiatement. Attendre ne sert à rien : les modifications de grub.cfg ne seront pas soudainement différentes à la n-ième exécution de update-grub.
Dernière modification par raleur (24-07-2021 13:24:07)
Il vaut mieux montrer que raconter.
Hors ligne
phlinux a écrit :Ce qui peut laisser penser que le nomodeset ne s'applique pas depuis le départ du boot.
nomodeset s'applique au chargement du pilote KMS du noyau.
Je vais infirmer ce que j'ai écrit. En mode normal au bout de deux lignes de boot l'affichage passe en casse inférieure. Par contre en mode recovery ça reste en gros caractères pendant disons 30'' jusqu'à ce que ça perde la carte. Qui prend en charge l'affichage jusque là ?
Mais si, il suffit de décharger le module et le recharger en forçant modeset=1.
Je me trompe ou tu as une configuration manuelle pour Xorg ?
Oui j'ai une config manuelle
Pour le message ce n'est pas au prompt de recovery mais dans journalctl
Pour avoir une idée d'où ça coupe en recovery sans nomodeset, la fin du journalctl
Dernière modification par phlinux (25-07-2021 12:42:08)
Pages perso : feh, omegat, udisks, passerelle, schroot vraiment transparent
Hors ligne
en terme clair tu n'a pas de gpu détecter
je sais pas ce que tu a modifier , mais c'est pas correct
Dernière modification par anonyme (24-07-2021 18:41:55)
Dernière modification par phlinux (25-07-2021 12:42:50)
Pages perso : feh, omegat, udisks, passerelle, schroot vraiment transparent
Hors ligne
En mode normal au bout de deux lignes de boot l'affichage passe en casse inférieure. Par contre en mode recovery ça reste en gros caractères pendant disons 30'' jusqu'à ce que ça perde la carte. Qui prend en charge l'affichage jusque là ?
Le pilote VGA du noyau.
Ce n'est pas logique, les pilotes chargés sont les mêmes en mode normal et recovery, il ne devrait pas y avoir de différence.
Difficile de comparer "au bout de deux lignes" dans un cas et "pendent 30 secondes" dans l'autre, tu ne trouves pas ?
Il y a deux différences dans la ligne de commande du noyau entre les modes normal et recovery :
- en mode normal, l'option "quiet" est ajoutée pour supprimer l'affichage des messages normaux
- en mode recovery, l'option "single" est ajoutée pour activer le mode "single user". Elle a peut-être d'autres effets plus discrets.
La présence de l'option "quiet" dans un cas et pas dans l'autre complique la comparaison. Je te suggère donc de refaire les tests soit en l'ajoutant à la ligne de commande en mode recovery, en la supprimant de la ligne de commande en mode normal, depuis l'éditeur du menu de GRUB au démarrage.
Est-ce que plymouth est installé ? Si oui, y a-t-il une option "splash" ou "nosplash" dans la ligne de commande du noyau ?
Oui j'ai une config manuelle
Pourquoi ? Je pense que c'est elle qui empêche le démarrage de Xorg avec nomodeset. En configuration manuelle, Xorg pourrait utiliser le pilote VESA par défaut. L'affichage serait probablement gros, moche et lent mais au moins ça marcherait.
Sinon, as-tu essayé ma suggestion de recharger le module nouveau avec modeset=1 ?
Est-ce que ça provoque la perte de signal comme sans nomodeset ou bien le passage en haute résolution comme en mode normal ?
EDIT : A tester tantôt avant de quitter le mode recovery, tantôt après.
Sinon pour l'extrait du log c'est sans doute dû au mode recovery
Bien sûr.
Dernière modification par raleur (25-07-2021 14:58:58)
Il vaut mieux montrer que raconter.
Hors ligne
sans rien (ubuntu ou nomodeset)
lancer le mode maintenance
entrer le MDP root
faire ce que tu a faire (maintenance)
puis taper ctrl+d pour relancer le bureau
après avoir taper ctrl+d la première chose que fait le système c'est lancer le réseau
ps: testé sur ma machine aucun soucis
sinon je suis de l'avis de raleur , a minima c'est un driver vga (ou vesa) qui est utilisé avec nomodeset
ps : mais j'ai eu des soucis avec un gpu intel et le mode "nomodeset" (écran noir , sortie avec "ctrl+alt+suppr")
teste la méthode ci dessus sans aucune option , ça doit fonctionner
remarque : mince tu a un mode particulier pour lancer le bureau , moi je suis en mode standart de debian
pas logique la perte de signal vidéo en mode maintenance , comme dit raleur identique entre mode normal et maintenance
Dernière modification par anonyme (25-07-2021 14:58:28)
a partir de la je pense que c'est après le "ctrl+d" et le système est comme avec un démarrage normal
a partir de la je pense que c'est après le "ctrl+d"
Non, les lignes à 0.78 correspondent visiblement à l'exécution de l'initramfs (/init), donc bien avant l'exécution de l'init normal (/sbin/init), l'entrée ou la sortie du mode single.
Jamais vu ces messages sur mes machines.
Dernière modification par raleur (25-07-2021 15:33:07)
Il vaut mieux montrer que raconter.
Hors ligne
moi je pense que tu devrais chercher du coté du bug d'affichage en mode rescue et abandonner l idée d utiliser l option "nomodeset"
j'utilise le paquet "lightdm" pour lancer le bureau (gestionnaire de connexion) que tu n'a pas je suppose
Dernière modification par anonyme (25-07-2021 15:35:28)
Même avec vesa installé
Ensuite tenté le mode normal sans quiet; ça n'arrive même pas au prompt du login avec un "no signal detected". Mode normal avec nomodeset et quiet : 3 lignes et curseur clignotant ad vitam.
Voilà, voilà...
Pages perso : feh, omegat, udisks, passerelle, schroot vraiment transparent
Hors ligne
avec un affichage des plus basic bien sur
quand ce sera réparer je ferais des test avec nomodeset et en normal et recovery
j'ai pas ton matériel , le gpu est une gtx750 (bas de gamme )et je suis en bullseye comme debian
c'est beaucoup mieux et tu remarque que c'est "modeset" qui est utilisé , et pas "nouveau" (donc les modules du noyau)
ps: tous les paquets vidéo de base de debian sont présent , y compris le "xserver-xorg-video-nouveau" (installation récente de debian)
je vai démarrer en mode recovery
remarque
on utilise le module "nouveau" pour le driver , de kms (modeset) , du noyau
le serveur X utilise le module "nouveau" du paquet "xserver-xorg-video-nouveau" (pas utilisé ici)
je démarre avec nomodeset en normal
le serveur X n'a pas chargé "nouveau" sans la prise en charge du noyau
a mon avis tu a deux soucis , ton installation de debian et peut être un bug avec cette carte nvidia et sa prise en charge
la je fais une pause , il me reste a faire la même chose en recovery