Re: lastest kernel from cvs ( sh exists with signal 8 )
John Baldwin wrote: What happened is that binutils was upgraded from 2.9 to 2.10 in both -current and -stable, and the old and new binutils weren't compatible. So, you had to installworld before building your kernel (which is what I did, and always do in fact). However, this made some people uncomfortable, so a 'buildkernel' target was made to work around this one problem. No. The buildkernel target was created to support a source upgrade path and cross-building. It's been there since 4.0-RELEASE. The use of buildkernel has been advocated as the supported way of building a kernels, because it handles the difficult upgrade cases (such as the binutils upgrade) and thus works best for the uninitiated. The buildkernel target was, however, not designed for use as the preferred way to build any and all kernels, and it's this discrepancy that's making people unhappy in all sorts of ways and is the result of all kinds of misperceptions and bogus conclusions. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
Hello, On Sun, Jan 21, 2001 at 11:35:49PM -0800, John Baldwin wrote: I just do 'make includes' w/o the rm of /usr/include when I do this.. I normally do this, FWIW: 1) make buildworld 2) make installworld 3) config FOO 4) compile kernel FOO 5) install kernel FOO 6) update /etc 7) reboot OK, then I am not the only one left still sticking to the ole' style... which has always worked for me BTW... although this is also due to the fact that I read mailing lists, docs, and lately even cvs-all. Which is not true for many -stable users out there... 2) It hides the output from config(8). config(8) prints out all sorts of useful warnings when options are deprecated, etc., but buildkernel hides these from the user. The problem is that config(8) is by design an interactive tool, which buildkernel fails to take into account. The hack now is to have config(8) treat warnings as errors instead. :-/ I can second this. Way back when I upgraded from 3.x to 4.x I had to use this method and boy, was I lucky to stare at the screen all while it was running... this way I cought the errors from config(8) that were quickly scrolling by, and buildkernel continued despite of the errors! I broke my personal record for hitting Ctrl-C and so ended this crazy ride, after which config file was fixed and a succesful buildkernel followed. (Yes, I know... using custom kernel config files was not supported during the upgrade... but hey, I knew what I was doing... I even managed to preserve my old config file from 3.3 days by always converting it to new syntax requirements instead of starting over:-) So buildkernel should most deifintely be fixed. But relax, guys. The FreeBSD source upgrade system is still the most robust of any OS I saw out there, including all the other BSDs. Eg you cannot normally upgrade between releases because they are not prepared for those extra steps our buildworld does wrt the toolchain. (You have to rebuild gcc by hand etc.) Keep up the good work! -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
"Donald J . Maddox" wrote: Ok, fair enough. I have to confess that my usual procedure remains, as it has been for a long time, like this: 1) rm -r /usr/include; cd /usr/src; make includes This may be controversial, but it has always worked for me, and although it's not supposed to (in my understanding), the build (I think both world and kernel) does use installed headers. If you don't think so, mv /usr/include and then try to build either. 2) cd usr.sbin/config; make obj make depend make make install 3) config and build kernel 4) make buildworld 5) install kernel 6) make installworld 7) update /etc if necessary 8) reboot Here lately, I have been trying to break this cycle and use the 1) make buildworld 2) make buildkernel 3) make installkernel 4) make installworld Here is where you are going wrong.. You reboot before doing an installworld because you can boot kernel.old real easy, but you cannot undo an installworld. 5) reboot cycle instead, since I have been assured that this is the canonical way of doing things now. It appears that these pronouncements were premature at best. The optimal way always has been and still is: update config if required build kernel install, reboot. check out your kernel. Make sure it is basically functional. If so, then: make buildworld # a stress test for the kernel you just built. If and only if the buildworld lives, do an installworld. *never never never* install a world before the kernel, you cannot back out of it if the kernel is unstable. This is especially important in -current with the SMPng work going on. If your new kernel cannot build a world, then you *dont want to run it* and go back to kernel.old. There is no installworld.old to roll back to. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
Warner Losh wrote: In message [EMAIL PROTECTED] John Baldwin writes: : 2) It hides the output from config(8). config(8) prints out all sorts of : useful warnings when options are deprecated, etc., but buildkernel hides th ese : from the user. The problem is that config(8) is by design an interactive t ool, : which buildkernel fails to take into account. The hack now is to have : config(8) treat warnings as errors instead. :-/ config is not an interactive tool, any more than the compiler is an interactive tool. Config is *loaded* with places where it does not return an error code if something is wrong. This is a recipe for disaster by automating it so that people can do a 'make buildkernel' and switch to a different vty/window and never see that there were 3 parse errors in their kernel config file. That is the fundamental problem. I've started converting the notices in config(8) to fatal errors that I hope buildkernel will pick up, but it is IMHO still wrong, especially for -current that is changing on a daily basis. -stable is a different story, but this is outright deadly for -current. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
On Sun, 21 Jan 2001, John Baldwin wrote: On 22-Jan-01 Donald J . Maddox wrote: Ok, fair enough. I have to confess that my usual procedure remains, as it has been for a long time, like this: 1) rm -r /usr/include; cd /usr/src; make includes I just do 'make includes' w/o the rm of /usr/include when I do this.. I never do this. `includes' is a private target in Makefile.inc1. Running it at any time except as part of buildworld or installworld may give an inconsistent set of includes. 1) make buildworld 2) make installworld 3) config FOO 4) compile kernel FOO 5) install kernel FOO 6) update /etc 7) reboot 1-5 are all in 2 scripts, and part of 6) is in a script. For building kernels, I normally skip steps 1-2 (update config if necessary) and 6 (even more rarely necessary), and I never use the kernel install rules since they blow away backups and set inconvenient schg flags. 2) It hides the output from config(8). config(8) prints out all sorts of useful warnings when options are deprecated, etc., but buildkernel hides these from the user. The problem is that config(8) is by design an interactive tool, which buildkernel fails to take into account. The hack now is to have config(8) treat warnings as errors instead. :-/ Doesn't this break things? The current warnings for LINT are: WARNING: Old ISA driver compatability shims present. WARNING: COMPAT_SVR4 is broken and usage is, until fixed, not recommended Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
On Sun, Jan 21, 2001 at 11:12:44PM -0800, John Baldwin wrote: Rarely if ever do you need the new tools. The only cases are for a binutils upgrade that is not backwards compatible (such as the 2.9 - 2.10 upgrade), or if you need a newer version of config, which can be handled by installing config and then building your kernel. The config(8) changes won't happen in stable, and I don't foresee anymore drastic buildkernel changes in the future. I agree that developers don't need to use buildkernel because we are mostly capable of doing the manual workarounds on the rare occasions when things need to be done differently. But if you cast your mind back to the many dozens of support messages on -stable and other lists after the binutils upgrade, you will note that users are incapable of following special-case directions even when their mailbox is full of messages repeating them, and they need to have a magic wand which does it for them. That's what buildkernel is supposed to be..whether or not it's broken or can be fixed is a separate question. I never use buildkernel either because I know enough to fix things when they break, but that's not true for Joe Random, and we shouldn't advocate against it to the general user base unless we have a better magic solution. Kris -- NOTE: To fetch an updated copy of my GPG key which has not expired, finger [EMAIL PROTECTED] PGP signature
Re: lastest kernel from cvs ( sh exists with signal 8 )
In message [EMAIL PROTECTED] Kris Kennaway writes: : I agree that developers don't need to use buildkernel because we are : mostly capable of doing the manual workarounds on the rare occasions : when things need to be done differently. But if you cast your mind : back to the many dozens of support messages on -stable and other lists : after the binutils upgrade, you will note that users are incapable of : following special-case directions even when their mailbox is full of : messages repeating them, and they need to have a magic wand which does : it for them. That's what buildkernel is supposed to be..whether or not : it's broken or can be fixed is a separate question. : : I never use buildkernel either because I know enough to fix things : when they break, but that's not true for Joe Random, and we shouldn't : advocate against it to the general user base unless we have a better : magic solution. Agreed. It *IS* the documented way of building kernels. It is in the handbook and we've been recommending it for over a year. If it is broken in some way, we should fix the way in which it is broken. Kris is right, most normal users can't follow directions more complex than make buildkernel. I've spent my time in the trenches, as have others which is why make buildkernel exists. Believe us when we tell you this. We had litterally a dozen questions each week about this before buildkernel. Now we have almost none (maybe 2-3 a month for people not using buildkernel, or whacked out cases where buildkernel was done without a buildworld immediately before it). If you don't like it, don't use it. If it is broken, fix it, or tell others how to fix it. Personally, I use it here from time to time to test things, but when I'm in a development cycle, I'm more likely to use the old way because I know enough to know what body part I'm about to shoot off... It is in the handbook, and has been for some time. I'm reviewing the recent KERNEL - KERNCONF changes to make sure that they make it into the handbook properly (I assume there will be a MFC in a few days, since putting KERNEL in /etc/make.conf is a setup for disaster right now). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
Warner Losh [EMAIL PROTECTED] types: It is in the handbook, and has been for some time. I'm reviewing the recent KERNEL - KERNCONF changes to make sure that they make it into the handbook properly (I assume there will be a MFC in a few days, since putting KERNEL in /etc/make.conf is a setup for disaster right now). Could you also make sure it makes it into /etc/defaults/make.conf (KERNEL isn't mentioned there at all) and make.conf(5)? Thanx, mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
In message [EMAIL PROTECTED] Mike Meyer writes: : Warner Losh [EMAIL PROTECTED] types: : It is in the handbook, and has been for some time. I'm reviewing the : recent KERNEL - KERNCONF changes to make sure that they make it into : the handbook properly (I assume there will be a MFC in a few days, : since putting KERNEL in /etc/make.conf is a setup for disaster right : now). : : Could you also make sure it makes it into /etc/defaults/make.conf : (KERNEL isn't mentioned there at all) and make.conf(5)? That's really Peter's job since he made the change without any lead time at all to resolve issues like this. I'll see what I can do to backstop things, but it really isn't my baby. When people change things that have impact in different parts of the whole tree, they should be the ones to make the changes to those different parts of the tree, or at least submit patches to the maintainers of those parts of the tree. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
On 22-Jan-01 Warner Losh wrote: In message [EMAIL PROTECTED] Mike Meyer writes: : Warner Losh [EMAIL PROTECTED] types: : It is in the handbook, and has been for some time. I'm reviewing the : recent KERNEL - KERNCONF changes to make sure that they make it into : the handbook properly (I assume there will be a MFC in a few days, : since putting KERNEL in /etc/make.conf is a setup for disaster right : now). : : Could you also make sure it makes it into /etc/defaults/make.conf : (KERNEL isn't mentioned there at all) and make.conf(5)? That's really Peter's job since he made the change without any lead time at all to resolve issues like this. I'll see what I can do to backstop things, but it really isn't my baby. When people change things that have impact in different parts of the whole tree, they should be the ones to make the changes to those different parts of the tree, or at least submit patches to the maintainers of those parts of the tree. Erm, if it wasn't documented in the first place, making a change doesn't put the burden of documenting the old behavior on the person making the change. Are there any kernel manpages for all of the oldcard and newcard API's floating around btw? (As an example.) I agree it should be documented, but just because Peter made the change doesn't mean that the onus that the people who originally did buildkernel didn't bother to document it in places like make.conf(5) should fall on Peter. Warner -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
John Baldwin [EMAIL PROTECTED] types: On 22-Jan-01 Warner Losh wrote: In message [EMAIL PROTECTED] Mike Meyer writes: : Warner Losh [EMAIL PROTECTED] types: : It is in the handbook, and has been for some time. I'm reviewing the : recent KERNEL - KERNCONF changes to make sure that they make it into : the handbook properly (I assume there will be a MFC in a few days, : since putting KERNEL in /etc/make.conf is a setup for disaster right : now). : : Could you also make sure it makes it into /etc/defaults/make.conf : (KERNEL isn't mentioned there at all) and make.conf(5)? That's really Peter's job since he made the change without any lead time at all to resolve issues like this. I'll see what I can do to backstop things, but it really isn't my baby. When people change things that have impact in different parts of the whole tree, they should be the ones to make the changes to those different parts of the tree, or at least submit patches to the maintainers of those parts of the tree. Erm, if it wasn't documented in the first place, making a change doesn't put the burden of documenting the old behavior on the person making the change. Are there any kernel manpages for all of the oldcard and newcard API's floating around btw? (As an example.) I agree it should be documented, but just because Peter made the change doesn't mean that the onus that the people who originally did buildkernel didn't bother to document it in places like make.conf(5) should fall on Peter. KERNEL is documented in make.conf(5), but not in /etc/defaults/make.conf. Since the only thing in the latter that's anything other than a comment is BDECFLAGS, I suggested nuking most of /etc/defaults/make.conf and putting in a pointer to make.conf(5). That way, this stuff only needs to be documented in one place. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
In message [EMAIL PROTECTED] John Baldwin writes: : : On 22-Jan-01 Warner Losh wrote: : In message [EMAIL PROTECTED] Mike Meyer writes: : : Warner Losh [EMAIL PROTECTED] types: : : It is in the handbook, and has been for some time. I'm reviewing the : : recent KERNEL - KERNCONF changes to make sure that they make it into : : the handbook properly (I assume there will be a MFC in a few days, : : since putting KERNEL in /etc/make.conf is a setup for disaster right : : now). : : : : Could you also make sure it makes it into /etc/defaults/make.conf : : (KERNEL isn't mentioned there at all) and make.conf(5)? : : That's really Peter's job since he made the change without any lead : time at all to resolve issues like this. I'll see what I can do to : backstop things, but it really isn't my baby. When people change : things that have impact in different parts of the whole tree, they : should be the ones to make the changes to those different parts of the : tree, or at least submit patches to the maintainers of those parts of : the tree. : : Erm, if it wasn't documented in the first place, making a change doesn't : put the burden of documenting the old behavior on the person making the change. It was in the handbook, explicitly documented. Nothing undocumented about it. If I were to change how ls worked in some way, I'd be exepcted to update the man page for ls. This is no different than that. This is the documented way to build kernels, see http://www.freebsd.org/handbook/kernelconfig-building.html for the current instructions. They have been in there since at least 1.29 (alex 15-Jul-00): prompt.root; userinputmake... 1.29 (alex 15-Jul-00): prompt.root; userinputmake... when alex added them. That's at least 6 months ago. They have been in UPDATING longer than that. : Are there any kernel manpages for all of the oldcard and newcard API's floating : around btw? (As an example.) Neither have ever been documented. Eventually newcard will be documented. However, that's fundamentally different. We have maybe 5 NEWCARD folks hacking drivers right now. We have easily 50,000 folks running current, following the previously published instructions which are now inaccurate. Fortunatley, the change is now in UPDATING. : I agree it should be documented, but just : because Peter made the change doesn't mean that the onus that the people who : originally did buildkernel didn't bother to document it in places like : make.conf(5) should fall on Peter. I disagree. Peter made a fairly major change that needs many documentation changes to document the change. Yes, it was a small change, but it is how we are telling people to build things in the handbook. Fortunately the doc changes are relatively easy to make. Warner P.S. The following should do the trick: Index: chapter.sgml === RCS file: /home/imp/FreeBSD/CVS/doc/en_US.ISO_8859-1/books/handbook/kernelconfig/chapter.sgml,v retrieving revision 1.36 diff -u -r1.36 chapter.sgml --- chapter.sgml2000/08/10 02:09:18 1.36 +++ chapter.sgml2001/01/22 23:20:48 @@ -167,8 +167,8 @@ following commands:/para screenprompt.root; userinputcd /usr/src/userinput -prompt.root; userinputmake buildkernel KERNEL=MYKERNEL/userinput -prompt.root; userinputmake installkernel KERNEL=MYKERNEL/userinput/screen +prompt.root; userinputmake buildkernel KERNCONF=MYKERNEL/userinput +prompt.root; userinputmake installkernel KERNCONF=MYKERNEL/userinput/screen paraIf you have emphasisnot/emphasis upgraded your source tree in any way (you have not run applicationCVSup/application, To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
In message [EMAIL PROTECTED] Mike Meyer writes:
: KERNEL is documented in make.conf(5), but not in
: /etc/defaults/make.conf. Since the only thing in the latter that's
: anything other than a comment is BDECFLAGS, I suggested nuking most of
: /etc/defaults/make.conf and putting in a pointer to make.conf(5). That
: way, this stuff only needs to be documented in one place.
So it is. Something like the following untested change should do the
trick.
Warner
Index: make.conf.5
===
RCS file: /home/imp/FreeBSD/CVS/src/share/man/man5/make.conf.5,v
retrieving revision 1.8
diff -u -r1.8 make.conf.5
--- make.conf.5 2001/01/18 09:42:50 1.8
+++ make.conf.5 2001/01/22 23:43:04
@@ -250,7 +250,7 @@
Optimization levels above
.Oo Fl O ( O2 , No ...\ ) Oc
are not supported.
-.It Va KERNEL
+.It Va KERNCONF
.Vt ( str )
Controls which kernel configurations will be
built by
@@ -259,7 +259,7 @@
.Dq Li "${MAKE} installkernel" .
For example,
.Bd -literal -offset indent
-KERNEL=MINE DEBUG GENERIC OTHERMACHINE
+KERNCONF=MINE DEBUG GENERIC OTHERMACHINE
.Ed
.Pp
will build the the kernels specified by the config files
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
On 22-Jan-01 Warner Losh wrote: In message [EMAIL PROTECTED] John Baldwin writes: : : Erm, if it wasn't documented in the first place, making a change doesn't : put the burden of documenting the old behavior on the person making the : change. It was in the handbook, explicitly documented. Nothing undocumented about it. If I were to change how ls worked in some way, I'd be exepcted to update the man page for ls. This is no different than that. This is the documented way to build kernels, see http://www.freebsd.org/handbook/kernelconfig-building.html for the current instructions. They have been in there since at least 1.29 (alex 15-Jul-00): prompt.root; userinputmake... 1.29 (alex 15-Jul-00): prompt.root; userinputmake... when alex added them. That's at least 6 months ago. They have been in UPDATING longer than that. Nm. I was referring to the original request: : : Could you also make sure it makes it into /etc/defaults/make.conf : : (KERNEL isn't mentioned there at all) and make.conf(5)? Which basically says: "this wasn't documented before, can you document it now?" But anyways, this isn't really worth the effort. My laptop still isn't booting, so I'll get back to that -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
In message [EMAIL PROTECTED] John Baldwin writes:
: Nm. I was referring to the original request:
:
: : : Could you also make sure it makes it into /etc/defaults/make.conf
: : : (KERNEL isn't mentioned there at all) and make.conf(5)?
:
: Which basically says: "this wasn't documented before, can you document it now?"
: But anyways, this isn't really worth the effort. My laptop still isn't
: booting, so I'll get back to that
Ah. That makes sense. Technically, it was documented, but that was a
very very recent change:
revision 1.7
date: 2001/01/17 11:51:43; author: ben; state: Exp; lines: +19 -1
document ${KERNEL}
so I agree with your sentiment as far as that goes.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
lastest kernel from cvs ( sh exists with signal 8 )
just tried to reboot with a latest build (from this afternoon), and upon
reboot, it gives:
pid 6 (sh), uid 0: exited with signal 8
when /etc/rc tries to run, and, of course, won't let me get to single user
mode for same reason ...
checked /usr/src/UPDATING, and nothing in there seems to apply ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
The Hermit Hacker wrote: just tried to reboot with a latest build (from this afternoon), and upon reboot, it gives: pid 6 (sh), uid 0: exited with signal 8 when /etc/rc tries to run, and, of course, won't let me get to single user mode for same reason ... checked /usr/src/UPDATING, and nothing in there seems to apply ... We were discussing this and a couple of other related strange things that turned up. I might have broken the npx code with my last config(8) change and the corresponding #ifdefs. I have not gone back over it all again but will shortly. Given that two people have this sort of problem now, things are pointing to the npx commits somehow. You did rebuild config, right? Can you please check the opt_npx.h file in your build directory and make sure it has "#define DEV_NPX 1" in it? Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
d'oh, did it backwards again ... buildkernel then buildworld ... let me go
back and rebuild kernel and see if that is all it was in my case ...
On Sun, 21 Jan 2001, Peter Wemm wrote:
The Hermit Hacker wrote:
just tried to reboot with a latest build (from this afternoon), and upon
reboot, it gives:
pid 6 (sh), uid 0: exited with signal 8
when /etc/rc tries to run, and, of course, won't let me get to single user
mode for same reason ...
checked /usr/src/UPDATING, and nothing in there seems to apply ...
We were discussing this and a couple of other related strange things
that turned up. I might have broken the npx code with my last config(8)
change and the corresponding #ifdefs. I have not gone back over it all
again but will shortly. Given that two people have this sort of problem
now, things are pointing to the npx commits somehow. You did rebuild config,
right?
Can you please check the opt_npx.h file in your build directory and make sure
it has "#define DEV_NPX 1" in it?
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
The Hermit Hacker wrote:
d'oh, did it backwards again ... buildkernel then buildworld ... let me go
back and rebuild kernel and see if that is all it was in my case ...
Argh! I wish people would stop using buildkernel! :-( It calls config(8)
in such a way that buries the warning messages where people dont see.
config(8) is meant to be used interactively :-(
On Sun, 21 Jan 2001, Peter Wemm wrote:
The Hermit Hacker wrote:
just tried to reboot with a latest build (from this afternoon), and upon
reboot, it gives:
pid 6 (sh), uid 0: exited with signal 8
when /etc/rc tries to run, and, of course, won't let me get to single use
r
mode for same reason ...
checked /usr/src/UPDATING, and nothing in there seems to apply ...
We were discussing this and a couple of other related strange things
that turned up. I might have broken the npx code with my last config(8)
change and the corresponding #ifdefs. I have not gone back over it all
again but will shortly. Given that two people have this sort of problem
now, things are pointing to the npx commits somehow. You did rebuild confi
g,
right?
Can you please check the opt_npx.h file in your build directory and make su
re
it has "#define DEV_NPX 1" in it?
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
Marc G. Fournier ICQ#7615664 IRC Nick: Scrapp
y
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.or
g
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
On Sun, Jan 21, 2001 at 10:49:30PM -0800, Peter Wemm wrote: Argh! I wish people would stop using buildkernel! :-( It calls config(8) in such a way that buries the warning messages where people dont see. config(8) is meant to be used interactively :-( Is there another target that will get a kernel built with new tools in /usr/obj rather than old, previously installed binaries? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
-On [20010122 07:55], Peter Wemm ([EMAIL PROTECTED]) wrote: The Hermit Hacker wrote: d'oh, did it backwards again ... buildkernel then buildworld ... let me go back and rebuild kernel and see if that is all it was in my case ... Argh! I wish people would stop using buildkernel! :-( It calls config(8) in such a way that buries the warning messages where people dont see. config(8) is meant to be used interactively :-( Yeah well, buildkernel was advocated as the next best thing to sliced bread. Myself, I'll stick to the ``old way''. Never failed me thus far. At least, nothing a good rm -rf compile/KERNEL cannot solve. -- Jeroen Ruigrok van der Werven VIA Net.Works The Netherlands BSD: Technical excellence at its best Network- and systemadministrator D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 Killing me is not enough to make me go away... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
On 22-Jan-01 Donald J . Maddox wrote: On Sun, Jan 21, 2001 at 10:49:30PM -0800, Peter Wemm wrote: Argh! I wish people would stop using buildkernel! :-( It calls config(8) in such a way that buries the warning messages where people dont see. config(8) is meant to be used interactively :-( Is there another target that will get a kernel built with new tools in /usr/obj rather than old, previously installed binaries? Rarely if ever do you need the new tools. The only cases are for a binutils upgrade that is not backwards compatible (such as the 2.9 - 2.10 upgrade), or if you need a newer version of config, which can be handled by installing config and then building your kernel. The config(8) changes won't happen in stable, and I don't foresee anymore drastic buildkernel changes in the future. FWIW, I _never_ use buildkernel to update my kernels on any of my boxes. I just do it the old fashioned way, and with the exception of the 2.9 - 2.10 binutils upgrade, it always works. buildkernel overloads the KERNEL variable and thus violates POLA, so it needs fixing regardless, but I don't see a reason to encourage its use unless it is actually needed. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
On Sun, 21 Jan 2001, Peter Wemm wrote:
The Hermit Hacker wrote:
d'oh, did it backwards again ... buildkernel then buildworld ... let me go
back and rebuild kernel and see if that is all it was in my case ...
Argh! I wish people would stop using buildkernel! :-( It calls config(8)
in such a way that buries the warning messages where people dont see.
config(8) is meant to be used interactively :-(
well, according to /usr/src/UPDATING, that is the documented way to do
things, or at least two out of 4 of them:
To build a kernel
-
If you are updating from a prior version of FreeBSD (even one just
a few days old), you should follow this procedure. With a
/usr/obj tree with a fresh buildworld,
make buildkernel KERNEL=YOUR_KERNEL_HERE
make installkernel KERNEL=YOUR_KERNEL_HERE
To just build a kernel when you know that it won't mess you up
--
cd src/sys/{i386,alpha}/conf
config KERNEL_NAME_HERE [1]
cd ../../compile/KERNEL_NAME_HERE
make depend
make
make install
[1] If in doubt, -r might help here.
If this fails, go to the "To build a kernel" section.
To rebuild everything and install it on the current system.
---
make world
Build a new kernel, see above.
To upgrade from 4.x-stable to current
-
make buildworld
make buildkernel KERNEL=YOUR_KERNEL_HERE
cp src/sys/${MACHINE_ARCH}/GENERIC.hints /boot/device.hints [2]
make installkernel KERNEL=YOUR_KERNEL_HERE
make installworld
[1]
reboot
If this is wrong, can we get that updated?
Even /usr/src/README references and steers ppl to buildkernel:
"The ``buildkernel'' and ``installkernel'' targets build and install the
kernel and the modules (see below)"
I have no probs with switching back to the more 'manual way' of cd'ng into
conf and using config, etc ... I just got the impression awhile back that
using buildkernel/installkernel was the recommended way of doing this, so
switched to it ...
On Sun, 21 Jan 2001, Peter Wemm wrote:
The Hermit Hacker wrote:
just tried to reboot with a latest build (from this afternoon), and upon
reboot, it gives:
pid 6 (sh), uid 0: exited with signal 8
when /etc/rc tries to run, and, of course, won't let me get to single use
r
mode for same reason ...
checked /usr/src/UPDATING, and nothing in there seems to apply ...
We were discussing this and a couple of other related strange things
that turned up. I might have broken the npx code with my last config(8)
change and the corresponding #ifdefs. I have not gone back over it all
again but will shortly. Given that two people have this sort of problem
now, things are pointing to the npx commits somehow. You did rebuild confi
g,
right?
Can you please check the opt_npx.h file in your build directory and make su
re
it has "#define DEV_NPX 1" in it?
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
Marc G. Fournier ICQ#7615664 IRC Nick: Scrapp
y
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.or
g
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
On 22-Jan-01 John Baldwin wrote: On 22-Jan-01 Donald J . Maddox wrote: On Sun, Jan 21, 2001 at 10:49:30PM -0800, Peter Wemm wrote: Argh! I wish people would stop using buildkernel! :-( It calls config(8) in such a way that buries the warning messages where people dont see. config(8) is meant to be used interactively :-( Is there another target that will get a kernel built with new tools in /usr/obj rather than old, previously installed binaries? Rarely if ever do you need the new tools. The only cases are for a binutils upgrade that is not backwards compatible (such as the 2.9 - 2.10 upgrade), or if you need a newer version of config, which can be handled by installing config and then building your kernel. The config(8) changes won't happen in stable, and I don't foresee anymore drastic buildkernel changes in the future. That last 'buildkernel' should be 'toolchain'. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
Ok, fair enough. I have to confess that my usual procedure remains, as it has been for a long time, like this: 1) rm -r /usr/include; cd /usr/src; make includes This may be controversial, but it has always worked for me, and although it's not supposed to (in my understanding), the build (I think both world and kernel) does use installed headers. If you don't think so, mv /usr/include and then try to build either. 2) cd usr.sbin/config; make obj make depend make make install 3) config and build kernel 4) make buildworld 5) install kernel 6) make installworld 7) update /etc if necessary 8) reboot Here lately, I have been trying to break this cycle and use the 1) make buildworld 2) make buildkernel 3) make installkernel 4) make installworld 5) reboot cycle instead, since I have been assured that this is the canonical way of doing things now. It appears that these pronouncements were premature at best. On Sun, Jan 21, 2001 at 11:12:44PM -0800, John Baldwin wrote: Rarely if ever do you need the new tools. The only cases are for a binutils upgrade that is not backwards compatible (such as the 2.9 - 2.10 upgrade), or if you need a newer version of config, which can be handled by installing config and then building your kernel. The config(8) changes won't happen in stable, and I don't foresee anymore drastic buildkernel changes in the future. FWIW, I _never_ use buildkernel to update my kernels on any of my boxes. I just do it the old fashioned way, and with the exception of the 2.9 - 2.10 binutils upgrade, it always works. buildkernel overloads the KERNEL variable and thus violates POLA, so it needs fixing regardless, but I don't see a reason to encourage its use unless it is actually needed. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
On 22-Jan-01 The Hermit Hacker wrote: On Sun, 21 Jan 2001, Peter Wemm wrote: The Hermit Hacker wrote: d'oh, did it backwards again ... buildkernel then buildworld ... let me go back and rebuild kernel and see if that is all it was in my case ... Argh! I wish people would stop using buildkernel! :-( It calls config(8) in such a way that buries the warning messages where people dont see. config(8) is meant to be used interactively :-( well, according to /usr/src/UPDATING, that is the documented way to do things, or at least two out of 4 of them: What happened is that binutils was upgraded from 2.9 to 2.10 in both -current and -stable, and the old and new binutils weren't compatible. So, you had to installworld before building your kernel (which is what I did, and always do in fact). However, this made some people uncomfortable, so a 'buildkernel' target was made to work around this one problem. Then, in order to really beat it into -stable users heads to use it for the one needed upgrade, it was declared the end-all be-all method of upgrading a kernel when updating world. Except that it really isn't. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
On 22-Jan-01 Donald J . Maddox wrote: Ok, fair enough. I have to confess that my usual procedure remains, as it has been for a long time, like this: 1) rm -r /usr/include; cd /usr/src; make includes I just do 'make includes' w/o the rm of /usr/include when I do this.. I normally do this, FWIW: 1) make buildworld 2) make installworld 3) config FOO 4) compile kernel FOO 5) install kernel FOO 6) update /etc 7) reboot 1-5 are all in 2 scripts, and part of 6) is in a script. Here lately, I have been trying to break this cycle and use the 1) make buildworld 2) make buildkernel 3) make installkernel 4) make installworld 5) reboot This should work, except that buildkernel has a few problems: 1) It (ab)uses the KERNEL make variable so that it now has 2 conflicting meanings. Simply using KERNCONF for the buildkernel case instead can fix this, however. 2) It hides the output from config(8). config(8) prints out all sorts of useful warnings when options are deprecated, etc., but buildkernel hides these from the user. The problem is that config(8) is by design an interactive tool, which buildkernel fails to take into account. The hack now is to have config(8) treat warnings as errors instead. :-/ -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
In message [EMAIL PROTECTED] "Donald J . Maddox" writes: : way of doing things now. It appears that these pronouncements were : premature at best. Actually no. It isn't premature. It is the canonical way. It is how we've been telling people to build it for at least the past year or so. Some people don't like it and this is really the first I've heard of it. The reliance on buildworld is, I'll agree, a bit much. But that's going away soon. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
On Sun, Jan 21, 2001 at 11:35:49PM -0800, John Baldwin wrote: On 22-Jan-01 Donald J . Maddox wrote: 1) rm -r /usr/include; cd /usr/src; make includes I just do 'make includes' w/o the rm of /usr/include when I do this.. I used to do 'make -DCLOBBER includes' to make sure no old stuff survived, but somebody decided that was just too convenient, I guess. No CLOBBER in the Makefiles anymore... SNIP This should work, except that buildkernel has a few problems: 1) It (ab)uses the KERNEL make variable so that it now has 2 conflicting meanings. Simply using KERNCONF for the buildkernel case instead can fix this, however. 2) It hides the output from config(8). config(8) prints out all sorts of useful warnings when options are deprecated, etc., but buildkernel hides these from the user. The problem is that config(8) is by design an interactive tool, which buildkernel fails to take into account. The hack now is to have config(8) treat warnings as errors instead. :-/ I think this is a good policy :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
In message [EMAIL PROTECTED] John Baldwin writes: : 2) It hides the output from config(8). config(8) prints out all sorts of : useful warnings when options are deprecated, etc., but buildkernel hides these : from the user. The problem is that config(8) is by design an interactive tool, : which buildkernel fails to take into account. The hack now is to have : config(8) treat warnings as errors instead. :-/ config is not an interactive tool, any more than the compiler is an interactive tool. buildkernel hiding it from the user is a bug in buildkernel. It should be fixed. You shouldn't throw the baby out with the bath water. buildkernel is a much simplified way of telling people how to build kernels. As someone in the front lines of that game, I can tell you that the support load from that has dropped off quite a bit since we started telling people to use it. If you want to advocate all the steps that make it safe by hand, feel free, but the average user had no need to know them, nor do them by hand. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
