Boot normal impossible : seul recovery fonctionne [RESOLU]

geole · Le 09/12/2020, à 11:04

Une piste avec ce message ????

déc 06 13:36:38 phi-P7641-MD99855 kernel: NVRM: Can't find an IRQ for your NVIDIA card!
déc 06 13:36:38 phi-P7641-MD99855 kernel: NVRM: Please check your BIOS settings.
déc 06 13:36:38 phi-P7641-MD99855 kernel: NVRM: [Plug & Play OS] should be set to NO
déc 06 13:36:38 phi-P7641-MD99855 kernel: NVRM: [Assign IRQ to VGA] should be set to YES 
déc 06 13:36:38 phi-P7641-MD99855 kernel: nvidia: probe of 0000:01:00.0 failed with error -1
déc 06 13:36:38 phi-P7641-MD99855 kernel: NVRM: The NVIDIA probe routine failed for 1 device(s).
déc 06 13:36:38 phi-P7641-MD99855 kernel: NVRM: None of the NVIDIA devices were initialized.
déc 06 13:36:38 phi-P7641-MD99855 kernel: nvidia-nvlink: Unregistered the Nvlink Core, major device number 236
déc 06 13:36:38 phi-P7641-MD99855 systemd[533]: Blocking net.

on va continuer de remonter le temps

journalctl --no-pager --since "2020-12-06 13:36" --until   "2020-12-06 13:40"   | tail  -16000  | head -2000  >T.txt && xdg-open T.txt

Peux-tu vérifier que tu peux voir les fichiers T.txt et T1.txt dans ce site [https://onedrive.live.com/?authkey=%21ABWZ43nV3XR9S6w&id=2A85BACF788EE786%213180&cid=2A85BACF788EE786
Si oui tenter d'y mettre tes fichiers

Dernière modification par geole (Le 09/12/2020, à 11:37)

karabouya · Le 09/12/2020, à 11:31

Pour rappel, j'avais supprimé les pilotes Nvidia
Ne faut-il pas les réinstaller ? Si oui comment car impossible via les paramètres > pilotes additionnels ?
Oui, je suis bien P.R... et je vois tes 2 fichiers T et T1 sur onedrive, que je n'ai jamais utilisé et donc je patauge...
J'ai toutefois exécuter la dernière commande et j'ai enregistré le texte sur T2 là : https://onedrive.live.com/?authkey=%21A … 58FC0DA353
Désolé mais je ne connais pas le fonctionnement de onedrive

geole · Le 09/12/2020, à 11:46

Je pense que tu as mis dans ton propre onedrive et que tu n'as pas autorisé en lecture..... car le lien que tu donnes est vide, et dans mon lien, il y a toujours mes contenus

Il me semble que les messages sont plus en rapport avec le matériel qu'avec le logiciel, Mais je peux me tromper

journalctl --no-pager --since "2020-12-06 13:36" --until   "2020-12-06 13:40"   | tail  -16000  | head -2000  >T.txt && xdg-open T.txt

et ce qui devrait être la fin

journalctl --no-pager --since "2020-12-06 13:36" --until   "2020-12-06 13:40"   | tail  -18000  | head -2000  >T.txt && xdg-open T.txt

Dernière modification par geole (Le 09/12/2020, à 11:47)

karabouya · Le 09/12/2020, à 11:56

Dis-moi si tu peux voir T3 et T4 sur ton onedrive stp.
Comment réinstaller éventuellement les pilotes Nvidia ?
Merci

geole · Le 09/12/2020, à 12:17

Je vois T2 T3 et T4 dont le début est

-- Logs begin at Fri 2020-11-27 17:32:43 CET, end at Wed 2020-12-09 11:53:06 CET. --
déc 06 13:36:35 phi-P7641-MD99855 kernel: Linux version 5.4.0-56-generic (buildd@lgw01-amd64-025) (gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)) #62-Ubuntu SMP Mon Nov 23 19:20:19 UTC 2020 (Ubuntu 5.4.0-56.62-generic 5.4.73)
déc 06 13:36:35 phi-P7641-MD99855 kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.4.0-56-generic root=UUID=cd858d63-9a64-44f0-8830-e055e3db5dca ro debug loglevel=1 boot_delay=10 nomodeset acpi=off noapic dis_ucode_ldr modprobe.blacklist=nouveau noresume

