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
