The mkdumprd from kexec-tools creates a busybox-based initrd image with an init script that issues "fsck.ext3" and "fsck.ext2" commands, which seem to be currently disabled in busybox-1.10.3-4. See bug 476368, comment #32.
For now fsck.ext3 and fsck.ext2 applets are disabled in busybox package so they can't be added (upstream disabled them and the reason is it is too problematic to maintain them).
I want to expand on this. busybox used to have e2fs tools. They are still retained in the tree in e2fsprogs/old_e2fsprogs/*, including e2fsck.c, but they are disabled (it's impossible to select then in menuconfig). However, e2fsck is NOT a thing you would want to treat lightly. It's a filesystem repair tool. It needs to know filesystem structure in every fine detail. It needs to take intelligent decisions in order to repair it, or at least to not damage it even further. IOW, e2fsck must be written and maintained by e2fsck developer team. Sure, technically it's possible to snatch a copy of source code, "busyboxify" it and use. The question is, what will happen next? e2fsck is presumably evolving. Bugs are discovered and fixed. Support for ext3, ext4, ext999 is added. Repairing algorithm gets better. Nothing of this will happen in busybox's applet unless someone will actively maintain it. And this means that busybox's e2fsck will have unfixed bugs. It will know nothing about, say, e4fsck, and if such filesystem will be given to it to "repair", hell knows how much worse it will be after that "repair". That will be bad. Unless busybox project commits developer resources to actively maintain e2fsprogs, it's better to NOT have e2fsck in it.