d'après cette documentation https://doc.ubuntu-fr.org/nvidia

sudo add-apt-repository ppa:graphics-drivers/ppa 
sudo apt update 
ubuntu-drivers devices  
sudo apt install nvidia-(numéro du pilote)

Il me semble que c'est le 340

===> une correction de bug https://askubuntu.com/questions/984970/ … -about-thi
ou https://linuxtrack.net/viewtopic.php?id=2391

Dernière modification par geole (Le 09/12/2020, à 12:50)

karabouya · Le 09/12/2020, à 13:31

Pour les pilotes Nvidia, après celles que tu as proposées, j'ai passé les commandes

sudo add-apt-repository ppa:graphics-drivers/ppa 
sudo apt update && sudo apt upgrade

indiqués sur cette page.
Après redémarrage, rien n'a changé et dans les paramètres pilotes additionnels je ne peux toujours rien changer à ceci ni donc utiliser Nvidia:

" Il me semble que les messages sont plus en rapport avec le matériel qu'avec le logiciel, Mais je peux me tromper" dis-tu;
ça veut dire quoi ? le matériel aurait subi un problème entre-temps ? Cela expliquerait que ma réinstallation de la version 20.04.1 du 27/11 n'a pas eu les mêmes effets que la même installation initiale de 20.04.1 de juin ?
J'ai regardé les liens que tu indiques à propos du bug mais sorry, je n'y comprends rien, je ne suis qu'un simple utilisateur lambda dont l'âge ne l'autorise même plus à lire tintin...
Tu m'aides sans compter et je l'apprécie énormément mais j'avoue que je commence à désespérer.

AJOUT
Je n'ai rien d'un geek. Je suis sûr que tu comprends bien mon désarroi. En plus, j'ai entrainé ma femme, qui est aussi âgée, à utiliser ubuntu. Imagines-tu ce qu'elle va faire si ça lui était arrivé à elle toute seule... Je lui ai déjà déjà dit dans ce cas de retourner à windows dans ce cas et d'aller voir son fournisseur en cas de problème.

Dernière modification par karabouya (Le 09/12/2020, à 13:49)

geole · Le 09/12/2020, à 13:49

Un extrait de la seconde capture me semble intéressant

déc 06 13:36:37  kernel: nvidia: loading out-of-tree module taints kernel.
déc 06 13:36:37  kernel: nvidia: module license 'NVIDIA' taints kernel.
déc 06 13:36:37  kernel: Disabling lock debugging due to kernel taint
déc 06 13:36:37  kernel: nvidia-nvlink: Nvlink Core is being initialized, major device number 236
déc 06 13:36:37  kernel: nvidia 0000:01:00.0: enabling device (0006 -> 0007)
déc 06 13:36:37  kernel: nvidia 0000:01:00.0: can't find IRQ for PCI INT A; please try using pci=biosirq
déc 06 13:36:37  kernel: NVRM: Can't find an IRQ for your NVIDIA card!
déc 06 13:36:37  kernel: NVRM: Please check your BIOS settings.
déc 06 13:36:37  kernel: NVRM: [Plug & Play OS] should be set to NO
déc 06 13:36:37  kernel: NVRM: [Assign IRQ to VGA] should be set to YES 
déc 06 13:36:37  kernel: nvidia: probe of 0000:01:00.0 failed with error -1
déc 06 13:36:37  kernel: NVRM: The NVIDIA probe routine failed for 1 device(s).
déc 06 13:36:37  kernel: NVRM: None of the NVIDIA devices were initialized.
déc 06 13:36:37  kernel: nvidia-nvlink: Unregistered the Nvlink Core, major device number 236

