Hi all

Last year on my gentoo box I compiled the 2.6.12.5 kernel and it came in at
around 1.5 mgs, and today I compiled the 2.6.17 kernel with mostly the same
options and it came in around 4.5 mgs! I re-tired to compile the 2.6.12.5
kernel with the same settings I had last year (.config file) and it now also
comes in at around 4.5 mgs. Why is this?

Since last year I have upgraded baselayout, portage, and various other
utilities, I have not upgraded gcc or binutils. When going through grub to boot
the only kernel that works is the original 1.5 mg 2.6.12.5 kernel made last
year; both 4.5 mg kernels I compiled today give grub error 13's, which means
they can't execute the format (linux bzImage).

The options compiled in the 2.6.12.5 kernel from last year and today are EXACTLY
the same and the 2.6.17 kernel is close enough that the problem is not in the
kernel options. I have a feeling one of the symptoms is an increase in size.
What could be causing this, and how can I fix it?

TIA,
~David~

On Monday 19 June 2006 00:02, ~David~ stood up and spoke the following
words to the masses in /alt.os.linux.gentoo...:/

> Hi all
>
> Last year on my gentoo box I compiled the 2.6.12.5 kernel and it came
> in at around 1.5 mgs, and today I compiled the 2.6.17 kernel with
> mostly the same options and it came in around 4.5 mgs! I re-tired to
> compile the 2.6.12.5 kernel with the same settings I had last year
> (.config file) and it now also comes in at around 4.5 mgs. Why is
> this?
>
> Since last year I have upgraded baselayout, portage, and various other
> utilities, I have not upgraded gcc or binutils. When going through
> grub to boot the only kernel that works is the original 1.5 mg
> 2.6.12.5 kernel made last year; both 4.5 mg kernels I compiled today
> give grub error 13's, which means they can't execute the format (linux
> bzImage).
>
> The options compiled in the 2.6.12.5 kernel from last year and today
> are EXACTLY the same and the 2.6.17 kernel is close enough that the
> problem is not in the kernel options. I have a feeling one of the
> symptoms is an increase in size. What could be causing this, and how
> can I fix it?

The only thing I can think of which would explain both the increase in
filesize and the GRUB error would be if the file you've copied into
*/boot* is the actual compiled kernel - i.e. the /vmlinux/ file - and
not the compressed kernel image - i.e. the /vmlinuz/ file.

It's only one character that differs in the name, but a significantly
different thing in regards to getting to boot such a kernel, and of
course to the filesize... ;-)

Just my two cents worth... ;-)

--
With kind regards,

*Aragorn*
(Registered GNU/Linux user # 223157)

On Sun, 18 Jun 2006 22:02:43 +0000, ~David~ wrote:

> Hi all
>
> Last year on my gentoo box I compiled the 2.6.12.5 kernel and it came in
> at around 1.5 mgs, and today I compiled the 2.6.17 kernel with mostly the
> same options and it came in around 4.5 mgs! I re-tired to compile the
> 2.6.12.5 kernel with the same settings I had last year (.config file) and
> it now also comes in at around 4.5 mgs. Why is this?
>
> Since last year I have upgraded baselayout, portage, and various other
> utilities, I have not upgraded gcc or binutils. When going through grub to
> boot the only kernel that works is the original 1.5 mg 2.6.12.5 kernel
> made last year; both 4.5 mg kernels I compiled today give grub error 13's,
> which means they can't execute the format (linux bzImage).
>
> The options compiled in the 2.6.12.5 kernel from last year and today are
> EXACTLY the same and the 2.6.17 kernel is close enough that the problem is
> not in the kernel options. I have a feeling one of the symptoms is an
> increase in size. What could be causing this, and how can I fix it?
>
> TIA,
> ~David~

1: did you run make oldconfig first? If not, some defaults could be adding
to the bloat. If /boot does not have a config file, copy the config file
from your 2.6.12 src directory to the 2.6.17 one. Are you compiling using
-g? Are debugging options turned on in the .config file. Did you compile
using the bzImage option? (make all usually defaults to that).

And, as the other poster noted, are you copying the right file to /boot?

cp -v arch/i386/boot/bzImage /boot/bzImage-${kernel-version}

I have x86, your second directory above may differ.
--
Peter

Aragorn <stryder@telenet.invalid> wrote:
> On Monday 19 June 2006 00:02, ~David~ stood up and spoke the following
> words to the masses in /alt.os.linux.gentoo...:/
>
> The only thing I can think of which would explain both the increase in
> filesize and the GRUB error would be if the file you've copied into
> */boot* is the actual compiled kernel - i.e. the /vmlinux/ file - and
> not the compressed kernel image - i.e. the /vmlinuz/ file.
>
> It's only one character that differs in the name, but a significantly
> different thing in regards to getting to boot such a kernel, and of
> course to the filesize... ;-)
>
> Just my two cents worth... ;-)

