On Wed, 02 Mar 2005, Russell Stuart wrote: > > Although kerntypes is required if you use lcrash, it is not if you use > > crash, or netdump. Since you may not be using lcrash or may be using > > lcrash, but on another system, installing Kerntypes into /boot isn't > > always necessary. > > Well, this is fine, but netdump is not a way of analysising > a dump - it is a way of saving it. I don't know what crash > is, but if it is a program it isn't distributed with Debian.
No netdump is not a way of analyzing a dump, however if you are using netdump to send your dump to another machine where you will analyze it, then having the Kerntypes in /boot on the machine where the dump was generated doesn't do you any good at all. Crash is distributed with Debian, its currently in Sid and in Woody, it hasn't progressed into Sarge because of a build problem on Alphas. > This means when it comes to analyse a dump using a Debian > distribution, you have to use lcrash, and you can't do that > without kerntypes. Or crash, which doesn't need Kerntypes. > > Looking closer at the patch, Troy noticed that it > > only does the install for some architectures (ie. i386 and s390). > > Well - yes, that is because I only use one of them, and > apparently I am the one doing this. I don't have access > to the others, so I can't test them. The s390 looked > similar to i386, so I did that, but the rest I will leave > to someone else who has access to the hardware. > > Anyway, I don't see that because a feature works on some > architectures and not others is a reason to exclude it. > It certainly isn't Debian policy. It is not like adding > the feature breaks anything. No, its not a reason to exclude it, but having it for all achitectures is going to make the chances for including it much more. If it only works for two architectures then the instructions in lkcdutils actually get more complex, rather than simpler. We'd have to tell people that if they are using i386/S390 then they can do this, if they are using other architectures, they will have to do this. > > The instructions that come with lkcdutils (in the README.Debian) tell > > you how to properly deal with the kerntypes file. > > Many people, me included, remove the kernel build directory once > I am happy. So saying this to me is like saying "if you plan to > have a car crash, be sure to put your seatbelt on beforehand". > Yeah right - as if I am going to remember to do that! Or you can do what I always do -- put on the seatbelt when I first enter the car. In kernel building speak that translates to: After building any kernel, I always copy the .config to a safe spot (/boot/config-kernel-rev), copy out the kerntypes, the System.map and the boot image. But, I agree, not everyone does this, just like not everyone puts on their seatbelt before they throw themselves down the road in their relatively destructible metal container. > > Ideally, we would like to keep the patch as close to > > upstream as possible, or come up with a debian specific > > patch that does things, such as this patch. > > Debian specific? To quote the lcrash-howto that is distributed > with Debian: > "lcrash /boot/System.map-2.2.18 /dev/mem /boot/Kerntypes" > To quote the lkcd man page: > "Kerntypes is initially created when the kernel is built. > It is copied to /boot/Kerntypes-<kernel_version> during > kernel installation." > This is the UPSTREAM man page! and it is wrong, thanks for pointing that out... that was true in the old version, but a lot has changed, and still is changing with lkcdutils (soon to be known as dumputils), so it is not a surprise that this is out of date. I've changed the manpage to reflect this, although the replacement of lkcdutils with dumputils may make that change not appear in the archive. > > In any case, this bug should be a wishlist bug, and we > > could send it upstream if you like, but chances are they > > will give a similar reason why this should not be done. > > I can't comment on what upstream will or won't do. But > as for it being a wishlist item: I've talked with upstream about it and they are considering it, probably will be able to do it pretty quickly. > - The man page is wrong - Kerntypes isn't installed for you. A wrong manpage bug is not an "important" severity, it would be "normal" or "minor", but thats not what this bug was, this bug was asking to include the patches that you have to provide Kerntypes in /boot, which is a different issue, one that I consider a wishlist bug, and now has been forwarded to upstream. > - After installing it the package doesn't work in the > default setup. You have to follow a few manual steps > to make it work. This would be excusable, if there > were no easy way to automate those steps - but there is. Not "important" however... you can paint it as inexcusible if you wish, but that seems a little harsh considering the "easy way to automate these steps" is what the dumputils package is being designed for, only *one* of the steps is dealt with in your patch (not all the steps) and your patch doesn't make it easier to automate for everyone, it makes it easier to automate for i386 and s390, but not for the other architectures, and arguably makes the steps harder because there are different instructions for different architectures. Additionally, if you want to make it easier then provide a dpatch, not an entirely different version of upstream's patch. However, I dont know how well dpatch would play along with kpatches, so that would take some work to figure that out. One of the big benefits of Debian is that things come through us, and we push them upstream, this benefits more than just Debian users. This is what I have done with this and it is being considered. > - The feature used to exist before - in 2.4. It has been > removed in the 2.6 kernels. This is evidenced by the > fact that kernel-package knows about Kerntypes, and > includes it in the image if it is present. This is justification against the severity of the bug being wishlist? This is something that upstream has changed, not Debian, and it is being discussed with them at your request. > But anyway (and after calming down and thinking about it in > a more constructive fashion), that is all beside the point to > some extent. The real issue is that the system is much easier > to use, and more robust (as in Kerntypes is actually present > when you need it), when Kerntypes is installed automatically. > For that reason alone Debian should strive to install it. But not other operating systems? > Current kernel-package automatically adds Kerntypes if it > find in in the kernel build root. Perhaps kernel-package > should be changed to look at a different place for Kerntypes > for 2.6 kernels - but that isn't possible now for Sarge, I > suspect. If the current kernel-package automatically adds Kerntypes if it is found, then the debian way of solving this problem (if we were not to bug upstream) would be to file a wishlist bug with kernel-package to ask them to look in a different place for the kerntypes.o file, including a patch will get it accepted much more quickly. There is nothing that makes this impossible for Sarge, kernels aren't frozen. > So how about this: build Kerntypes for Sarge. It is not a > big deal: Sarge will be frozen soon anyway, so the deviation > from upstream won't matter that much. I'm going to wait to see what the upstream thinks before I do anything on this. If you'd like to figure out if dpatch would work and provide a dpatch that would be the debian way of adding this feature, I'd consider figuring out the dpatch coexistence with kpatches and how to make a diff from your changes after I've heard from upstream. If you'd like to figure this out faster than I can, I'll be happy to integrate it. > Then see if you can't convince the maintainer of > kernel-package to look in utils/kerntypes.o for Kerntypes > for 2.6 kernels. (This may not be necessary as I notice > kernel-package does run scripts in: > <kernel-root>/debian/image.d/ > during the build. Perhaps you can alter what included in > the .deb by adding a script. This would be much cleaner - > but you will have to stop using dh_installkpatches and > write you own patch install script.) Once you have done > all that, by all means stop building Kerntypes. You should file a bug against kernel-package asking for this. micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