Je sauve pour récuperer

geole · Le 09/12/2020, à 13:59

Je te propose de mettre l'option suggérée de façon définitive.
Avec ton éditeur favori, ouvre le fichier /etc/default/grub
Tu y trouveras une ligne ressemblant à cela (je ne sais plus exactement ce qu'il y a!!)

GRUB_CMDLINE_LINUX_DEFAULT="debug ignore_loglevel    xxxxxxxxxx       xxxxxxxxxx noresume"

Tu fais le nécessaire pour qu'elle devienne

GRUB_CMDLINE_LINUX_DEFAULT="pci=biosirq"

Tu sauvegardes et tu fais prendre en charge avec cette commande

sudo update-grub

Puis tu rebootes normalement.

Maintenant, cela sera plus simple de récupérer la totalité des traces......

karabouya · Le 09/12/2020, à 14:31

Voilà la modif de grub

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="pci=biosirq"
GRUB_CMDLINE_LINUX=""
boot_delay=10
# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

Le reboot normal, après update de grub : plantage. Ecran noir. Touches magiques inopérantes, donc arrêt bouton on/off...
Reboot en avancé recovery.

geole · Le 09/12/2020, à 14:56

Il fallait malgré tout essayer. On est repartit pour un tour

1) Identification des dates et heures des derniers boots

journalctl   --list-boots | tail -10

2) Tu vérifies que c'est bien celui indiqué au n° -1

3) Tu extrais la totalité du contenu

journalctl   -b -1 > T5.txt

4) Tu postes dans le nouveau lieu de stockage.

5) Tu dis quand c'est fait.

karabouya · Le 09/12/2020, à 15:06

journalctl   --list-boots | tail -10

T5 envoyé

phi@phi-P7641-MD99855:~$ journalctl   --list-boots | tail -10
  -9 39b7fe6c80d64f02b2ea852782163ec2 Tue 2020-12-08 20:56:09 CET—Tue 2020-12-08 21:01:01 CET
  -8 70327d55a59f47f5b96e590217b96a32 Tue 2020-12-08 21:02:04 CET—Tue 2020-12-08 21:35:30 CET
  -7 73d80d3ed42246baaad9f420fb430150 Wed 2020-12-09 09:06:13 CET—Wed 2020-12-09 09:59:38 CET
  -6 fce984df78bc43269b5179095c2cb2fe Wed 2020-12-09 10:03:38 CET—Wed 2020-12-09 10:28:10 CET
  -5 7d6a3545d814449aaeb9200c7d598610 Wed 2020-12-09 10:29:57 CET—Wed 2020-12-09 12:28:02 CET
  -4 1268ffa11c09449686d40db770071cfc Wed 2020-12-09 12:29:31 CET—Wed 2020-12-09 12:38:56 CET
  -3 59be1f19699e49b896cc58d132434927 Wed 2020-12-09 12:40:21 CET—Wed 2020-12-09 13:34:46 CET
  -2 a3d21b3db23a408c8317c816575a4344 Wed 2020-12-09 14:08:08 CET—Wed 2020-12-09 14:13:10 CET
  -1 fdd9f721567a478b9074859f00da0b08 Wed 2020-12-09 14:17:26 CET—Wed 2020-12-09 14:20:23 CET
   0 83074f190a20408e8d78e403a9bd6585 Wed 2020-12-09 14:27:30 CET—Wed 2020-12-09 14:42:37 CET
phi@phi-P7641-MD99855:~$

Dernière modification par karabouya (Le 09/12/2020, à 15:06)

geole · Le 09/12/2020, à 15:32

