Dear group,

i know, i am another one's kernel too big, yes. Thats right...

It does no matter, i can

- only do a "make menuconfig", the menue starts, and i quit the
makeconfig, in deed, i configure nothing...

- disable things like usb, wlan, sound, and so on...

- make many modules

my kernel is between 2.2 MB and 2.8 MB big.

I do the following steps:
make menuconfig for config kernelparameters or only for having a
makefile
make dep for depend.
make clean cleaning

make bzImage for a zipped kernel....


have anyone ideas???

thanks, nice weekend.

tom

T wrote:

> my kernel is between 2.2 MB and 2.8 MB big.

> I do the following steps:
> make menuconfig for config kernelparameters or only for having a
> makefile
> make dep for depend.
> make clean cleaning
>
> make bzImage for a zipped kernel....

Hmmm. Very weird order to do things. I'd use the following order:

make clean
make menuconfig
make dep bzImage modules
make modules_install install

-Timo

--
Timo Voipio | Helsinki, Finland | ICBM at: 60 11.800 N 024 52.760 E
GeekCode ver 3: GU>CC d s-: a--- C++ UL(+)$>+++$ P+>+++ L++(+) E- W++ N++
o? K? w O M- V- PS PE Y+ PGP+ t 5++ X R tv- b++(++++) DI+ D G e- h! r !y

T <dejablue@firemail.de> wrote:
> my kernel is between 2.2 MB and 2.8 MB big.

Well, that's about 3 times too big.


> I do the following steps:
> make menuconfig for config kernelparameters or only for having a
> makefile
> make dep for depend.
> make clean cleaning

> make bzImage for a zipped kernel....

And did you then USE the bzImage, or something else altogether? A
passing idiot would imagine that you mistakenly used something else.
The idiot would tend to believe that even more, since you carefully
avoid telling us what you used as the kernel image.

> have anyone ideas???

You do. Start thinking.

Peter

Dave Uhring <daveuhring@yahoo.com> wrote:
> On Fri, 18 Jul 2003 22:15:39 +0200, Peter T. Breuer wrote:

>> T <dejablue@firemail.de> wrote:
>>> my kernel is between 2.2 MB and 2.8 MB big.
>>
>> Well, that's about 3 times too big.

> Lot smaller than my vmlinuz:

> -rwxr-xr-x 1 root root 3921955 Jun 19 21:08 vmlinux

> and only twice the size of a kernel built to support XFS and no modules
> required:

> -rw-r--r-- 1 root root 1459916 Jun 19 21:08 vmlinuz-2.4.21-xfs

betty:/boot% ls -lSr vm*
-rw-r--r-- 1 root 557214 Jan 21 2002 vmlinuz-2.2.20-SMP
-rw-r--r-- 1 root 665462 Jan 27 2002 vmlinuz-2.2.18pre18-SMP
-rw-r--r-- 1 root 829425 Sep 25 2002 vmlinuz-2.5.31-SMP-test
-rw-r--r-- 1 root 849483 Sep 2 2002 vmlinuz-2.5.31-SMP
-rw-r--r-- 1 root 890188 Jan 14 2003 vmlinuz-2.4.19-SMP-xfs
-rw-r--r-- 1 root 914979 Jan 14 2002 vmlinuz-2.4.17rc2-xfs-swsusp
-rw-r--r-- 1 root 939515 Jan 23 2002 vmlinuz-2.4.8-SMP-xfs.lkcd
-rw-r--r-- 1 root 946396 Dec 21 2001 vmlinuz-2.4.16-SMP-xfs
-rw-r--r-- 1 root 983954 Jul 30 2002 vmlinuz-2.4.17rc2-SMP-xfs-tosh_acpi
-rw-r--r-- 1 root 1000702 Oct 29 2002 vmlinuz-2.5.44-SMP
-rw-r--r-- 1 root 1007429 Nov 9 2002 vmlinuz-2.5.46-SMP
-rw-r--r-- 1 root 1008821 Jan 9 2003 vmlinuz-2.4.20-SMP-xfs
-rw-r--r-- 1 root 1010794 Nov 12 2002 vmlinuz-2.5.47-SMP
-rw-r--r-- 1 root 1052787 Mar 9 09:02 vmlinuz-2.5.64-SMP


Peter

On Fri, 18 Jul 2003 22:59:35 +0200, Peter T. Breuer wrote:

> betty:/boot% ls -lSr vm*
> -rw-r--r-- 1 root 557214 Jan 21 2002 vmlinuz-2.2.20-SMP
> -rw-r--r-- 1 root 665462 Jan 27 2002 vmlinuz-2.2.18pre18-SMP
> -rw-r--r-- 1 root 829425 Sep 25 2002 vmlinuz-2.5.31-SMP-test
> -rw-r--r-- 1 root 849483 Sep 2 2002 vmlinuz-2.5.31-SMP
> -rw-r--r-- 1 root 890188 Jan 14 2003 vmlinuz-2.4.19-SMP-xfs
> -rw-r--r-- 1 root 914979 Jan 14 2002 vmlinuz-2.4.17rc2-xfs-swsusp
> -rw-r--r-- 1 root 939515 Jan 23 2002 vmlinuz-2.4.8-SMP-xfs.lkcd
> -rw-r--r-- 1 root 946396 Dec 21 2001 vmlinuz-2.4.16-SMP-xfs
> -rw-r--r-- 1 root 983954 Jul 30 2002 vmlinuz-2.4.17rc2-SMP-xfs-tosh_acpi
> -rw-r--r-- 1 root 1000702 Oct 29 2002 vmlinuz-2.5.44-SMP
> -rw-r--r-- 1 root 1007429 Nov 9 2002 vmlinuz-2.5.46-SMP
> -rw-r--r-- 1 root 1008821 Jan 9 2003 vmlinuz-2.4.20-SMP-xfs
> -rw-r--r-- 1 root 1010794 Nov 12 2002 vmlinuz-2.5.47-SMP
> -rw-r--r-- 1 root 1052787 Mar 9 09:02 vmlinuz-2.5.64-SMP

I'm surprised you keep such old versions around; you don't use them, do
you?

Your 2.4.20-SMP-xfs kernel is surprisingly small. Did you build device
support as modules? The kernel whose size I posted has full support for
all devices on the box where it runs, including SCSI disks and tape with
an Adaptec 2940UW controller.

On Fri, 18 Jul 2003 23:52:47 +0200, Peter T. Breuer wrote:

> It's the one I suse most often (this is my portable). It has most stuff
> as modules. Umm .. let me clear out the alsa sound moudles ..
>
> betty:/boot% /sbin/lsmod

[snip list of modules ]

On my Slackware system:

[linux]# lsmod
Module Size Used by Not tainted
via686a 8096 0
i2c-proc 6992 0 [via686a]
i2c-isa 1160 0 (unused)
i2c-dev 4132 0 (unused)
i2c-viapro 3984 0 (unused)
i2c-core 14472 0 [via686a i2c-proc i2c-isa i2c-dev i2c-viapro]

Can't build lm-sensors into the kernel ;-) Well, I -might- but it would
be a waste of effort.

> Well, that would be silly, unless you boot from the scsi disk. If you
> do that, then ...

Not at all. I normally boot from /dev/hda5. The size of the kernel is
irrelevant unless one is trying to build a rescue diskette. Should I need
a rescue boot I use the Slackware installation CD and boot xfs.i to a root
prompt.

> The point is that normal sized kernels are almost one third the size of
> his.

You were probably correct about the OP using /usr/src/linux/vmlinux
instead of /usr/src/linux/arch/i386/boot/bzImage as his kernel. OP likely
does not even know where bzImage is located after a kernel build.

Dave Uhring <daveuhring@yahoo.com> wrote:
> On Fri, 18 Jul 2003 22:15:39 +0200, Peter T. Breuer wrote:

>> T <dejablue@firemail.de> wrote:
>>> my kernel is between 2.2 MB and 2.8 MB big.
>>
>> Well, that's about 3 times too big.

> Lot smaller than my vmlinuz:

> -rwxr-xr-x 1 root root 3921955 Jun 19 21:08 vmlinux

> and only twice the size of a kernel built to support XFS and no modules
> required:

> -rw-r--r-- 1 root root 1459916 Jun 19 21:08 vmlinuz-2.4.21-xfs

That's big, I have tons of stuff built in, could be easily stripped down more,
but then I don't change the config that much.

-rw-r--r-- 1 root root 999407 Nov 7 2002 /boot/vmlinuz-2.4.19
-rw-r--r-- 1 root root 1019766 Dec 1 2002 /boot/vmlinuz-2.4.20
-rw-r--r-- 1 root root 1024084 Feb 14 22:07 /boot/vmlinuz-2.4.20mh
-rw-r--r-- 1 root root 1024188 Mar 20 18:46 /boot/vmlinuz-2.4.20mh-pt
-rw-r--r-- 1 root root 1038353 Jun 14 09:57 /boot/vmlinuz-2.4.21

One doesn't get any remarkable uptime this way, but then I had one CPU melt
down this year.

--
Michael Heiming

Remove +SIGNS and www. if you expect an answer, sorry for
inconvenience, but I get tons of SPAM

On Sat, 19 Jul 2003 00:16:32 +0200, Michael Heiming wrote:

