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.)
Steve
dunham@cse.msu.edu
Reply to: