Re: -CURRENT `make world` fails.. (ucontext.h?)
[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) [EMAIL PROTECTED] [EMAIL PROTECTED] "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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT `make world` fails.. (ucontext.h?)
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 file.h #include. Yes, I thought the machine/ucontext.h 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT `make world` fails.. (ucontext.h?)
[removing cc's, since I addressed them in another message in another
thread in another list :]
Will Andrews wrote:
Yes, that's how I did it. Actually, I had 3.3-RELEASE.. I downloaded the entire
If you had 3.3-RELEASE, you wouldn't need a new loader to load the
-current kernel. That's not true of someone who had 3.1-RELEASE.
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.
Yes, I thought the machine/ucontext.h 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.
Actually, now that I spent a few minutes witht he code, it's obvious
that I was way short-sighted in this. The analysis above is too
naive, and, to be blunt, dumb. :-) Obviously, /usr/src/sys/machine/*
cannot be found, because it does not exist. /usr/include/machine/*
is generated from /usr/src/sys/${MACHINE_ARCH}/include. The makefile
uses -I so that sys/* files will be found under /usr/src/sys
(well, not exactly -- it uses a relative path, but that's the gist
of it :), but the machine/* files included by those cannot be
found.
Thus, we have a situation in which some of the include files are the
latest (sys/*.h), and some are not (machine/*.h).
The problem is triggered by machine/ucontext.h, but it could have
been triggered by a number of other files. It's just not a simple
problem to solve. :-(
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?
You ought to say that a -STABLE world will have problems with a
-CURRENT kernel. The kernel ought to be immune to -STABLE world's
problems. :-) In a perfect world, anyway. :-) Anyway, there are
problems a -STABLE world will have with a -CURRENT kernel, but they
are not likely to be crippling (ie, you should be able to make world
after booting the new kernel). One thing that *can* bite is the use
of klds. Bad ju ju may result from the use of old klds with a new
kernel.
--
Daniel C. Sobral(8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
"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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