>
>> and only twice the size of a kernel built to support XFS and no modules
>> required:
>
>> -rw-r--r-- 1 root root 1459916 Jun 19 21:08 vmlinuz-2.4.21-xfs
>
> That's big, I have tons of stuff built in, could be easily stripped down more,
> but then I don't change the config that much.
>
> -rw-r--r-- 1 root root 999407 Nov 7 2002 /boot/vmlinuz-2.4.19
> -rw-r--r-- 1 root root 1019766 Dec 1 2002 /boot/vmlinuz-2.4.20
> -rw-r--r-- 1 root root 1024084 Feb 14 22:07 /boot/vmlinuz-2.4.20mh
> -rw-r--r-- 1 root root 1024188 Mar 20 18:46 /boot/vmlinuz-2.4.20mh-pt
> -rw-r--r-- 1 root root 1038353 Jun 14 09:57 /boot/vmlinuz-2.4.21
>
> One doesn't get any remarkable uptime this way, but then I had one CPU melt
> down this year.

I saw one posting on comp.unix.solaris where the OP was running the
108528-01 kernel and was bragging about his uptime. That kernel is the
FCS kernel from Jan 2000 and the machine had never been rebooted. Current
patch level is -22. Is uptime more important than keeping one's system
updated? I don't think so.

Even IBM seems to recommend periodic "maintenance downtimes", and at least
one place I know of that happens each Sunday for a dual S-390
installation.

Much of the difference in size between our kernels is due to the XFS
filesystem which I use and perhaps the SCSI drivers. The only modules
which I load are those required for lm-sensors to work with gkrellm.

If you had that working you might have seen your CPU temp rising ;-)

Dave Uhring <daveuhring@yahoo.com> wrote:
> On Sat, 19 Jul 2003 00:16:32 +0200, Michael Heiming wrote:

>> -rw-r--r-- 1 root root 999407 Nov 7 2002 /boot/vmlinuz-2.4.19
>> -rw-r--r-- 1 root root 1019766 Dec 1 2002 /boot/vmlinuz-2.4.20
>> -rw-r--r-- 1 root root 1024084 Feb 14 22:07 /boot/vmlinuz-2.4.20mh
>> -rw-r--r-- 1 root root 1024188 Mar 20 18:46 /boot/vmlinuz-2.4.20mh-pt
>> -rw-r--r-- 1 root root 1038353 Jun 14 09:57 /boot/vmlinuz-2.4.21
>>
>> One doesn't get any remarkable uptime this way, but then I had one CPU melt
>> down this year.

> I saw one posting on comp.unix.solaris where the OP was running the
> 108528-01 kernel and was bragging about his uptime. That kernel is the
> FCS kernel from Jan 2000 and the machine had never been rebooted. Current
> patch level is -22. Is uptime more important than keeping one's system
> updated? I don't think so.

There was a system with >1200 days uptime.

Honestly, as you can see from my above list, there is a constant rebooting, cause
of kernel updates. If you need availability you need a cluster anyway.

> If you had that working you might have seen your CPU temp rising ;-)

Had lm_sensors/i2c working on some of the above kernel, but just the
time the CPU melt away I was just thinking about monitoring temperature,
but I've been told that those older Athlons have a bug which will drain
more voltage if the get overheated (fan failure), which melts them away
even faster. Unsure if this leaves enough time to shutdown the box,
doesn't sound like.

BTW
Keep an eye on

--
Michael Heiming

Remove +SIGNS and www. if you expect an answer, sorry for
inconvenience, but I get tons of SPAM

On Sat, 19 Jul 2003 01:39:05 +0200, Michael Heiming wrote:

> There was a system with >1200 days uptime.

I wonder how many zombie trojans were installed on that one.

> Honestly, as you can see from my above list, there is a constant rebooting, cause
> of kernel updates. If you need availability you need a cluster anyway.

Live Upgrade on Solaris 8 and 9 provides that capability on single machine
systems. A bit of a PITA to implement, but possibly worth it. Better
IMHO to simply insist on periodic scheduled downtime.

> Had lm_sensors/i2c working on some of the above kernel, but just the
> time the CPU melt away I was just thinking about monitoring temperature,

We usually get bitten by procrastinating, don't we?

> but I've been told that those older Athlons have a bug which will drain
> more voltage if the get overheated (fan failure), which melts them away
> even faster. Unsure if this leaves enough time to shutdown the box,
> doesn't sound like.

A failing fan will probably show up in the lm_sensors display on gkrellm.
Mine is running at 6490 rpm right now with CPU core temp at 50.7 C. It
-is- time for a system cleaning. That temp should be closer to 44 C at
the current ambient of 25.3 C.

But you are likely correct about early Athlons cooking themselves to
death with inadequate cooling. One of the critical differences between
PeeCees and servers like my AlphaServer is that the Alpha will shut down
when the fan speed drops from a nominal value.

In fact, I got that AlphaServer 4100 gratis because the previous sys
admin was too dumb to diagnose and fix the problem.