J'ai remarqué que mon /var/log/boot.logfichier a la date 2016-04-22, la dernière fois que j'ai démarré en 15.10. Où se trouvent les boot.logfichiers Xenial ?

Utilisation journalctl

Puisqu'il journaldcontient tous les journaux, vous pouvez utiliser la journalctlcommande avec des filtres appropriés. Dans le cas de boot.log, qui contenait autrefois des messages du système init, vous pouvez faire:

journalctl -b0 SYSLOG_PID=1

• -b0affiche les messages du démarrage actuel, -b1du démarrage précédent, etc. Sans l' -boption, journalctlaffichera les messages depuis le début du journal.
• SYSLOG_PID filtre les messages du PID 1, alias init.

Ou:

journalctl -b0 --system _COMM=systemd

• _COMM=systemdrecherche les messages de la systemdcommande. Puisque systemdc'est init, c'est celui qui nous intéresse.
• --system filtre les messages du journal système au lieu des journaux de session utilisateur.

Exemple:

muru@muru-vm:~$ journalctl -b0 SYSLOG_PID=1
Apr 30 12:29:18 muru-vm systemd[1]: systemd 229 running in system mode. (+PA
Apr 30 12:29:18 muru-vm systemd[1]: Detected virtualization qemu.
Apr 30 12:29:18 muru-vm systemd[1]: Detected architecture x86-64.
Apr 30 12:29:18 muru-vm systemd[1]: Set hostname to <muru-vm>.
Apr 30 12:29:18 muru-vm systemd[1]: Initializing machine ID from random gene
Apr 30 12:29:18 muru-vm systemd[1]: Installed transient /etc/machine-id file
Apr 30 12:29:18 muru-vm systemd[1]: Set up automount Arbitrary Executable Fi
Apr 30 12:29:18 muru-vm systemd[1]: Listening on fsck to fsckd communication
Apr 30 12:29:18 muru-vm systemd[1]: Reached target User and Group Name Looku
Apr 30 12:29:18 muru-vm systemd[1]: Listening on udev Kernel Socket.
Apr 30 12:29:18 muru-vm systemd[1]: Started Forward Password Requests to Wal
Apr 30 12:29:18 muru-vm systemd[1]: Listening on /dev/initctl Compatibility 
Apr 30 12:29:18 muru-vm systemd[1]: Listening on Journal Socket.
Apr 30 12:29:18 muru-vm systemd[1]: Created slice User and Session Slice.
Apr 30 12:29:18 muru-vm systemd[1]: Created slice System Slice.
Apr 30 12:29:18 muru-vm systemd[1]: Starting Braille Device Support...
Apr 30 12:29:18 muru-vm systemd[1]: Mounting POSIX Message Queue File System
Apr 30 12:29:18 muru-vm systemd[1]: Mounting Debug File System...
Apr 30 12:29:18 muru-vm systemd[1]: Mounting Huge Pages File System...
Apr 30 12:29:18 muru-vm systemd[1]: Starting Load Kernel Modules...
Apr 30 12:29:18 muru-vm systemd[1]: Starting Uncomplicated firewall...
Apr 30 12:29:18 muru-vm systemd[1]: Starting Create list of required static 
lines 1-23

journalctlouvre les journaux dans un pager par défaut, vous n'avez donc pas besoin de rediriger vers less.

Journalisation persistante

Ubuntu, par défaut, n'active pas les journaux journaliers persistants. Grâce au commentaire de @Auspex , vous devez effectuer l'une des actions suivantes :

1. Modifier /etc/systemd/journald.confpour inclure:

   Storage=persistent
   

2. Créez un /var/log/journalrépertoire manuellement:

   mkdir /var/log/journal
   systemd-tmpfiles --create --prefix /var/log/journal
   systemctl restart systemd-journald
   

En relation:

• Comment afficher les messages de journal des démarrages précédents sous CentOS 7?

Je parcourais quelques rapports de bogues et j'ai remarqué dans celui-ci: https://bugs.launchpad.net/ubuntu/+source/ubuntu-gnome-default-settings/+bug/1536771 que Plymouth écrit réellement dans boot.log.

Si vous regardez https://launchpadlibrarian.net/257898272/plymouth-debug.log et recherchez dans votre navigateur «boot.log», vous obtenez les lignes suivantes:

[main.c:821] on_system_initialized:system now initialized, opening log 
[main.c:742] get_log_file_for_state:returning log file '/var/log/boot.log'
[main.c:805] prepare_logging:opening log '/var/log/boot.log'

Je ne comprends pas comment fonctionnent les composants internes de Plymouth, mais comme il est responsable de l'écran de démarrage qui s'affiche avant l'écran de connexion, je ne peux que supposer que s'il n'y a pas d'écran de démarrage (écran noir) avant d'accéder à l'écran de connexion , le fichier n'est pas modifié. Si un écran de démarrage s'affiche avant l'écran de connexion, la sortie du processus de démarrage est redirigée vers le fichier boot.log.

Dans Ubuntu 16.04, le boot.logfichier se trouve toujours dans le /var/logdossier comme vous pouvez le voir ici . Le fichier journal de démarrage date d'aujourd'hui (29/04/2016). Peut-être que quelque chose s'est mal passé lorsque vous avez installé Ubuntu 16.04 ou que vous avez mis à niveau le système d'exploitation d'Ubuntu 15.10 vers Ubuntu 16.04 LTS.

Vous pouvez également examiner le comportement de démarrage général à partir du kern.logfichier complet . Une autre alternative possible serait de configurer manuellement le démon syslog pour générer le fichier journal de démarrage et voici un tutoriel comment faire exactement cela: Comment afficher et configurer les journaux Linux

Information additionnelle :

J'ai étudié le comportement de journalisation du démarrage sur deux machines différentes. Sur un ordinateur avec un BIOS basé sur UEFI, le boot.logfichier existe - mais sur un ordinateur avec un BIOS basé sur l'héritage, il semble qu'il n'existe pas du tout. Donc, si le système est installé en mode BIOS hérité (MBR / msdos), cela pourrait expliquer pourquoi votre boot.logfichier est daté du 22/04/2016, c'est un reste d'Ubuntu 15.10.

Informations mises à jour 2016-05-02:

J'ai continué à enquêter sur le comportement du fichier journal de démarrage et j'ai observé que le boot.logfichier existe toujours sur la machine basée sur UEFI, mais depuis quelques jours, le fichier est vide. Une autre alternative, j'ai essayé de voir ce qui se passe pendant le processus de démarrage, était d'installer BootChart , mais bootchart.pngn'existait pas dans le /var/logdossier comme prévu après le redémarrage du système ... il n'y avait qu'un /var/log/bootchartdossier vide qui ne contenait pas non plus le bootchart.pngfichier attendu .

Informations mises à jour 2016-05-04:

Aujourd'hui, le boot.logfichier semble à nouveau avoir une "fonctionnalité", il est rempli d'informations partielles du processus de démarrage. Il semble que ce soit un comportement qui change aléatoirement et qui, je pense, ne peut pas être résolu ici sur Ask Ubuntu - vous devriez donc envisager de déposer un rapport de bogue sur Launchpad pour résoudre ce problème!

Conclusion - après une semaine d'enquête sur le boot.logcomportement des fichiers dans Ubuntu 16.04: vous ne devriez plus vous inquiéter /var/log/boot.loget vous y habituer journalctl.