How to find previous boot log after Ubuntu 16.04 restarts?












15














My question is, how can I find boot log from previous system boot attempt?



Today when first powering on my PC, boot process stopped on Ubuntu logo, when I pressed Esc I have seen several lines containing some kernel error and restart required at the bottom, so I pressed Ctrl+ALt+Del and next boot went OK without problems.



I have trouble finding messages from the screen I have seen during the first unsuccessful boot. Should I have taken picture to my phone?



/var/log/boot is there but empty, I searched kern.log and syslog for strings I remembered with today's date like error but found nothing familiar to what I have seen on previous boot screen.



$ journalctl -b -1 gives me only kernel messages during boot, I can find that elsewhere too, and they are not what was appearing on screen during boot, journalctl is useless for me, I am looking for messages appearing on screen during boot time.



For now, only option is take a photo of write the message on paper.










share|improve this question





























    15














    My question is, how can I find boot log from previous system boot attempt?



    Today when first powering on my PC, boot process stopped on Ubuntu logo, when I pressed Esc I have seen several lines containing some kernel error and restart required at the bottom, so I pressed Ctrl+ALt+Del and next boot went OK without problems.



    I have trouble finding messages from the screen I have seen during the first unsuccessful boot. Should I have taken picture to my phone?



    /var/log/boot is there but empty, I searched kern.log and syslog for strings I remembered with today's date like error but found nothing familiar to what I have seen on previous boot screen.



    $ journalctl -b -1 gives me only kernel messages during boot, I can find that elsewhere too, and they are not what was appearing on screen during boot, journalctl is useless for me, I am looking for messages appearing on screen during boot time.



    For now, only option is take a photo of write the message on paper.










    share|improve this question



























      15












      15








      15


      9





      My question is, how can I find boot log from previous system boot attempt?



      Today when first powering on my PC, boot process stopped on Ubuntu logo, when I pressed Esc I have seen several lines containing some kernel error and restart required at the bottom, so I pressed Ctrl+ALt+Del and next boot went OK without problems.



      I have trouble finding messages from the screen I have seen during the first unsuccessful boot. Should I have taken picture to my phone?



      /var/log/boot is there but empty, I searched kern.log and syslog for strings I remembered with today's date like error but found nothing familiar to what I have seen on previous boot screen.



      $ journalctl -b -1 gives me only kernel messages during boot, I can find that elsewhere too, and they are not what was appearing on screen during boot, journalctl is useless for me, I am looking for messages appearing on screen during boot time.



      For now, only option is take a photo of write the message on paper.










      share|improve this question















      My question is, how can I find boot log from previous system boot attempt?



      Today when first powering on my PC, boot process stopped on Ubuntu logo, when I pressed Esc I have seen several lines containing some kernel error and restart required at the bottom, so I pressed Ctrl+ALt+Del and next boot went OK without problems.



      I have trouble finding messages from the screen I have seen during the first unsuccessful boot. Should I have taken picture to my phone?



      /var/log/boot is there but empty, I searched kern.log and syslog for strings I remembered with today's date like error but found nothing familiar to what I have seen on previous boot screen.



      $ journalctl -b -1 gives me only kernel messages during boot, I can find that elsewhere too, and they are not what was appearing on screen during boot, journalctl is useless for me, I am looking for messages appearing on screen during boot time.



      For now, only option is take a photo of write the message on paper.







      boot 16.04 logs






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited May 18 '16 at 17:45

























      asked Apr 30 '16 at 6:37









      Mike

      2,81682150




      2,81682150






















          5 Answers
          5






          active

          oldest

          votes


















          10














          Reported as a bug that's an undocumented feature



          There is a bug report filed on this topic. Because rsyslog already maintains multiple boot journals in /var/log/syslog and syslog.1, .2.gz, .3.gz... syslog.7.gz the developers felt keeping extra journalctl logs would waste disk space.



          The bug report states on January 3, 2018 that for new installs rsyslog will no longer be the default and that journalctl will keep multiple boot data logs.



          Create multiple boot logs without reinstalling Ubuntu



          Most of us won't do a new install so to enable multiple journalctl boot logs in which case we can use:



          $ 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


          According to this github report the warning message "Cannot set file attribute" can be ignored.



          Optional persistent storage setting



          After using previous boot logging for many months I've discovered another option that can be set in /etc/systemd/journald.conf:




          Storage=



          Controls where to store journal data. One of "volatile", "persistent", "auto" and "none". If "volatile", journal log data will
          be stored only in memory, i.e. below the /run/log/journal hierarchy
          (which is created if needed). If "persistent", data will be stored
          preferably on disk, i.e. below the /var/log/journal hierarchy (which
          is created if needed), with a fallback to /run/log/journal (which is
          created if needed), during early boot and if the disk is not writable.
          "auto" is similar to "persistent" but the directory /var/log/journal
          is not created if needed, so that its existence controls where log
          data goes. "none" turns off all storage, all log data received will be
          dropped. Forwarding to other targets, such as the console, the kernel
          log buffer, or a syslog socket will still work however. Defaults to
          "auto".




          In a nutshell remove the comment and revise the line to:



          storage=persistent


          Display list of previous boots



          $ 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


          Display last boot log



          $ 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
          Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000000058000-0x0000000000058fff] reser
          Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000000059000-0x000000000009dfff] usabl
          Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x000000000009e000-0x000000000009ffff] reser
          Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000000100000-0x0000000030a5ffff] usabl
          Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030a60000-0x0000000030a71fff] reser
          Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030a72000-0x0000000030a89fff] usabl
          Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030a8a000-0x0000000030a8afff] ACPI
          Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030a8b000-0x0000000030ad4fff] reser
          Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030ad5000-0x0000000030b2dfff] usabl
          Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030b2e000-0x0000000031099fff] reser
          lines 1-29


          Pay close attention to the parameter -b-1 it is different than other references you may see.






          share|improve this answer























          • You would have to systemctl restart systemd-journald or killall -USR1 systemd-journald. Also uncomment Storage=auto from /etc/systemd/journald.conf.
            – Pablo Bianchi
            Mar 26 at 18:37












          • @PabloBianchi Thank you for your comment. As I've already created my multiple-boot logs and the vacuum cleaner to trim them down from 300MB + to < 150MB is setup as a monthly cron job I don't feel like deleting everything and starting over from scratch to test your recommendations. Hopefully it will help others to avoid the error messages which don't seem to effect anything anyway.
            – WinEunuuchs2Unix
            Mar 27 at 1:10










          • @PabloBianchi "storage=auto" is the default. I've revised my answer showing how "storage=persistent" is the recommendation cited from sources.
            – WinEunuuchs2Unix
            Aug 4 at 15:28



















          9














          I had the same issue, and apparently found the answer on the #ubuntu irc-channel.



          For whatsoever reason, I was missing the folder /var/log/journal group-accessible to systemd-journal.



          After adding the folder, I was able to see logs of previous boots via $ journalctl -b1






          share|improve this answer





















          • Thank you but, I already managed to make journalctl to work perfectly a while ago, but there is not boot log there, it is only kernel messages from boot time, I can find that elsewhere too. I did not manage to find a log containing messages that appear on screen during boot.
            – Mike
            May 18 '16 at 17:41






          • 10




            Actually alternative solution is given in wiki, namely set Storage=persistent in /etc/systemd/journald.conf and run systemctl restart systemd-journald.
            – dma_k
            Jun 20 '16 at 19:09






          • 1




            yup was mising /var/log/journal too! This is fresh install, how is something as important as journal is missing!!!
            – dashesy
            Aug 9 '16 at 21:22










          • In my case editing /etc/systemd/journald.conf created a previously nonexistant /var/log/journal/, and filled it with a subdirectory containing a loooong bootlog (took 1 minute to complete)
            – knb
            Oct 27 '16 at 8:18










          • @knb, fwiw, I'm pretty sure it's the systemctl restart systemd-journald that actually created your /var/log/journal
            – Auspex
            Nov 28 '16 at 15:17



















          3














          The steps to accomplish the solution from the top answer here, from the man page for systemd-journald:



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


          I did this as su






          share|improve this answer





























            3














            The answer can be found in man journald.conf, specifically the option Storage=:




            Controls where to store journal data. One of "volatile", "persistent", "auto" and "none". [...] "auto" is similar to "persistent" but the directory /var/log/journal is not created if needed, so that its existence controls where log data goes. [...] Defaults to "auto".




            Please keep in mind that there is no need for log rotation or similar techniques that were common with the old syslog daemon. The journal file is by default configured to grow to a certain size and old log entries are automatically deleted when the journal file grows too large.



            On my system this size is currently configured as 120MB, you can adjust it in /etc/systemd/journald.conf for the systemd-journald.service unit.






            share|improve this answer





























              3














              Use journalctl -bX where x is the boot you refer to, so -b0 is your actual boot and -b-1 the boot before (which only works if you have the folder /var/log/journal belonging to group 'systemd-journal' present). Cant tell you how far exactly you can go but those two for sure.



              List available boots with



              journalctl --list-boots





              share|improve this answer



















              • 2




                -b0 worked but -b1 gave me Specifying boot ID has no effect, no persistent journal was found. After some googling I think it has to be enabled for storing more data.
                – Mike
                Apr 30 '16 at 8:09










              • then my guess is the data is gone from that failed boot. Have a look here i just found out myself that is impossible without much hassle to reactivate the old logging. Had around 2 hours of fun fiddling around in my systems inerts.
                – Videonauth
                Apr 30 '16 at 8:12












              • Vote Up, but I hope somebody will add another way to do this, it would be shame if finding previous boot log from previous session is not possible with default config, how would one debug boot problems then?
                – Mike
                Apr 30 '16 at 18:16






              • 1




                The post here works in default config on Ubuntu Server 16.04LTS (unix.stackexchange.com/a/345978/77095) journalctl -o short-precise -k -b -1 shows last boot.
                – jtlindsey
                Aug 27 '17 at 12:16











              Your Answer








              StackExchange.ready(function() {
              var channelOptions = {
              tags: "".split(" "),
              id: "89"
              };
              initTagRenderer("".split(" "), "".split(" "), channelOptions);

              StackExchange.using("externalEditor", function() {
              // Have to fire editor after snippets, if snippets enabled
              if (StackExchange.settings.snippets.snippetsEnabled) {
              StackExchange.using("snippets", function() {
              createEditor();
              });
              }
              else {
              createEditor();
              }
              });

              function createEditor() {
              StackExchange.prepareEditor({
              heartbeatType: 'answer',
              autoActivateHeartbeat: false,
              convertImagesToLinks: true,
              noModals: true,
              showLowRepImageUploadWarning: true,
              reputationToPostImages: 10,
              bindNavPrevention: true,
              postfix: "",
              imageUploader: {
              brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
              contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
              allowUrls: true
              },
              onDemand: true,
              discardSelector: ".discard-answer"
              ,immediatelyShowMarkdownHelp:true
              });


              }
              });














              draft saved

              draft discarded


















              StackExchange.ready(
              function () {
              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f765315%2fhow-to-find-previous-boot-log-after-ubuntu-16-04-restarts%23new-answer', 'question_page');
              }
              );

              Post as a guest















              Required, but never shown

























              5 Answers
              5






              active

              oldest

              votes








              5 Answers
              5






              active

              oldest

              votes









              active

              oldest

              votes






              active

              oldest

              votes









              10














              Reported as a bug that's an undocumented feature



              There is a bug report filed on this topic. Because rsyslog already maintains multiple boot journals in /var/log/syslog and syslog.1, .2.gz, .3.gz... syslog.7.gz the developers felt keeping extra journalctl logs would waste disk space.



              The bug report states on January 3, 2018 that for new installs rsyslog will no longer be the default and that journalctl will keep multiple boot data logs.



              Create multiple boot logs without reinstalling Ubuntu



              Most of us won't do a new install so to enable multiple journalctl boot logs in which case we can use:



              $ 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


              According to this github report the warning message "Cannot set file attribute" can be ignored.



              Optional persistent storage setting



              After using previous boot logging for many months I've discovered another option that can be set in /etc/systemd/journald.conf:




              Storage=



              Controls where to store journal data. One of "volatile", "persistent", "auto" and "none". If "volatile", journal log data will
              be stored only in memory, i.e. below the /run/log/journal hierarchy
              (which is created if needed). If "persistent", data will be stored
              preferably on disk, i.e. below the /var/log/journal hierarchy (which
              is created if needed), with a fallback to /run/log/journal (which is
              created if needed), during early boot and if the disk is not writable.
              "auto" is similar to "persistent" but the directory /var/log/journal
              is not created if needed, so that its existence controls where log
              data goes. "none" turns off all storage, all log data received will be
              dropped. Forwarding to other targets, such as the console, the kernel
              log buffer, or a syslog socket will still work however. Defaults to
              "auto".




              In a nutshell remove the comment and revise the line to:



              storage=persistent


              Display list of previous boots



              $ 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


              Display last boot log



              $ 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
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000000058000-0x0000000000058fff] reser
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000000059000-0x000000000009dfff] usabl
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x000000000009e000-0x000000000009ffff] reser
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000000100000-0x0000000030a5ffff] usabl
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030a60000-0x0000000030a71fff] reser
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030a72000-0x0000000030a89fff] usabl
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030a8a000-0x0000000030a8afff] ACPI
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030a8b000-0x0000000030ad4fff] reser
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030ad5000-0x0000000030b2dfff] usabl
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030b2e000-0x0000000031099fff] reser
              lines 1-29


              Pay close attention to the parameter -b-1 it is different than other references you may see.






              share|improve this answer























              • You would have to systemctl restart systemd-journald or killall -USR1 systemd-journald. Also uncomment Storage=auto from /etc/systemd/journald.conf.
                – Pablo Bianchi
                Mar 26 at 18:37












              • @PabloBianchi Thank you for your comment. As I've already created my multiple-boot logs and the vacuum cleaner to trim them down from 300MB + to < 150MB is setup as a monthly cron job I don't feel like deleting everything and starting over from scratch to test your recommendations. Hopefully it will help others to avoid the error messages which don't seem to effect anything anyway.
                – WinEunuuchs2Unix
                Mar 27 at 1:10










              • @PabloBianchi "storage=auto" is the default. I've revised my answer showing how "storage=persistent" is the recommendation cited from sources.
                – WinEunuuchs2Unix
                Aug 4 at 15:28
















              10














              Reported as a bug that's an undocumented feature



              There is a bug report filed on this topic. Because rsyslog already maintains multiple boot journals in /var/log/syslog and syslog.1, .2.gz, .3.gz... syslog.7.gz the developers felt keeping extra journalctl logs would waste disk space.



              The bug report states on January 3, 2018 that for new installs rsyslog will no longer be the default and that journalctl will keep multiple boot data logs.



              Create multiple boot logs without reinstalling Ubuntu



              Most of us won't do a new install so to enable multiple journalctl boot logs in which case we can use:



              $ 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


              According to this github report the warning message "Cannot set file attribute" can be ignored.



              Optional persistent storage setting



              After using previous boot logging for many months I've discovered another option that can be set in /etc/systemd/journald.conf:




              Storage=



              Controls where to store journal data. One of "volatile", "persistent", "auto" and "none". If "volatile", journal log data will
              be stored only in memory, i.e. below the /run/log/journal hierarchy
              (which is created if needed). If "persistent", data will be stored
              preferably on disk, i.e. below the /var/log/journal hierarchy (which
              is created if needed), with a fallback to /run/log/journal (which is
              created if needed), during early boot and if the disk is not writable.
              "auto" is similar to "persistent" but the directory /var/log/journal
              is not created if needed, so that its existence controls where log
              data goes. "none" turns off all storage, all log data received will be
              dropped. Forwarding to other targets, such as the console, the kernel
              log buffer, or a syslog socket will still work however. Defaults to
              "auto".




              In a nutshell remove the comment and revise the line to:



              storage=persistent


              Display list of previous boots



              $ 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


              Display last boot log



              $ 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
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000000058000-0x0000000000058fff] reser
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000000059000-0x000000000009dfff] usabl
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x000000000009e000-0x000000000009ffff] reser
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000000100000-0x0000000030a5ffff] usabl
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030a60000-0x0000000030a71fff] reser
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030a72000-0x0000000030a89fff] usabl
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030a8a000-0x0000000030a8afff] ACPI
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030a8b000-0x0000000030ad4fff] reser
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030ad5000-0x0000000030b2dfff] usabl
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030b2e000-0x0000000031099fff] reser
              lines 1-29


              Pay close attention to the parameter -b-1 it is different than other references you may see.






              share|improve this answer























              • You would have to systemctl restart systemd-journald or killall -USR1 systemd-journald. Also uncomment Storage=auto from /etc/systemd/journald.conf.
                – Pablo Bianchi
                Mar 26 at 18:37












              • @PabloBianchi Thank you for your comment. As I've already created my multiple-boot logs and the vacuum cleaner to trim them down from 300MB + to < 150MB is setup as a monthly cron job I don't feel like deleting everything and starting over from scratch to test your recommendations. Hopefully it will help others to avoid the error messages which don't seem to effect anything anyway.
                – WinEunuuchs2Unix
                Mar 27 at 1:10










              • @PabloBianchi "storage=auto" is the default. I've revised my answer showing how "storage=persistent" is the recommendation cited from sources.
                – WinEunuuchs2Unix
                Aug 4 at 15:28














              10












              10








              10






              Reported as a bug that's an undocumented feature



              There is a bug report filed on this topic. Because rsyslog already maintains multiple boot journals in /var/log/syslog and syslog.1, .2.gz, .3.gz... syslog.7.gz the developers felt keeping extra journalctl logs would waste disk space.



              The bug report states on January 3, 2018 that for new installs rsyslog will no longer be the default and that journalctl will keep multiple boot data logs.



              Create multiple boot logs without reinstalling Ubuntu



              Most of us won't do a new install so to enable multiple journalctl boot logs in which case we can use:



              $ 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


              According to this github report the warning message "Cannot set file attribute" can be ignored.



              Optional persistent storage setting



              After using previous boot logging for many months I've discovered another option that can be set in /etc/systemd/journald.conf:




              Storage=



              Controls where to store journal data. One of "volatile", "persistent", "auto" and "none". If "volatile", journal log data will
              be stored only in memory, i.e. below the /run/log/journal hierarchy
              (which is created if needed). If "persistent", data will be stored
              preferably on disk, i.e. below the /var/log/journal hierarchy (which
              is created if needed), with a fallback to /run/log/journal (which is
              created if needed), during early boot and if the disk is not writable.
              "auto" is similar to "persistent" but the directory /var/log/journal
              is not created if needed, so that its existence controls where log
              data goes. "none" turns off all storage, all log data received will be
              dropped. Forwarding to other targets, such as the console, the kernel
              log buffer, or a syslog socket will still work however. Defaults to
              "auto".




              In a nutshell remove the comment and revise the line to:



              storage=persistent


              Display list of previous boots



              $ 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


              Display last boot log



              $ 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
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000000058000-0x0000000000058fff] reser
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000000059000-0x000000000009dfff] usabl
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x000000000009e000-0x000000000009ffff] reser
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000000100000-0x0000000030a5ffff] usabl
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030a60000-0x0000000030a71fff] reser
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030a72000-0x0000000030a89fff] usabl
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030a8a000-0x0000000030a8afff] ACPI
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030a8b000-0x0000000030ad4fff] reser
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030ad5000-0x0000000030b2dfff] usabl
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030b2e000-0x0000000031099fff] reser
              lines 1-29


              Pay close attention to the parameter -b-1 it is different than other references you may see.






              share|improve this answer














              Reported as a bug that's an undocumented feature



              There is a bug report filed on this topic. Because rsyslog already maintains multiple boot journals in /var/log/syslog and syslog.1, .2.gz, .3.gz... syslog.7.gz the developers felt keeping extra journalctl logs would waste disk space.



              The bug report states on January 3, 2018 that for new installs rsyslog will no longer be the default and that journalctl will keep multiple boot data logs.



              Create multiple boot logs without reinstalling Ubuntu



              Most of us won't do a new install so to enable multiple journalctl boot logs in which case we can use:



              $ 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


              According to this github report the warning message "Cannot set file attribute" can be ignored.



              Optional persistent storage setting



              After using previous boot logging for many months I've discovered another option that can be set in /etc/systemd/journald.conf:




              Storage=



              Controls where to store journal data. One of "volatile", "persistent", "auto" and "none". If "volatile", journal log data will
              be stored only in memory, i.e. below the /run/log/journal hierarchy
              (which is created if needed). If "persistent", data will be stored
              preferably on disk, i.e. below the /var/log/journal hierarchy (which
              is created if needed), with a fallback to /run/log/journal (which is
              created if needed), during early boot and if the disk is not writable.
              "auto" is similar to "persistent" but the directory /var/log/journal
              is not created if needed, so that its existence controls where log
              data goes. "none" turns off all storage, all log data received will be
              dropped. Forwarding to other targets, such as the console, the kernel
              log buffer, or a syslog socket will still work however. Defaults to
              "auto".




              In a nutshell remove the comment and revise the line to:



              storage=persistent


              Display list of previous boots



              $ 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


              Display last boot log



              $ 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
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000000058000-0x0000000000058fff] reser
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000000059000-0x000000000009dfff] usabl
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x000000000009e000-0x000000000009ffff] reser
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000000100000-0x0000000030a5ffff] usabl
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030a60000-0x0000000030a71fff] reser
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030a72000-0x0000000030a89fff] usabl
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030a8a000-0x0000000030a8afff] ACPI
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030a8b000-0x0000000030ad4fff] reser
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030ad5000-0x0000000030b2dfff] usabl
              Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000030b2e000-0x0000000031099fff] reser
              lines 1-29


              Pay close attention to the parameter -b-1 it is different than other references you may see.







              share|improve this answer














              share|improve this answer



              share|improve this answer








              edited Aug 4 at 15:28

























              answered Feb 21 at 1:24









              WinEunuuchs2Unix

              43.2k1075163




              43.2k1075163












              • You would have to systemctl restart systemd-journald or killall -USR1 systemd-journald. Also uncomment Storage=auto from /etc/systemd/journald.conf.
                – Pablo Bianchi
                Mar 26 at 18:37












              • @PabloBianchi Thank you for your comment. As I've already created my multiple-boot logs and the vacuum cleaner to trim them down from 300MB + to < 150MB is setup as a monthly cron job I don't feel like deleting everything and starting over from scratch to test your recommendations. Hopefully it will help others to avoid the error messages which don't seem to effect anything anyway.
                – WinEunuuchs2Unix
                Mar 27 at 1:10










              • @PabloBianchi "storage=auto" is the default. I've revised my answer showing how "storage=persistent" is the recommendation cited from sources.
                – WinEunuuchs2Unix
                Aug 4 at 15:28


















              • You would have to systemctl restart systemd-journald or killall -USR1 systemd-journald. Also uncomment Storage=auto from /etc/systemd/journald.conf.
                – Pablo Bianchi
                Mar 26 at 18:37












              • @PabloBianchi Thank you for your comment. As I've already created my multiple-boot logs and the vacuum cleaner to trim them down from 300MB + to < 150MB is setup as a monthly cron job I don't feel like deleting everything and starting over from scratch to test your recommendations. Hopefully it will help others to avoid the error messages which don't seem to effect anything anyway.
                – WinEunuuchs2Unix
                Mar 27 at 1:10










              • @PabloBianchi "storage=auto" is the default. I've revised my answer showing how "storage=persistent" is the recommendation cited from sources.
                – WinEunuuchs2Unix
                Aug 4 at 15:28
















              You would have to systemctl restart systemd-journald or killall -USR1 systemd-journald. Also uncomment Storage=auto from /etc/systemd/journald.conf.
              – Pablo Bianchi
              Mar 26 at 18:37






              You would have to systemctl restart systemd-journald or killall -USR1 systemd-journald. Also uncomment Storage=auto from /etc/systemd/journald.conf.
              – Pablo Bianchi
              Mar 26 at 18:37














              @PabloBianchi Thank you for your comment. As I've already created my multiple-boot logs and the vacuum cleaner to trim them down from 300MB + to < 150MB is setup as a monthly cron job I don't feel like deleting everything and starting over from scratch to test your recommendations. Hopefully it will help others to avoid the error messages which don't seem to effect anything anyway.
              – WinEunuuchs2Unix
              Mar 27 at 1:10




              @PabloBianchi Thank you for your comment. As I've already created my multiple-boot logs and the vacuum cleaner to trim them down from 300MB + to < 150MB is setup as a monthly cron job I don't feel like deleting everything and starting over from scratch to test your recommendations. Hopefully it will help others to avoid the error messages which don't seem to effect anything anyway.
              – WinEunuuchs2Unix
              Mar 27 at 1:10












              @PabloBianchi "storage=auto" is the default. I've revised my answer showing how "storage=persistent" is the recommendation cited from sources.
              – WinEunuuchs2Unix
              Aug 4 at 15:28




              @PabloBianchi "storage=auto" is the default. I've revised my answer showing how "storage=persistent" is the recommendation cited from sources.
              – WinEunuuchs2Unix
              Aug 4 at 15:28













              9














              I had the same issue, and apparently found the answer on the #ubuntu irc-channel.



              For whatsoever reason, I was missing the folder /var/log/journal group-accessible to systemd-journal.



              After adding the folder, I was able to see logs of previous boots via $ journalctl -b1






              share|improve this answer





















              • Thank you but, I already managed to make journalctl to work perfectly a while ago, but there is not boot log there, it is only kernel messages from boot time, I can find that elsewhere too. I did not manage to find a log containing messages that appear on screen during boot.
                – Mike
                May 18 '16 at 17:41






              • 10




                Actually alternative solution is given in wiki, namely set Storage=persistent in /etc/systemd/journald.conf and run systemctl restart systemd-journald.
                – dma_k
                Jun 20 '16 at 19:09






              • 1




                yup was mising /var/log/journal too! This is fresh install, how is something as important as journal is missing!!!
                – dashesy
                Aug 9 '16 at 21:22










              • In my case editing /etc/systemd/journald.conf created a previously nonexistant /var/log/journal/, and filled it with a subdirectory containing a loooong bootlog (took 1 minute to complete)
                – knb
                Oct 27 '16 at 8:18










              • @knb, fwiw, I'm pretty sure it's the systemctl restart systemd-journald that actually created your /var/log/journal
                – Auspex
                Nov 28 '16 at 15:17
















              9














              I had the same issue, and apparently found the answer on the #ubuntu irc-channel.



              For whatsoever reason, I was missing the folder /var/log/journal group-accessible to systemd-journal.



              After adding the folder, I was able to see logs of previous boots via $ journalctl -b1






              share|improve this answer





















              • Thank you but, I already managed to make journalctl to work perfectly a while ago, but there is not boot log there, it is only kernel messages from boot time, I can find that elsewhere too. I did not manage to find a log containing messages that appear on screen during boot.
                – Mike
                May 18 '16 at 17:41






              • 10




                Actually alternative solution is given in wiki, namely set Storage=persistent in /etc/systemd/journald.conf and run systemctl restart systemd-journald.
                – dma_k
                Jun 20 '16 at 19:09






              • 1




                yup was mising /var/log/journal too! This is fresh install, how is something as important as journal is missing!!!
                – dashesy
                Aug 9 '16 at 21:22










              • In my case editing /etc/systemd/journald.conf created a previously nonexistant /var/log/journal/, and filled it with a subdirectory containing a loooong bootlog (took 1 minute to complete)
                – knb
                Oct 27 '16 at 8:18










              • @knb, fwiw, I'm pretty sure it's the systemctl restart systemd-journald that actually created your /var/log/journal
                – Auspex
                Nov 28 '16 at 15:17














              9












              9








              9






              I had the same issue, and apparently found the answer on the #ubuntu irc-channel.



              For whatsoever reason, I was missing the folder /var/log/journal group-accessible to systemd-journal.



              After adding the folder, I was able to see logs of previous boots via $ journalctl -b1






              share|improve this answer












              I had the same issue, and apparently found the answer on the #ubuntu irc-channel.



              For whatsoever reason, I was missing the folder /var/log/journal group-accessible to systemd-journal.



              After adding the folder, I was able to see logs of previous boots via $ journalctl -b1







              share|improve this answer












              share|improve this answer



              share|improve this answer










              answered May 18 '16 at 17:27









              dbacc

              965




              965












              • Thank you but, I already managed to make journalctl to work perfectly a while ago, but there is not boot log there, it is only kernel messages from boot time, I can find that elsewhere too. I did not manage to find a log containing messages that appear on screen during boot.
                – Mike
                May 18 '16 at 17:41






              • 10




                Actually alternative solution is given in wiki, namely set Storage=persistent in /etc/systemd/journald.conf and run systemctl restart systemd-journald.
                – dma_k
                Jun 20 '16 at 19:09






              • 1




                yup was mising /var/log/journal too! This is fresh install, how is something as important as journal is missing!!!
                – dashesy
                Aug 9 '16 at 21:22










              • In my case editing /etc/systemd/journald.conf created a previously nonexistant /var/log/journal/, and filled it with a subdirectory containing a loooong bootlog (took 1 minute to complete)
                – knb
                Oct 27 '16 at 8:18










              • @knb, fwiw, I'm pretty sure it's the systemctl restart systemd-journald that actually created your /var/log/journal
                – Auspex
                Nov 28 '16 at 15:17


















              • Thank you but, I already managed to make journalctl to work perfectly a while ago, but there is not boot log there, it is only kernel messages from boot time, I can find that elsewhere too. I did not manage to find a log containing messages that appear on screen during boot.
                – Mike
                May 18 '16 at 17:41






              • 10




                Actually alternative solution is given in wiki, namely set Storage=persistent in /etc/systemd/journald.conf and run systemctl restart systemd-journald.
                – dma_k
                Jun 20 '16 at 19:09






              • 1




                yup was mising /var/log/journal too! This is fresh install, how is something as important as journal is missing!!!
                – dashesy
                Aug 9 '16 at 21:22










              • In my case editing /etc/systemd/journald.conf created a previously nonexistant /var/log/journal/, and filled it with a subdirectory containing a loooong bootlog (took 1 minute to complete)
                – knb
                Oct 27 '16 at 8:18










              • @knb, fwiw, I'm pretty sure it's the systemctl restart systemd-journald that actually created your /var/log/journal
                – Auspex
                Nov 28 '16 at 15:17
















              Thank you but, I already managed to make journalctl to work perfectly a while ago, but there is not boot log there, it is only kernel messages from boot time, I can find that elsewhere too. I did not manage to find a log containing messages that appear on screen during boot.
              – Mike
              May 18 '16 at 17:41




              Thank you but, I already managed to make journalctl to work perfectly a while ago, but there is not boot log there, it is only kernel messages from boot time, I can find that elsewhere too. I did not manage to find a log containing messages that appear on screen during boot.
              – Mike
              May 18 '16 at 17:41




              10




              10




              Actually alternative solution is given in wiki, namely set Storage=persistent in /etc/systemd/journald.conf and run systemctl restart systemd-journald.
              – dma_k
              Jun 20 '16 at 19:09




              Actually alternative solution is given in wiki, namely set Storage=persistent in /etc/systemd/journald.conf and run systemctl restart systemd-journald.
              – dma_k
              Jun 20 '16 at 19:09




              1




              1




              yup was mising /var/log/journal too! This is fresh install, how is something as important as journal is missing!!!
              – dashesy
              Aug 9 '16 at 21:22




              yup was mising /var/log/journal too! This is fresh install, how is something as important as journal is missing!!!
              – dashesy
              Aug 9 '16 at 21:22












              In my case editing /etc/systemd/journald.conf created a previously nonexistant /var/log/journal/, and filled it with a subdirectory containing a loooong bootlog (took 1 minute to complete)
              – knb
              Oct 27 '16 at 8:18




              In my case editing /etc/systemd/journald.conf created a previously nonexistant /var/log/journal/, and filled it with a subdirectory containing a loooong bootlog (took 1 minute to complete)
              – knb
              Oct 27 '16 at 8:18












              @knb, fwiw, I'm pretty sure it's the systemctl restart systemd-journald that actually created your /var/log/journal
              – Auspex
              Nov 28 '16 at 15:17




              @knb, fwiw, I'm pretty sure it's the systemctl restart systemd-journald that actually created your /var/log/journal
              – Auspex
              Nov 28 '16 at 15:17











              3














              The steps to accomplish the solution from the top answer here, from the man page for systemd-journald:



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


              I did this as su






              share|improve this answer


























                3














                The steps to accomplish the solution from the top answer here, from the man page for systemd-journald:



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


                I did this as su






                share|improve this answer
























                  3












                  3








                  3






                  The steps to accomplish the solution from the top answer here, from the man page for systemd-journald:



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


                  I did this as su






                  share|improve this answer












                  The steps to accomplish the solution from the top answer here, from the man page for systemd-journald:



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


                  I did this as su







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Dec 7 '16 at 18:21









                  Aaron Skomra

                  361314




                  361314























                      3














                      The answer can be found in man journald.conf, specifically the option Storage=:




                      Controls where to store journal data. One of "volatile", "persistent", "auto" and "none". [...] "auto" is similar to "persistent" but the directory /var/log/journal is not created if needed, so that its existence controls where log data goes. [...] Defaults to "auto".




                      Please keep in mind that there is no need for log rotation or similar techniques that were common with the old syslog daemon. The journal file is by default configured to grow to a certain size and old log entries are automatically deleted when the journal file grows too large.



                      On my system this size is currently configured as 120MB, you can adjust it in /etc/systemd/journald.conf for the systemd-journald.service unit.






                      share|improve this answer


























                        3














                        The answer can be found in man journald.conf, specifically the option Storage=:




                        Controls where to store journal data. One of "volatile", "persistent", "auto" and "none". [...] "auto" is similar to "persistent" but the directory /var/log/journal is not created if needed, so that its existence controls where log data goes. [...] Defaults to "auto".




                        Please keep in mind that there is no need for log rotation or similar techniques that were common with the old syslog daemon. The journal file is by default configured to grow to a certain size and old log entries are automatically deleted when the journal file grows too large.



                        On my system this size is currently configured as 120MB, you can adjust it in /etc/systemd/journald.conf for the systemd-journald.service unit.






                        share|improve this answer
























                          3












                          3








                          3






                          The answer can be found in man journald.conf, specifically the option Storage=:




                          Controls where to store journal data. One of "volatile", "persistent", "auto" and "none". [...] "auto" is similar to "persistent" but the directory /var/log/journal is not created if needed, so that its existence controls where log data goes. [...] Defaults to "auto".




                          Please keep in mind that there is no need for log rotation or similar techniques that were common with the old syslog daemon. The journal file is by default configured to grow to a certain size and old log entries are automatically deleted when the journal file grows too large.



                          On my system this size is currently configured as 120MB, you can adjust it in /etc/systemd/journald.conf for the systemd-journald.service unit.






                          share|improve this answer












                          The answer can be found in man journald.conf, specifically the option Storage=:




                          Controls where to store journal data. One of "volatile", "persistent", "auto" and "none". [...] "auto" is similar to "persistent" but the directory /var/log/journal is not created if needed, so that its existence controls where log data goes. [...] Defaults to "auto".




                          Please keep in mind that there is no need for log rotation or similar techniques that were common with the old syslog daemon. The journal file is by default configured to grow to a certain size and old log entries are automatically deleted when the journal file grows too large.



                          On my system this size is currently configured as 120MB, you can adjust it in /etc/systemd/journald.conf for the systemd-journald.service unit.







                          share|improve this answer












                          share|improve this answer



                          share|improve this answer










                          answered Jan 12 '17 at 21:42









                          lanoxx

                          5692517




                          5692517























                              3














                              Use journalctl -bX where x is the boot you refer to, so -b0 is your actual boot and -b-1 the boot before (which only works if you have the folder /var/log/journal belonging to group 'systemd-journal' present). Cant tell you how far exactly you can go but those two for sure.



                              List available boots with



                              journalctl --list-boots





                              share|improve this answer



















                              • 2




                                -b0 worked but -b1 gave me Specifying boot ID has no effect, no persistent journal was found. After some googling I think it has to be enabled for storing more data.
                                – Mike
                                Apr 30 '16 at 8:09










                              • then my guess is the data is gone from that failed boot. Have a look here i just found out myself that is impossible without much hassle to reactivate the old logging. Had around 2 hours of fun fiddling around in my systems inerts.
                                – Videonauth
                                Apr 30 '16 at 8:12












                              • Vote Up, but I hope somebody will add another way to do this, it would be shame if finding previous boot log from previous session is not possible with default config, how would one debug boot problems then?
                                – Mike
                                Apr 30 '16 at 18:16






                              • 1




                                The post here works in default config on Ubuntu Server 16.04LTS (unix.stackexchange.com/a/345978/77095) journalctl -o short-precise -k -b -1 shows last boot.
                                – jtlindsey
                                Aug 27 '17 at 12:16
















                              3














                              Use journalctl -bX where x is the boot you refer to, so -b0 is your actual boot and -b-1 the boot before (which only works if you have the folder /var/log/journal belonging to group 'systemd-journal' present). Cant tell you how far exactly you can go but those two for sure.



                              List available boots with



                              journalctl --list-boots





                              share|improve this answer



















                              • 2




                                -b0 worked but -b1 gave me Specifying boot ID has no effect, no persistent journal was found. After some googling I think it has to be enabled for storing more data.
                                – Mike
                                Apr 30 '16 at 8:09










                              • then my guess is the data is gone from that failed boot. Have a look here i just found out myself that is impossible without much hassle to reactivate the old logging. Had around 2 hours of fun fiddling around in my systems inerts.
                                – Videonauth
                                Apr 30 '16 at 8:12












                              • Vote Up, but I hope somebody will add another way to do this, it would be shame if finding previous boot log from previous session is not possible with default config, how would one debug boot problems then?
                                – Mike
                                Apr 30 '16 at 18:16






                              • 1




                                The post here works in default config on Ubuntu Server 16.04LTS (unix.stackexchange.com/a/345978/77095) journalctl -o short-precise -k -b -1 shows last boot.
                                – jtlindsey
                                Aug 27 '17 at 12:16














                              3












                              3








                              3






                              Use journalctl -bX where x is the boot you refer to, so -b0 is your actual boot and -b-1 the boot before (which only works if you have the folder /var/log/journal belonging to group 'systemd-journal' present). Cant tell you how far exactly you can go but those two for sure.



                              List available boots with



                              journalctl --list-boots





                              share|improve this answer














                              Use journalctl -bX where x is the boot you refer to, so -b0 is your actual boot and -b-1 the boot before (which only works if you have the folder /var/log/journal belonging to group 'systemd-journal' present). Cant tell you how far exactly you can go but those two for sure.



                              List available boots with



                              journalctl --list-boots






                              share|improve this answer














                              share|improve this answer



                              share|improve this answer








                              edited Dec 23 at 23:15









                              Pablo Bianchi

                              2,3481528




                              2,3481528










                              answered Apr 30 '16 at 7:58









                              Videonauth

                              23.7k126898




                              23.7k126898








                              • 2




                                -b0 worked but -b1 gave me Specifying boot ID has no effect, no persistent journal was found. After some googling I think it has to be enabled for storing more data.
                                – Mike
                                Apr 30 '16 at 8:09










                              • then my guess is the data is gone from that failed boot. Have a look here i just found out myself that is impossible without much hassle to reactivate the old logging. Had around 2 hours of fun fiddling around in my systems inerts.
                                – Videonauth
                                Apr 30 '16 at 8:12












                              • Vote Up, but I hope somebody will add another way to do this, it would be shame if finding previous boot log from previous session is not possible with default config, how would one debug boot problems then?
                                – Mike
                                Apr 30 '16 at 18:16






                              • 1




                                The post here works in default config on Ubuntu Server 16.04LTS (unix.stackexchange.com/a/345978/77095) journalctl -o short-precise -k -b -1 shows last boot.
                                – jtlindsey
                                Aug 27 '17 at 12:16














                              • 2




                                -b0 worked but -b1 gave me Specifying boot ID has no effect, no persistent journal was found. After some googling I think it has to be enabled for storing more data.
                                – Mike
                                Apr 30 '16 at 8:09










                              • then my guess is the data is gone from that failed boot. Have a look here i just found out myself that is impossible without much hassle to reactivate the old logging. Had around 2 hours of fun fiddling around in my systems inerts.
                                – Videonauth
                                Apr 30 '16 at 8:12












                              • Vote Up, but I hope somebody will add another way to do this, it would be shame if finding previous boot log from previous session is not possible with default config, how would one debug boot problems then?
                                – Mike
                                Apr 30 '16 at 18:16






                              • 1




                                The post here works in default config on Ubuntu Server 16.04LTS (unix.stackexchange.com/a/345978/77095) journalctl -o short-precise -k -b -1 shows last boot.
                                – jtlindsey
                                Aug 27 '17 at 12:16








                              2




                              2




                              -b0 worked but -b1 gave me Specifying boot ID has no effect, no persistent journal was found. After some googling I think it has to be enabled for storing more data.
                              – Mike
                              Apr 30 '16 at 8:09




                              -b0 worked but -b1 gave me Specifying boot ID has no effect, no persistent journal was found. After some googling I think it has to be enabled for storing more data.
                              – Mike
                              Apr 30 '16 at 8:09












                              then my guess is the data is gone from that failed boot. Have a look here i just found out myself that is impossible without much hassle to reactivate the old logging. Had around 2 hours of fun fiddling around in my systems inerts.
                              – Videonauth
                              Apr 30 '16 at 8:12






                              then my guess is the data is gone from that failed boot. Have a look here i just found out myself that is impossible without much hassle to reactivate the old logging. Had around 2 hours of fun fiddling around in my systems inerts.
                              – Videonauth
                              Apr 30 '16 at 8:12














                              Vote Up, but I hope somebody will add another way to do this, it would be shame if finding previous boot log from previous session is not possible with default config, how would one debug boot problems then?
                              – Mike
                              Apr 30 '16 at 18:16




                              Vote Up, but I hope somebody will add another way to do this, it would be shame if finding previous boot log from previous session is not possible with default config, how would one debug boot problems then?
                              – Mike
                              Apr 30 '16 at 18:16




                              1




                              1




                              The post here works in default config on Ubuntu Server 16.04LTS (unix.stackexchange.com/a/345978/77095) journalctl -o short-precise -k -b -1 shows last boot.
                              – jtlindsey
                              Aug 27 '17 at 12:16




                              The post here works in default config on Ubuntu Server 16.04LTS (unix.stackexchange.com/a/345978/77095) journalctl -o short-precise -k -b -1 shows last boot.
                              – jtlindsey
                              Aug 27 '17 at 12:16


















                              draft saved

                              draft discarded




















































                              Thanks for contributing an answer to Ask Ubuntu!


                              • Please be sure to answer the question. Provide details and share your research!

                              But avoid



                              • Asking for help, clarification, or responding to other answers.

                              • Making statements based on opinion; back them up with references or personal experience.


                              To learn more, see our tips on writing great answers.





                              Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                              Please pay close attention to the following guidance:


                              • Please be sure to answer the question. Provide details and share your research!

                              But avoid



                              • Asking for help, clarification, or responding to other answers.

                              • Making statements based on opinion; back them up with references or personal experience.


                              To learn more, see our tips on writing great answers.




                              draft saved


                              draft discarded














                              StackExchange.ready(
                              function () {
                              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f765315%2fhow-to-find-previous-boot-log-after-ubuntu-16-04-restarts%23new-answer', 'question_page');
                              }
                              );

                              Post as a guest















                              Required, but never shown





















































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown

































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown







                              Popular posts from this blog

                              數位音樂下載

                              When can things happen in Etherscan, such as the picture below?

                              格利澤436b