linux-kernel - Re: Magic Sysrq key option ... What is the option to record the boot logs to my hard disk before i issue a reboot command ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20181119184803.GB19377@thunk.org>
Date:   Mon, 19 Nov 2018 13:48:03 -0500
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     AIAMUZZ <muzafsh.113@...il.com>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: Magic Sysrq key option ... What is the option to record the boot
 logs to my hard disk before i issue a reboot command ?

On Mon, Nov 19, 2018 at 08:51:17PM +0530, AIAMUZZ wrote:
> Hi,
> 
> I have this nagging and frustrating boot freeze i often face on my
> Deepin OS boot ... Deepin OS i think uses 'journalctl' to record logs
> on its system.
> 
> 'journalctl' however seems to record boot logs ONLY for successful
> boots ... boot logs for instances of boot freezes/hangs that are
> issued with a ... 'Ctrl+Alt+Del' ... key combination or the ... Magic
> Sysrq 'b' ... key combination to get out of the frozen/hung machine
> state are just not aved in the 'journalctl' log ...
> 
> Is there any option using Magic Sysrq that will enable me to record
> the failed/frozen/hung boot information to a file for troubleshooting
> before i reboot the system using the option 'b' ?
> 
> If not ... Isn't it a good idea to have such an option added to Magic
> Sysrq options, that can save/record the boot/system logs upto that
> point, until just before we restart the machines ?

This is a hard problem to solve, because there's no place to store the
information, at least not in the general case.  The problem is on an
unsuccessful boot, the root file system may not have been mounted yet.
Heck, the storage devices might not have been probed at all!

If your hardware has a place to store dmesg output across reboots (via
one of the CONFIG_PSTORE_* kernel configuration options) then this
would be an easy problem --- in fact, it would be the default even
with out needing a magic sysrq to request it.  The problem is that
most x86 devices do not have hardware capable of supporting
CONFIG_PSTORE.  If you have a custom BIOS which doesn't clear memory
across a warm reset, that would make things easy.  Unless, unless you
are a big cloud company using custom hardware and/or a custom BIOS,
life is much more difficult.  :-(

One alternative solution you can use is to simply use a serial
console, and have a another computer monitoring the output from the
serial console.  This will allow you to see all of the kernel messages
during early bootup and afterwards.  So this is also useful for when
your X server dies and your system mysteriously reboot; either
CONFIG_PSTORE_* hardware or using a serial console might allow you to
see the kernel oops message which took out your desktop machine.  (Or
in the case of servers, you can cross connect your servers' serial
ports so that one server is monitoring another server's serial
consoles.)

Cheers,

					- Ted