Re: Problems with kver suffix and MULTI_KERNELS.
>>>>> "Randolph" == Randolph Chung <tausq@debian.org> writes:
>> 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?
Randolph> there are two driver modules that may go into root.bin on i386, this is
Randolph> unix.o for the vanilla kernel, and af_packet for both vanilla and compact.
Randolph> this sounds terribly kludgy to me, but that's the way it's done right now.
That seems wrong to me also. Why are those built as modules that get
insmod every time, rather than builtins? If they are built in, the
same root.bin can be used for all rescue images. `flavor' is passed
on the kernel command line by syslinux. If there are flavor kernels
for other arch's, they must do the similar, I assume.
>> 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
Randolph> this sounds good.
Or just comment off the define MULTI_KERNELS altogether... I really
don't think that KVER ought to be hard coded into `dbootstrap' like
that. I don't completely understand why this code was written this
way.
>> 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'.
Randolph> this should already be done.
It is; see my reply. I had used http and had put the wrong
drivers.tgz in there to retrieve.
>> 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
Randolph> no, you need to define EXTRA_VERSION in the makefile. See the source for the
Randolph> kernel-image-2.2.14-compact package.
Is it `EXTRA_VERSION', or does it need the patch in the
`kernel-package' docs that adds a `FLAVOUR' variable to the kernel
Makefile?
>> 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)
Randolph> you can't. drivers.tgz relies on the deb's to have the correct paths in
Randolph> them. if the debs don't have the right paths you should file bugs.
The paths _are_ correct; see above.
>> 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.
Randolph> how can you do this? you can't do a directory listing over http...
The `release' script could create a catalog file for netfetch to grab
and turn into a menu, perhaps. A `find ... -printf' would work fine,
to create a colon sep catalog or somesuch that would be easy to
parse. The other methods could use it also, then additionally offer
the directory browser, perhaps.
Reply to: