<div dir="ltr">package: systemd<div>version: 241-7~deb10u2</div><div>severity: important</div><div><br></div><div>Prior to adopting systemd we had a init.d script /etc/init.d/bootmisc.sh which had run just before login and at the end of this script it had done a dmesg > /var/log/dmesg preserving the boot time kernel messages.</div><div><br></div><div>As a long time supporter on IRC, I consider these messages to be critical to providing support to our users. I had been frustrated by this no longer being available and then I found journalctl -k and thought I'd found a reliable solution.</div><div><br></div><div>However it has come to my attention in doing support tonight, that a user said they only had two lines in the output of journalctl -k and I have checked all my systems and found that I too had one that has been up 27 days and journalctl -k only had two lines in it. I have machines here that have been up far longer and go all the way back to boot. Including machines up over 90 days with more than 3G worth of logs where the machine I have with this issue has only 38.2M of logs, only 11% of /run in use, and all logs pass verification, yet I don't have my boot messages. All my machines are using the default journald configs and do not have the persistent logs dir.</div><div><br></div><div>My concern is that we find a way that all our users preserve these kernel boot messages by default for support purposes so as volunteer supporters we have a reliable method of checking these messages for issues. If journald is supposed to address this, I now have two confirmed cases from one of my machines and another supporter's machine where this is not the case. I don't care if we just have a systemd oneshot unit that mimics the behavior of bootmisc.sh and simply does dmesg > /var/log/dmesg at boot, but I feel it is critical to providing good support that we make sure that these messages are preserved.</div><div><br></div><div>If there is any more information I could provide, please let me know.</div></div>