[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Fixed silo uploaded (Was: something wierd about silo...)

Eric Delaunay <delaunay@lix.polytechnique.fr> writes:

> Steve Dunham wrote:
> > I'm uploading a silo NMU to fix a (unfiled) critical bug.  Namely,
> > that silo won't boot CDs on many systems (particularly Sun4m).  The
> > issue is the kernel overwriting the RAM disk (not the kernel
> > executable, but the kernel overwrites the RAM disk while it's
> > initializing memory management) - solution is to give the kernel a
> > little more headroom.  (It had about 1MB of space between the end of
> > the kernel and the RAM disk, but apparently that wasn't enough.)

> I have had to shrink down the size of the 2.0.35 kernel (by removing one or
> two drivers) to be able to load the ramdisk.  It worked on SparcClassic but
> maybe the kernel is allocating more memory in sparc10 and co :-((
> Thanks for fixing this problem.

The Sun4m kernel is allocating a bit more memory.

> OTOH, there is still a bug in the /dev/fb* devices (bad permissions
> I guess).  I don't know if I will have time to upload a new set of
> bootdisks that fixes it.  I will be out of my town till sunday
> night, and the time to release is now really short.  If I need to
> upload them, I'm afraid I cannot do it before next monday evening
> :-(( Therefore, could it be fixed in the postinst of xserver-xsun*
> packages instead?  Or could it be just well documented in a bug
> section of the documentation ?

There is also one more change I'd like in the 2.2.1 kernels.  When you
told me to include RARP support, I thought you meant IP_PNP_RARP,
which is very annoying.  (It causes long delays on startup if you
don't have a RARP server.)  It will be in the binary packages I upload
today.  It's not critical.

(I think I'm going to give up on kpkg-make - writing my own rules file
is easier than writing one that makes kpkg-make do what I want.)


Reply to: