kernel compile problems in Sun workstation
 

I was attempting to compile an kernel for my Redhat 6.2 Sparc box. My
workstation is the Sun Ultra 10.

I downloaded linux-2.2.16.tar.gz from kernel.org and untarred it as
/usr/src/linux-2.2.16

I entered the linux-2.2.20 dir and followed the steps:

make config
make dep
make vmlinux
make modules
make modules_install


I copied the vmlinux and System.map in /usr/src/2.2.16 to /boot then renamed them
System.map-2.2.16, vmlinux-2.2.16

edited silo to look like

partition=1
timeout=50
root=/dev/md1
read-only
default=linux

image=/vmlinux-2.2.16
label=linux

and restarted..
It looked ok then suddenly
Fatal error : Image too large to fit in destination.
Image not found. Try again.

I checked /boot/vmlinux and found the size of vmlinux is about 29M. Then I booted into the old kernel and tried zipping
my vmlinux and renaming the zipped file to
vmlinuz-2.2.16 modifying silo.conf and restarting.
I then got:
Decompression error: Uncompressed image too long - wouldn't fit into
destination. Image not found. Try again.

Does anyone see what I am doing wrong, Or can anyone give advice on how to make this work.

Instead of make vmlinux you might try make bzImage. I think that creates a compressed kernel. You also might want to go through the configuration and remove everything you don't absolutely have to have. Both make menuconfig and make xconfig(if you are in X) are much nicer ways of configuring than make config.

Sun machines don't need to compress kernel images. It's really only needed to get around the memory limitations when booting on a PC (i.e 1M in real mode). You can compress it with gzip and SILO will recognize that, but it is not needed. 29M is a really large kernel and I wonder if you just read it wrong. A google search turned up a mailing-list post. The limit seems to be around 2.6M and compression doesn't make a difference. If you read the size wrong (hint: use the '-h' option with ls to get nicer sizes) and it's really 2.9M, then it's just over the limit. Try recompiling using more modules to reduce the size of the kernel.
Oh, and don't rename your kernel to 'look like' 2.2.16. Several utilities will be looking for System.map-2.2.20, among other issues. It will also be confusing to you or others later on. I like to use symbolic links for the maintaining kernel images. Just make a link like "vmlinux-main" and edit silo.conf to use that and rerun silo. You should also make a link like "vmlinux-backup" and have that as a "backup" option in silo.conf. Then when you compile a new kernel, move vmlinux-main to vmlinux-backup, make a new vmlinux-main link for the new kernel, and run silo.