Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #56667 > unrolled thread

Bug#852194: make a /run/initramfs/messages

Back to article view | Back to linux.debian.kernel

Contents

  Bug#852194: make a /run/initramfs/messages Dan Jacobson <jidanni@jidanni.org> - 2017-01-22 13:10 +0100
    Bug#852194: make a /run/initramfs/messages Ben Hutchings <ben@decadent.org.uk> - 2017-01-22 18:40 +0100
    Bug#852194: make a /run/initramfs/messages 積丹尼 Dan Jacobson <jidanni@jidanni.org> - 2017-01-22 19:40 +0100
      Bug#852194: make a /run/initramfs/messages Ben Hutchings <ben@decadent.org.uk> - 2017-01-22 20:00 +0100
    Bug#852194: make a /run/initramfs/messages 積丹尼 Dan Jacobson <jidanni@jidanni.org> - 2017-01-23 01:10 +0100
      Bug#852194: make a /run/initramfs/messages Ben Hutchings <ben@decadent.org.uk> - 2017-01-23 02:10 +0100

#56667 — Bug#852194: make a /run/initramfs/messages

Package: initramfs-tools
Version: 0.126
Severity: wishlist

You generate
/run/initramfs/fsck-root
/run/initramfs/fsck.log
Good.

Please also generate a similar log of the messages that the user sees
fly by upon boot before the ones that are captured by journalctl.

Actually it turns out they are not messages before boot,
but messages during boot that don't have [ timestamps ] on them.
There are not logged anywhere, and fly off the screen.

E.g., I saw one, something about "Failed to start ..." that was just
outside of what I could pull back down with Shift-PageUp. Below it,
still thankfully on the screen was a message that told me to do
"systemctl status systemd-modules-load.service".
Again, both messages were not in journalctl.

(One would think changing log_buf_len boot parameter would give more
lines, but it doesn't.)

[toc] | [next] | [standalone]

#56671

[Multipart message — attachments visible in raw view] — view raw

On Sun, 2017-01-22 at 18:34 +0800, Dan Jacobson wrote:
> Package: initramfs-tools
> Version: 0.126
> Severity: wishlist
> 
> You generate
> /run/initramfs/fsck-root
> /run/initramfs/fsck.log
> Good.
> 
> Please also generate a similar log of the messages that the user sees
> fly by upon boot before the ones that are captured by journalctl.
> 
> Actually it turns out they are not messages before boot,
> but messages during boot that don't have [ timestamps ] on them.
> There are not logged anywhere, and fly off the screen.
> 
> E.g., I saw one, something about "Failed to start ..." that was just
> outside of what I could pull back down with Shift-PageUp. Below it,
> still thankfully on the screen was a message that told me to do
> "systemctl status systemd-modules-load.service".
> Again, both messages were not in journalctl.

initramfs-tools does not use systemd.  If systemd is failing to log its
 output at boot time, that is not a bug in initramfs-tools.

(I recognise that initramfs-tools should log output before it hands
over to systemd (or other init system), so this is a valid bug. 
Unfortunately it will not be easy to do this consistently.)

Ben.

> (One would think changing log_buf_len boot parameter would give more
> lines, but it doesn't.)
> 
-- 
Ben Hutchings
For every complex problem
there is a solution that is simple, neat, and wrong.

[toc] | [prev] | [next] | [standalone]

#56675

BH> initramfs-tools does not use systemd.  If systemd is failing to log its
BH>  output at boot time, that is not a bug in initramfs-tools.

OK I filed #852229 [systemd] failing to log output at boot time

BH> (I recognise that initramfs-tools should log output before it hands
BH> over to systemd (or other init system), so this is a valid bug.
BH> Unfortunately it will not be easy to do this consistently.)

Yes even though the user sees them flying by in the original order on
the screen, alas you will probably have to collect them into separate files
depending on where they came from. It is too bad they can't be put into
the dmesg/syslog... or actually they could. With just a simple logger(1) command(?).

[toc] | [prev] | [next] | [standalone]

#56676

[Multipart message — attachments visible in raw view] — view raw

On Mon, 2017-01-23 at 02:30 +0800, 積丹尼 Dan Jacobson wrote:
> BH> initramfs-tools does not use systemd.  If systemd is failing to log its
> BH>  output at boot time, that is not a bug in initramfs-tools.
> 
> OK I filed #852229 [systemd] failing to log output at boot time
> 
> BH> (I recognise that initramfs-tools should log output before it hands
> BH> over to systemd (or other init system), so this is a valid bug.
> BH> Unfortunately it will not be easy to do this consistently.)
> 
> Yes even though the user sees them flying by in the original order on
> the screen, alas you will probably have to collect them into separate files
> depending on where they came from. It is too bad they can't be put into
> the dmesg/syslog... or actually they could. With just a simple logger(1) command(?).

There is no log daemon for logger to talk to.

Ben.

-- 
Ben Hutchings
For every complex problem
there is a solution that is simple, neat, and wrong.

[toc] | [prev] | [next] | [standalone]

#56677

BH> There is no log daemon for logger to talk to.

Err... I mean talk to the same thing that is saving them up to put them
into journalctl.

[toc] | [prev] | [next] | [standalone]

#56678

[Multipart message — attachments visible in raw view] — view raw

On Mon, 2017-01-23 at 07:58 +0800, 積丹尼 Dan Jacobson wrote:
> BH> There is no log daemon for logger to talk to.
> 
> Err... I mean talk to the same thing that is saving them up to put them
> into journalctl.

I think the only place available is the kernel log buffer.

Ben.

-- 
Ben Hutchings
Hoare's Law of Large Problems:
        Inside every large problem is a small problem struggling to get
out.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web