Re: Alpha is seriously broken

From: Ruslan Ermilov <ru_at_FreeBSD.org>
Date: Fri, 20 Aug 2004 20:48:45 +0300
On Fri, Aug 20, 2004 at 05:46:08PM +0100, Doug Rabson wrote:
> On Fri, 2004-08-20 at 16:15, Ruslan Ermilov wrote:
> > On Fri, Aug 20, 2004 at 03:41:13PM +0100, Doug Rabson wrote:
> > > On Fri, 2004-08-20 at 14:58, Ruslan Ermilov wrote:
> > > > On Fri, Aug 20, 2004 at 03:24:52PM +0200, Dag-Erling Sm?rgrav wrote:
> > > > > Ruslan Ermilov <ru_at_freebsd.org> writes:
> > > > > > I think there's no emergency plan other than to reinstall "base"
> > > > > > on these systems from some older snapshot?
> > > > > 
> > > > > cross-compile on a different machine in the cluster, copy over the new
> > > > > make(1), then use it to installworld over NFS.
> > > > > 
> > > > Only if this machine is also Alpha.  To tell you the truth, some bits
> > > > produced by cross-compiles on different architectures are not ready
> > > > for use on a native architecture.  This includes binary files such as
> > > > fortune(6) .dat files, NLS catalogs, etc.  I haven't identified them
> > > > all yet.
> > > > 
> > > > Once I get my "modern" Alpha box, I will start working on a project
> > > > that will eventually address this, so cross- builds and releases
> > > > will produce the same binary files as on native platforms.  NetBSD
> > > > achieved a great success in this direction, so it shouldn't be too
> > > > hard to fix.
> > > 
> > > It might be quicker to extract various critical static binaries (init,
> > > make, cc, ld etc.) from an unbroken bindist. Oh and hope that beast
> > > doesn't crash before you replace init :-)
> > > 
> > Hmm, but init(8) is also a statically linked binary.  Heh, and I know
> > why beast is still alive -- it's due to the way the /root script that
> > automatically updates the world and kernel on beast works.  The script
> > does, in this risky sequence: buildworld, installworld, and the "old
> > way" kernel build/install, then reboots in five minutes.  At this time,
> > after it made installworld and attempted to build a kernel, it failed
> > to do so (the /boot/kernel/kernel is still old).  Installworld was
> > fine because it saves tools that it uses (including "sh" and "make"
> > into WORLDTMP).
> > 
> > So Ken, if you want to attempt to revive this machine, don't reboot
> > it yet, it won't boot up with the new init(8).  Of course, we have
> > /sbin/init.bak saved, but...  ;)
> 
> Another idea - if the obj tree is still around on beast, you might be
> able to re-run 'make everything' if you can find a working make binary.
> 
Unlucky day for the beast...  That was the first thing I though about.
Unfortunately, /usr/obj/usr/src on beast is not around, because
/root/buildworld.sh does the following:

rm -rf world* build* /usr/obj/`/bin/pwd`
tcsh -c 'time make -s buildworld' > /usr/src/world.log 2>&1

Since /bin/rm is dynamically linked, it succeeded in removing
/usr/obj/usr/src.  Then make(1) failed right away:

$ cat /usr/src/world.log
Segmentation fault (core dumped)
0.000u 0.005s 0:00.00 0.0%      0+0k 0+0io 0pf+0w

My sincere sympathies to Ken.


Cheers,
-- 
Ruslan Ermilov
ru_at_FreeBSD.org
FreeBSD committer

Received on Fri Aug 20 2004 - 15:48:50 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:07 UTC