Let me chime in with mine too -- on a system with an internal drive these
days, there's really no point in having a compressed kernel image -- it
takes slightly longer as it has to unpack, and you lose a tiny bit of
memory.
For a USB/CD install, yes, I can see the point of saving disk space, but for
today's large and fast HDs, it isn't beneficial.

(The trade-off between speed and storage is seen other places too, where I
believe the GNU/Linux distros have made the wrong choice. For example, man
pages are traditionally compressed with "pack" in Unix, despite there being
better packers. This is done deliberately, because even though pack doesn't
pack too well, it's lightning fast, and in most cases it's faster to
decompress a packed file than it is to read the original. But, with
GNU/Linux, no, the distros use gzip or bzip2, which eat CPU and RAM, and are
much much slower. It's like they whoever implemented it didn't know why
"pack" was used in the first place, or had serious space issues.)

Regards,
--
*Art

You were right, I copied the wrong image over.

I've done this a few times times so you'd think I'd have remembered the bzImage
location by now...

Thanks,
~David~
>
> The only thing I can think of which would explain both the increase in
> filesize and the GRUB error would be if the file you've copied into
> */boot* is the actual compiled kernel - i.e. the /vmlinux/ file - and
> not the compressed kernel image - i.e. the /vmlinuz/ file.
>
> It's only one character that differs in the name, but a significantly
> different thing in regards to getting to boot such a kernel, and of
> course to the filesize... ;-)

Arthur Hagen wrote:

>
> Let me chime in with mine too -- on a system with an internal drive
> these days, there's really no point in having a compressed kernel image
> -- it takes slightly longer as it has to unpack, and you lose a tiny bit
> of memory.
> For a USB/CD install, yes, I can see the point of saving disk space, but
> for today's large and fast HDs, it isn't beneficial.
>
> (The trade-off between speed and storage is seen other places too, where
> I believe the GNU/Linux distros have made the wrong choice. For
> example, man pages are traditionally compressed with "pack" in Unix,
> despite there being better packers. This is done deliberately, because
> even though pack doesn't pack too well, it's lightning fast, and in most
> cases it's faster to decompress a packed file than it is to read the
> original. But, with GNU/Linux, no, the distros use gzip or bzip2, which
> eat CPU and RAM, and are much much slower. It's like they whoever
> implemented it didn't know why "pack" was used in the first place, or
> had serious space issues.)
>
> Regards,



One thing, the kernel is loaded in a "special" part of the memory and
that size is limited. Compressing the kernel is not for the sake of
saving disk space but for it to not exceed that memory size...

That is why grub (or lilo) tells you that the kernel is too big when you
try to boot the uncompressed one.

Personnally runing linux on an ppc i don't need to worry about that and
use a non compressed kernel which doesn't need loading/decompression
time on boot.

On Wednesday 28 June 2006 09:29, abelenda stood up and spoke the
following words to the masses in /alt.os.linux.gentoo...:/

> Arthur Hagen wrote:
>
>> Let me chime in with mine too -- on a system with an internal drive
>> these days, there's really no point in having a compressed kernel
>> image -- it takes slightly longer as it has to unpack, and you lose a
>> tiny bit of memory. [...]
>
> One thing, the kernel is loaded in a "special" part of the memory and
> that size is limited. Compressing the kernel is not for the sake of
> saving disk space but for it to not exceed that memory size...

This is correct. /x86/ CPU's traditionally boot up in the CPU's /real/
/mode,/ which emulates an 8086. This is a heritage from times now long
gone, which was needed for two reasons:

(1) Microsoft Windows was the most used operating environment on /x86/
architectures as of Windows 3.0, which ran on top of DOS. Later on,
Microsoft kept on marketing alleged operating systems such as Windows
95 (in various iterations), Windows 98 (in two versions) and Windows
Millenium Edition.

All of these still bootstrapped off of a DOS kernel, and DOS doesn't
recognize anything other than an /i8086/ CPU without special device
drivers that tell it that there's more memory installed than 640 KB and
that make use of this memory by switching the CPU to /protected/ /mode/
- the native mode of any 32-bit and 64-bit /x86/ CPU - to access this
memory. Windows itself - or at least, the core of it - was programmed
in DPMI, i.e. DOS Protected Mode Interface.

