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: <e901d13d-68e7-c9be-96d6-9f49d3a44ceb@infradead.org>
Date:   Mon, 19 Nov 2018 11:31:21 -0800
From:   Randy Dunlap <rdunlap@...radead.org>
To:     "Theodore Y. Ts'o" <tytso@....edu>,
        AIAMUZZ <muzafsh.113@...il.com>, 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 11/19/18 10:48 AM, Theodore Y. Ts'o wrote:
> 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,

Yes, all of that.
Having some kind of pstore on x86 would be wonderful.

kexec/kdump used to be an option also.  I haven't tried it lately.

-- 
~Randy