figure out how to ensure crash is available for hotkdump

[nkshirsagar]

so we can either make sure crash is installed or install if not, or keep a built master of crash in the hotkdump repo, or keep just the built crash binary in the repo (not sure if that would work), or other options .. but somehow we need to ensure whoever git clones hotkdump and tries to use it doesn't need to worry about crash setup..

[joalif]

I suggest we snapify hotkdump and add crash there as a dependency.
This will also address the problem that the crash that comes with ubuntu is sometimes outdated or buggy.

[nkshirsagar]

If we integrate pykdump with hotkdump so we can gather outputs like scsishow dmshow multipath -l etc, I think it comes with crash binary as well as the extensions pre-built. ( see https://sourceforge.net/projects/pykdump/files/ ) which mentions,

While you can build PyKdump from sources, we provide prebuilt binaries for X86_64. Starting with version 3.9, there are binaries built for crash 
versions 7 and 8, e.g.:  

mpykdump-3.9.0-crash7.so
mpykdump-3.9.0-crash8.so

Due to limitations on crash extensions, these are not interchangeable; you will need to use the appropriate version for your major version of crash.

For PyKdump versions older than 3.9, the archives provide both the mpykdump extension and a crash executable built from recent (at the time) sources, e.g.:

usr/local/bin/crash64
usr/local/lib/mpykdump64.so

All versions of PyKdump starting from 3.0.0 are Python3-based. If you have Python2 programs, they will not work until modified. See python2to3.pdf for details.

All binaries in this directory were built on X86_64 systems.  The most recent versions were built on RHEL7, while older 3.x versions were built on RHEL6, and versions before that on RHEL5.

As the only dependency is GLIBC, the binaries can be used on any distribution with GLIBC not older than the one used for build. So for PyKdump-3.0.0 and later, this will be RHEL6+, SLES11+, etc.

The provided utilities work with any kernel starting from 2.4.21 and have been tested with versions up to at least 5.3.  New features are added for recent kernels only, and regression testing for
older kernels is limited.  It is possible that some features may stop working on very old kernels; if this happens, use older versions of PyKdump.

[xmkg]

If we integrate pykdump with hotkdump so we can gather outputs like scsishow dmshow multipath -l etc, I think it comes with crash binary as well as the extensions pre-built. ( see https://sourceforge.net/projects/pykdump/files/ ) which mentions,

While you can build PyKdump from sources, we provide prebuilt binaries for X86_64. Starting with version 3.9, there are binaries built for crash 
versions 7 and 8, e.g.:  

mpykdump-3.9.0-crash7.so
mpykdump-3.9.0-crash8.so

Due to limitations on crash extensions, these are not interchangeable; you will need to use the appropriate version for your major version of crash.

For PyKdump versions older than 3.9, the archives provide both the mpykdump extension and a crash executable built from recent (at the time) sources, e.g.:

usr/local/bin/crash64
usr/local/lib/mpykdump64.so

All versions of PyKdump starting from 3.0.0 are Python3-based. If you have Python2 programs, they will not work until modified. See python2to3.pdf for details.

All binaries in this directory were built on X86_64 systems.  The most recent versions were built on RHEL7, while older 3.x versions were built on RHEL6, and versions before that on RHEL5.

As the only dependency is GLIBC, the binaries can be used on any distribution with GLIBC not older than the one used for build. So for PyKdump-3.0.0 and later, this will be RHEL6+, SLES11+, etc.

The provided utilities work with any kernel starting from 2.4.21 and have been tested with versions up to at least 5.3.  New features are added for recent kernels only, and regression testing for
older kernels is limited.  It is possible that some features may stop working on very old kernels; if this happens, use older versions of PyKdump.

The pre-built crash64 binary shipped with pykdump seems to be not so plug-n-play:

 15:11 ❯ ldd crash64 
	linux-vdso.so.1 (0x00007ffdbe998000)
	libncurses.so.5 => not found
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f6261502000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f626141b000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6261416000)
	liblzo2.so.2 => /lib/x86_64-linux-gnu/liblzo2.so.2 (0x00007f62613f5000)
	libsnappy.so.1 => /lib/x86_64-linux-gnu/libsnappy.so.1 (0x00007f62613e9000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6261000000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f626153c000)
	libtinfo.so.5 => not found
	libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f6260c00000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f62613c9000)

... so the downstream consumer would have to install libncurses and libtinfo in order to make crash work. IMO, on top of what @joalif has suggested, we can ship a lean docker container (... alternatively host a hotkdump lxc image, or even both) as well.