Prev: IPv4 localhost network problem
Next: ext2/3 vs xfs for maildir
From: Celejar on 29 Dec 2009 16:30
On Tue, 29 Dec 2009 11:54:36 -0600
Stan Hoeppner <stan(a)hardwarefreak.com> wrote:

> David Baron put forth on 12/29/2009 10:35 AM:
>
> > -rw-r--r-- 1 root root 12781374 Oct 29 18:11 /usr/src/linux-image-2.6.31-
> > davidb_2.6.31-davidb-10.00.Custom_i386.deb
> > -rw-r--r-- 1 root root 12785544 Nov 16 22:14 /usr/src/linux-image-2.6.31-
> > davidb-svn14611_2.6.31-davidb-svn14611-10.00.Custom_i386.deb
> > -rw-r--r-- 1 root root 12870190 Oct 28 19:29 /usr/src/linux-image-2.6.31-rt-
> > davidb_2.6.31-rt-davidb-10.00.Custom_i386.deb
> > -rw-r--r-- 1 root root 13104356 Dec 27 21:23 /usr/src/linux-image-2.6.32.1-
> > davidb_2.6.32-davidb-10.00.Custom_i386.deb
> > -rw-r--r-- 1 root root 13109468 Dec 28 19:41 /usr/src/linux-image-2.6.32-
> > davidb_2.6.32-davidb-10.00.Custom_i386.deb
> >
> > The last one is the 2.6.32.3 image. Simply note the progression :-)
> > The 2.6.31.1 (first one) is much much smaller.
>
> 12.2 MB vs 12.5 MB? "much much smaller"? Why do you consider 300 KB to be
> "much much smaller"?
>
> My kernel.deb is 1.5 MB and my vmlinuz is 1.2 MB. _That_ is "much much
> smaller". ;) I've only done custom kernels on 32bit x86 headless server
> platforms, so maybe mine would double in size if I were doing X86-84 kernels due
> to 8 byte instruction words vs 4 byte words, and triple in size if I was doing
> desktops/laptops. Still, my kernel would only be 3-4.5 MB. How is yours in the
> 13MB range? Kitchen sink in there too? ;)

My current 2.6.32 laptop kernel:

-rw-r--r-- 1 root root 1439312 Dec 3 16:44 vmlinuz-2.6.32-lizzie

This is a pretty full featured config, for normal laptop use (e.g.,
includes webcam support (gspca), bluetooth, Intel graphics, iptables,
etc.). OTOH, I prune very aggressively, and take out anything that I
don't actually need.

Celejar
--
foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
From: David Baron on 30 Dec 2009 09:10
On Tuesday 29 December 2009 23:21:21 debian-user-digest-
request(a)lists.debian.org wrote:
> 12.2 MB vs 12.5 MB? "much much smaller"? Why do you consider 300 KB to be
> "much much smaller"?
>
> My kernel.deb is 1.5 MB and my vmlinuz is 1.2 MB. That is "much much
> smaller". ;) I've only done custom kernels on 32bit x86 headless server
> platforms, so maybe mine would double in size if I were doing X86-84
> kernels due to 8 byte instruction words vs 4 byte words, and triple in
> size if I was doing desktops/laptops. Still, my kernel would only be
> 3-4.5 MB. How is yours in the 13MB range? Kitchen sink in there too? ;)
>

Probably is because I do not know what is safe to set to "no". These are
basically stock kernels with whatever would have been in the initrd compiled
in instead. The debs are full of modules, most of which simply take up space.


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
From: John Hasler on 30 Dec 2009 09:40
David Baron writes:
> Probably is because I do not know what is safe to set to "no". These
> are basically stock kernels with whatever would have been in the
> initrd compiled in instead.

Then why not use the initrd?
--
John Hasler


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
From: Mark Allums on 30 Dec 2009 13:10
I've only done custom kernels on 32bit x86 headless server
>> platforms, so maybe mine would double in size if I were doing X86-84
>> kernels due to 8 byte instruction words vs 4 byte words,

I expect that this is merely terminology, but I don't think that 64-bit
x86_64/amd64 architecture exactly has eight byte instruction words;
rather it has 64/128-bit registers. What mainly changed is the addition
of many more general purpose registers, and the support for 64-addresses
(i.e. pointers.)

You are correct that virtually all 64-bit executable text binaries are
much larger as a result.

Mark Allums


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
From: Stephen Powell on 30 Dec 2009 15:50
On 2009-12-30 at 08:45:14 -0500, David Baron wrote:
> Probably is because I do not know what is safe to set to "no". These are
> basically stock kernels with whatever would have been in the initrd compiled
> in instead. The debs are full of modules, most of which simply take up space.

Why is it important to you to compile everything in? That makes your kernel
unnecessarily big and wastes RAM. If the stock kernel does what you need it
to do, why bother to create a custom kernel anyway? That chews up a lot of
disk space too. My advice, for what it's worth, is this:

(1) use a stock kernel if you can, unless you really need something that's not
included in the stock kernel.

(2) If you do need to create a custom kernel, don't compile anything in that
can be modularized.

(3) If you still have problems with lilo running out of space between the end
of the kernel and the beginning of the EBDA (i.e. not enough room to load
the initial RAM disk image), then add the large-memory option in the
the /etc/lilo.conf file, if your BIOS supports it, and re-run lilo.
(If the BIOS doesn't support the large-memory option, you'll
know pretty quickly! Make sure you have a rescue CD at the ready.
This option will affect all kernels defined to lilo; so if you can't
boot one, you probably can't boot any!)

(4) If your BIOS doesn't support the large-memory option, try editing
/etc/initramfs-tools/initramfs.conf and change "modules=most" to
"modules=dep", then run update-initramfs to update your initial RAM
file system. (Issue "rm /boot/*.bak" afterward to save disk space.)
If update-initramfs doesn't re-run lilo, then re-run lilo manually.
This will reduce the size of your initial RAM file system, which we
hope will allow it to fit between the end of the kernel and the beginning
of the EBDA. (Do remember to take the large-memory option out of
/etc/lilo.conf before running update-initramfs, if you tried it
and it didn't work.)

(5) If that doesn't work for you, upgrade to a newer boot loader, such
as grub, which can get around the BIOS memory restrictions with native I/O.


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: IPv4 localhost network problem
Next: ext2/3 vs xfs for maildir