Forum

Reprise du message précédent

Si ça peut servir, avec la commande journalctl --no-hostname -b -5 >journal.txt exécutée en utilisateur ordinaire, le fichier journal.txt obtenu:

journal.txt

Pour le moment, je me contente du démarrage automatique par défaut avec le noyau 6.6.14 ...

Suis-je le seul à avoir eu le problème ?!

artenaki :

Bonjour,

Papoteur :

en mode super administrateur

Pourquoi super administrateur ? La commande fonctionne également à partir de l'utilisateur.

Lorsque tu lances journalctl en utilisateur simple, tu n'as pas toutes les informations.

Yuusha :

Lorsque tu lances journalctl en utilisateur simple, tu n'as pas toutes les informations

Mais j'ai vérifié le md5sum des logs avec et sans sudo - ça correspond. Sous xubuntu, cependant.

artenaki :

Bonjour,

Papoteur :

en mode super administrateur

Pourquoi super administrateur ? La commande fonctionne également à partir de l'utilisateur.

Bonjour,
Parce qu'en mode utilisateur, le résultat n'est pas le même. Il n'inclut pas les messages système?

Papipio :

Si ça peut servir, avec la commande journalctl --no-hostname -b -5 >journal.txt exécutée en utilisateur ordinaire, le fichier journal.txt obtenu:

journal.txt

Pour le moment, je me contente du démarrage automatique par défaut avec le noyau 6.6.14 ...

Suis-je le seul à avoir eu le problème ?!

Bonjour,
On peut voir sur la première ligne que le démarrage a été fait sur le noyau 6.6.14. Ce n'est donc pas avec le 6.6.18, celui qui pourrait nous intéresser.
Il y a quelques rapport de bogues ouverts pour le 6.6.8, mais qui ne correspondent pas à ce que tu décris. C'est souvent en lien avec les pilotes Nvidia.

Pour le fichier journal ci-joint, j'ai effectué 2 démarrages avec échec, puis un 3ème OK.
J'ai créé le fichier avec l'utilisateur root.

journal.txt

Papipio :

Pour le fichier journal ci-joint, j'ai effectué 2 démarrages avec échec, puis un 3ème OK.
J'ai créé le fichier avec l'utilisateur root.

journal.txt

Ceci reste le journal d'une session qui a commencé hier après-midi à 14:49 et qui s'est terminée à 20:10 sur le noyau 6.6.14, comme le montre les deux premières lignes.

Bonjour,

Papoteur :

Parce qu'en mode utilisateur, le résultat n'est pas le même. Il n'inclut pas les messages système?

Peux-tu le prouver ? Je suis simplement curieux.
Je pense qu'il s'agit d'une recommandation dépassée...

Peut-être seulement dans quelques rares cas...

Édité par Visiteur Le 07/03/2024 à 17h04

artenaki :

Bonjour,

Papoteur :

Parce qu'en mode utilisateur, le résultat n'est pas le même. Il n'inclut pas les messages système?

Peux-tu le prouver ? Je suis simplement curieux.
Je pense qu'il s'agit d'une recommandation dépassée...

C'est bon ?

J'ai refait un essai directement root pour ne pas qu'on me dise que ça peut venir de ma redirection de commande :

Dans ubuntu, "su" ne fonctionne pas, et l'appel à "sudo" est enregistré dans le journal, ce qui perturbe la somme md5. J'ai donc enregistré les journaux dans des fichiers texte (commande > log1.txt), j'ai supprimé les queues, c'est-à-dire que j'ai égalisé les extrémités. Ensuite, j'ai déjà calculé les sommes md5 des fichiers texte. J'ai également comparé les fichiers en fonction de leur contenu dans Double Commander. C'est pratique pour rechercher des lignes différentes.

Papoteur, Jybz :
Je serais intéressé de voir une comparaison de vos logs (lignes différentes) dans Double Commander...

Édité par Visiteur Le 07/03/2024 à 18h46

Les recommandations fournies dans le cadre de ce fil s'appliquent à Mageia.
Que Ubuntu ait des réglages différents, c'est fort probable, et cela peut avoir des effets sur le mode de fonctionnement de journalctl.
Jusqu'à preuve du contraire, avec Mageia, les résultats sont différents selon qu'on soit simple utilisateur ou root.

Même une nouvelle ligne supplémentaire peut modifier la somme md5, ce n'est pas un indicateur.
Aussi (au moins), il est intéressant de comparer la taille des journaux de texte. En octets.

Merci de se reconcentrer sur le sujet. Artenaki, si tu souhaites approfondir, merci d'ouvrir un sujet dédié.

Bonjour,

Faire une comparaison de somme md5 ou de taille de fichier n' est pas forcément probant à mon avis (le journal est en perpétuel changement sauf erreur), sauf si on est sur que les deux journaux s' arrêtent pile à la même seconde ( et encore, la dernière ligne ferait fois pour s' assurer que la sortie est la même ou non). Je ne pas argumenter plus vu que le journal utilisateur sur ma machine me dit "pas de log", donc je suis obligé d' utiliser le root .

De plus par exemple si je compare la sortie d' un "systemctl status service.qui.a.planté" entre root et non root, je n'ai pas la même chose. Quelle est la source de systemctl ?

Mais ici ce n' est pas le sujet

Le sujet est donc : pourquoi le noyau plante t' il sur la version 6.6.18 sur la machine de Papipio ?

Dans ce cadre, si l' on veut un log de la version 6.6.18, on est malheureusement obligé de procéder ainsi:

- tentative de boot sur la version 6.6.18 ( qui on sait va planter)
- redémarrage sur la version 6.6.14
- générer la sortie de du journalctl pour le boot précédent ( journalctl -b -1 ) ainsi on saura que le boot précédent est en version 6.6.18 . Après je laisse juge Papipio de lancer la commande en root ou pas ( même si j' aurais tendance à préférer la première )

edit : si la sortie est toujours en version 6.6.14, alors c' est probablement que systemd ne démarre pas du tout lors du plantage.

Édité par nic80 Le 07/03/2024 à 19h31

Si le boot plante avant systemd, il faut passer àu débug de l'initrd, en ajoutant rd.debug=1