Ma question est la suivante: comment puis-je trouver le journal de démarrage d'une tentative de démarrage précédente du système?
Aujourd'hui, lors de la première mise sous tension de mon PC, le processus de démarrage s'est arrêté sur le logo Ubuntu, lorsque j'ai appuyé sur Esc J'ai vu plusieurs lignes contenant une erreur de noyau et un redémarrage requis en bas, alors j'ai appuyé sur Ctrl+ALt+Del et le prochain démarrage s'est bien passé sans problèmes.
Je ne parviens pas à trouver des messages sur l'écran que j'ai vu lors du premier démarrage infructueux. Aurais-je dû prendre une photo sur mon téléphone?
/var/log/boot
est là mais vide, j'ai cherché kern.log et syslog pour les chaînes dont je me souvenais avec la date d'aujourd'hui comme error
mais je n'ai rien trouvé de familier à ce que j'ai vu sur l'écran de démarrage précédent.
$ journalctl -b -1
ne me donne que les messages du noyau au démarrage, je peux trouver cela ailleurs aussi, et ce ne sont pas ce qui était affiché à l'écran lors du démarrage, journalctl est inutile pour moi, je recherche des messages qui apparaissent à l'écran pendant le démarrage.
Pour l'instant, la seule option est de prendre une photo ou d'écrire le message sur papier.
Un rapport de bogue a été déposé sur ce sujet . Étant donné que rsyslog
gère déjà plusieurs journaux de démarrage dans /var/log/syslog
et syslog.1
, .2.gz
, .3.gz
... syslog.7.gz
, les développeurs ont estimé que conserver des journaux supplémentaires journalctl
entraînerait une perte d'espace disque.
Le rapport de bogue indique le 3 janvier 2018 que pour les nouvelles installations rsyslog
ne sera plus la valeur par défaut et que journalctl
conservera plusieurs journaux de données de démarrage.
La plupart d'entre nous ne procéderons pas à une nouvelle installation. Par conséquent, pour activer plusieurs journaux de démarrage journalctl
name__, auquel cas nous pouvons utiliser:
$ Sudo mkdir -p /var/log/journal
$ Sudo systemd-tmpfiles --create --prefix /var/log/journal
Cannot set file attribute for '/var/log/journal', value=0x00800000, mask=0x00800000: Operation not supported
Selon ce rapport github , le message d'avertissement "Impossible de définir l'attribut de fichier" peut être ignoré.
Après avoir utilisé la journalisation de démarrage précédente pendant plusieurs mois, j'ai découvert une autre option qui peut être définie dans /etc/systemd/journald.conf
:
De page de manuel journald.conf :
Stockage =
Contrôle où stocker les données du journal. Un de "volatile", "persistant", "auto" et "aucun". Si elles sont "volatiles", les données du journal ne seront stockées qu’en mémoire, c’est-à-dire au-dessous de la hiérarchie/run/log/journal (créée le cas échéant). Si "persistant", les données seront stockées de préférence sur le disque, c'est-à-dire en dessous de la hiérarchie
/var/log/journal
(qui est créée si nécessaire), avec un repli sur/run/log/journal
(qui est créé si nécessaire), au démarrage initial et si le disque n'est pas accessible en écriture. "auto" est similaire à "persistant" mais le répertoire/var/log/journal
n'est pas créé si nécessaire, de sorte que son existence contrôle l'emplacement où les données du journal vont. "none" désactive tout le stockage, toutes les données de journal reçues seront supprimées. Le transfert vers d'autres cibles, telles que la console, le tampon de journal du noyau ou un socket syslog fonctionnera toujours. La valeur par défaut est "auto".
En un mot, supprimez le commentaire et modifiez la ligne pour:
Storage=persistent
$ journalctl --list-boots
-15 58a9e56135564cd8a52d547b19e76bf5 Fri 2018-02-02 18:34:35 MST—Fri 2018-02-02 23:07:14 M
-14 3514e056440341b1b6e5f03d109681bc Sat 2018-02-03 06:05:12 MST—Sat 2018-02-03 08:07:44 M
-13 0d1a32dc275348589f5ecdc72180c018 Sat 2018-02-03 08:08:05 MST—Sat 2018-02-03 08:08:34 M
-12 74159b593f3a401589ee6bd78e31684b Sat 2018-02-03 08:08:51 MST—Sun 2018-02-04 08:32:09 M
-11 4b394a9aad584ab2bfabe3b77eeed78f Sun 2018-02-04 08:32:26 MST—Mon 2018-02-05 16:54:02 M
-10 8e461ed2593c4fd896ca3b71eb3c0fba Mon 2018-02-05 16:54:34 MST—Tue 2018-02-06 03:54:30 M
-9 ec7ba0e4dfe241c0b9c978d278fcca6d Tue 2018-02-06 03:54:47 MST—Tue 2018-02-06 16:25:02 M
-8 b5c110267c214c38b63d0a367197d118 Tue 2018-02-06 16:25:19 MST—Thu 2018-02-08 16:49:03 M
-7 75c3b117ac6a4de984dc3ced15edb7f8 Thu 2018-02-08 16:49:22 MST—Fri 2018-02-09 03:51:09 M
-6 7338bd1007bc42dda5c8667eeefe1a59 Fri 2018-02-09 03:51:26 MST—Fri 2018-02-09 16:55:52 M
-5 4b6cd0121327454ca3db035c7ed42df6 Fri 2018-02-09 16:56:09 MST—Sat 2018-02-10 07:55:14 M
-4 0d56207f9ec0405ca3a3fd638334de2f Sat 2018-02-10 07:55:32 MST—Mon 2018-02-12 22:16:05 M
-3 0f230cc546fd4aec8f5233e0074ab3e1 Tue 2018-02-13 03:57:20 MST—Wed 2018-02-14 22:58:56 M
-2 c0d2c0141dd840cbab75d3c2254f8781 Wed 2018-02-14 22:59:13 MST—Sat 2018-02-17 22:46:14 M
-1 aafb2573a6374e019a7165cb8eee74a0 Sun 2018-02-18 06:02:03 MST—Mon 2018-02-19 04:16:36 M
0 8462f1969c6f4d61973e7e245014b846 Mon 2018-02-19 04:16:53 MST—Tue 2018-02-20 18:51:42 M
$ journalctl -b-1
-- Logs begin at Fri 2018-02-02 18:34:35 MST, end at Thu 2018-03-01 16:43:25 MST. --
Feb 28 20:03:15 alien systemd-journald[290]: Runtime journal (/run/log/journal/) is 8.0M,
Feb 28 20:03:15 alien kernel: Linux version 4.14.23-041423-generic (kernel@kathleen) (gcc
Feb 28 20:03:15 alien kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-4.14.23-041423-generi
Feb 28 20:03:15 alien kernel: KERNEL supported cpus:
Feb 28 20:03:15 alien kernel: Intel GenuineIntel
Feb 28 20:03:15 alien kernel: AMD AuthenticAMD
Feb 28 20:03:15 alien kernel: Centaur CentaurHauls
Feb 28 20:03:15 alien kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point
Feb 28 20:03:15 alien kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Feb 28 20:03:15 alien kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
Feb 28 20:03:15 alien kernel: x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registe
Feb 28 20:03:15 alien kernel: x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
Feb 28 20:03:15 alien kernel: x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
Feb 28 20:03:15 alien kernel: x86/fpu: xstate_offset[3]: 832, xstate_sizes[3]: 64
Feb 28 20:03:15 alien kernel: x86/fpu: xstate_offset[4]: 896, xstate_sizes[4]: 64
Feb 28 20:03:15 alien kernel: x86/fpu: Enabled xstate features 0x1f, context size is 960 b
Feb 28 20:03:15 alien kernel: e820: BIOS-provided physical RAM map:
Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000000000000-0x0000000000057fff] usabl
lines 1-19
Portez une attention particulière au paramètre -b-1
. Il est différent des autres références que vous pouvez voir. De page de manuel :
-b [ID][±offset], --boot=[ID][±offset]
Afficher les messages d'un démarrage spécifique. Cela ajoutera une correspondance pour "_BOOT_ID =".
L'argument peut être vide, auquel cas les journaux du démarrage actuel seront affichés.
Si l'ID de démarrage est omis, un décalage positif recherchera les démarrages à partir du début du journal et un décalage égal ou inférieur à zéro recherchera des démarrages à partir de la fin du journal. Ainsi, 1 signifie la première botte trouvée dans le journal dans l'ordre chronologique, 2 la seconde et ainsi de suite; tandis que -0 est le dernier démarrage, -1 le démarrage avant dernier, et ainsi de suite. Un décalage vide équivaut à spécifier -0, sauf lorsque le démarrage actuel n'est pas le dernier (par exemple, car --directory a été spécifié pour consulter les journaux d'un autre ordinateur).
Puis de temps en temps, avec cron
ou minuteries vous pouvez nettoyer anciens journaux :
journalctl --vacuum-time=2d # keep last two days or
journalctl --vacuum-size=300M # keep last 300MB
J'ai eu le même problème, et apparemment, j'ai trouvé la réponse sur le #ubuntu
irc-channel.
Pour quelque raison que ce soit, il me manquait le dossier /var/log/journal
accessible au groupe par systemd-journal.
Après avoir ajouté le dossier, j'ai pu voir les journaux des bottes précédentes via $ journalctl -b1
Les étapes à suivre pour obtenir la solution depuis la réponse du haut ici, à partir de la page de manuel de systemd-journald:
mkdir -p /var/log/journal
systemd-tmpfiles --create --prefix /var/log/journal
systemctl restart systemd-journald
Je l'ai fait comme su
La réponse peut être trouvée dans man journald.conf
, en particulier l'option Storage=
:
Contrôle où stocker les données du journal. Un de "volatile", "persistant", "auto" et "aucun". [...] "auto" est similaire à "persistant" mais le répertoire/var/log/journal n'est pas créé si nécessaire, de sorte que son existence contrôle l'emplacement de stockage des données du journal. [...] La valeur par défaut est "auto".
N'oubliez pas qu'il n'est pas nécessaire de recourir à la rotation des journaux ou à des techniques similaires à celles utilisées avec l'ancien démon syslog. Le fichier journal est configuré par défaut pour atteindre une certaine taille et les anciennes entrées de journal sont automatiquement supprimées lorsque le fichier journal devient trop volumineux.
Sur mon système, cette taille est actuellement configurée à 120 Mo. Vous pouvez l’ajuster dans /etc/systemd/journald.conf
pour l’unité systemd-journald.service.
Utilisez journalctl -bX
où x est le démarrage auquel vous vous référez, donc -b0
correspond à votre démarrage réel et -b-1
le démarrage précédent (qui ne fonctionne que si le dossier /var/log/journal
appartenant au groupe 'systemd-journal' est présent). Je ne peux pas vous dire jusqu'où vous pouvez aller, mais ces deux-là à coup sûr.
Liste disponible bottes avec
journalctl --list-boots