Finalement, je ne pense pas que le n° moins 1 correspond au démarrage
-- Logs begin at Fri 2020-11-27 17:32:43 CET, end at Wed 2020-12-09 14:42:37 CET. --
déc 09 14:17:26 kernel: Linux version 5.4.0-56-generic (buildd@lgw01-amd64-025) (gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)) #62-Ubuntu SMP Mon Nov 23 19:20:19 UTC 2020 (Ubuntu 5.4.0-56.62-generic 5.4.73)
déc 09 14:17:26 kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.4.0-56-generic root=UUID=cd858d63-9a64-44f0-8830-e055e3db5dca ro recovery nomodeset dis_ucode_ldr
déc 09 14:17:26 kernel: KERNEL supported cpus:

Refais avec le n° -2. Tu pourras remettre au même endroi

journalctl   -b -2 > T5.txt

Dernière modification par geole (Le 09/12/2020, à 15:34)

karabouya · Le 09/12/2020, à 15:37

j'y pige toujours rien, mais c'est envoyé

geole · Le 09/12/2020, à 16:11

Je commence de nouveau à ne plus comprendre
La version moins 2
déc 09 14:08:08 phi-P7641-MD99855 kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.4.0-56-generic root=UUID=cd858d63-9a64-44f0-8830-e055e3db5dca ro recovery nomodeset dis_ucode_ldr
est aussi en recovery

est-ce lié a cela "Touches magiques inopérantes, donc arrêt bouton on/off."..???
ou au fait que le débug est enlevé???

Explication pour une ligne

 -4 1268ffa11c09449686d40db770071cfc Wed 2020-12-09 12:29:31 CET—Wed 2020-12-09 12:38:56 CET

-4 est le numéro relative dans le temps par rapport à la référence du boot actuel qui est toujours 0
Donc au prochain boot la valeur -4 devient -5 c'est pour cela qu'il m'arrive de mettre des créneaux de dates

1268ffa11c09449686d40db770071cfc est le nom du fichier dans la structure /var/log/journal

Wed est le jour de la semaine en anglais pour le début de la collecte de ce journal
2020-12-09 est la date du jour au format anglais
12:29:31 heures minutes et secondes pour le début
CET exprimée en référence à l'europe centrale

Les 4 paramètres suivants font référence à la fin de ce fichier de collecte.

Je te propose de rajouter uniquement le paramètre debug et de voir si les écritures se font de nouveau...

Pour la suite, note bien les heures car c'est plus facile pour toi de connaître quand cela bloque...

karabouya · Le 09/12/2020, à 16:50

Merci pour ces explications.
je viens de booter en recovery à 16:42:10
J'ai rajouté debug et envoyé T6.

GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="debug loglevel=1 pci=biosirq"
GRUB_CMDLINE_LINUX=""
boot_delay=10

J'espère que c'est comme ça qu'il fallait fallait faire...

Je reste sur ma faim quant à cette question de mon post 196 :

Une question m'obsède. J'ai installé avec le DVD Xubuntu 20.04.1 en juin sur le pc de ma femme, puis sur le mien.
Cela a très bien fonctionné jusqu'à ces problèmes que tu connais et le 27/11 j'ai refait la MEME installation à côté de Windows en demandant de SUPPRIMER la version xubuntu 20.10 installée par mise à niveau. La MEME installation que celle de juin qui marchait nickel et cette fois le bug ! Là j'avoue que quelque chose m'échappe... D'après ton expérience, quelles explications possible à cela ? Merci

geole · Le 09/12/2020, à 17:00

Il faudrait que tu regardes les premières lignes avant d'expédier

head -3  T5.txt

et n'hésite pas à redemander la liste des dernières collectes.

- Logs begin at Fri 2020-11-27 17:32:43 CET, end at Wed 2020-12-09 16:42:52 CET. --
déc 09 15:48:50 phi-P7641-MD99855 kernel: Linux version 5.4.0-56-generic (buildd@lgw01-amd64-025) (gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)) #62-Ubuntu SMP Mon Nov 23 19:20:19 UTC 2020 (Ubuntu 5.4.0-56.62-generic 5.4.73)
déc 09 15:48:50 phi-P7641-MD99855 kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.4.0-56-generic root=UUID=cd858d63-9a64-44f0-8830-e055e3db5dca ro recovery nomodeset dis_ucode_ldr

Si je connaissais la cause du problème, il n'y aurait pas lieu de chercher une idée dans les traces .

NOTA: Tu penseras à supprimer cette ligne de ton fichier de paramétrage
boot_delay=10

Dernière modification par geole (Le 09/12/2020, à 17:11)

karabouya · Le 09/12/2020, à 17:19

Geole, merci pour tout, j'abandonne, désolé.
Je n'en sortirai jamais et je n'ai aucune compétence pour toutes ces recherches et manipulations.
Je n'ai plus l'âge hélas.
S'il faut passer par tout ça pour simplement utiliser un PC, il y a alors vraiment un truc qui cloche...
Je vais sans doute m'acheter un nouveau PC et je verrai bien.
Ma question de base restera sans réponse : deux fois la MEME installation, la première fois ça marche, la seconde fois la MEME ne marche plus.
Un immense MERCI !

geole · Le 09/12/2020, à 17:37

Je te comprends. La collecte est difficile et sans collecte, je n'ai aucune idée

Si tu le souhaites, tu peux ajouter les mots recovery nomodeset dans les options de /etc/default/grub

Du coup, il me semble qu'il te reste le problème du réglage de l'affichage en nomodeset , pour qu'il te convienne
Exemple de paramétrage (toujours dans le /etc/default/grub)

Pour augmenter la taille des caractères de l'écran de choix du boot,

####GRUB_GFXMODE=1280x1024
GRUB_GFXMODE=640x380

et pour l'affichage en cours d'utilisation
GRUB_CMDLINE_LINUX_DEFAULT="debug=all loglevel=8 dis_ucode_ldr vga=0x31B "

Je vais te mettre un lien pour la correspondance à mettre. Voici le tableau pour le choix https://doc.ubuntu-fr.org/tutoriel/definition_demarrage

Pense aussi qu'il est possible de changer plus rapidement la valeur au moment du boot pour essayer avant de reporter dans le fichier de paramétrage

Dernière modification par geole (Le 09/12/2020, à 17:45)

karabouya · Le 09/12/2020, à 18:23

Merci encore.
Tu mérites bien l'anagramme de ton pseudo : éloge
Bonne soirée.

geole · Le 10/12/2020, à 11:32

Bonjour
Permets-moi de continuer un peu cette discussion
A propos de la seconde installation
N'ayant pas du tout compris ce qui ne marche pas, Je ne t'ai pas proposé d'en faire une troisième en repartant de zéro...

A propos d'un nouveau PC.
Certains en achètent puis il découvrent que
Les disques ne sont pas visibles
Réinstaller windows peut ne pas suffire
Il faut rebrancher autrement les disques pour que le live-USB fonctionnent
Le second disque interne n'est visible qu'en sortie de veille....
Installer ubuntu puis le faire lancer est compliqué

A propos d'utiliser simplement un PC.
Pense à regarder ce forum et clique sur messages récents, tu y verras plein de problèmes
Le wifi qui ne fonctionne pas
Les temps de mise en route très longs
L'écran qui reste noir sans raison apparente
Sans parler des logiciels pas si facile que cela à faire fonctionner

A propos des compétences
Seul devant son micro, on fait toujours la même chose mais petit à petit on découvre quelque chose de plus: Moins bien ou mieux ou inutile.
Je pense qu'il faut simplement persévérer .

Pour ton problème particulier
Initialement tu bootais avec boot-repair. Ce cap est franchi.
Les traces de mises en route qui s'affichent à l'écran défilent trop vites pour être lues... Toujours pas de solution.
Pour leur taille, rien ne semble prévu.

L'enregistrement des traces du démarrage normal.
Initialement , il n'y en avait pas. On a fini par trouver une solution.
De nouveau, il n'y en a plus, mais je pense savoir pourquoi..

