LWN: Comments on "Persistent storage for a kernel's "dying breath""

Persistent storage for a kernel's "dying breath"

mjg59 — 2011-05-19T14:46:58+00:00

Modern macs implement it as an EFI variable. Unsurprisingly, their implementation is incompatible with the EFI spec's implementation of the concept.

Persistent storage for a kernel's "dying breath"

kayabek — 2011-05-19T14:37:26+00:00

This idea is not new. Macs have had such a device for ages.

Persistent storage for a kernel's "dying breath"

cbf123 — 2011-04-01T19:20:24+00:00

If the vendor provided storage for ERST, then pstore would work on a normal PC.

If no hardware storage is available, the next best option is to use "kexec -p" to set up a recovery kernel that uses kexec to take over on a panic. The init scripts can then be modified to detect when they're running under the recovery kernel, and they can just dumps the original kernel memory to disk and then reboot.

crashdump to write logs

Tobu — 2011-03-26T11:28:32+00:00

A while ago LWN explained a proposal of using kexec to debug crashes. One prepares a crashdump kernel in some reserved memory area, and when the system crashes, it kexecs into the new kernel which can then write back a big core dump of the crashed kernel. Here are the kdump docs.

It seems like both kernels could be extended to dump and read logs in some ram area, which doesn't require hardware support and could be a fallback when there is no persistent area for pstore. Those logs can then be read without requiring kernel debug symbols or a kernel hacker to make sense of the kdump image.

Persistent storage for a kernel's "dying breath"

mjg59 — 2011-03-24T13:57:35+00:00

Not reliably, no. The only persistent storage that's guaranteed on a BIOS-based PC is the real time clock, and there's not really enough space there. EFI actually helps here(!), although right now we don't implement the bits of the spec that cover this.

Persistent storage for a kernel's "dying breath"

ebirdie — 2011-03-24T13:52:29+00:00

The article reminded me about some very old article of writing oopses to a block device, like swap. At then the conclusion was that it isn't wise since a block device might be at stage of mayhem and there is data at stake. Still I find it appealing, that there could be a block driver for pstore and it is at sysadmin's choice to use it or not. The block driver could be configured to use a USB-storage or whatever storage auxiliary to data storage. I guess the main point is that the sysadmin is very very aware to place the pstore behind some other subsystem than the system's main storage.

Persistent storage for a kernel's "dying breath"

rwmj — 2011-03-24T13:39:11+00:00

On ordinary PCs, can RAM be reserved that is preserved across a reboot?

I'd love this feature, if it was able to tell me why some box silently rebooted overnight.

Rich.