Difference between revisions of "Checkstop"

From RCS Wiki
Jump to navigation Jump to search
(→‎Diagnosing a Checkstop: Client console)
Line 5: Line 5:
 
== nvram ==
 
== nvram ==
  
From either the OS or Skiroot, run this as root/sudo after the machine has rebooted following the checkstop (but before rebooting again):
+
From either the OS or Skiroot, run this as root/sudo after the machine has force-rebooted following the checkstop (but before rebooting again):
  
 
<code>nvram --unzip lnx,oops-log</code>
 
<code>nvram --unzip lnx,oops-log</code>
Line 18: Line 18:
  
 
Once installed, if you're lucky, any subsequent checkstops should show up in <code>journalctl</code> output.
 
Once installed, if you're lucky, any subsequent checkstops should show up in <code>journalctl</code> output.
 +
 +
== Client Console ==
 +
 +
While the checkstop occurs, be connected to the [[BMC Client Console]] from another machine. During the subsequent forced reboot, Hostboot will print a log of the checkstop.

Revision as of 10:17, 10 February 2023

Diagnosing a Checkstop

There are a few ways to obtain logs of a checkstop.

nvram

From either the OS or Skiroot, run this as root/sudo after the machine has force-rebooted following the checkstop (but before rebooting again):

nvram --unzip lnx,oops-log

If you're lucky, it will return a log of the most recent checkstop. If you instead get nvram: ERROR: can't decompress text: inflate() returned -3, then the log in NVRAM is corrupted for some reason, and you'll need to try a different approach.

opal-prd

Before the checkstop occurs, run the following from the OS (this is for Debian; most other distros package it as well; see your distro's documentation for details):

sudo apt install opal-prd

Once installed, if you're lucky, any subsequent checkstops should show up in journalctl output.

Client Console

While the checkstop occurs, be connected to the BMC Client Console from another machine. During the subsequent forced reboot, Hostboot will print a log of the checkstop.