Le pilote graphique nvdia, il a été enlevé, il a été remis mais sans résultat probant.

Le transfert du contenu des fichiers de trace
Je pense que cela t'a épuisé, en tout cas ce fut le cas pour moi et je viens de trouver un contournement qui ne me semble pas trop compliqué. Tu pourras donner ton avis
J'avais déjà traité une seule fois une trace de débugging (débrancher les disques pour que le live-USB continue à être lu) Dans ce contexte on savait, que cela se passait au démarrage.J'avais donc demandé en commençant par le début. On s'est heurté au problème de volumétrie
=> Transfert de fichiers par pastbin : Taille très limitée
=> Technique de copier/coller. Il faut maîtriser le copier puis il faut que le copier ne soit pas trop volumineux. Je crois que tu l'as constaté.
D'où la solution de découpage par paquets, J'ai choisis 2000 lignes, peut-être que 3000 lignes auraient passé.
On peut regretter que le forum ne dispose pas de la technique pièce jointe, Mais c'est comme cela.
J'ai commis l'erreur de penser que cela serait plus visible en commençant par la fin plutôt que par le début.

Depuis hier, on vient de mettre au point une technique qui permet maintenant de transférer la totalité de la trace en un seul paquet.
Ce qui va sacrément te faciliter la vie. En un seul coup, tu expédies tout, j'en ai pour la journée à lire avant de te répondre.
Tu peux même expédier toutes les captures de la journée pour être certain d'y mettre la bonne. Je pense que cela tiendra dans l'espace mis à notre disposition. (on doit pouvoir épurer facilement)
le problème se posera si un intrus vient y déposer des fichiers.

Alors, ce n'est pas le moment de lâcher car tout va devenir plus simple pour toi.

Voici donc , ce que je te propose
1) On remodifie le fichier /etc/default/grub en y remettant toutes les options. On verra plus tard celle(s) qui permet(tent) d'écrire.

GRUB_CMDLINE_LINUX_DEFAULT="pci=biosirq debug loglevel=7 boot_delay=10 nomodeset acpi=off noapic dis_ucode_ldr modprobe.blacklist=nouveau noresume"

2) Tu refais "sudo update-grub"
3) Tu notes l'heure.
4) Tu bootes normalement.
Je pense que cela va continuer à bloquer.
5) Tu arrêtes de nouveau avec les touches magiques.
J'espère qu'elles vont remarcher.
6) Tu rebootes en recovery
7) Tu fais l'état des fichiers journaux

journalctl   --list-boots | tail -10

8) Tu extrais les deux ou trois derniers en fonction des heures que tu as noté.
Je n’ai besoin que de celui du mode normal. Le mode recovery est inutile

journalctl   -b -1 > J-1.txt
journalctl   -b -2 > J-2.txt

9) Tu vérifies qu’ils ne sont pas en recovery

tail -3  J-1.txt
tail -3 J-2.txt

10) Tu les transferts et tu me préviens

A propos de la taille des polices du mode recovery
Tu devrais booter avec windows, il me semble qu'en faisant un clic droit dans l'écran, un logiciel permettant de choisir la taille de la police s'ouvre
Cela te permet de faire des choix .Tu indiqueras la taille qui te convient. On trouvera alors la correspondance.

karabouya · Le 10/12/2020, à 14:17

Bonjour,
Tout d'abord merci pour ta persévérance altruiste. Mon choix d'abandonner hier était le résultat d'un certain découragement (1er post le 20/11...) et le fait que je me relève d'une opération n'a fait qu'augmenter mon ressentiment.

geole a écrit :

Seul devant son micro, on fait toujours la même chose mais petit à petit on découvre quelque chose de plus: Moins bien ou mieux ou inutile.
Je pense qu'il faut simplement persévérer .

