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

From: Randy Dunlap
Date: Mon Nov 19 2018 - 14:31:32 EST


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