Re: kldxref problem
"Crist J. Clark" wrote: > > The real problem here is that these targets are such monsters > > that they really can't be cross-targets. The doc stuff is > > particularly nasty, viben that there are maybe 19 sets of > > packages that have to be sucked down and installed to make > > it work, because they aren't part of the default system, and > > they aren't in the source repository. When the FTP.freebsd.org > > blew up a while back, the only place you could get the tools > > the the proper versions was a combination of a site in England, > > a sunsite site, and two personal directories that lived on a > > machine in Japan. > > Where'd this observation come from? buildkernel/installkernel don't > pull packages from anywhere. Building the doc tree has almost nothing > to do with building world or kernel from the source tree. "make release". -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kldxref problem
On Tue, Apr 02, 2002 at 10:52:07PM -0800, Terry Lambert wrote: > Quite the thread from hell... ;^)... This is nuthin'. But one reason it continues is... > Peter Wemm wrote: > > Using buildkernel/installkernel is your biggest mistake. It is no secret > > what I think of those two targets. > > I have to agree with this. They are attempts to idiot-proof > something that can't be idiot-proofed, because idiots are so > cunning. 8-). > > The real problem here is that these targets are such monsters > that they really can't be cross-targets. The doc stuff is > particularly nasty, viben that there are maybe 19 sets of > packages that have to be sucked down and installed to make > it work, because they aren't part of the default system, and > they aren't in the source repository. When the FTP.freebsd.org > blew up a while back, the only place you could get the tools > the the proper versions was a combination of a site in England, > a sunsite site, and two personal directories that lived on a > machine in Japan. Where'd this observation come from? buildkernel/installkernel don't pull packages from anywhere. Building the doc tree has almost nothing to do with building world or kernel from the source tree. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kldxref problem
Quite the thread from hell... ;^)... Peter Wemm wrote: > Using buildkernel/installkernel is your biggest mistake. It is no secret > what I think of those two targets. I have to agree with this. They are attempts to idiot-proof something that can't be idiot-proofed, because idiots are so cunning. 8-). The real problem here is that these targets are such monsters that they really can't be cross-targets. The doc stuff is particularly nasty, viben that there are maybe 19 sets of packages that have to be sucked down and installed to make it work, because they aren't part of the default system, and they aren't in the source repository. When the FTP.freebsd.org blew up a while back, the only place you could get the tools the the proper versions was a combination of a site in England, a sunsite site, and two personal directories that lived on a machine in Japan. > > Yes, it is a kludge. Comments? > > The patch is better than nothing, but do not include this part: [ ... leave the '-' ignore on the kldxref ... ] > It should not be a kill-the-build event if the optional tool fails. You could almost make this same argument about ldconfig, which _is_ necessary for a running system. Unfortunately, what was supposed to be a cache is now an authoritative location for putting the data, so the tolls build for the cross can fail because of library incompatability between versions, when doing a cross-version build. 8-(. I really think these "hints" things need to be considered _as_ hints, rather than as authoritative; see the recent long scree on the tags cache in CVS for another example of assumed authority resulting in wrong answers... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kldxref problem
"Crist J. Clark" wrote:
> On Tue, Apr 02, 2002 at 04:45:13PM -0800, Peter Wemm wrote:
> > "Crist J. Clark" wrote:
> > > On Mon, Apr 01, 2002 at 03:07:46PM -0800, Terry Lambert wrote:
> > > > "Crist J. Clark" wrote:
> > > > > This whole argument ignores what the real problem is. The really
> > > > > correct way to handle this is to use the kldxref(8) built in the
> > > > > 'buildworld' phase. (It's bad form to be using any executables from
> > > > > the base system if we have a full object tree.) Actually using the on
e
> > > > > in /usr/obj/usr/src/usr.sbin/kldxref seems pretty ugly. The better
> > > > > thing to do is to have a version in /usr/obj/usr/src//usr/sbin
> > > > > by making it a crosstool. The failure should not be ignored in this
> > > > > case.
> > > >
> > > > Uh, that doesn't work incredibly well when the machine you
> > > > are on is an x86, and the machine that the buildworld targets
> > > > is, say, the Alpha.
> > > >
> > > > This came up in the first place because it's a cross-envrionment
> > > > issue that needs resolving. The "workaround" exists because the
> > > > workaround cops out on the cross-environment part of the process
> > > > and spits out the warnming, instead.
> > >
> > > An 'installworld' doesn't even come close to working in a cross
> > > environment for a whole variety of reasons, so I don't see the
> > > relevance.
> >
> > It used to. If it no longer works, it should be fixed. I partially do thi
s
> > for cross-architecture builds quite often where the target system is NFS
> > mounted somewhere.
>
> If it ever worked, without actually digging into the history, I would
> guess that it was because it only used existing binaries in the host
> environment to run the install. However, now a (somewhat half-baked)
> effort is made to use newly built tools to do the install, rather than
> the ones already on the host.
It has worked several times, because I remember it turned up a gcc bug
in the cross compiled gcc binaries. Specifically, if you did a
'make buildworld TARGET_ARCH=alpha', the compiler would generate invalid
code unless you also used -O0. But it did work. I also recall somebody
fixed it again relatively recently.
> But that's somewhat of a digression. 'installkernel' will work in the
> cross-platform case. It doesn't try to use build tools, but the tools
> in the system.
Using buildkernel/installkernel is your biggest mistake. It is no secret
what I think of those two targets.
> > kldxref however, does not have any cross capability, and is just a hint
> > mechanism even then. It is not essential to run it.
>
> I don't think it is essential either, but it does break module
> auto-loading until someone does run it. And this whole thread started
> because people don't think the error message is asthetically pleasing.
>
> But to hopefully put an end to some of the idle chatter here, here are
> patches to build a working kldxref(8) on 4-STABLE and 5-CURRENT in the
> the cross-tool phase. The 'installkernel' of a 5-CURRENT build on
> 4-STABLE system should not error on kldxref(8).
>
> Yes, it is a kludge. Comments?
The patch is better than nothing, but do not include this part:
> Index: src/sys/modules/Makefile
> ===
> RCS file: /export/freebsd/ncvs/src/sys/modules/Makefile,v
> retrieving revision 1.236
> diff -u -r1.236 Makefile
> --- src/sys/modules/Makefile 21 Mar 2002 09:15:38 - 1.236
> +++ src/sys/modules/Makefile 3 Apr 2002 01:57:18 -
> @@ -184,7 +184,7 @@
> .if !defined(NO_XREF)
> .MAKEFLAGS:= ${.MAKEFLAGS} -DNO_XREF
> afterinstall:
> - -kldxref ${DESTDIR}${KMODDIR}
> + kldxref ${DESTDIR}${KMODDIR}
> .endif
It should not be a kill-the-build event if the optional tool fails.
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: kldxref problem
On Tue, Apr 02, 2002 at 04:45:13PM -0800, Peter Wemm wrote:
> "Crist J. Clark" wrote:
> > On Mon, Apr 01, 2002 at 03:07:46PM -0800, Terry Lambert wrote:
> > > "Crist J. Clark" wrote:
> > > > This whole argument ignores what the real problem is. The really
> > > > correct way to handle this is to use the kldxref(8) built in the
> > > > 'buildworld' phase. (It's bad form to be using any executables from
> > > > the base system if we have a full object tree.) Actually using the one
> > > > in /usr/obj/usr/src/usr.sbin/kldxref seems pretty ugly. The better
> > > > thing to do is to have a version in /usr/obj/usr/src//usr/sbin
> > > > by making it a crosstool. The failure should not be ignored in this
> > > > case.
> > >
> > > Uh, that doesn't work incredibly well when the machine you
> > > are on is an x86, and the machine that the buildworld targets
> > > is, say, the Alpha.
> > >
> > > This came up in the first place because it's a cross-envrionment
> > > issue that needs resolving. The "workaround" exists because the
> > > workaround cops out on the cross-environment part of the process
> > > and spits out the warnming, instead.
> >
> > An 'installworld' doesn't even come close to working in a cross
> > environment for a whole variety of reasons, so I don't see the
> > relevance.
>
> It used to. If it no longer works, it should be fixed. I partially do this
> for cross-architecture builds quite often where the target system is NFS
> mounted somewhere.
If it ever worked, without actually digging into the history, I would
guess that it was because it only used existing binaries in the host
environment to run the install. However, now a (somewhat half-baked)
effort is made to use newly built tools to do the install, rather than
the ones already on the host.
But that's somewhat of a digression. 'installkernel' will work in the
cross-platform case. It doesn't try to use build tools, but the tools
in the system.
> kldxref however, does not have any cross capability, and is just a hint
> mechanism even then. It is not essential to run it.
I don't think it is essential either, but it does break module
auto-loading until someone does run it. And this whole thread started
because people don't think the error message is asthetically pleasing.
But to hopefully put an end to some of the idle chatter here, here are
patches to build a working kldxref(8) on 4-STABLE and 5-CURRENT in the
the cross-tool phase. The 'installkernel' of a 5-CURRENT build on
4-STABLE system should not error on kldxref(8).
Yes, it is a kludge. Comments?
Index: src/Makefile.inc1
===
RCS file: /export/freebsd/ncvs/src/Makefile.inc1,v
retrieving revision 1.246
diff -u -r1.246 Makefile.inc1
--- src/Makefile.inc1 26 Mar 2002 16:05:09 - 1.246
+++ src/Makefile.inc1 3 Apr 2002 05:54:54 -
@@ -457,7 +457,9 @@
#
installkernel:
cd ${KRNLOBJDIR}/${INSTALLKERNEL}; \
- ${CROSSENV} ${MAKE} KERNEL=${INSTKERNNAME} install
+ ${CROSSENV} \
+ PATH=${PATH}:${STRICTTMPPATH} \
+ ${MAKE} KERNEL=${INSTKERNNAME} install
reinstallkernel:
cd ${KRNLOBJDIR}/${INSTALLKERNEL}; \
${CROSSENV} ${MAKE} KERNEL=${INSTKERNNAME} reinstall
@@ -619,7 +621,8 @@
cross-tools:
.for _tool in ${_btxld} ${_elf2exe} \
-gnu/usr.bin/binutils usr.bin/objformat gnu/usr.bin/cc ${_xlint}
+gnu/usr.bin/binutils usr.bin/objformat gnu/usr.bin/cc ${_xlint} \
+usr.sbin/kldxref
cd ${.CURDIR}/${_tool}; \
${MAKE} obj; \
${MAKE} depend; \
Index: src/sys/modules/Makefile
===
RCS file: /export/freebsd/ncvs/src/sys/modules/Makefile,v
retrieving revision 1.236
diff -u -r1.236 Makefile
--- src/sys/modules/Makefile21 Mar 2002 09:15:38 - 1.236
+++ src/sys/modules/Makefile3 Apr 2002 01:57:18 -
@@ -184,7 +184,7 @@
.if !defined(NO_XREF)
.MAKEFLAGS:= ${.MAKEFLAGS} -DNO_XREF
afterinstall:
- -kldxref ${DESTDIR}${KMODDIR}
+ kldxref ${DESTDIR}${KMODDIR}
.endif
.include
Index: src/usr.sbin/kldxref/Makefile
===
RCS file: /export/freebsd/ncvs/src/usr.sbin/kldxref/Makefile,v
retrieving revision 1.4
diff -u -r1.4 Makefile
--- src/usr.sbin/kldxref/Makefile 10 Dec 2001 21:13:35 - 1.4
+++ src/usr.sbin/kldxref/Makefile 3 Apr 2002 05:05:09 -
@@ -5,4 +5,11 @@
WARNS?=2
MAN= kldxref.8
+.if defined(BOOTSTRAPPING)
+CFLAGS+= -I${.CURDIR}/../../sys -I.
+machine:
+ ln -sf ${.CURDIR}/../../sys/${MACHINE_ARCH}/include machine
+beforedepend: machine
+.endif
+
.include
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscr
Re: kldxref problem
"Crist J. Clark" wrote: > On Mon, Apr 01, 2002 at 03:07:46PM -0800, Terry Lambert wrote: > > "Crist J. Clark" wrote: > > > This whole argument ignores what the real problem is. The really > > > correct way to handle this is to use the kldxref(8) built in the > > > 'buildworld' phase. (It's bad form to be using any executables from > > > the base system if we have a full object tree.) Actually using the one > > > in /usr/obj/usr/src/usr.sbin/kldxref seems pretty ugly. The better > > > thing to do is to have a version in /usr/obj/usr/src//usr/sbin > > > by making it a crosstool. The failure should not be ignored in this > > > case. > > > > Uh, that doesn't work incredibly well when the machine you > > are on is an x86, and the machine that the buildworld targets > > is, say, the Alpha. > > > > This came up in the first place because it's a cross-envrionment > > issue that needs resolving. The "workaround" exists because the > > workaround cops out on the cross-environment part of the process > > and spits out the warnming, instead. > > An 'installworld' doesn't even come close to working in a cross > environment for a whole variety of reasons, so I don't see the > relevance. It used to. If it no longer works, it should be fixed. I partially do this for cross-architecture builds quite often where the target system is NFS mounted somewhere. kldxref however, does not have any cross capability, and is just a hint mechanism even then. It is not essential to run it. > The situation this question comes up is typically 5-CURRENT builds on > 4-STABLE systems, not in cross-archetecture builds. That is a different set of problems. cross-version builds have always been very trouble-prone. same-version cross builds are far less of a problem. 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: kldxref problem
"Crist J. Clark" wrote: > > The problem is that the kldxref deserves to get its own tools > > build, so that there is a version that works against 5.x code > > that can be built on 4.x (or NetBSD or Linux or Solaris or > > whatever). > > It builds fine on 4.x as long as you use the correct headers. It > appears to run fine on 4.x too. It's just that you pretty much need to > add a new stage to the build process. A stage where one builds > cross-tools with the new header files. I think we would all be happy with this. I think it's a requirement for the 5.x rollout, if people are going to be using buildworld to move themselves forward from 4.x. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kldxref problem
On Mon, Apr 01, 2002 at 06:08:40PM -0800, Terry Lambert wrote: > "Crist J. Clark" wrote: > > > This came up in the first place because it's a cross-envrionment > > > issue that needs resolving. The "workaround" exists because the > > > workaround cops out on the cross-environment part of the process > > > and spits out the warnming, instead. > > > > An 'installworld' doesn't even come close to working in a cross > > environment for a whole variety of reasons, so I don't see the > > relevance. > > > > The situation this question comes up is typically 5-CURRENT builds on > > 4-STABLE systems, not in cross-archetecture builds. > > Since this is the recommended upgrade path for going from 4.x > to 5.x right now, it's an issue, if you can't cross-build 5.x > on 4.x. You can't do it with 4.x .h-files. You need to use 5-CURRENT headers. The cross-tools phase, stage 3, uses the host system's headers. > That other things are broken doesn't really excuse this being > broken. > > The problem is that the kldxref deserves to get its own tools > build, so that there is a version that works against 5.x code > that can be built on 4.x (or NetBSD or Linux or Solaris or > whatever). It builds fine on 4.x as long as you use the correct headers. It appears to run fine on 4.x too. It's just that you pretty much need to add a new stage to the build process. A stage where one builds cross-tools with the new header files. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kldxref problem
"Crist J. Clark" wrote: > > This came up in the first place because it's a cross-envrionment > > issue that needs resolving. The "workaround" exists because the > > workaround cops out on the cross-environment part of the process > > and spits out the warnming, instead. > > An 'installworld' doesn't even come close to working in a cross > environment for a whole variety of reasons, so I don't see the > relevance. > > The situation this question comes up is typically 5-CURRENT builds on > 4-STABLE systems, not in cross-archetecture builds. Since this is the recommended upgrade path for going from 4.x to 5.x right now, it's an issue, if you can't cross-build 5.x on 4.x. That other things are broken doesn't really excuse this being broken. The problem is that the kldxref deserves to get its own tools build, so that there is a version that works against 5.x code that can be built on 4.x (or NetBSD or Linux or Solaris or whatever). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kldxref problem
On Mon, Apr 01, 2002 at 03:07:46PM -0800, Terry Lambert wrote: > "Crist J. Clark" wrote: > > This whole argument ignores what the real problem is. The really > > correct way to handle this is to use the kldxref(8) built in the > > 'buildworld' phase. (It's bad form to be using any executables from > > the base system if we have a full object tree.) Actually using the one > > in /usr/obj/usr/src/usr.sbin/kldxref seems pretty ugly. The better > > thing to do is to have a version in /usr/obj/usr/src//usr/sbin > > by making it a crosstool. The failure should not be ignored in this > > case. > > Uh, that doesn't work incredibly well when the machine you > are on is an x86, and the machine that the buildworld targets > is, say, the Alpha. > > This came up in the first place because it's a cross-envrionment > issue that needs resolving. The "workaround" exists because the > workaround cops out on the cross-environment part of the process > and spits out the warnming, instead. An 'installworld' doesn't even come close to working in a cross environment for a whole variety of reasons, so I don't see the relevance. The situation this question comes up is typically 5-CURRENT builds on 4-STABLE systems, not in cross-archetecture builds. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kldxref problem
"Crist J. Clark" wrote: > This whole argument ignores what the real problem is. The really > correct way to handle this is to use the kldxref(8) built in the > 'buildworld' phase. (It's bad form to be using any executables from > the base system if we have a full object tree.) Actually using the one > in /usr/obj/usr/src/usr.sbin/kldxref seems pretty ugly. The better > thing to do is to have a version in /usr/obj/usr/src//usr/sbin > by making it a crosstool. The failure should not be ignored in this > case. Uh, that doesn't work incredibly well when the machine you are on is an x86, and the machine that the buildworld targets is, say, the Alpha. This came up in the first place because it's a cross-envrionment issue that needs resolving. The "workaround" exists because the workaround cops out on the cross-environment part of the process and spits out the warnming, instead. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kldxref problem
On Mon, Apr 01, 2002 at 12:35:21AM -0800, David O'Brien wrote: > On Sun, Mar 31, 2002 at 12:38:24PM +0200, Emiel Kollof wrote: > > On Sun, 2002-03-31 at 09:51, Terry Lambert wrote: > > > > > > > > Perhaps if the kernel printf also "ignored" the request to print > > > the little S.O.B. out, there would be less confusion... > > > > I'm still sticking to the idea that one could test for kldxref, and if > > it isn't there, don't execute it. > > > > [ -x /usr/sbin/kldxref ] && /usr/sbin/kldxref > > > > like so, which is perfectly sane bourne shell syntax, which is also used > > by BSD make. > > Not really. Use: > > : > rule1 > rule2 > .if exists(/usr/sbin/kldxref) > /usr/sbin/kldxref > .endif This whole argument ignores what the real problem is. The really correct way to handle this is to use the kldxref(8) built in the 'buildworld' phase. (It's bad form to be using any executables from the base system if we have a full object tree.) Actually using the one in /usr/obj/usr/src/usr.sbin/kldxref seems pretty ugly. The better thing to do is to have a version in /usr/obj/usr/src//usr/sbin by making it a crosstool. The failure should not be ignored in this case. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kldxref problem
On Sun, Mar 31, 2002 at 12:38:24PM +0200, Emiel Kollof wrote: > On Sun, 2002-03-31 at 09:51, Terry Lambert wrote: > > > > > Perhaps if the kernel printf also "ignored" the request to print > > the little S.O.B. out, there would be less confusion... > > I'm still sticking to the idea that one could test for kldxref, and if > it isn't there, don't execute it. > > [ -x /usr/sbin/kldxref ] && /usr/sbin/kldxref > > like so, which is perfectly sane bourne shell syntax, which is also used > by BSD make. Not really. Use: : rule1 rule2 .if exists(/usr/sbin/kldxref) /usr/sbin/kldxref .endif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kldxref problem
Emiel Kollof wrote: > On Sun, 2002-03-31 at 09:51, Terry Lambert wrote: > > Perhaps if the kernel printf also "ignored" the request to print > > the little S.O.B. out, there would be less confusion... > > I'm still sticking to the idea that one could test for kldxref, and if > it isn't there, don't execute it. > > [ -x /usr/sbin/kldxref ] && /usr/sbin/kldxref > > like so, which is perfectly sane bourne shell syntax, which is also used > by BSD make. Like someone else says, work around it or deal with the > users that don't get the (ignored) part. If failures are ignorable, then it shouldn't try, since attempts are ignorable (might as well "fail" up front by not even trying, and not generate the message, if failing's an OK thing to do). It seems to me that there are four potential cases: 1) It's not there, and it's not OK. 2) It's there, and that's fantastic. 3) It's not there, and it's not OK, but instead of stopping, the code is going to do some half job where you don't get everything, and then bitch about it in such a way that it will be hard to find the source of some failure later, if someone really cared about the failure enough that complaining about it is important in the first place. 4) It's not there, and it's OK, but the code is going to bitch about it not being there anyway because it likes to add to the amount of entropy in the universe, and this is an easy way to do it that's unlikely to get fixed. It seems to me that #3 and #4 are bad, and should be removed from the realm of allowable output. I think the "test to see if it's available" hack you suggested is #3, without the code bitching about it, which is even worse than #3 as it is. 8-(. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kldxref problem
On Sun, 2002-03-31 at 09:51, Terry Lambert wrote: > > Perhaps if the kernel printf also "ignored" the request to print > the little S.O.B. out, there would be less confusion... I'm still sticking to the idea that one could test for kldxref, and if it isn't there, don't execute it. [ -x /usr/sbin/kldxref ] && /usr/sbin/kldxref like so, which is perfectly sane bourne shell syntax, which is also used by BSD make. Like someone else says, work around it or deal with the users that don't get the (ignored) part. Just my .02 Euro's Cheers, Emiel signature.asc Description: This is a digitally signed message part
Re: kldxref problem
Doug White wrote: > On Sat, 30 Mar 2002, A.Z. wrote: > > ***Error code 1(ignored) > Did you miss this part? > > Man, this throws everyone off. > > The error was IGNORED. THERE IS NO PROBLEM. Perhaps if the kernel printf also "ignored" the request to print the little S.O.B. out, there would be less confusion... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kldxref problem
On Sat, 30 Mar 2002, Doug White wrote: > On Sat, 30 Mar 2002, A.Z. wrote: > > I am upgrading 4.5 to -current. > > > > buildworld went fine, > > make buildkernel also fine, > > but make installkernel is giving me an error > > > > kldxref/boot/kernel > > kldxref: No Such Fule or Directory > > > > ***Error code 1(ignored) > Did you miss this part? > > Man, this throws everyone off. > > The error was IGNORED. THERE IS NO PROBLEM. I'm telling you all, its very easy to miss that "(ignored)" Either work around this or suffer through posts about it every single week... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kldxref problem
On Sat, 30 Mar 2002, A.Z. wrote: > I am upgrading 4.5 to -current. > > buildworld went fine, > make buildkernel also fine, > but make installkernel is giving me an error > > kldxref/boot/kernel > kldxref: No Such Fule or Directory > > ***Error code 1(ignored) Did you miss this part? Man, this throws everyone off. The error was IGNORED. THERE IS NO PROBLEM. Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
kldxref problem
I am upgrading 4.5 to -current. buildworld went fine, make buildkernel also fine, but make installkernel is giving me an error kldxref/boot/kernel kldxref: No Such Fule or Directory ***Error code 1(ignored) Any suggestions? I am using SMP system. Thanks, Andrei. P.S. please CC me as I am not on the list. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