Tu as parfaitement raison, j'ai appris beaucoup de choses, t'en remercie et ne m'en porte que mieux.
Et en plus, tout va bien maintenant ! Je récapitule mes actions du matin :
- réinstallation complète avec le DVD xubuntu 20.04.1, en supprimant l'ancien 20.04.1
- en cours, je choisis "faire les mises à jour pendant l'installation" et "ok pour installer les logiciels tiers"
- avant la fin de l'install, un message : plantage suite à un bug
- je lance une nouvelle réinstall mais SANS demander la mise jour NI les logiciels tiers
- l'install va jusqu'au bout, demande de redémarrer et là, rien. Je dois mettre power off et booter normalement (sans choisir un noyau, donc pas défaut)
- tout s'ouvre normalement, je choisis mon affichage 1360x768, je constate qu'aucun pilote addit n'est utilisé mais seul X.orgXserver
- j'éteins : ok, normal
- je relance en testant l'ouverture avec le noyau 5.4.0-54 et là : rien ! Clavier bloqué, pas de touches magiques et donc power off
- je relance mode normal par défaut : ok
- 12:49 je demande à redémarrer d'après la grille (veille - éteindre - redémarrer - changer d'utilisateur) : rien - power off
- 12:52 boot par défaut : ok
- 12:53 mise en veille : ok
- 13:48 sortie de veille : ok

Pour ton info, grub :

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

Donc, à part le redémarrage, tout va bien. J'attends ta réaction et peux t'envoyer tous les retours que tu souhaiterais.
Ensuite, personnellement je ne toucherais plus à rien et réinstallerais mes 2 imprimantes Brother, et ça, c'est pas de la tarte !

geole · Le 10/12/2020, à 14:37

Bonjour
Heureux de te retrouver combatif.
Ce n'est pas mal d'avoir tout réinitialisé. Pour le moment, je te propose simplement de faire un boot-info afin de savoir ce qui est installé.

sudo add-apt-repository -y ppa:yannubuntu/boot-repair && sudo apt update && sudo apt install -y boot-info && boot-info

J'ai noté que les mises en veille et sortie de veille fonctionnent.

Je comprends que dans ce choix "je demande à redémarrer d'après la grille (veille - éteindre - redémarrer - changer d'utilisateur)" Tu retrouves le même problème me semble-t-il.

Dois-je comprendre que dans ce choix "d'après la grille (veille - éteindre - redémarrer - changer d'utilisateur) ": tu peux mettre en route de façon normale?

karabouya · Le 10/12/2020, à 14:48

https://paste.ubuntu.com/p/PFmxGPN72P/

geole a écrit :

Dois-je comprendre que dans ce choix "d'après la grille (veille - éteindre - redémarrer - changer d'utilisateur) ": tu peux mettre en route de façon normale?

je teste ça

karabouya · Le 10/12/2020, à 15:03

Je continue sur un autre PC car...

C'est à n'y rien comprendre !
- Je fais le boot info et te le poste
- je vais sur la grille (déconnexion, redémarrer, etc) et j'éteins
- 14:53:00 j'allume pour boot par défaut, j'attends...
- 14:53:37 : rien ! écran noir + pas de touches magiques
- 14:55:00 power off
Mais que se passe-t-il encore ?
Que faut-il essayer ? Un recovery, encore ?

geole · Le 10/12/2020, à 15:19

Dans ton boot-info,on voit cela

=================== sdb5: Location of files loaded by Grub ====================
           GiB - GB             File                                 Fragment(s)
  97,106075287 = 104,266854400  boot/grub/grub.cfg                             2
  70,765758514 = 75,984154624   boot/vmlinuz                                   1
  62,773555756 = 67,402592256   boot/vmlinuz-5.4.0-42-generic                  1
  70,765758514 = 75,984154624   boot/vmlinuz-5.4.0-54-generic                  1
  62,773555756 = 67,402592256   boot/vmlinuz.old                               1
  61,270210266 = 65,788387328   boot/initrd.img                                3
  72,590492249 = 77,943447552   boot/initrd.img-5.4.0-42-generic               1
  61,270210266 = 65,788387328   boot/initrd.img-5.4.0-54-generic               3
  72,590492249 = 77,943447552   boot/initrd.img.old                            1

