On Aug 30, 2007, at 10:48 AM, Maxim Belooussov wrote:

> Hi,
>
>
>> If you are referring to dmassage, this is a prudent & excellent
>> approach.  For those unfamiliar with dmassage, it is a Perl script
> Yes, that's what I was referring to, typo on my side :)
>
>> This is not true.  See the following:
>>
>> http://netbsd.org/ports/cobalt/faq.html#kernel
>
> Point taken. I must have misread this:
> http://mail-index.netbsd.org/port-cobalt/2007/08/09/0000.html
>
> Normally dmassage produces smaller kernels, let's see if something can
> be squeezed out of current configuration :)
>
> No further questions, I'll try to get the latest restore CD running,
> and will try to compile some dmassage-generated kernels with wireless
> drivers.

  I thought that at this time, the way it worked is that minimal  
boot.gz on the tiny partition loads, got things going, then loaded / 
netbsd- which can be bigger.

At least, when I built kernel updates for 3.99.whatever, I just put  
them in as /netbsd and left the .gz bootloader on the little  
partition alone.  Is there real reason to keep /netbsd and the other  
one in sync- is that part of the FAQ dated?

My 3.99.whatever kernel I build in March is 2.98 megs uncompressed, I  
only put it in /netbsd, and it does indeed load.  Unless the mk.conf  
did things I didn't notice, I've been fine only updating /netbsd to  
whatever I build.  I don't even mount the little boot partition so I  
would be surprised it could get updated without my knowing/seeing an  
error...

I thought that change in the bootloader happened a while back and did  
remove the problem with the kernel sizes.
If someone wants an install disk with a decked-out kernel it could  
thus be possible- if you adjust the right one.

If I've misunderstood the flow here, please educate me!

Brian