Date: Tue, 19 Oct 1999 00:51:27 +0900 From: "Daniel C. Sobral" <dcs@newsguy.com> To: Will Andrews <andrews@TECHNOLOGIST.COM> Cc: current@FreeBSD.ORG, marcel@freebsd.org, msmith@freebsd.org, peter@freebsd.org Subject: Re: -CURRENT `make world` fails.. (ucontext.h?) Message-ID: <380B41FF.C4CB44D8@newsguy.com> References: <XFMail.991017203233.andrews@TECHNOLOGIST.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
[cc'ing Marcel just in case he wants to volunteer any suggestion... :)] [also cc'ing Mike Smith since aout_freebsd.c seems to be his] [and cc'ing Peter too, since he dabbed a lot in that file] Will Andrews wrote: > ... > Is there any additional information I can provide (I noticed a related thread, > but DCS's reply didn't seem to help..)? 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. 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. Alternatively (I just thought of it), you might want to interrupt the boot at boot2 (press any key while the | is being displayed), and boot the kernel directly from there, avoiding going through loader. I'd be interested in hearing whether this can be used as a work-around or not. 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. 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 <file.h> #include. 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? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "I always feel generous when I'm in the inner circle of a conspiracy to subvert the world order and, with a small group of allies, just defeated an alien invasion. Maybe I should value myself a little more?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?380B41FF.C4CB44D8>