(2) As has been the tradition ever since Microsoft got a stronghold on
the PC market, hardware manufacturers have been adjusting to Microsoft
and Windows, rather than that the software was adjusted to the
hardware. As a result of this, the PC architecture was stuck with
legacy BIOS versions, which would always reset the CPU on boot-up, so
that it boots in /real/ /mode./

For those using other architectures and unfamiliar with the modes of the
/x86/ architecture: /real/ /mode/ is called "real" because in this
mode, the software can access the real hardware and memory addresses,
whereas in /protected/ /mode,/ only the kernel can do that, and virtual
memory is issued to userspace processes.

> That is why grub (or lilo) tells you that the kernel is too big when
> you try to boot the uncompressed one.
>
> Personnally runing linux on an ppc i don't need to worry about that
> and use a non compressed kernel which doesn't need
> loading/decompression time on boot.

That's again because of two things... ;-) First of all, the /PPC/
architecture doesn't feature a /real/ /mode/ like the /x86/ does - it's
a RISC design - and secondly, /PPC/ machines make use of an EFI BIOS.

EFI also exists for /x86/ - although it's not quite widespread there yet
- and could allow an /x86/ CPU to boot in /protected/ /mode,/ thus
skipping the loading of a compressed kernel image in /real/ /mode/ and
then switching the CPU to /protected/ /mode/ prior to decompressing the
kernel (and an eventual /initrd/ or /initramfs)./

Another advantage of an EFI BIOS is that it supports up to 128 primary
partitions per hard disk, whereas the current legacy BIOS only supports
four primary partitions, one or several of which could be extended
partition containers with logical partitions in them.

Of course, having an EFI BIOS in the machine warrants a special version
of LILO, called /ELILO./ I don't know about GRUB, but I presume that
it does or will exist in a special version for EFI as well by the time
EFI becomes mainstream on /x86./

;-)

--
With kind regards,

*Aragorn*
(Registered GNU/Linux user # 223157)

In article <e7677g$n4g$1@tree.broomstick.com>,
"Arthur Hagen" <art@broomstick.com> wrote:

>Let me chime in with mine too -- on a system with an internal drive these
>days, there's really no point in having a compressed kernel image -- it
>takes slightly longer as it has to unpack, and you lose a tiny bit of
>memory.
>For a USB/CD install, yes, I can see the point of saving disk space, but for
>today's large and fast HDs, it isn't beneficial.

It's the opposite way round. The disparity between RAM and hard drive
speeds is so great these days that it's quicker to load a compressed
file into RAM and then spend the CPU time to decompress it, than it is
to load the larger, uncompressed file.

This applies to most peripherals, not just hard drives. Also includes
networks.

In article <TPNog.509481$8U2.12784742@phobos.telenet-ops.be>,
Aragorn <stryder@telenet.invalid> wrote:

>... and secondly, /PPC/ machines make use of an EFI BIOS.

EFI on PowerPC? First I heard of it. Wasn't EFI invented by Intel within
the last 5 years? Whereas PowerPC machines go back to 1993 or so.

I think you mean Open Firmware rather than EFI?

On Saturday 08 July 2006 02:04, Lawrence D'Oliveiro stood up and spoke
the following words to the masses in /alt.os.linux.gentoo...:/

> In article <TPNog.509481$8U2.12784742@phobos.telenet-ops.be>,
> Aragorn <stryder@telenet.invalid> wrote:
>
>>... and secondly, /PPC/ machines make use of an EFI BIOS.
>
> EFI on PowerPC? First I heard of it. Wasn't EFI invented by Intel
> within the last 5 years? Whereas PowerPC machines go back to 1993 or
> so.

Well, I could be wrong of course - I certainly don't want to proclaim
myself to hold the Gospel on anything ;-) - but I was told that the
/PPC-based/ MacIntoshes - e.g. G3, G4 and G5 - had an EFI BIOS.

I've never owned such a machine - I've only sat at a G3 once before to
do some desktop publishing work - so I can't really vouch for the
validity of what I've written there. I apologize for my being too
presumptious... :-/

> I think you mean Open Firmware rather than EFI?

I'm not sure about that - you've given me doubts... I'd have to look it
up again to be certain... ;-)

--
With kind regards,

*Aragorn*
(Registered GNU/Linux user # 223157)