On 5 January 2017 at 13:05, Louis Bouchard <email@example.com> wrote:
> The upstream version of makedumpfile does a verification of the kernel version
> being used and issue the message "kernel version is not supported" if it finds
> that the kernel being used it newer than the latest version that upstream has
> This causes repetitive bug reports when we push new kernels out, especially in
> LTS releases even if, the crash file produced by makedumpfile remains valid.
> Upstream adapt to the latest kernel version in each major release, so doing an
> SRU of the major release is not a valid solution.
> Since kernel specific changes to makedumpfile are small, they are usually
> backported to the older release but the version check is never adapted.
> I am thinking of adding a patch to the versions of makedumpfile in stable
> releases where it has been confirmed that the newer kernel works to avoid such a
> message,even if this verification has not been done upstream. LP: #1626269 is
> an example of such a situation.
> Does that sound like a reasonable solution ?
I would vote for killing this check and warning message with distro
patch. Realistically, if the user is using that combination of kernel
and makedumpfile, they usually have no choice to do anything about it.
This warming message is for the distribution developers and upstream;
not for the end-users.
There have been similar pointless version checks elsewhere, e.g.
aufs-tools (or something of the related sort) would FTBFS because
kernel headers version string and/or running kernel version was too
high... when in practice everything just worked and yes our buildd can
be running newer/older kernels, building against newer/older kernel
headers, which don't necessarily match the runtime kernels on the end
> Kind regards,
ubuntu-devel mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel