kernel too big

Hi all
i have a problem with my new kernel 2.4.20.
i've compiled kernel with bzImage and it still too big. It's about 700kB.
what is solution for this? i've marked only necessary options in kernel
configuration menu (necessery for me)

thanks in advance
Rafal

Hey - 700K is normal, unless you are making a kernel for a boot-floppy.

Usual redhat or mandrake kernels are about 1.2M large.

Anyway, if you want to reduce the size of the kernel, try compiling cdrom,
floppy, usb, iso9660fs and other not-frequently-used stuff as modules.


Again, what is this kernel for? If not for a floppy - don't worry, 700K is
okay.


> Hi all
> i have a problem with my new kernel 2.4.20.
> i've compiled kernel with bzImage and it still too big. It's about 700kB.
> what is solution for this? i've marked only necessary options in kernel
> configuration menu (necessery for me)
>
> thanks in advance
> Rafal

In article <bdv7hl$e3e$1@atlantis.news.tpi.pl>, Rafa³ wrote:
> Hi all
> i have a problem with my new kernel 2.4.20.
> i've compiled kernel with bzImage and it still too big. It's about 700kB.
> what is solution for this? i've marked only necessary options in kernel
> configuration menu (necessery for me)

Make good use of modules. Mine is 572K.

What makes you think 700K is too big?

--
Seth H Holmes

Artemio <artemio@artemio.net> wrote:
> Hey - 700K is normal, unless you are making a kernel for a boot-floppy.

Why do you say that? There will be lots of room to spare on the usual
1.44 mB floppy.

--
Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* I hear and I forget. I see and I remember. I do and I understand.
--Confucius, 551-479 BC */

Clifford Kite wrote:

> Artemio <artemio@artemio.net> wrote:
>> Hey - 700K is normal, unless you are making a kernel for a boot-floppy.
>
> Why do you say that? There will be lots of room to spare on the usual
> 1.44 mB floppy.
>

Probably depends on what glibc you are using on this boot floppy.

And, yes just a floppy too boot can hold a rather big kernel, no glibc
needed, but a rescue disk must have a shell and some utils in there that
require glibc.

E.g.:
Even with busybox (~200K) and tinylogin (~70K) used, I couldn't fit 2.4.18
kernel (600K) with glibc 2.2.

Well, yes, I did't try hard either :-)

> Nathan D Higgins wrote:

> Explain your definition of big ?
>
> --

i mean too big for lilo. when i configure lilo.conf and run lilo - lilo says
that kernel is too big
i'm going to use this kernel from local disk
my previous kernel (2.2.20) works good but it's about 600kB


Rafal

On Wed, 2 Jul 2003, Clifford Kite wrote:

>
> You said boot-floppy, not boot/root-floppy. The root floppy can
> be separate, and, in fact, I make and use a two disk rescue pair.

Why bother? Most machines can boot from a CDROM and there is a fantastic
"superrescue" CDROM available.

When was the last time you had to work with a machine that could not boot
off a CDROM?

Rafa³ wrote:
>>Nathan D Higgins wrote:
>
>
>>Explain your definition of big ?
>>
>>--
>
>
> i mean too big for lilo. when i configure lilo.conf and run lilo - lilo says
> that kernel is too big
> i'm going to use this kernel from local disk
> my previous kernel (2.2.20) works good but it's about 600kB
>
>
> Rafal
>
>

Did you use the bzImage for lilo ???

SPAM_FREE wrote:
> Did you use the bzImage for lilo ???

I remember a discussion that adressed this issue a while back.

I tried a google search to freshen my memory, but no success.

To sum things up: If Your kernel is bigger than 640k, You _must_
use the "bzImage" target when "make"-ing the kernel image, because
the loading of the "big compressed" (that's what "b" and "z" in
"bzImage" are for) kernel image requires special treatment, namely
loading it to a RAM address starting at 0x100000, while a "zImage"
will reside inside the low 640k memory range. - Which will only work
with an image size < 640k, of course. (N. b.: A "zImage" will be
unzipped to address 0x100000 also, but the "decompress_kernel" and
"inflate" functions, as well as the compressed image, are in the
low 640k space. With "bzImage", only the functions are in low memory,
but the compressed big image is at 0x100000.)

One more thing to add is that, for this to happen, You need a BIOS
that supports this. So if You have a really old box or BIOS, You might
not be able to load any "bzImage" at all. You will then eventually have
to produce a smaller kernel. (Or, rewrite the loading mechanism for the
whole story here, which in the end is the same thing.)


Cheers, Jack.

--
----------------------------------------------------------------------
My personal reading of the string "MicroSoft" expands to "NanoWeak"...

jack wrote:
> SPAM_FREE wrote:
>
>> Did you use the bzImage for lilo ???
>
>
> I remember a discussion that adressed this issue a while back.
>
> I tried a google search to freshen my memory, but no success.
>
[ SNIP ]
>>>>> One more thing to add is that, for this to happen, You need a BIOS
>>>>> that supports this. So if You have a really old box or BIOS, You might
>>>>> not be able to load any "bzImage" at all. You will then eventually have
>>>>> to produce a smaller kernel. (Or, rewrite the loading mechanism for the
>>>>> whole story here, which in the end is the same thing.)
>
>
> Cheers, Jack.
>

What you said here makes no sense ..Anything 386 and newer handels
extended memory any thing older than a 386 WON"T run linux PERIOD !

I still use an old 386 (my first IBM) as a firewall and can't remember
how long ago I started using bzImages.

I have stoped using lilo infavor of the old dos-win95 boot menu
and loadlin. Gives a nice boot menu for different ways to boot, and is
easy to manange. You don't have to remember to run lilo every time you
change the kernel ( which is a pain when trying several New additions
to a kernel) .... anyway I had several fights with lilo
The only down side is you need a small 2-3 Meg dos partition for booting