Bug#518412: linux-2.6 install errors due to incompatible depmod files [was Re: Bug#518412: initramfs-tools: must support relative paths in modules.dep ]
On Fri, 2009-03-20 at 12:05 +0100, Marco d'Itri wrote: On Mar 20, Scott James Remnant sc...@canonical.com wrote: Doesn't Debian run depmod in the postinst of the kernel package - and iirc, again on boot anyway? Not anymore on boot, but I can't see why depmod should NOT being run when the kernel is installed. This is the thing I'm trying to understand. That, and what I can really do in the absence of a time machine to change a former release :) Jon. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518412: linux-2.6 install errors due to incompatible depmod files [was Re: Bug#518412: initramfs-tools: must support relative paths in modules.dep ]
On Thu, 2009-03-19 at 21:13 +0100, maximilian attems wrote: [ adding jcm and lkml to Cc: ] [ You want linux-modu...@vger.kernel.org rather than LKML. I've added the former to the CC list, we can kill LKML off the CC shortly. ] 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. Unless I'm missing something, in which case please clarify. I would like it also if you'd send me the generated files, distro info, etc. Jon. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518412: linux-2.6 install errors due to incompatible depmod files [was Re: Bug#518412: initramfs-tools: must support relative paths in modules.dep ]
On Thu, 2009-03-19 at 21:57 +0100, Frans Pop wrote: 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. Well, that lack of understanding the difference between relative/explict paths was fixed but of course we can't go back in time and fix what's already out there and in use. Yes, it was a bad idea of mine (perhaps) to change the existing file format and I've learned something, but it should only have affected for example that 3.4 release you're using. Jon. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518412: linux-2.6 install errors due to incompatible depmod files [was Re: Bug#518412: initramfs-tools: must support relative paths in modules.dep ]
On Thu, 2009-03-19 at 23:09 +0100, Frans Pop wrote: On Thursday 19 March 2009, Jon Masters wrote: Yes, it was a bad idea of mine (perhaps) to change the existing file format and I've learned something, but it should only have affected for example that 3.4 release you're using. Do you mean that earlier versions are not affected? Hasn't depmod generated full paths basically any version up to 3.6? Yes, it was 3.6 where it changed, not 3.4. However, there was a backward compatibility issue during development that I was referring to. That isn't the problem here anyway. The problem is that you want to use a newly generated .dep file on an old install. I know that would be nice, and I'm sorry that it bothers you, but at the same time you don't expect newly built binaries to run against an older version of glibc they weren't built against, etc. But even if it is only 3.4, that still makes it every Debian stable user (and unknown other distros) who runs the risk of ending up with an unbootable system for hard to trace reasons... No, it really doesn't. If you upgrade to a new module-init-tools and run depmod, then everything works. If you use the old .dep files then it still works. If you force downgrade and don't rebuild your .dep files then there certainly is the risk of being out of sync - but there are other times where such things can happen too. I'm sure other utilities have similar. Potentially painful for example for NAS devices where the kernel and initrd get installed in flash, replacing the previous version. Yes, and in that case there's no problem. If you do a forward upgrade everything works just fine. It's only if you try to mix versions and go backwards that you get a problem. I can see this in a cross-build setup being a slight annoyance, but even there most people would use the same version of the tools or expect to have problems building on a newer box for an older release. As the kernel Makefile does run depmod during a build, I don't think it's strange to assume users rely on that modules.dep being valid, even for older versions of modprobe. It works fine as long as your box is self-consistent. What is the actual problem other than that mixing versions and trying to go backward without quickly re-running depmod might cause module load problems? What exactly are the resons behind the change in file format that're so strong that depmod cannot continue to generate the old format for the next 5 years or so as a transition period I guess it's called progress ;) Sarcasm aside, if you can give me an example of an actual real life set of users who are adversely affected then I'll try to do something to help out. But if you're asking for old versions of software to be compatible with newer releases in every case I think you're not being terribly realistic. The kernel changes to make progress, and so do other utilities. Jon. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518412: linux-2.6 install errors due to incompatible depmod files [was Re: Bug#518412: initramfs-tools: must support relative paths in modules.dep ]
On Thu, 2009-03-19 at 23:58 +0100, Frans Pop wrote: I guess it's called progress ;) Sarcasm aside, if you can give me an example of an actual real life set of users who are adversely affected then I'll try to do something to help out. But if you're asking for old versions of software to be compatible with newer releases in every case I think you're not being terribly realistic. The kernel changes to make progress, and so do other utilities. Sure, if there are very strong reasons to break things, fine. But whenever possible the kernel has ensured backwards compatibility, mostly only _after_ someone complained. Think of the i386 and x86_64 symlinks after the x86 integration, think of the COMPAT_SYSFS flags, think of optional support for old /proc files, think feature-removal-schedule.txt. All of these examples refer to the future. The *future*. Things that will change, preserving backward compatibility, keeping symlinks around for those who are used to the old location. *Backward* compatibility. But the issue you raised was about *Forward* compatibility. This is nice but isn't the same. That would be like guaranteeing that all future kernel features will work with a kernel from 6 months ago, or that modules will, or other similar stuff. So far you seem to be avoiding to give the reasons for the change. What would be so wrong with ensuring the compatibility for some transition period and avoiding the problem? There is compatibility. From the past, to the present, into the future. But you want to use *future* generated files with a *past* version. That is not backward compatibility and it is not the kind of thing where you can preserve for 5 years, etc. How does the old version know something is going to change? It doesn't and it can't. v3.4 will always be the same, and it won't change. The files changed slightly in v3.6, but v3.4 can never know about that. P.S. Thanks a lot for your prompt replies. I do appreciate the discussion. Sure. Hopefully you see that this is not a regular compatibility issue. Jon. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
