Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#3601 - boot dmesg saved somewhere

Attached to Project: Arch Linux
Opened by Dale Blount (dale) - Friday, 09 December 2005, 02:29 GMT
Last edited by Aaron Griffin (phrakture) - Thursday, 17 April 2008, 19:11 GMT
Task Type Feature Request
Category System
Status Closed
Assigned To Aaron Griffin (phrakture)
Architecture All
Severity Low
Priority Normal
Reported Version 0.7 Wombat
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No


it would be nice to have a copy of dmesg saved shortly after boot incase it gets flooded

/var/log/dmesg or /var/log/boot.log are common on other distros.

This task depends upon

Closed by  Aaron Griffin (phrakture)
Thursday, 17 April 2008, 19:11 GMT
Reason for closing:  Implemented
Additional comments about closing: tscripts.git;a=commitdiff;h=20d6e1081ec7 105207c01e9d8d2a58bb4a145331
Comment by Alexander Baldeck (kth5) - Friday, 09 December 2005, 05:29 GMT
/var/log/kernel.log isn't enough?
Comment by Dale Blount (dale) - Friday, 09 December 2005, 11:55 GMT
Not if the box has over 1 month of uptime and the original boot logs have been rotated out by then.
Comment by Alexander Baldeck (kth5) - Friday, 09 December 2005, 15:11 GMT
true. 1 or 2K for a boot.log isn't much anyway. i suggest to include the DAEMONS=() as well, like which started and which failed. if something fails i can then take a look at daemons.log.
Comment by Dale Blount (dale) - Wednesday, 22 March 2006, 15:14 GMT
I found myself needing this again. mdadm alerted me that a mirror had failed. It seems rather hard to find the model of a drive without having the Model: from scsi detection (scsi doesn't have a model "file" in proc like IDE does.
Comment by Jan de Groot (JGC) - Sunday, 04 February 2007, 13:35 GMT
What about saving it to /var/log/dmesg at bootup and disallow logrotate from touching it? I have several debian boxes with this file, each with uptimes of half a year.
Comment by Dale Blount (dale) - Sunday, 04 February 2007, 15:09 GMT
That's how RedHat does it as well, which is what I was used to.
Comment by Aaron Griffin (phrakture) - Monday, 17 December 2007, 07:54 GMT
So, for clarity:

You want "/bin/dmesg > /var/log/dmesg" run at the tail end of rc.sysinit? Is that sufficient?
Comment by Alexander Baldeck (kth5) - Monday, 17 December 2007, 09:11 GMT
That's exactly how it would be done in my opinion. Just don't think it's necessary thinking of the fact that we already have kernel.log. In theory that could be replaced since everything.log already has it.
Comment by Aaron Griffin (phrakture) - Monday, 17 December 2007, 09:19 GMT
What's the best way to handle rotation here? Should we also force a logrotate call? Or should we >> /var/log/dmesg?

Dale, could you clarify why kernel.log is insufficient? Is it simply because the logrotate config is inappropriate?
Comment by Dale Blount (dale) - Monday, 17 December 2007, 13:15 GMT
On a box with sufficient uptime, logrotate will have rotated out the original boot logs a long time ago. If the dmesg buffer is filled up with other errors (think NFS server down, iptables -j LOG, software md failures), it's impossible to get back the original dmesg data from boot time (unless you set logrotate to keep logs for a year or two, but who has the space to do that?).

So yes, "/bin/dmesg > /var/log/dmesg" would be sufficient for my needs.
Comment by Aaron Griffin (phrakture) - Monday, 17 December 2007, 22:14 GMT;a=commitdiff;h=20d6e1081ec7105207c01e9d8d2a58bb4a145331

I have some other initscripts changes to make, and may release a new package soon
Comment by Gavin Bisesi (Daenyth) - Thursday, 17 April 2008, 19:06 GMT
What's the status on this bug?