(lkml dropped) On Thursday 19 March 2009, Jon Masters wrote: > On Thu, 2009-03-19 at 21:13 +0100, maximilian attems wrote: > > > That would mean that m-i-t has created a backwards incompatibility > > > problem _with itself_ and that the problem actually is "installing > > > a kernel, that was built on a system with new m-i-t, on a system > > > with old m-i-t". > > Looks like the problem is actually that depmod was run under the newer > version and then you tried to use the generated files with an older > modprobe. I'm not sure that's actually an error - it was noted that the > slight format change was unideal for such unlikely cases and in fact we > won't do that again in the future. But if you were just moving forwards > from one release to the next you would have been fine - you're talking > lack of forward compatibility actually. The use case here, which I suspect is not all that uncommon, is that I built a kernel from upstream source on a (Debian unstable) system with the new version of depmod and then installed that kernel on a (Debian stable) system that has an older version of modprobe [1]. The kernel Makefile of course does: /sbin/depmod -ae -F System.map -b $(INSTALL_MOD_PATH) $(KERNELRELEASE) Because the old modprobe does not understand the new relative (or rather rootless) paths, aggravated by the fact that initramfs-tools does not error out or display errors from modprobe (probably for good historic reasons), I suddenly had an initramfs that contained no modules and thus a system that failed to reboot with the new kernel. It took me quite a lot of time to trace it back to the upgrade of module-init-tools. Needless to say that this had always worked without any problems before. -- To unsubscribe from this list: send the line "unsubscribe linux-modules" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
