Re: make-kpkg question
Hi,
>>"George" == George Bonser <grep@oriole.sbay.org> writes:
George> For the most part, make-kpkg is "A Good Thing". I have a
George> question on how it would handle remaking the same kernel
George> version with a new .conf entry that would break the old kernel
George> running the new modules.
This has already been considered and documented ;-)
George> Example:
George> User has 2.0.29 and recompiles for multiprocessor support.
George> Makes a new kernel package with make-kpkg, and installs it
George> with dpkg. The installation moves the old kernel out of the
George> way, installs the new one, installs the new modules and
George> removes modules.dep.
George> User boots the new kernel and realizes they made a major
George> goof. It does not boot. They try to boot the old kernel and
George> the modules no longer work. Same kernel version but the
George> modules are incompatable.
From the README file:
______________________________________________________________________
Now, there is a caveat: If you already have kernel 2.0.29 installed,
and you have a freshly created custom 2.0.29 kernel, just installing
the new 2.0.29 kernel shall install modules (as it should) in
/lib/modules/2.0.29, which is where the old modules were! If you have
added or removed modules relative to the old 2.0.29 kernel (very
likely if your old kernel was the default gigantic generic kernel),
then you shall have a mish-mash of modules in /lib/modules/2.0.29 ;-(
Unfortunately, there is no reasonable solution; I suggest moving the
old modules directory before installation, like so:
# mv /lib/modules/2.0.29 /lib/modules/2.0.29.save
# dpkg -i kernel-image-2.0.29_custom.1.0_i386.deb
and later get rid of the .save directory.
People who want to have multiple flavours of the same kernel version
around should look at the file /usr/doc/kernel-package/Flavours.gz for
details (Note: This involves modifying the kernel sources top level
Makefile; not recommended unless you are *sure* you need it).
______________________________________________________________________
George> I have not done this but I am woring with SEUL and it is a
George> scenario that has come up. Does make-kpkg flag the modules in
George> some way and put them in a different location if it detects
George> that the new modules are incompatable with the old ones
George> ... does it even look, is this an area that we can help?
Help me lobby Linus to consider/usr/lib/kernel-package/Flavours
manoj
The Flavours file follows
--
Even kings' splendid carriages wear out, and the body is certain
bound to grow old, but the Truth found by the saints is not subject
to aging. That is what the saints themselves proclaim. 151
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Multiple flavours of the same kernel version
======== ======== == === ==== ====== =======
There is an expressed need from people to have several
alternative flavors of a single kernel version around. It is
certainly useful to have a backup flavour of a kernel version around
when one is experimenting with device driver variations (it may not
be possible to run a different version of a kernel and hence have
that as a backup).
Unfortunately, this is more complicated than it initially
appears, since the presence of possibly incompatible modules has to
be addressed.
Firstly, the modules from different flavours have to be
installed in separate directories, the modutils have to be made aware
of this alternative dorectory, and also, the kernel (and klogd)
should be able to load the right set of symbols from a System.map
file (which are different enough in different flavours that klogd
refuses to load the wrong one).
The proper way to address this may well be to modify the
kernel version in some fashion (Note: this would involve modifying
the kernel source's top level Makefile). Unfortunately, SUBLEVEL
needs to stay numeric (and under 255, as far as I can tell), so it is
a wee bit more complex than just modifying the SUBLEVEL variable.
The solution seems to be to add a FLAVOUR field to the end of
UTS_RELEASE, which uname then reads properly. As of 2.1.47, this
variable is used purely for output purposes (nothing seems to parse
it).
This way, the user has to modify the kernel Makefile (an sample
patch is provided below) to read, say, "FLAVOUR := speed_hack", and
the kernel would be installed as /boot/vmlinuz-2.0.30-speed_hack, the
modules would be installed under /lib/modules/2.0.30-speed_hack,
uname -r would report the version as 2.0.30-speed_hack.
The patch provided below is from the Makefile for 2.1.47
kernel, and may not apply cleanly on other Makefiles. It is
recommended that you use it purely as a guideline, and modify the
Makefile manually.
This effort has been based on the ideas and work of Bill
Mitchell <mitchell@mozcom.com> and Noel Maddy <ncm@biostat.hfh.edu>.
======================================================================
--- Makefile.dist Mon Aug 4 12:18:57 1997
+++ Makefile Mon Aug 4 12:24:55 1997
@@ -2,6 +2,22 @@
PATCHLEVEL = 1
SUBLEVEL = 47
+# This is an example only: Uncomment the FLAVOUR line below and name
+# this flavour.
+#
+# If you want to have more than one kernel configuration per kernel
+# version, set FLAVOUR -- it will be appended to UTS_RELEASE in
+# version.h (separated by a hyphen)
+#
+#FLAVOUR = speed_hack
+
+ifneq ($(strip $(FLAVOUR)),)
+INT_FLAV := -$(FLAVOUR)
+else
+INT_FLAV :=
+endif
+
+
ARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/)
#
@@ -244,7 +260,7 @@
@mv -f .ver $@
include/linux/version.h: ./Makefile
- @echo \#define UTS_RELEASE \"$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)\" > .ver
+ @echo \#define UTS_RELEASE \"$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(INT_FLAV)\" > .ver
@echo \#define LINUX_VERSION_CODE `expr $(VERSION) \\* 65536 + $(PATCHLEVEL) \\* 256 + $(SUBLEVEL)` >> .ver
@mv -f .ver $@
@@ -289,7 +305,7 @@
modules_install:
@( \
- MODLIB=/lib/modules/$(VERSION).$(PATCHLEVEL).$(SUBLEVEL); \
+ MODLIB=/lib/modules/$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(INT_FLAV); \
cd modules; \
MODULES=""; \
inst_mod() { These="`cat $$1`"; MODULES="$$MODULES $$These"; \
Reply to: