Problems with kver suffix and MULTI_KERNELS.
Here's some things we need to work on this week.
What's our deadline, anyway? We're not ready for release yet, but
maybe can be in a busy week...?
Net fetch of rescue and drivers for the compact set is looking for
current/compact/drivers-2.2.14-compact.tgz and
current/disks-1.44/compact/rescue-2.2.14-compact.bin. [1]
That works out ok if you've got symlinks in the http mirror (like, in
current/disks-1.44/compact, rescue-2.2.14-compact.bin -> rescue.bin)
but after it opens up the drivers.tgz file, and you go to configure
modules, `modconf' cannot find /target/lib/modules/2.2.14-compact,
because the modules.tgz inside the drivers.tgz is untarred to become
/target/lib/modules/2.2.14/*.
In dbootstrap.h are a set of defines of some sprintf format strings
that are used in main.c to form the image filenames. When
MULTI_KERNELS is defined (bottom of dbootstrap.h) it opens
/proc/sys/kernel/osrelease, scanf's that into a string, then strcmp's
that with a _hard-coded_ string expanded from the KVER macro, which
was passed down from the toplevel boot-floppies Makefile. It's
expansion is typically "2.2.14" at the time `dbootstrap' is built.
When they don't match, a kver_suffix variable is set to the string
retrieved via proc. That suffix is sprintf'd into the filename
format strings to form names like "rescue-2.2.14-compact.bin". When
the suffix variable is blank, that is, when the running kernel (the
one on the rescue floppy you booted with) is the same osrelease as
the one hard coded into `dbootstrap', the filename looks like
"rescue.bin".
The kver_suffix thing is ok, I guess, in case you want to offer both
2.2.14 and 2.2.15 or something. For the flavors (compact, IDE, ???
(safe isn't really a kernel flavor)), we already have a subdirectory
for them. The images in there don't really need a suffix also; the
subdirectory provides that functionality.
The suffix also extends the filename beyond the DOS compatible 8.3
limit. That's fine for the majority of user's, I guess... The other
thing is that they can name it anything they like on their machine,
use it to burn the images onto floppies, then boot from those and
from then on they're free of the 8.3 limitations forever.
I don't think that `dbootstrap' should not have a hard coded KVER
built into it. It ought to get that from the environment or on the
command line. Perhaps a kernel boot command line option can pass
that down? But what if a user puts their own kernel on a rescue
floppy? Maybe dbootstrap should use only the osrelease... unless
that rdev.sh script can do the right thing with the syslinux linux
kernel command line. A problem with that is that the user might
build a custom kernel, put it on the floppy, boot with it using our
root.bin, then try to netfetch modules that don't match that kernel.
How can we make it simple to grab a set of modules that match a
custom kernel? The kernel they build might not have a flavor
extension in osrelease, &c...
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?
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
should get rid of the kver_suffix thing altogether and just have it
use subdirs on the archive site? For sure the modules for each must
be kept next to the matching kernel. That's obvious. Also, when the
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'.
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
already a part of the kernel-source I have if I did an `apt-get
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)
The `uname -r' isn't really enough to identify a particular kernel,
for matching with a set of drivers. `uname -a' ought to be though.
Can that info be obtained somehow from the non-running kernel image
or other files in it's package?
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. That can come from a file on the archive
site, CD, or mirror. The default one ought to be first in the list,
and it should start with the highlight bar over the default. The
same thing obviously ought to work over NFS, to a mounted filesystem,
or off a CD, LS120, or Zip. For the filesystem installs, the
directory browser ought to be available for finding the archive.
Footnotes:
[1] s/disks-/images-/ very soon, after tausq debugs it a little more.
Some of the mirrors are using `rsync' with `--exclude' settings
to not mirror non-i386 stuff. They have a "- disks-*/" and a "+
disks-i386/" in the exclude rules, but that excludes the
disks-1.44 &c. from their mirror. tausq is renaming disks-1.44
&c to images-1.44 &c to accomodate them.
Reply to: