Project Description

When we experience a early boot crash, we are not able to analyze the kernel dump, as user-space wasn't able to load the crash system. The idea is to make the crash system compiled into the host kernel (think of initramfs) so that we can create a kernel dump really early in the boot process.

Goal for the Hackweeks

  1. Investigate if this is possible and the implications it would have (done in HW21)
  2. Hack up a PoC (done in HW22 and HW23)
  3. Prepare RFC series (giving it's only one week, we are entering wishful thinking territory here).

update HW23

  • I was able to include the crash kernel into the kernel Image.
  • I'll need to find a way to load that from init/main.c:startkernel() probably after kcsaninit()
  • I workaround for a smoke test was to hack kexecfileload systemcall which has two problems:
    1. My initramfs in the porduction kernel does not have a new enough kexec version, that's not a blocker but where the week ended
    2. As the crash kernel is part of init.data it will be already stale once I can call kexecfileload from user-space.

The solution is probably to rewrite the POC so that the invocation can be done from init.text (that's my theory) but I'm not sure if I can reuse the kexec infrastructure in the kernel from there, which I rely on heavily.

Resources

Looking for hackers with the skills:

kernel kdump

This project is part of:

Hack Week 21 Hack Week 22 Hack Week 23 Hack Week 24

Activity

  • about 1 month ago: eomelette joined this project.
  • about 1 month ago: m.crivellari liked this project.
  • 11 months ago: vbabka liked this project.
  • 11 months ago: pvorel liked this project.
  • over 1 year ago: jzerebecki liked this project.
  • over 1 year ago: tdz liked this project.
  • over 1 year ago: Zildj1an liked this project.
  • over 1 year ago: Zildj1an joined this project.
  • over 1 year ago: tschmitz liked this project.
  • over 1 year ago: paolodepa liked this project.
  • over 1 year ago: afeijoo liked this project.
  • over 2 years ago: clin liked this project.
  • over 2 years ago: ptesarik liked this project.
  • over 2 years ago: akumar joined this project.
  • over 2 years ago: akumar liked this project.
  • over 2 years ago: coolgw liked this project.
  • over 2 years ago: mbrugger started this project.
  • over 2 years ago: mbrugger added keyword "kdump" to this project.
  • over 2 years ago: mbrugger added keyword "kernel" to this project.
  • over 2 years ago: mbrugger originated this project.

  • Comments

    • mbrugger
      12 months ago by mbrugger | Reply

      I got a tip to look into grub2 multiboot. Maybe we can load the crash kernel to the reserved memory region from grub. We then would only need to pass a kernel argument so that the kernel takes this into account.

    • ptesarik
      2 months ago by ptesarik | Reply

      FWIW I was contemplating a similar scheme back in 2016. My idea was to load: 1. kdump kernel 2. kdump initrd 3. production kernel 4. production initrd Then boot into the kdump kernel, update memory maps and kexec to the production kernel. When the production kernel crashes, pass control back to the kdump kernel. For the return to the kdump kernel, I was looking at the KEXEC_PRESERVE_CONTEXT flag, but in the end I doubt it's really helpful without further modifications to the production kernel. At this point, it's probably easier to boot the production kernel first and set up an initial crash kernel at early boot.

      Good luck!

    Similar Projects

    FizzBuzz OS by mssola

    Project Description

    FizzBuzz OS (or just ...