Re: Direct dumped kernel cores

Hi Justin,

So, this is like the 'crashkernel' thing Linux has, where it kexec()s an alternate kernel when the main one panics?

I haven't looked at the patch -- most of it will be way out of my expertise -- but what, if anything, is done to make sure the on-disk state of the target filesystem is okay, before the "rescue" kernel starts writing to it?

Thanks,

Ravi (rpokala@)

-----Original Message-----
From: <owner-freebsd-arch@FreeBSD.org <mailto:owner-freebsd-arch@FreeBSD.org>> on behalf of Justin Hibbits <jhibbits@FreeBSD.org <mailto:jhibbits@FreeBSD.org>>
Date: Thursday, October 31, 2024 at 15:23
To: <freebsd-hackers@FreeBSD.org <mailto:freebsd-hackers@FreeBSD.org>>, <freebsd-arch@freebsd.org <mailto:freebsd-arch@freebsd.org>>
Subject: Direct dumped kernel cores


Hi everyone,


At Juniper we've been using a so-called 'rescue' kernel for dumping
vmcores directly to the filesystem after a panic. We're now
contributing this feature, implemented by Klara Systems, to FreeBSD, and
looking for feedback. I posted a review
at https://reviews.freebsd.org/D47358 <https://reviews.freebsd.org/D47358> for anyone interested.


Interesting bits to keep in mind:
* It requires a 2-stage build process, one to build the rescue kernel,
the other to build the main kernel, which embeds the rescue kernel
inside its image. This might need some further work.
* Thus far it's been implemented for amd64 and arm64, once proven out,
other architectures (powerpc64/le, riscv64) can follow suit.
* Kernel environment bits to pass down to the rescue kernel are
prefixed `debug.rescue.`, for instance
`debug.rescue.vfs.root.mountfrom`.


There are many more details in the review summary.


We'd love to get feedback from anyone interested.


Thanks,
Justin Hibbits