Il serait bon que tu fasses un essai
Lorsque le grub s'affiche sur la première ligne, tu descends d'une ligne pour te positionner sur le mode avancé et tu valides.
Tu auras alors plusieurs lignes te proposant le noyau 54
A priori on sait que le recovery du noyau 54 fonctionne.
Tu auras alors plusieurs lignes te proposant le noyau 42
J'aimerais simplement savoir si un boot normal avec le noyau 42 fonctionne.
Donc, tu te positionnes sur la ligne proposant "/vmlinuz-5.4.0-42-generic " en mode normal et tu valides.

Dernière modification par geole (Le 10/12/2020, à 15:45)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#201 Le 09/12/2020, à 11:04

Re : Boot normal impossible : seul recovery fonctionne [RESOLU]

#202 Le 09/12/2020, à 11:31

Re : Boot normal impossible : seul recovery fonctionne [RESOLU]

#203 Le 09/12/2020, à 11:46

Re : Boot normal impossible : seul recovery fonctionne [RESOLU]

#204 Le 09/12/2020, à 11:56

Re : Boot normal impossible : seul recovery fonctionne [RESOLU]

#205 Le 09/12/2020, à 12:17

Re : Boot normal impossible : seul recovery fonctionne [RESOLU]

#206 Le 09/12/2020, à 13:31

Re : Boot normal impossible : seul recovery fonctionne [RESOLU]

#207 Le 09/12/2020, à 13:49

Re : Boot normal impossible : seul recovery fonctionne [RESOLU]

#208 Le 09/12/2020, à 13:59

Re : Boot normal impossible : seul recovery fonctionne [RESOLU]

#209 Le 09/12/2020, à 14:31

Re : Boot normal impossible : seul recovery fonctionne [RESOLU]

#210 Le 09/12/2020, à 14:56

Re : Boot normal impossible : seul recovery fonctionne [RESOLU]

#211 Le 09/12/2020, à 15:06

Re : Boot normal impossible : seul recovery fonctionne [RESOLU]

#212 Le 09/12/2020, à 15:32

Re : Boot normal impossible : seul recovery fonctionne [RESOLU]

#213 Le 09/12/2020, à 15:37

Re : Boot normal impossible : seul recovery fonctionne [RESOLU]

#214 Le 09/12/2020, à 16:11

Re : Boot normal impossible : seul recovery fonctionne [RESOLU]

#215 Le 09/12/2020, à 16:50

Re : Boot normal impossible : seul recovery fonctionne [RESOLU]

#216 Le 09/12/2020, à 17:00

Re : Boot normal impossible : seul recovery fonctionne [RESOLU]

#217 Le 09/12/2020, à 17:19

Re : Boot normal impossible : seul recovery fonctionne [RESOLU]

#218 Le 09/12/2020, à 17:37

Re : Boot normal impossible : seul recovery fonctionne [RESOLU]

#219 Le 09/12/2020, à 18:23

Re : Boot normal impossible : seul recovery fonctionne [RESOLU]

#220 Le 10/12/2020, à 11:32

Re : Boot normal impossible : seul recovery fonctionne [RESOLU]

#221 Le 10/12/2020, à 14:17

Re : Boot normal impossible : seul recovery fonctionne [RESOLU]

#222 Le 10/12/2020, à 14:37

Re : Boot normal impossible : seul recovery fonctionne [RESOLU]

#223 Le 10/12/2020, à 14:48

Re : Boot normal impossible : seul recovery fonctionne [RESOLU]

#224 Le 10/12/2020, à 15:03

Re : Boot normal impossible : seul recovery fonctionne [RESOLU]

#225 Le 10/12/2020, à 15:19

Re : Boot normal impossible : seul recovery fonctionne [RESOLU]

Pied de page des forums