Date: Fri, 20 Aug 2004 17:46:08 +0100 From: Doug Rabson <dfr@nlsystems.com> To: Ruslan Ermilov <ru@FreeBSD.org> Cc: Ken Smith <kensmith@FreeBSD.org> Subject: Re: Alpha is seriously broken Message-ID: <1093020367.9863.13.camel@builder02.qubesoft.com> In-Reply-To: <20040820151503.GC92603@ip.net.ua> References: <20040820101817.GE27931@ip.net.ua> <1092999187.9863.2.camel@builder02.qubesoft.com> <20040820105915.GA29178@ip.net.ua> <1093000460.9863.4.camel@builder02.qubesoft.com> <20040820120757.GC29568@ip.net.ua> <xzpn00qeycb.fsf@dwp.des.no> <20040820135844.GA76070@ip.net.ua> <1093012873.9863.11.camel@builder02.qubesoft.com> <20040820151503.GC92603@ip.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1093020367.9863.13.camel>