Re: Problems with kver suffix and MULTI_KERNELS.
> What's different between the root<flavor>.bin and the straight
> root.bin? Does there really need to be different root.bin's for
> flavor kernels? Why?
there are two driver modules that may go into root.bin on i386, this is
unix.o for the vanilla kernel, and af_packet for both vanilla and compact.
this sounds terribly kludgy to me, but that's the way it's done right now.
> I think it ought to fall back on the plain name, with no suffix, as a
> default, when the one with the extension isn't there. Maybe we
this sounds good.
> modules are packaged, we have to ensure that later on they untar into
> /target/lib/modules/$(uname -r)/, and be aware that for "flavor"
> kernels, `uname -r' will be something like `2.2.14-compact'.
this should already be done.
> How does that work? Isn't there a patch or something with make-kpkg
> that you have to apply to the kernel-source to make it work? Is that
no, you need to define EXTRA_VERSION in the makefile. See the source for the
kernel-image-2.2.14-compact package.
> source kernel-image-2.2.14'? How can we query a non-running
> kernel-image as to what it will call itself once it's booted? (for
> the scripts that create the drivers.tgz)
you can't. drivers.tgz relies on the deb's to have the correct paths in
them. if the debs don't have the right paths you should file bugs.
> From `dbootstrap', you ought to be able to choose the kernel (aka
> rescue disk) image with matched drivers to netfetch install when
> several are available, independantly from whatever you happened to
> boot the install setup with. They should be listed in a chooser menu
> with a brief description.
how can you do this? you can't do a directory listing over http...
randolph
--
Debian Developer <tausq@debian.org>
http://www.TauSq.org/
Reply to: