Your message dated Wed, 25 Nov 2020 03:14:13 +0100
with message-id <[email protected]>
and subject line Re: kernel boot messages are not longer reliably kept by
default
has caused the Debian Bug report #970219,
regarding kernel boot messages are not longer reliably kept by default
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
970219: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970219
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
package: systemd
version: 241-7~deb10u2
severity: important
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.
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.
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.
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.
If there is any more information I could provide, please let me know.
--- End Message ---
--- Begin Message ---
On Sun, 13 Sep 2020 01:53:16 -0400 Scott Nanni <[email protected]> wrote:
package: systemd
version: 241-7~deb10u2
severity: important
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.
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.
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.
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.
In buster and before, the default journal configuration is indeed that
we use volatile storage, i.e. /run, which is usually limited space wise.
That said, all messages are forwarded to your syslog daemon (rsyslog by
default), where the messages are persistently stored in /var/log and
your kernel messages should end up in /var/log/kern.log.
In bullseye we enable persistent journal storage, i.e. we don't have the
same space limitations as for /run anymore, i.e. you should be able to
get your kernel messages from journalctl.
I thus don't see the need to add a separate service which dumps the
output of dmesg and basically duplicating that information.
Regards,
Michael
--- End Message ---
