From owner-freebsd-current Mon Oct 18 9:38:42 1999 Delivered-To: freebsd-current@freebsd.org Received: from saturn.psn.net (saturn.psn.net [207.211.58.15]) by hub.freebsd.org (Postfix) with ESMTP id 24F6914BC5; Mon, 18 Oct 1999 09:38:35 -0700 (PDT) (envelope-from will@blackdawn.com) Received: from shadow.blackdawn.com (5042-243.008.popsite.net [209.224.140.243]) by saturn.psn.net (8.9.3/8.9.3) with ESMTP id JAA20926; Mon, 18 Oct 1999 09:50:39 -0700 (MST) Received: (from will@localhost) by shadow.blackdawn.com (8.9.3/8.9.3) id MAA77002; Mon, 18 Oct 1999 12:38:24 -0400 (EDT) (envelope-from will) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <380B41FF.C4CB44D8@newsguy.com> Date: Mon, 18 Oct 1999 12:38:24 -0400 (EDT) Reply-To: Will Andrews From: Will Andrews To: "Daniel C. Sobral" Subject: Re: -CURRENT `make world` fails.. (ucontext.h?) Cc: peter@FreeBSD.ORG, msmith@FreeBSD.ORG, marcel@FreeBSD.ORG, current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 18-Oct-99 Daniel C. Sobral wrote: > I'm tracking this now. Well, I'll start tracking as soon as I finish > my mail. I suggested first upgrading to 3.3 (or even 3.2), and only > then to current. That _will_ work, as it will upgrade the loader. > Alas, you need not even go to such pains. Just cvsup to -stable, cd > /sys/boot; make depend && make all install, and then cvsup to > -current, make the kernel, etc, etc. Yes, that's how I did it. Actually, I had 3.3-RELEASE.. I downloaded the entire -CURRENT CVS repository so I could get sources for September 29, before marcel's changes. Then I burned those sources to a CD-R, and loaded it on my laptop. Made world, rebooted, and I'm in 4.0-CURRENT. Then after several unsuccessful attempts to do a newer world, I finally got it. argon.blackdawn.com (my laptop) is _NOW_ running 4.0-CURRENT as of October 17, 1999 @ 9PM EDT. Only one problem is left - my pccard isn't working. I'm working with Warner Losh on that... (hopefully something good will come out of that.) > The person who first reported the problem said he succesfully used > the loader from a recent snap. That will work. Go to a near FreeBSD > ftp site, get the "loader" binary from a snapshot, copy it to /boot, > and that will be able to load a -current kernel. Interesting. All I did was rebuild the kernel again and tried another make world. For some reason, the system wanted me to build the same kernel twice. Or maybe I cvsup'd more than once, and didn't build a new kernel the second or third time. I don't know. :) I didn't try a bootloader off the ftp sites.. that wouldn't have worked for me anyway, since pccard support broke around the time I got to the bootloader in `make world`. I mean, it broke 'cause I lost my old Sept. 29 kernel. I forgot to keep a backup copy of it.. :\ > As for the problem it goes like this: > > FreeBSD 3.1's loader was not capable of loading a kernel at a > different base address than the one FreeBSD used up to that point. > Unfortunately, this resulted in an annoying bug that affected > machines with lots of RAM and big maxusers (like, for instance, > 256). This was corrected by moving the base address of kernel, which > required modifications to loader. > > Thus, FreeBSD's 3.1 loader is not capable of booting a current > kernel. Perhaps people need to install a new boot loader first (one that is of 4.0-CURRENT lineage), as you suggested. Then perhaps building a -CURRENT kernel, and rebooting. Of course, I dunno if that'd work, given the differing kernel and world.. > Now, aout_freebsd.c (and possibly other files) in > sys/boot/i386/libi386 includes sys/param.h, which, in turn, includes > sys/signal.h. The later requires machine/ucontext.h, which is not > present. Why the newer signal.h is found but not ucontext.h, I'll > find out shortly (I hope :). For now, I'm working with the > hypothesis of a "file.h" instead of #include. Yes, I thought the was the problem. Is "machine/ucontext.h" under /usr/src somewhere? I thought I saw one, but couldn't seem to finger its precise path. > All things considered, this isn't much of a problem in itself. > > There is a huge problem here,though. Generally speaking, loader is > immune to world troubles, since it uses libstand. But, are we not > risking chicken-and-egg problems such as this by including standard > sys/*.h? Situations where newer loaders are needed to boot a new > kernel (as much as we would like loader to be able to handle all > future kernels), but not being able to build them until a newer > kernel is booted? Like I said above, a -CURRENT kernel may have problems with a -STABLE world. I'm honestly not fully aware of the dependencies regarding the signal changes (i.e., ucontext.h), so my thoughts may be completely wrong. :-) Comments? -- Will Andrews GCS/E/S @d- s+:+>+:- a--->+++ C++ UB++++ P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP+>+++ t++ 5 X++ R+ tv+ b++>++++ DI+++ D+ G++>+++ e->++++ h! r-->+++ y? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message