On Fri, Dec 05, 2003 at 12:27:42AM +0100, Olivier Bornet wrote: > Hi Ben, > > On Thu, Dec 04, 2003 at 09:34:10AM -0500, Ben Collins wrote: > > Also, this includes a new sparc-mini.iso with the fixed SILO so that > > things boot again for sparc64. > > > > ISO: http://www.phunnypharm.org/pub/for/sparc-folks/sparc-mini.iso > > :-))) > > Right: this boot again on sparc64 (at least on my Ultra 10). Thanks. > > Just for my information, what was the cause, and how do you have correct > this ? I'm curious, as I have do lot of tests with the last ISO, and I > have make lot of different tries. > > Thanks in advance for your answer.
Well, I tried your scenario. I made a kernel that was small enough unstripped to boot, and then stripped it. Both times it worked. My failure only came into play with larger kernels (> 3.x Megs). Not sure of the exact byte count. However, I found that this kernel worked just fine without an initrd (just setting root=/dev/hda1), even when loaded from CD. So that all pointed to just an interaction between larger kernels and initrd's. If this was a general "stripped kernel" problem, it would have been seen when booting any machine, not just from ISO's. It was only noticed recently, because the size of kernel images on CD installs has been getting larger, but the problem has surely been there a long time. When I added code to print out the memory location that the initrd was being loaded to, I noticed the difference. On the larger kernel, it was being loaded to 0x2000, right over top of the kernel. On smaller kernels it was getting loaded up in the mapped memory regions, where it was safe. A little checking after that and the problem code was obvious. -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ WatchGuard - http://www.watchguard.com/
