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

Bug#68016: tftp and floppy install broken on sun4m

On Tue, Aug 01, 2000 at 01:16:39PM -0600, Erik Andersen wrote:
> On Tue Aug 01, 2000 at 07:40:38PM +0200, Christian Meder wrote:
> > > 
> > > The umount the rescue image, and try again.  Changing things
> > > the way will avoid all the pain of recompiling everything.
> > 
> > I guess we won't be able to avoid recompiling stuff, see below:
> > 
> > + mount proc /proc -t proc
> > Segmentation fault
> > 
> > The busybox mount is segfaulting for some reason. This doesn't happen with
> > the normal mount and the same kernel.
> Could you install the sparc version of strace and libnsl and 
> then run it as "strace mount proc /proc -t proc" and find where 
> it chokes.  That would help greatly,

Sorry for the late answer but I was digging a little bit into the problem:

Ok so here's my debugging story for the problem:
I started by trying your suggestion to strace the mount of proc. Copied 
strace into the root image, copied libnsl, compressed it again, wrote it 
to floppy. rebooted and oh joy: strace segfaulted too ;-)

Next try: switch to the second console of the installation and start 
strace manually. Complains that it's missing a symbol which is probably 
stripped out by the library reduction, urgh :-(

Started playing around with the console and got closer to the core of the
problem. Only two out of four command invocations from the ash shell 
are executed the rest does just segfault.

Now that we know the culprit I returned to my good old desktop sparc 10 
which is running potato and started playing with ash. Took the default
potato sparc package and verified that the behaviour is the same as the
one I see on the boot-floppies. Tested the potato package on a sparc64 
potato machine: it works fine there. Interesting ...

Compiled my own ash-0.3.5 Debian package on the sparc 10, same random 
segfaulting behaviour (note that the forked shells segfault _not_ the rootshell
itself). Compiled the slink ash-0.3.4 package: this one works fine ;-)
Compiled the ash-0.3.5 package with jobs.c reverted to ash-0.3.4, works too.
Tried to find the guilty change by invidually reverting the changes
to jobs.c to the 0.3.4 version but no luck. There's something fishy going on
here ...

Let's check the compilers. Compile 0.3.5 on a slink sparc machine and copy
it to a potato box: oh wonder, it works. Urgh, so probably a compiler problem
slink used gcc on sparc. Another last test to see if it's compiler
related: compiled 0.3.5 on potato but disabled optimization for the jobs.c
file. This version works too.

So what's the moral of the story: a (normal) bug report against gcc 2.95 
because it seems to misoptimise jobs.c for sparc (although it works on 
sparc64), an (important) bug report against ash to get it recompiled for 
sparc potato (either disable -O2 for jobs.c or use gcc2.7.2.3) which is 
needed to get proper boot floppies for sparc32 and a clarification to the
boot floppies and busybox people which are not responsible for this bug.

I'll keep the boot floppies bug open anyway until we got new sparc boot 
floppies with a fixed ash.


Christian Meder, email: meder@isr.uni-stuttgart.de
What's the railroad to me ?
I never go to see
Where it ends.
It fills a few hollows,
And makes banks for the swallows, 
It sets the sand a-blowing,
And the blackberries a-growing.
                      (Henry David Thoreau)

Reply to: