1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
|
$Id: README,v 1.50 2002/01/22 03:51:06 srivasta Exp $
This is the Debian GNU/Linux packaging scripts for the Linux kernel.
This package has been put together by Manoj Srivastava <srivasta@debian.org>.
INSTALLATION NOTES:
To use this package to create kernel-image packages, you need to get
the kernel source (available from your favorite Linux archive),
unpack your kernel somewhere. Preferably somewhere other than
/usr/src/linux (more on this later).
Before you go any further, please allow me to point out that you need to
have a few other packages installed before you can compile your own kernels
(it is difficult to compile anything without a compiler ;-).
Firstly, you will need gcc, the libc development package (libc5-dev or
libc6-dev at the time of writing), and, on Intel platforms, bin86. [If
you use the menuconfig target of make, you will need ncursesX.X-dev,
and make xconfig also requires tkX.X-dev, and other packages these
depend on]
The packages suggested are:
devel: gcc, libc5-dev/libc6-dev, binutils, make, and, for intel
x86 platforms, bin86 (non-Intel platforms don't need
this).
interpreters: awk, which is contained in either the mawk or gawk packages
base: gzip, shellutils, and grep.
Some of these packages are marked essential, and hence are going to be
present on your machine already. Others you have to check and install.
Also, please note that some versions of gcc do not interact well with
the kernel sources (gcc 2.95 has problems compiling the kernel without
the flag '-fno-strict-aliasing'. This issue has been taken care of for
recent kernels (2.2 and 2.4 series are fine) (I think you may have to
edit the makefile for older kernels, or something).
Of course, pretty GUI front ends to kernel configuration require more
packages, but they are not strictly essential (though quite nice really).
For the Brave and the impatient:
Phase ONE: Getting and configuring the kernel
1% cd <kernel source tree>
2% make config # or make menuconfig or make xconfig and configure
Phase TWO: Create a portable kernel image .deb file
3% make-kpkg clean
4% $Get_Root make-kpkg --revision=custom.1.0 kernel_image
(Get_Root is whatever you need to become root -- fakeroot or
sudo are examples that come to mind). NOTE: if you have
instructed your boot loader to expect initrd kernels (which is
the norm for recent official kernel image packages) you need to
addd --initrd to the line above
% $Get_Root make-kpkg --initrd --revision=custom.1.0 kernel_image
Personally, I prefer non initrd images for my personal machines,
since then adding third party modules to the machine has fewere
gotchas
Phase THREE: Install the kernel image on one or more machines
5# dpkg -i ../kernel-image-X.XXX_1.0_<arch>.deb
6# shutdown -r now # If and only if LILO/SILO/QUIK/PALO/VMELILO/ZIPL/yaboot/..
# worked or you have a means of
# booting the new kernel. YOU HAVE BEEN WARNED!!
With the addition of fakeroot ( a really nice program, I recommend
it). Steps 1 to 4 can be carried out as a non root user. Step 5 does
require root privileges.
If you're using the patch_the_kernel facility, you may want to remove
step 2 and instead insert `--config=menuconfig' into the make-kpkg
command-line of step 4 (or perhaps use `xconfig' or `config' in place
of `menuconfig'). This way, patching the kernel happens before
menuconfig (or whichever), and you'll get better defaults for any
questions introduced by the patches. (Also look at the
--added_patches command line option to selectively apply some patches
in conjunction with patch_the_kernel)
Unpacking kernel sources:
-------------------------
Some of the suggestions about where to unpack the kernel packages are
a) /tmp/linux
b) /var/tmp/linux
c) /usr/local/src/<whatever>
d) /usr/src/linux-X.X.XX; where X.X.XX is the version number of the
kernel.
In any case, choose a partition that has a large amount of free space,
since recent kernels, unpacked, run to about 23MB, and you need more
than double that in order to create kernel-image, kernel-source, and
the tar file (that is, if you choose to build everything together with
the dist target in debian.rules -- say if you want, for whatever
reason, to run dchanges on the files created). I needed nearly 60MB to
create the full spectrum of packages for version 1.99.7 (and doubtless
this size will go up in the future).
Now, cd linux (wherever you have created the kernel sources).
Versions and revisions
----------------------
The version number is deduced from the kernel Makefile directly to
ensure that the version numbers are in sync[1], so you don't have to
worry about that.
Then, remember to change the revision number (using the --revision
option of make-kpkg). It has been suggested that you renumber the
revision number in such a way that a generic kernel image package will
not override the custom package while using dselect (or dpkg
-BOGiE). You may also do this on the fly by setting the
DEBIAN_REVISION environmental variable.
The revision number (the argument supplied after the --revision flag)
has certain constraints:
a) It only has an effect during the configure phase (in other words,
if a file called stamp-configure exists, this option has no effect
-- run make-kpkg clean or manually remove stamp-configure,
stamp-debian, and debian/official for it to have an effect -- I
strongly suggest make-kpkg clean unless you know what you are
doing). Additionally, official source package maintainers provide
their own version numbers and data for the official uploads, and
hence a number of things, including the Debian revision, is not
modified by make-kpkg. If you happen to have an official source,
(that would mean that the file debian/official exists), and want to
use your own revision number, make sure you remove debian/official
before running make-kpkg clean for this option to have an effect.
So, if you want to re-run make-kpkg with a different revision
number, you have to make sure you start with a clean slate.
b) It may contain only alphanumerics and the characters + . (full
stop, and plus) and should contain a digit. NOTE: No hyphens
allowed (Look at the Debian Policy manual for details). Optionally,
you may prepend the revision with a digit followed by a colon (:);
this shall put your revision into a new epoch; more on this later.
You should _not_ use a "_" in the revision number! As tempting as it may
seem, it actually interferes with the policy.
The revision number is required because dpkg imposes an ordering on
version numbers, so that it can tell whether packages are being up- or
downgraded and so that dselect can tell whether a package it finds
available is newer than the one installed on the system. Dselect uses
an option that prevents a package from being downgraded, for example.
Packaged kernel-images in the distribution also have a version number -
not at all coincidentally coinciding with the kernel version, because it
is used to reflect the upstream version number. Note that the kernel
version is also part of the package's name, thus it appears twice in the
package's file name. It also gets a debian revision number relating to
differences in builds. It then looks like:
kernel-image-2.0.29_2.0.29-8.deb
I've found that using a two-level scheme where the major level starts
with a letter nicely does the job -- unless epochs are used,
(--revision custom.Y, so the image package become
kernel-image-X.X.XX-custom.Y.deb), and dselect and dpkg -BOGiE will
refuse to downgrade to a generic kernel (don't give the BOG arguments
to dpkg if you actually do want to downgrade later).
The reason for telling kernel-package that the package has a version
"custom-x.y.whatever.you-want.to+add.more-just.do.not+use.an=underscore"
is that to dpkg that is always a higher version number than any version
number starting with a numeral ( e.g. "a" > "2" like "b" > "a". ) This way,
dselect will not try to upgrade your "roll-it-yourself" kernel-image when
a new build of the distribution default kernel appears in the archive.
Unfortunately, this fails if the upstream maintainer uses epochs to
correct a version misnumbering ;-(. The good news is that you can add
your own epoch to your customized image, ugly though that may
be. (--revision 1:custom.Y; the kernel image file shall remain
kernel-image-X.X.XX-custom.Y.deb, but dpkg shall know that it should
not replace that with a standard kernel with an epoch. Hopefully, we
shall never see an epoch greater than 1 on a standard kernel, but who
knows. Choose your epoch, if you must use it, wisely. I fear, though,
that with the introduction of epochs in kernel image versions shame
has entered the garden of eden, and we must forever use epochs to
guard against forced upgrades.
So, try using an epoch for your custom packages:
make-kpkg clean
$Get_Root make-kpkg --revision=3:custom.1.0 kernel_image
(Get_Root is whatever you need to become root -- fakeroot or
sudo are examples that come to mind).
And the next time when you build a kernel, because you just bought a new
sound card or you discovered that you suddenly want masquerading in your
kernel enabled, you'll type:
make-kpkg clean
$Get_Root make-kpkg --revision=3:custom.2.0 kernel_image
(Get_Root is whatever you need to become root -- fakeroot or
sudo are examples that come to mind).
(remember to do a make-kpkg clean before you compile again with a
different revision, or else the revision flag shall not have any
effect)
NOTE about using initial ram disk images (initrd). Recent official
kitchen sink kernel image packages tend to use this, in order to
accomodate as wide a vareity of root file system types as humanly
possible without building them all into the kernel. In order to use
these images, you need to instruct you boot loader that this is a
kernel image using intrd, and tell the boot loader where to find the
initrd image. Unfortunately, you can't just substitute a non initrd
image afterwards without changing the boot loader instructions. So,
if your boot loader configuration expects to see an initrd image, add
--initrd to the above invocation, like so:
make-kpkg clean
$Get_Root make-kpkg --initrd --revision=3:custom.2.0 kernel_image
When make-kpkg is finished, you'll have
kernel-image-2.0.29_custom.1.0_i386.deb and all it takes now is to
install the package (as root):
# dpkg -i kernel-image-2.0.29_custom.1.0_i386.deb
This will install the kernel, the modules, the map file and do some other
administrativia and finally it will ask you if you want to make a
boot floppy and if you want to run lilo now.
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 [having remembered
to do a make-kpkg clean in between ;-], 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 (need to be root):
# 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 append_to_version flag of make-kpkg. This
appends to the EXTRAVERSION variable of the kernel Makefile, and does
not require one to edit that makefile manually. This can also be done
by setting the environment variable APPEND_TO_VERSION. The command
line invocation overrides the env variable.
The method described in the /usr/share/doc/kernel-package/Flavours.gz
file is obsolete (Note: This involves modifying the kernel sources top
level Makefile). Also, if recompiling and using a different flavour,
one needs to do a make-kpkg clean in between compiles.
You may also place long term directives (like your name and email
address) in the file /etc/kernel-pkg.conf. (or ~/.kernel-pk.conf)
Putting your name and address in that file is a good idea, to remind
you that this is not an official package, unless, of course, you
happen to be the maintainer (Hi Herbert). The file
/etc/kernel-pkg.conf (or ~/.kernel-pkg.conf) is actually a Makefile
snippet included during the kernel packages build process, and hence
you may put any legal Makefile directive in that file (just make very
sure you know what you are doing ;-).
At the moment, the user modifiable variables supported are:
maintainer Local kernel-* package maintainer. Please note that
any apostrophes "'" shall have to be quoted like so:
maintainer = John O'\\''Brien.
Yes, this is ugly, but this works.
email The email address of that person.
pgp Name to search for in the pgp database _iff_ separate
modules (like pcmcia etc) are being built in
/usr/src/modules/*. Can be set from environment
variable PGP_SIGNATURE. Defaults to maintainer.
debian The Debian revision of the kernel packages. Can be set
from the environment variable DEBIAN_REVISION. Defaults
to 1.0.
image_in_boot Set to True if you want the kernel image symlink (vmlinuz)
in /boot rather than the default /. Can be set from the
environment variable IMAGE_IN_BOOT. Defaults to
undefined.
kimage The kernel image type (i.e. zImage or bzImage). Can be
set from the environment variable IMAGE_TYPE. Defaults
to bzImage.
no_symlinks Mutually exclusive to reverse_symlinks Can be used with
image_in_boot. The image is placed in vmlinuz (instead
of /boot/vmlinuz-X.X.XX). The old vmlinuz is moved to
vmlinuz.old unconditionally. (Normally, that is only
done if the version of the new image differs from the
old one). This restricts you to two images, unless you
take additional action and save copies of older
images. This is for people who have /boot on a system
that does not use symlinks (and say, they use loadlin)
This is a Hack.
reverse_symlinks Mutually exclusive to no_symlinks. Can be used with
image_in_boot. Just like no_symlinks, except that the
/boot/vmlinuz-X.XX is symlinked to the real new
image, vmlinuz. This too restricts you to just two
images unless further action is taken. The older
symlinks are left dangling. This is for people with
/boot on umsdos, and who can't see the link in dos,
but do want to know the image version when in Linux.
This is a Hack.
image_dest If you want the symbolic link (or image, if
move_image is set) to be stored elsewhere than /
set this variable to the dir where you want the
symbolic link. Please note that this is not a
boolean variable. This may be of help to loadlin
users, who may set both this and move_image.
Defaults to /. This can be used in conjunction with
all above options except image_in_boot, which would
not make sense. (If both image_dest and
image_in_boot are set, image_in_boot overrides).
patch_the_kernel This is an experts only variable. If set to YES (ENV
variable PATCH_THE_KERNEL overrides this), the build
process causes run-parts to be run over
/usr/src/kernel-patches/$(architecture)/apply and
(hopefully) reverses the process during clean by
running run-parts over
/usr/src/kernel-patches/$(architecture)/unpatch. The
special architecture all is used for arch independent
patches. You may use the --added_patches command line
in conjunction with this variable to selectively
apply only some patches from that directory. The
people who package the pacthes should have arranged
to have the order of application and unapplication be
sane.
root_cmd This should be set to a means of gaining superuser
access (for example, `sudo' or `fakeroot') as needed
by dpkg-buildpackages' -r option. This is used
to call dpkg-buildpackage with the proper
options. The environment variable ROOT_CMD overrides
this.
do_clean Set to anything but YES, this shall forego the make
clean done in the kernel source tree after building
the kernel image package. The environment variable
CLEAN_SOURCE overrides this.
make_libc_headers This is meant to be used by the libc6 maintainer,
when he compiles libc6, to also package up the
corresponding headers. DO NOT SET THIS as a
mismatch between the headers you package and libc6
may well create a subtle instability in all code
compiled on your machine. You have been warned. The
environment variable MAKE_LIBC_HEADERS overrides
this.
The value of a variable can be set so:
a) Defaults exist in the rules file. These are the values used if no
customization is done.
b) Variables can be set in the config file /etc/kernel-pkg.conf (or
~/.kernel-pkg.conf) These values override the defaults.
c) Variables can also be set by setting a corresponding environment
variable. These values override the config file and the defaults.
d) Using make-kpkg options, or, if using the rules file directly, on
command line ( # xxx/rules DEBIAN_REVISION=2.0a kernel_image). This
overrides all the above methods.
Please see kernel-pkg.conf (5).
However, most of these are done on the machine you compile on: but you
may need to install generic kernel image packages from time to time,
and you need control over where the image sticks the symbolic links
and such. With this in mind, there is the configuration file
/etc/kernel-img.conf which sits on the target machine (the machine
that the dpkg -i is run on, which need not be the same machine the
kernel was compiled on), and that allows you to tweak these variables:
This file is automatically created by the installation script if it
does not exist, and neither does the symbolic link /vmlinuz. The
script asks the user whether the symbolic link should be created, and
stashes the answer into /etc/kernel-img.conf
no_symlinks Mutually exclusive to reverse_symlinks Can be used with
image_in_boot. The image is placed in vmlinuz (instead
of /boot/vmlinuz-X.X.XX). The old vmlinuz is moved to
vmlinuz.old unconditionally. (Normally, that is only
done if the version of the new image differs from the
old one). This restricts you to two images, unless you
take additional action and save copies of older
images. This is for people who have /boot on a system
that does not use symlinks (and say, they use loadlin)
This is a Hack.
reverse_symlinks Mutually exclusive to no_symlinks. Can be used with
image_in_boot. Just like no_symlinks, except that the
/boot/vmlinuz-X.XX is symlinked to the real new
image, vmlinuz. This too restricts you to just two
images unless further action is taken. The older
symlinks are left dangling. This is for people with
/boot on umsdos, and who can't see the link in dos, but
do want to know the image version when in Linux.
This is a Hack.
do_symlinks By default, the kernel image post installation
script shall create or update the /vmlinuz and
/vmlinuz.old symbolic links. This is true if a /vmlinuz
link already exists, however, in absence of /vmlinuz,
the script looks to see if this configuration file
exists. If it does not, the configuration script asks
the user whether to create the symbolic link, and
stashes the answer in a newly created
/etc/kernel-img.conf. If the configuration file already
exists, and if this option is set to no, no symbolic
link is ever created. This for people who have other
means of booting their machines, and do not like the
symbolic links cluttering up their / directory.
image_in_boot Set to True if you want the kernel image symlink
(vmlinuz) in /boot rather than the default /.
Defaults to undefined.
image_dest If you want the symbolic link (or image, if
move_image is set) to be stored elsewhere than /
set this variable to the dir where you want the
symbolic link. Please note that this is not a
Boolean variable. This may be of help to loadlin
users, who may set both this and move_image.
Defaults to /. This can be used in conjunction with
all above options except image_in_boot, which would
not make sense. (If both image_dest and
image_in_boot are set, image_in_boot overrides).
move_image Instead of creating symbolic links to (or, if
reverse_symlinks is set, from) image_dest, the
image is moved from its location in /boot into
image_dest. If reverse_symlinks is set, /boot
shall contain a symbolic link to the actual image.
This option can be useful to people using loadlin,
who may need the image to be moved to a different
dos partition. This variable is unset by default.
clobber_modules
If set, the preinst shall silently try to move
/lib/modules/version out of the way if it is the
same version as the image being installed. Use at
your own risk. This variable is unset by default.
do_boot_enable
If set to NO, this shortcircuits all attempts to create
boot floppies, run lilo, etc. This has the additional
side effect that the postinst is silent. Setting both
do_bootfloppy and do_bootloader to NO implies setting
do_boot_enable to NO. Defaults to Yes.
do_bootfloppy
If set to NO, this prevents the postinst from asking
questions about creating a boot floppy, and no boot
floppy is created. The bootloader shall still be run.
This may cut down on the interaction the postinst has.
(It still prompts before formatting /dev/fd0). Defaults
to Yes.
do_bootloader
If set to NO, this prevents the postinst from running
the bootloader. The user may still be asked to create a
floppy, unless do_bootfloppy is also set to NO. Defaults
to Yes.
postinst_hook
Set this variable to a script to be executed during
installation after all the symbolic links are cre-
ated, but before running the bootloader or offer-
ing to create a floppy. This script shall be called
with two arguments, the first being the version of
the kernel image, and the second argument being the
location of the kernel image itself. Errors in the
script shall produce a warning message, but shall
be otherwise ignored. An example script for grub
users is present in /usr/share/doc/kernel-package/
directory.
postrm_hook
Set this variable to a script to be executed in the
postrm (that is, after the image has been removed)
after all the remove actions have been performed.
This script shall be called with two arguments, the
first being the version of the kernel image, and
the second argument being the location of the ker-
nel image itself. Errors in the script shall pro-
duce a warning message, but shall be otherwise
ignored.
Please see kernel-img.conf (5).
To generate a new kernel image, just run
% make-kpkg clean
% $Get_Root make-kpkg --revision=custom.1.0 kernel_image
(Get_Root is whatever you need to become root -- fakeroot or
sudo are examples that come to mind) or (if you use initrd)
$Get_Root make-kpkg --initrd --revision=3:custom.2.0 kernel_image
This will create a default kernel image (as in the image package or
available on the boot disks. The kernel image package produced, on
installation, shall offer you a chance to create a boot disk, or to
run LILO (or SILO, QUIK, VMELILO, ZIPL, yaboot, PALO, or update the
grub menu), but the default is not to do either, and you may choose to
ignore these friendly overtures by the postinst.
If you want a custom kernel, you may generate a config file by any of
these methods (just follow the directions).
% make config # boring old tty based method
or
% make menuconfig # curses based menu driven method (uses color if
you have any)
% make xconfig # An X window system based method -- make sure
you are running X windows when you call this.
All these methods ultimately generate a .config file. If you already
have a .config file, just copy it to this directory, and you are go.
With a custom .config file in place (created as above) run again:
% make-kpkg clean
% $Get_Root make-kpkg --revision=custom.1.0 kernel_image
(Get_Root is whatever you need to become root -- fakeroot or
sudo are examples that come to mind).
|-----------------------------------------------------------------------|
| Special needs |
| Or, for people who want to minimize time spent in fakeroot (for |
| whatever reasons that maybe -- I think that the separate step as |
| non-fake-root is not required, but that is a personal opinion) |
| % make-kpkg clean |
| % make-kpkg --revision=custom.1.0 build |
| % $Get_Root make-kpkg --revision=custom.1.0 kernel_image |
| (Get_Root is whatever you need to become root -- fakeroot or |
| sudo are examples that come to mind) |
| |
| For people who wish to see the username (not root) when they do a |
| uname -a on the machine when they install the kernel, there is a |
| trick: |
| % make config |
| % make-kpkg build |
| % $Get_Root make -f debian/rules kernel-image-deb |
| shall generate a kernel image with the username of the user embedded |
| in it. |
| |
| If you use initrd images (and have told your boot loader so) you need |
| to include the --initrd option on the command line, like so |
| |
| % $Get_Root make-kpkg --initrd --revision=3:custom.2.0 kernel_image |
| |
-------------------------------------------------------------------------
To create a source or header package, run
% make-kpkg clean
% $Get_Root make-kpkg --revision=custom.1.0 kernel_source
% $Get_Root make-kpkg --revision=custom.1.0 kernel_headers
Note: You only need one of these.
(Get_Root is whatever you need to become root -- fakeroot or
sudo are examples that come to mind).
Similarly, the documentation package is built by:
% $Get_Root make-kpkg --revision=custom.1.0 kernel_doc
Or if you want to generate the whole package,
% $Get_Root make-kpkg --revision=custom.1.0 \
--pgpsign="Your pgp ID" buildpackage
Note that this needs a pgp key.
(Get_Root is whatever you need to become root -- fakeroot or
sudo are examples that come to mind).
A note on boot loaders: the kernel-image install-scripts arrange to
have /vmlinuz and /vmlinuz.old point to the latest kernel image and
the next most recent one, respectively. You may choose to have your
boot loader take advantage of this by putting image = /vmlinuz and
image = /vmlinuz.old lines in your lilo.conf (or whatever config files
your boot loader uses -- please read documentation on your boot loader
for details). Oh, and if your kernel image package uses initrd (as do
the newer official kernel image packages), please do not forget to add
a line (initrd=/boot/initrd-2.4.X-flavour) in your lilo.conf file
pointing out this fact to your boot loader.
Conversely, people who wish to tightly control the versions in
lilo.conf (believe me, people, this gets to be a pain in the neck
fast) can use image = /boot/vmlinuz-X.X.XX.
For folks using grub, there are now postinst_hook and postrm_hook
variables that can be pointed to scripts that add or remove a line
from the grub menu list at kernel image install and remove times. A
sample script to add lines to a grub menu file is included in the dir
/usr/share/doc/kernel-package/; and simple scripts like:
# perl -nle 'print unless /^#Autogenerated by kernel-image $version/ \
.. /^#End kernel-image '$version/'
or for awk fans
# awk 'BEGIN{printit=1}
/^#Autogenerated by kernel-image $version/{printit=0}
/^#End kernel-image '$version/{printit=1}
{if (printit) {print}}'.
or
# awk '{p=0}
/^#Autogenerated by kernel-image $version$/,
/^#End kernel-image '$version$/ {p=1}
{if(!p) print}' < foo
can be put in a script and added to the postrm hook script to remove
the lines added by kernel_grub_conf.sh
So that loadlin people don't feel left out, all this talk about LILO
does not mean to ignore loadlin, you can use the generated
kernel-image just as easily (simply ignore the fol-de-rol with symlinks
in /). For instance, you could:
[1]# dpkg -BRGiE kernel-image-X.X.XX, # need to be root
and then
[2]% cp /boot/vmlinuz-X.X.XX <place where loadlin needs image>
[3]% echo '' > /boot/vmlinuz-X.X.XX
So you don't have the image taking up space, but still leave a
target for the /vmlinuz symlink.
Recompiling a kernel image
----------- - ------ -----
It happens to all of us. When we configured the kernel, we missed out
on an module. Or we added in more things than we really need, and need
to compile again. If you just recompile a kernel image, it shall, when
installed, contain the same /boot/{System.map,config,vmlinuz}-X.X.XX
files and the /lib/modules/X.X.XX directory that the previous kernel
image contained.
If you try to install the recompiled kernel image over the previous
kernel image (same version and flavour), then the install scripts
detect that, and ask you to move at least the /lib/modules/X.X.XX dir
away. If you continue anyway, the files in /boot shall be overwritten.
Also, if you try to recompile with a changed --revison option or a
different debian revision, you shall have to make-kpkg clean, and then
recompile.
Tecras and other notebooks
--------------------------
(Many thanks to Philip Hands <phil@hands.com> and
Avery Pennarun <apenwarr@worldvisions.ca> for this explanation)
Tecras and other notebooks, and some PCs have a problem where they
fail to flush the cache when switching on the a20 gate (IIRC), which
is provoked by bzImage kernels, but not by zImage kernels.
bzImage files are actually "big zImage" not "bzipped Image". bzImage
kernels can be as large as you like, but because they need to decompress
into extended memory, they aggravate this problem. zImage kernels just
compress into conventional memory, so they never need to touch the a20 gate,
but they hit the 640k limit.
There are two solutions that I know of:
1) Apply a patch, which flushes the cache. Unfortunately this
causes other machines to crash so is not universally applicable
(hence the tecra disks being segregated from the mainstream).
2) Build a zImage, rather than bzImage kernel. This seems to get
round the problem. use the --zimage option to make-kpkg, or even
set this as the default in /etc/kernel-pkg.conf (or ~/.kernel-pkg.conf) .
There some add-on modules that hook into make-kpkg and the kernel
sources so that they may be kept in synchrony with the kernel you
run. If you have such a module source package, for example,
pcmcia-source, then please read README.modules as well. If you don't
never mind. (The file is in /usr/share/doc/kernel-source-X.X.XX/. If you
don't have kernel-source packages installed [that's OK], there is a
copy in /usr/share/kernel-package/README.modules).
Have fun,
Manoj Srivastava
Foot note 1:
For an explanation on why this synchronization is required, consider
this. The kernel knows what version it is, as given in the kernel
Makefile as the variables VERSION, PATCHLEVEL, and SUBLEVEL. It will
look for the modules in /lib/modules/$VERSION.$PATCHLEVEL.$SUBLEVEL.
The Debian scripts think they know what the kernel version is, as
given in the Debian file rules as the variable v (near the top). It
then proceeds to put the modules in /lib/modules/$v. So, it is
essential that the kernel (Makefile) and the Debian script (rules)
agree about the version number, or the kernel will never figure out
where the Debian scripts hid the modules. So change the version
number in the file rules (v = X.X.XX) to be the same version as
given in the kernel Makefile (this will be
$VERSION.$PATCHLEVEL.$SUBLEVEL).
--
Manoj Srivastava <srivasta@debian.org>
PGP Key ID: 1024/C7261095
Key fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
|
