Re: CURRENT >r349150: boot failure in rc.conf.local
On Tue, Jun 18, 2019 at 11:49:58AM -0700, Conrad Meyer wrote: > Hi everyone, > > Please find a proposed fix in https://reviews.freebsd.org/D20686 . > > I didn't notice this thread because I'm already subscribed to current > and CC's don't display any differently in my mail reader. (I don't > read every thread on current.) > I confirmed the fix has been committed and now works again, thanks! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Compiling issues
Hello good evening can someone help me out with this issue [ 7%] Building CXX object src/CMakeFiles/services.dir/access.o In file included from /home/Dark/Downloads/anope-2.0.6/src/access.cpp:12: In file included from /home/Dark/Downloads/anope-2.0.6/include/service.h:15: In file included from /home/Dark/Downloads/anope-2.0.6/include/services.h:22: In file included from /usr/include/c++/v1/stdexcept:46: In file included from /usr/include/c++/v1/exception:81: In file included from /usr/include/c++/v1/cstddef:38: /home/Dark/Downloads/anope-2.0.6/include/version:1:1: error: expected unqualified-id ELF ... ^ /home/Dark/Downloads/anope-2.0.6/include/version:2:208: error: source file is not valid UTF-8 ...Y... ^ /home/Dark/Downloads/anope-2.0.6/include/version:2:216: error: source file is not valid UTF-8 ...Y... ^ /home/Dark/Downloads/anope-2.0.6/include/version:2:241: error: source file is not valid UTF-8 ... ... ^ /home/Dark/Downloads/anope-2.0.6/include/version:2:249: error: source file is not valid UTF-8 ... ... ^ /home/Dark/Downloads/anope-2.0.6/include/version:2:257: error: source file is not valid UTF-8 ... ... ^ /home/Dark/Downloads/anope-2.0.6/include/version:2:264: error: source file is not valid UTF-8 .. ^ /home/Dark/Downloads/anope-2.0.6/include/version:2:272: error: source file is not valid UTF-8 ... ... ^ /home/Dark/Downloads/anope-2.0.6/include/version:2:297: error: source file is not valid UTF-8 ...0 ... ^ /home/Dark/Downloads/anope-2.0.6/include/version:2:305: error: source file is not valid UTF-8 ... 0 ... ^ /home/Dark/Downloads/anope-2.0.6/include/version:2:313: error: source file is not valid UTF-8 ...0 ... ^ /home/Dark/Downloads/anope-2.0.6/include/version:2:320: error: source file is not valid UTF-8 .. ^ /home/Dark/Downloads/anope-2.0.6/include/version:2:328: error: source file is not valid UTF-8 .. ^ /home/Dark/Downloads/anope-2.0.6/include/version:2:345: error: source file is not valid UTF-8 ...td... ^ /home/Dark/Downloads/anope-2.0.6/include/version:2:353: error: source file is not valid UTF-8 ... ... ^ /home/Dark/Downloads/anope-2.0.6/include/version:2:361: error: source file is not valid UTF-8 ... ... ^ /home/Dark/Downloads/anope-2.0.6/include/version:2:369: error: source file is not valid UTF-8 ... ... ^ /home/Dark/Downloads/anope-2.0.6/include/version:2:376: error: source file is not valid UTF-8 .. ^ /home/Dark/Downloads/anope-2.0.6/include/version:2:401: error: source file is not valid UTF-8 ...td<... ^ fatal error: too many errors emitted, stopping now [-ferror-limit=] 20 errors generated. *** Error code 1 Stop. make[2]: stopped in /usr/home/Dark/Downloads/anope-2.0.6 *** Error code 1 Stop. make[1]: stopped in /usr/home/Dark/Downloads/anope-2.0.6 *** Error code 1 Stop. make: stopped in /usr/home/Dark/Downloads/anope-2.0.6 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: error: yacc.h: No such file or directory [patch/workaround]
On 6/18/2019 10:44 AM, Bryan Drewery wrote: > On 6/18/2019 10:02 AM, Ian Lepore wrote: >> On Tue, 2019-06-18 at 09:51 -0700, Bryan Drewery wrote: >>> On 6/18/2019 3:56 AM, Kubilay Kocak wrote: Have seen another report on Twitter yesterday. Didn't see a full build log, but theirs was had apparently without -j, apparently on June 14 sources: Error: /usr/src/usr.bin/mkesdb/lex.1:46:10: fatal error: 'yacc.h' file not found Fix committed in r349179 (different than my earlier patch). Sorry about that. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: CURRENT >r349150: boot failure in rc.conf.local
Hi everyone, Please find a proposed fix in https://reviews.freebsd.org/D20686 . I didn't notice this thread because I'm already subscribed to current and CC's don't display any differently in my mail reader. (I don't read every thread on current.) Take care, Conrad On Tue, Jun 18, 2019 at 11:03 AM Cy Schubert wrote: > > Looping in the committer of r349154. > On June 18, 2019 8:39:34 AM PDT, Takanori Watanabe > wrote: > >On Tue, Jun 18, 2019 at 09:03:17AM -0400, Jung-uk Kim wrote: > ... > >> I had the same problem and reverting r349154 fixed the problem for > >me. > ... > >In my machine, some executable, such as chromium, perl will hang like > >you. > >It is also fixed by reverting r349154. Thanks. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT >r349150: boot failure in rc.conf.local
Looping in the committer of r349154. On June 18, 2019 8:39:34 AM PDT, Takanori Watanabe wrote: >On Tue, Jun 18, 2019 at 09:03:17AM -0400, Jung-uk Kim wrote: >> On 19. 6. 18., O. Hartmann wrote: >> > On all CURRENT boxes running CURRENT > r349150 we face the very >same boot >> > failure, if /etc/rc.conf.local is present (i.e. on CURRENT, >13.0-CURRENT #7 >> > r349169: Tue Jun 18 10:34:13 CEST 2019 amd64): >> > >> > The box boots and thentries to start services denominated >> > in /etc/rc.conf.local, like net/openldap-server (slapd). The box is >then stuck >> > at "startingt slapd", hitting Ctrl-T shows state "running", but >Ctrl-C does not >> > show any effect, except Ctrl-Alt-Del (if enabled) is effectively >rebooting the >> > box. First I thought it might by a out-of-sync binary, but this >phenomenon >> > spreads even over recently via make installed systems. Disabling >OpenLDAP's >> > slapd at boot time gives my like rolling a dice the next service, >named >> > (dns/bind914) or net/samba48 (samba_server) - you name it. The box >gets stuck >> > forever and doesn't even start sshd to provide access. All boxes >have IPv6 >> > enabled as well as IPFW. >> > >> > Another server running CURRENT (r349169, also amd64) without >> > utilizing /etc/rc.conf.local but with a bunch of jails is booting >as usual! >> > >> > What happened here? Does anyone do have a hint or might know the >cause? >> >> I had the same problem and reverting r349154 fixed the problem for >me. >> >> https://svnweb.freebsd.org/changeset/base/349154 >> >> FYI... >> >> Jung-uk Kim > >In my machine, some executable, such as chromium, perl will hang like >you. >It is also fixed by reverting r349154. Thanks. >___ >freebsd-current@freebsd.org mailing list >https://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to >"freebsd-current-unsubscr...@freebsd.org" -- Pardon the typos and autocorrect, small keyboard in use. Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: error: yacc.h: No such file or directory [patch/workaround]
On 6/18/2019 10:02 AM, Ian Lepore wrote:
> On Tue, 2019-06-18 at 09:51 -0700, Bryan Drewery wrote:
>> On 6/18/2019 3:56 AM, Kubilay Kocak wrote:
>>> Have seen another report on Twitter yesterday. Didn't see a full
>>> build
>>> log, but theirs was had apparently without -j, apparently on June
>>> 14
>>> sources:
>>>
>>> Error:
>>> /usr/src/usr.bin/mkesdb/lex.1:46:10: fatal error: 'yacc.h' file not
>>> found
>>>
>>> Have not heard back from them whether it continued after trying -j2
>>> but
>>> I did ask them to hit up freebsd-current if it continued to be an
>>> issue
>>
>> Even -j1 should avoid it. For some reason I am only seeing it without
>> any -j flag at all.
>>
>> I should have a fix in soon.
This patch fixes it and allows bin/sh to still build right. I need to
test further before committing though.
http://people.freebsd.org/~bdrewery/patches/dep-headers.diff
That or -j1 is a simple workaround.
>>
>
> There's a subtle difference between -j1 and no -j at all, having to do
> with running in "compatibility mode". I forget the details, but I
> remember being burned by the difference once. :)
>
> -- Ian
>
Yeah fundamentally this makes sense. There's no dependency defined to
get yacc.h built before lex.o. So the oddness is actually that -j/job
mode gets the order right by accident and that it has a different order
than -B. Shrug.
In bsd.prog.mk historically was this:
.if defined(PROG) && !exists(${.OBJDIR}/${DEPENDFILE})
${OBJS}: ${SRCS:M*.h}
.endif
I changed this mechanism to use OBJS_DEPEND_GUESS which allows a list of
dependencies to apply by checking for the existence of the .depend.foo
file in 1 place. I ended up removing the addition of the headers in
r349061 though while targeting bin/sh build-tools cyclic dependency problem.
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
Re: error: yacc.h: No such file or directory
On Tue, 2019-06-18 at 09:51 -0700, Bryan Drewery wrote: > On 6/18/2019 3:56 AM, Kubilay Kocak wrote: > > Have seen another report on Twitter yesterday. Didn't see a full > > build > > log, but theirs was had apparently without -j, apparently on June > > 14 > > sources: > > > > Error: > > /usr/src/usr.bin/mkesdb/lex.1:46:10: fatal error: 'yacc.h' file not > > found > > > > Have not heard back from them whether it continued after trying -j2 > > but > > I did ask them to hit up freebsd-current if it continued to be an > > issue > > Even -j1 should avoid it. For some reason I am only seeing it without > any -j flag at all. > > I should have a fix in soon. > There's a subtle difference between -j1 and no -j at all, having to do with running in "compatibility mode". I forget the details, but I remember being burned by the difference once. :) -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: error: yacc.h: No such file or directory
On 6/18/2019 3:56 AM, Kubilay Kocak wrote: > Have seen another report on Twitter yesterday. Didn't see a full build > log, but theirs was had apparently without -j, apparently on June 14 > sources: > > Error: > /usr/src/usr.bin/mkesdb/lex.1:46:10: fatal error: 'yacc.h' file not found > > Have not heard back from them whether it continued after trying -j2 but > I did ask them to hit up freebsd-current if it continued to be an issue Even -j1 should avoid it. For some reason I am only seeing it without any -j flag at all. I should have a fix in soon. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: CURRENT >r349150: boot failure in rc.conf.local
On Tue, Jun 18, 2019 at 09:03:17AM -0400, Jung-uk Kim wrote: > On 19. 6. 18., O. Hartmann wrote: > > On all CURRENT boxes running CURRENT > r349150 we face the very same boot > > failure, if /etc/rc.conf.local is present (i.e. on CURRENT, 13.0-CURRENT #7 > > r349169: Tue Jun 18 10:34:13 CEST 2019 amd64): > > > > The box boots and thentries to start services denominated > > in /etc/rc.conf.local, like net/openldap-server (slapd). The box is then > > stuck > > at "startingt slapd", hitting Ctrl-T shows state "running", but Ctrl-C does > > not > > show any effect, except Ctrl-Alt-Del (if enabled) is effectively rebooting > > the > > box. First I thought it might by a out-of-sync binary, but this phenomenon > > spreads even over recently via make installed systems. Disabling OpenLDAP's > > slapd at boot time gives my like rolling a dice the next service, named > > (dns/bind914) or net/samba48 (samba_server) - you name it. The box gets > > stuck > > forever and doesn't even start sshd to provide access. All boxes have IPv6 > > enabled as well as IPFW. > > > > Another server running CURRENT (r349169, also amd64) without > > utilizing /etc/rc.conf.local but with a bunch of jails is booting as usual! > > > > What happened here? Does anyone do have a hint or might know the cause? > > I had the same problem and reverting r349154 fixed the problem for me. > > https://svnweb.freebsd.org/changeset/base/349154 > > FYI... > > Jung-uk Kim In my machine, some executable, such as chromium, perl will hang like you. It is also fixed by reverting r349154. Thanks. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: error: yacc.h: No such file or directory
Yes this is likely due to my changes as I removed headers from one of the forced dependency lists. I'll look at it in a bit. (I ran several clean and incremental builds without fault but yeah it could be a race.) Note my breakage likely only affected world and not kernel so any opt_*.h isn't new. Bryan On 6/18/2019 6:53 AM, Ian Lepore wrote: > On Tue, 2019-06-18 at 06:45 -0700, Cy Schubert wrote: >> On June 18, 2019 6:24:36 AM PDT, Michael Tuexen >> wrote: On 18. Jun 2019, at 12:56, Kubilay Kocak wrote: On 18/06/2019 5:42 pm, Michael Tuexen wrote: > Dear all, > I'm trying to run > sudo make buildworld > in a directory with r349168. > The result is: > cc -O2 -pipe -I/usr/home/tuexen/head/usr.bin/mkesdb_static >>> >>> -I/usr/home/tuexen/head/usr.bin/mkesdb_static/../mkesdb >>> -I/usr/home/tuexen/head/usr.bin/mkesdb_static/../../lib/libc/iconv >>> -g >>> -MD -MF.depend.lex.o -MTlex.o -std=gnu99 >>> -I/usr/obj/usr/home/tuexen/head/powerpc.powerpc64/tmp/legacy/usr/in >>> clude >>> -c lex.c -o lex.o > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:46:18: error: > yacc.h: No >>> >>> such file or directory > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l: In function > 'yylex': > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: 'R_LN' >>> >>> undeclared (first use in this function) > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: (Each >>> >>> undeclared identifier is reported only once > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: for each >>> >>> function it appears in.) > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:72: error: 'yylval' >>> >>> undeclared (first use in this function) > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:73: error: 'L_IMM' >>> >>> undeclared (first use in this function) > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:76: error: 'R_NAME' >>> >>> undeclared (first use in this function) > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:77: error: > 'R_ENCODING' >>> >>> undeclared (first use in this function) > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:78: error: > 'R_VARIABLE' >>> >>> undeclared (first use in this function) > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:79: error: > 'R_DEFCSID' >>> >>> undeclared (first use in this function) > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:80: error: > 'R_INVALID' >>> >>> undeclared (first use in this function) > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:88: error: > 'L_STRING' >>> >>> undeclared (first use in this function) > *** Error code 1 > Stop. > make[3]: stopped in /usr/home/tuexen/head/usr.bin/mkesdb_static > *** Error code 1 > Stop. > make[2]: stopped in /usr/home/tuexen/head > *** Error code 1 > Stop. > make[1]: stopped in /usr/home/tuexen/head > *** Error code 1 > Stop. > make: stopped in /usr/home/tuexen/head > This is on a 64 bit PPC system. Doing sudo rm -rf /usr/obj does > not >>> >>> resolve the issue. > Any idea what is going wrong? > Best regards > Michael Have seen another report on Twitter yesterday. Didn't see a full >>> >>> build log, but theirs was had apparently without -j, apparently on >>> June >>> 14 sources: Error: /usr/src/usr.bin/mkesdb/lex.1:46:10: fatal error: 'yacc.h' file not >>> >>> found Have not heard back from them whether it continued after trying -j2 >>> >>> but I did ask them to hit up freebsd-current if it continued to be >>> an >>> issue >>> OK, I started the build again with -j 2 and it seems that the >>> problem >>> does not occur. >>> >>> Since I have been using make buildworld without -j n in the past on >>> that machine, the >>> problem seems to be introduced recently. Any idea what is the cause >>> of >>> the problem? >>> >>> Best regards >>> Michael >>> >>> ___ >>> freebsd-current@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to >>> "freebsd-current-unsubscr...@freebsd.org" >> >> This is a generated file. It would appear the make target to build >> yacc.h hadn't run yet by the time the target that consumed the file >> ran. >> >> I had a similar problem on Sunday. It wasn't yacc.h but some other >> file, I cannot remember which. It occurred during one of four >> buildworlds. Simply restarting the failed buildworld was enough to >> resolve it. >> >> My hypothesis is a buildworld race. I wonder if some of the recent >> (over the last week or two) makefile changes exacerbated this issue. >> >> > > Last Saturday, Bryan (cc'd) made a series of commits (r349061-69) that > were all somehow related to dependency processing in the build. I > don't know the details, just remember seeing some commits about that. > > -- Ian > -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: error: yacc.h: No such file or directory
On Tue, 2019-06-18 at 07:01 -0700, Enji Cooper wrote: > > On Jun 18, 2019, at 06:59, Enji Cooper > > wrote: > > > > > > > On Jun 18, 2019, at 06:53, Ian Lepore wrote: > > > > ... > > > > > Last Saturday, Bryan (cc'd) made a series of commits (r349061-69) > > > that > > > were all somehow related to dependency processing in the > > > build. I > > > don't know the details, just remember seeing some commits about > > > that. > > > > I remember that as well. This might have changed the dependency > > order subtly, introducing a race. > > > > The headers might not be built in all cases in time now. > > > > Thanks, > > -Enji > > > > PS This is one of the reasons why I wasn’t quick to discount Peter > > Jeremy’s reported build issue. > > Correction: I meant Julian Stacey. Julian Stacey has 3 problems: 1. Missing opt_cam.h 2. Missing yacc.h 3. A years-long inability to report a problem without hurling personal insults at the project and everyone associated with it. Because of #3, I don't much care about 1 and 2. -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: error: yacc.h: No such file or directory
In message , Ian Le pore writes: > On Tue, 2019-06-18 at 07:01 -0700, Enji Cooper wrote: > > > On Jun 18, 2019, at 06:59, Enji Cooper > > > wrote: > > > > > > > > > > On Jun 18, 2019, at 06:53, Ian Lepore wrote: > > > > > > ... > > > > > > > Last Saturday, Bryan (cc'd) made a series of commits (r349061-69) > > > > that > > > > were all somehow related to dependency processing in the > > > > build. I > > > > don't know the details, just remember seeing some commits about > > > > that. > > > > > > I remember that as well. This might have changed the dependency > > > order subtly, introducing a race. > > > > > > The headers might not be built in all cases in time now. > > > > > > Thanks, > > > -Enji > > > > > > PS This is one of the reasons why I wasnât quick to discount Peter > > > Jeremyâs reported build issue. > > > > Correction: I meant Julian Stacey. > > Julian Stacey has 3 problems: > > 1. Missing opt_cam.h > 2. Missing yacc.h > 3. A years-long inability to report a problem without hurling personal > insults at the project and everyone associated with it. > > Because of #3, I don't much care about 1 and 2. Bingo! My point exactly! -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: error: yacc.h: No such file or directory
In message <02f99ef6-3a8e-42a2-8b35-6524fd4e1...@gmail.com>, Enji Cooper writes : > > > > On Jun 18, 2019, at 06:59, Enji Cooper wrote: > > > > > >> On Jun 18, 2019, at 06:53, Ian Lepore wrote: > > > > ... > > > >> Last Saturday, Bryan (cc'd) made a series of commits (r349061-69) that > >> were all somehow related to dependency processing in the build. I > >> don't know the details, just remember seeing some commits about that. > > > > I remember that as well. This might have changed the dependency order subtl > y, introducing a race. > > > > The headers might not be built in all cases in time now. > > > > Thanks, > > -Enji > > > > PS This is one of the reasons why I wasnât quick to discount Peter Jeremy > âs reported build issue. This is why I raised the issue of build race in that thread. My experience was a different file but it smelled similar. What led me to believe it was a race was that one of four buildworlds failed for no logical reason. The other three built fine. And, the failed buildworld built fine after simply restarting it. I've experienced these oddities before Bryan's series of commits though I thought it was a strange coincidence one of four would fail a day after the makefile changes. Hence my choice of words: exacerbated. > > Correction: I meant Julian Stacey. My issue with Julian was his attack. You can't help people who are on the warpath. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: error: yacc.h: No such file or directory
In message , Enji Cooper writes : > > > > On Jun 18, 2019, at 06:53, Ian Lepore wrote: > > ... > > > Last Saturday, Bryan (cc'd) made a series of commits (r349061-69) that > > were all somehow related to dependency processing in the build. I > > don't know the details, just remember seeing some commits about that. > > I remember that as well. This might have changed the dependency order subtly, > introducing a race. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. > > The headers might not be built in all cases in time now. > > Thanks, > -Enji > > PS This is one of the reasons why I wasnât quick to discount Peter Jeremyâ > s reported build issue. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: error: yacc.h: No such file or directory
> On Jun 18, 2019, at 06:59, Enji Cooper wrote: > > >> On Jun 18, 2019, at 06:53, Ian Lepore wrote: > > ... > >> Last Saturday, Bryan (cc'd) made a series of commits (r349061-69) that >> were all somehow related to dependency processing in the build. I >> don't know the details, just remember seeing some commits about that. > > I remember that as well. This might have changed the dependency order subtly, > introducing a race. > > The headers might not be built in all cases in time now. > > Thanks, > -Enji > > PS This is one of the reasons why I wasn’t quick to discount Peter Jeremy’s > reported build issue. Correction: I meant Julian Stacey. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: error: yacc.h: No such file or directory
> On Jun 18, 2019, at 06:53, Ian Lepore wrote: ... > Last Saturday, Bryan (cc'd) made a series of commits (r349061-69) that > were all somehow related to dependency processing in the build. I > don't know the details, just remember seeing some commits about that. I remember that as well. This might have changed the dependency order subtly, introducing a race. The headers might not be built in all cases in time now. Thanks, -Enji PS This is one of the reasons why I wasn’t quick to discount Peter Jeremy’s reported build issue. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: error: yacc.h: No such file or directory
On Tue, 2019-06-18 at 06:45 -0700, Cy Schubert wrote: > On June 18, 2019 6:24:36 AM PDT, Michael Tuexen > wrote: > > > On 18. Jun 2019, at 12:56, Kubilay Kocak > > > wrote: > > > > > > On 18/06/2019 5:42 pm, Michael Tuexen wrote: > > > > Dear all, > > > > I'm trying to run > > > > sudo make buildworld > > > > in a directory with r349168. > > > > The result is: > > > > cc -O2 -pipe -I/usr/home/tuexen/head/usr.bin/mkesdb_static > > > > -I/usr/home/tuexen/head/usr.bin/mkesdb_static/../mkesdb > > -I/usr/home/tuexen/head/usr.bin/mkesdb_static/../../lib/libc/iconv > > -g > > -MD -MF.depend.lex.o -MTlex.o -std=gnu99 > > -I/usr/obj/usr/home/tuexen/head/powerpc.powerpc64/tmp/legacy/usr/in > > clude > > -c lex.c -o lex.o > > > > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:46:18: error: > > > > yacc.h: No > > > > such file or directory > > > > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l: In function > > > > 'yylex': > > > > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: 'R_LN' > > > > undeclared (first use in this function) > > > > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: (Each > > > > undeclared identifier is reported only once > > > > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: for each > > > > function it appears in.) > > > > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:72: error: 'yylval' > > > > undeclared (first use in this function) > > > > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:73: error: 'L_IMM' > > > > undeclared (first use in this function) > > > > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:76: error: 'R_NAME' > > > > undeclared (first use in this function) > > > > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:77: error: > > > > 'R_ENCODING' > > > > undeclared (first use in this function) > > > > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:78: error: > > > > 'R_VARIABLE' > > > > undeclared (first use in this function) > > > > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:79: error: > > > > 'R_DEFCSID' > > > > undeclared (first use in this function) > > > > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:80: error: > > > > 'R_INVALID' > > > > undeclared (first use in this function) > > > > /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:88: error: > > > > 'L_STRING' > > > > undeclared (first use in this function) > > > > *** Error code 1 > > > > Stop. > > > > make[3]: stopped in /usr/home/tuexen/head/usr.bin/mkesdb_static > > > > *** Error code 1 > > > > Stop. > > > > make[2]: stopped in /usr/home/tuexen/head > > > > *** Error code 1 > > > > Stop. > > > > make[1]: stopped in /usr/home/tuexen/head > > > > *** Error code 1 > > > > Stop. > > > > make: stopped in /usr/home/tuexen/head > > > > This is on a 64 bit PPC system. Doing sudo rm -rf /usr/obj does > > > > not > > > > resolve the issue. > > > > Any idea what is going wrong? > > > > Best regards > > > > Michael > > > > > > Have seen another report on Twitter yesterday. Didn't see a full > > > > build log, but theirs was had apparently without -j, apparently on > > June > > 14 sources: > > > > > > Error: > > > /usr/src/usr.bin/mkesdb/lex.1:46:10: fatal error: 'yacc.h' file > > > not > > > > found > > > > > > Have not heard back from them whether it continued after trying > > > -j2 > > > > but I did ask them to hit up freebsd-current if it continued to be > > an > > issue > > OK, I started the build again with -j 2 and it seems that the > > problem > > does not occur. > > > > Since I have been using make buildworld without -j n in the past on > > that machine, the > > problem seems to be introduced recently. Any idea what is the cause > > of > > the problem? > > > > Best regards > > Michael > > > > > > > ___ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to > > "freebsd-current-unsubscr...@freebsd.org" > > This is a generated file. It would appear the make target to build > yacc.h hadn't run yet by the time the target that consumed the file > ran. > > I had a similar problem on Sunday. It wasn't yacc.h but some other > file, I cannot remember which. It occurred during one of four > buildworlds. Simply restarting the failed buildworld was enough to > resolve it. > > My hypothesis is a buildworld race. I wonder if some of the recent > (over the last week or two) makefile changes exacerbated this issue. > > Last Saturday, Bryan (cc'd) made a series of commits (r349061-69) that were all somehow related to dependency processing in the build. I don't know the details, just remember seeing some commits about that. -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: error: yacc.h: No such file or directory
On June 18, 2019 6:24:36 AM PDT, Michael Tuexen wrote: >> On 18. Jun 2019, at 12:56, Kubilay Kocak wrote: >> >> On 18/06/2019 5:42 pm, Michael Tuexen wrote: >>> Dear all, >>> I'm trying to run >>> sudo make buildworld >>> in a directory with r349168. >>> The result is: >>> cc -O2 -pipe -I/usr/home/tuexen/head/usr.bin/mkesdb_static >-I/usr/home/tuexen/head/usr.bin/mkesdb_static/../mkesdb >-I/usr/home/tuexen/head/usr.bin/mkesdb_static/../../lib/libc/iconv -g >-MD -MF.depend.lex.o -MTlex.o -std=gnu99 >-I/usr/obj/usr/home/tuexen/head/powerpc.powerpc64/tmp/legacy/usr/include >-c lex.c -o lex.o >>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:46:18: error: yacc.h: No >such file or directory >>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l: In function 'yylex': >>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: 'R_LN' >undeclared (first use in this function) >>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: (Each >undeclared identifier is reported only once >>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: for each >function it appears in.) >>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:72: error: 'yylval' >undeclared (first use in this function) >>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:73: error: 'L_IMM' >undeclared (first use in this function) >>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:76: error: 'R_NAME' >undeclared (first use in this function) >>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:77: error: 'R_ENCODING' >undeclared (first use in this function) >>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:78: error: 'R_VARIABLE' >undeclared (first use in this function) >>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:79: error: 'R_DEFCSID' >undeclared (first use in this function) >>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:80: error: 'R_INVALID' >undeclared (first use in this function) >>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:88: error: 'L_STRING' >undeclared (first use in this function) >>> *** Error code 1 >>> Stop. >>> make[3]: stopped in /usr/home/tuexen/head/usr.bin/mkesdb_static >>> *** Error code 1 >>> Stop. >>> make[2]: stopped in /usr/home/tuexen/head >>> *** Error code 1 >>> Stop. >>> make[1]: stopped in /usr/home/tuexen/head >>> *** Error code 1 >>> Stop. >>> make: stopped in /usr/home/tuexen/head >>> This is on a 64 bit PPC system. Doing sudo rm -rf /usr/obj does not >resolve the issue. >>> Any idea what is going wrong? >>> Best regards >>> Michael >> >> Have seen another report on Twitter yesterday. Didn't see a full >build log, but theirs was had apparently without -j, apparently on June >14 sources: >> >> Error: >> /usr/src/usr.bin/mkesdb/lex.1:46:10: fatal error: 'yacc.h' file not >found >> >> Have not heard back from them whether it continued after trying -j2 >but I did ask them to hit up freebsd-current if it continued to be an >issue >OK, I started the build again with -j 2 and it seems that the problem >does not occur. > >Since I have been using make buildworld without -j n in the past on >that machine, the >problem seems to be introduced recently. Any idea what is the cause of >the problem? > >Best regards >Michael >> > >___ >freebsd-current@freebsd.org mailing list >https://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to >"freebsd-current-unsubscr...@freebsd.org" This is a generated file. It would appear the make target to build yacc.h hadn't run yet by the time the target that consumed the file ran. I had a similar problem on Sunday. It wasn't yacc.h but some other file, I cannot remember which. It occurred during one of four buildworlds. Simply restarting the failed buildworld was enough to resolve it. My hypothesis is a buildworld race. I wonder if some of the recent (over the last week or two) makefile changes exacerbated this issue. -- Pardon the typos and autocorrect, small keyboard in use. Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: error: yacc.h: No such file or directory
> On 18. Jun 2019, at 12:56, Kubilay Kocak wrote: > > On 18/06/2019 5:42 pm, Michael Tuexen wrote: >> Dear all, >> I'm trying to run >> sudo make buildworld >> in a directory with r349168. >> The result is: >> cc -O2 -pipe -I/usr/home/tuexen/head/usr.bin/mkesdb_static >> -I/usr/home/tuexen/head/usr.bin/mkesdb_static/../mkesdb >> -I/usr/home/tuexen/head/usr.bin/mkesdb_static/../../lib/libc/iconv -g -MD >> -MF.depend.lex.o -MTlex.o -std=gnu99 >> -I/usr/obj/usr/home/tuexen/head/powerpc.powerpc64/tmp/legacy/usr/include -c >> lex.c -o lex.o >> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:46:18: error: yacc.h: No such >> file or directory >> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l: In function 'yylex': >> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: 'R_LN' undeclared >> (first use in this function) >> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: (Each undeclared >> identifier is reported only once >> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: for each function it >> appears in.) >> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:72: error: 'yylval' undeclared >> (first use in this function) >> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:73: error: 'L_IMM' undeclared >> (first use in this function) >> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:76: error: 'R_NAME' undeclared >> (first use in this function) >> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:77: error: 'R_ENCODING' >> undeclared (first use in this function) >> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:78: error: 'R_VARIABLE' >> undeclared (first use in this function) >> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:79: error: 'R_DEFCSID' undeclared >> (first use in this function) >> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:80: error: 'R_INVALID' undeclared >> (first use in this function) >> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:88: error: 'L_STRING' undeclared >> (first use in this function) >> *** Error code 1 >> Stop. >> make[3]: stopped in /usr/home/tuexen/head/usr.bin/mkesdb_static >> *** Error code 1 >> Stop. >> make[2]: stopped in /usr/home/tuexen/head >> *** Error code 1 >> Stop. >> make[1]: stopped in /usr/home/tuexen/head >> *** Error code 1 >> Stop. >> make: stopped in /usr/home/tuexen/head >> This is on a 64 bit PPC system. Doing sudo rm -rf /usr/obj does not resolve >> the issue. >> Any idea what is going wrong? >> Best regards >> Michael > > Have seen another report on Twitter yesterday. Didn't see a full build log, > but theirs was had apparently without -j, apparently on June 14 sources: > > Error: > /usr/src/usr.bin/mkesdb/lex.1:46:10: fatal error: 'yacc.h' file not found > > Have not heard back from them whether it continued after trying -j2 but I did > ask them to hit up freebsd-current if it continued to be an issue OK, I started the build again with -j 2 and it seems that the problem does not occur. Since I have been using make buildworld without -j n in the past on that machine, the problem seems to be introduced recently. Any idea what is the cause of the problem? Best regards Michael > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT >r349150: boot failure in rc.conf.local
On 19. 6. 18., O. Hartmann wrote: > On all CURRENT boxes running CURRENT > r349150 we face the very same boot > failure, if /etc/rc.conf.local is present (i.e. on CURRENT, 13.0-CURRENT #7 > r349169: Tue Jun 18 10:34:13 CEST 2019 amd64): > > The box boots and thentries to start services denominated > in /etc/rc.conf.local, like net/openldap-server (slapd). The box is then stuck > at "startingt slapd", hitting Ctrl-T shows state "running", but Ctrl-C does > not > show any effect, except Ctrl-Alt-Del (if enabled) is effectively rebooting the > box. First I thought it might by a out-of-sync binary, but this phenomenon > spreads even over recently via make installed systems. Disabling OpenLDAP's > slapd at boot time gives my like rolling a dice the next service, named > (dns/bind914) or net/samba48 (samba_server) - you name it. The box gets stuck > forever and doesn't even start sshd to provide access. All boxes have IPv6 > enabled as well as IPFW. > > Another server running CURRENT (r349169, also amd64) without > utilizing /etc/rc.conf.local but with a bunch of jails is booting as usual! > > What happened here? Does anyone do have a hint or might know the cause? I had the same problem and reverting r349154 fixed the problem for me. https://svnweb.freebsd.org/changeset/base/349154 FYI... Jung-uk Kim ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: error: yacc.h: No such file or directory
Hi, > On 18 Jun 2019, at 11:56, Kubilay Kocak wrote: > > On 18/06/2019 5:42 pm, Michael Tuexen wrote: >> Dear all, >> I'm trying to run >> sudo make buildworld >> in a directory with r349168. FWIW I have a successful build with r349167 >> The result is: >> cc -O2 -pipe -I/usr/home/tuexen/head/usr.bin/mkesdb_static >> -I/usr/home/tuexen/head/usr.bin/mkesdb_static/../mkesdb >> -I/usr/home/tuexen/head/usr.bin/mkesdb_static/../../lib/libc/iconv -g -MD >> -MF.depend.lex.o -MTlex.o -std=gnu99 >> -I/usr/obj/usr/home/tuexen/head/powerpc.powerpc64/tmp/legacy/usr/include -c >> lex.c -o lex.o >> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:46:18: error: yacc.h: No such >> file or directory >> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l: In function 'yylex': >> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: 'R_LN' undeclared >> (first use in this function) >> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: (Each undeclared >> identifier is reported only once >> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: for each function it >> appears in.) >> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:72: error: 'yylval' undeclared >> (first use in this function) >> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:73: error: 'L_IMM' undeclared >> (first use in this function) >> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:76: error: 'R_NAME' undeclared >> (first use in this function) >> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:77: error: 'R_ENCODING' >> undeclared (first use in this function) >> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:78: error: 'R_VARIABLE' >> undeclared (first use in this function) >> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:79: error: 'R_DEFCSID' undeclared >> (first use in this function) >> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:80: error: 'R_INVALID' undeclared >> (first use in this function) >> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:88: error: 'L_STRING' undeclared >> (first use in this function) >> *** Error code 1 >> Stop. >> make[3]: stopped in /usr/home/tuexen/head/usr.bin/mkesdb_static >> *** Error code 1 >> Stop. >> make[2]: stopped in /usr/home/tuexen/head >> *** Error code 1 >> Stop. >> make[1]: stopped in /usr/home/tuexen/head >> *** Error code 1 >> Stop. >> make: stopped in /usr/home/tuexen/head >> This is on a 64 bit PPC system. Doing sudo rm -rf /usr/obj does not resolve >> the issue. >> Any idea what is going wrong? >> Best regards >> Michael > > Have seen another report on Twitter yesterday. Didn't see a full build log, > but theirs was had apparently without -j, apparently on June 14 sources: > > Error: > /usr/src/usr.bin/mkesdb/lex.1:46:10: fatal error: 'yacc.h' file not found > > Have not heard back from them whether it continued after trying -j2 but I did > ask them to hit up freebsd-current if it continued to be an issue -- Bob Bishop r...@gid.co.uk ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: error: yacc.h: No such file or directory
On 18/06/2019 5:42 pm, Michael Tuexen wrote: Dear all, I'm trying to run sudo make buildworld in a directory with r349168. The result is: cc -O2 -pipe -I/usr/home/tuexen/head/usr.bin/mkesdb_static -I/usr/home/tuexen/head/usr.bin/mkesdb_static/../mkesdb -I/usr/home/tuexen/head/usr.bin/mkesdb_static/../../lib/libc/iconv -g -MD -MF.depend.lex.o -MTlex.o -std=gnu99 -I/usr/obj/usr/home/tuexen/head/powerpc.powerpc64/tmp/legacy/usr/include -c lex.c -o lex.o /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:46:18: error: yacc.h: No such file or directory /usr/home/tuexen/head/usr.bin/mkesdb/lex.l: In function 'yylex': /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: 'R_LN' undeclared (first use in this function) /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: (Each undeclared identifier is reported only once /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: for each function it appears in.) /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:72: error: 'yylval' undeclared (first use in this function) /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:73: error: 'L_IMM' undeclared (first use in this function) /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:76: error: 'R_NAME' undeclared (first use in this function) /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:77: error: 'R_ENCODING' undeclared (first use in this function) /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:78: error: 'R_VARIABLE' undeclared (first use in this function) /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:79: error: 'R_DEFCSID' undeclared (first use in this function) /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:80: error: 'R_INVALID' undeclared (first use in this function) /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:88: error: 'L_STRING' undeclared (first use in this function) *** Error code 1 Stop. make[3]: stopped in /usr/home/tuexen/head/usr.bin/mkesdb_static *** Error code 1 Stop. make[2]: stopped in /usr/home/tuexen/head *** Error code 1 Stop. make[1]: stopped in /usr/home/tuexen/head *** Error code 1 Stop. make: stopped in /usr/home/tuexen/head This is on a 64 bit PPC system. Doing sudo rm -rf /usr/obj does not resolve the issue. Any idea what is going wrong? Best regards Michael Have seen another report on Twitter yesterday. Didn't see a full build log, but theirs was had apparently without -j, apparently on June 14 sources: Error: /usr/src/usr.bin/mkesdb/lex.1:46:10: fatal error: 'yacc.h' file not found Have not heard back from them whether it continued after trying -j2 but I did ask them to hit up freebsd-current if it continued to be an issue ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
CURRENT >r349150: boot failure in rc.conf.local
On all CURRENT boxes running CURRENT > r349150 we face the very same boot failure, if /etc/rc.conf.local is present (i.e. on CURRENT, 13.0-CURRENT #7 r349169: Tue Jun 18 10:34:13 CEST 2019 amd64): The box boots and thentries to start services denominated in /etc/rc.conf.local, like net/openldap-server (slapd). The box is then stuck at "startingt slapd", hitting Ctrl-T shows state "running", but Ctrl-C does not show any effect, except Ctrl-Alt-Del (if enabled) is effectively rebooting the box. First I thought it might by a out-of-sync binary, but this phenomenon spreads even over recently via make installed systems. Disabling OpenLDAP's slapd at boot time gives my like rolling a dice the next service, named (dns/bind914) or net/samba48 (samba_server) - you name it. The box gets stuck forever and doesn't even start sshd to provide access. All boxes have IPv6 enabled as well as IPFW. Another server running CURRENT (r349169, also amd64) without utilizing /etc/rc.conf.local but with a bunch of jails is booting as usual! What happened here? Does anyone do have a hint or might know the cause? Thanks in advance, Oliver ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fwd: ZFS Crash/Pool in unhealthy state
On 17/06/2019 17:32, Larry Rosenman wrote: > Forwarding to -Current as well, since it's a -current box > > Original Message > Subject: ZFS Crash/Pool in unhealthy state > Date: 06/17/2019 8:30 am > From: Larry Rosenman > To: Freebsd fs > > I had a power failure today and my big server no longer boots > > If I try to import the pool using the memstick image and -F -f I get a panic > (see link). > > https://www.lerctr.org/~ler/ZFS_CRASH.png <--- Panic > > https://www.lerctr.org/~ler/ZFS_IMPORT.png <--- import tries. > > Ideas? Help? My reading of it is that somehow you got a situation where a block that ZFS considers as free is also queued for deferred freeing, which makes no sense. So, as soon as ZFS starts processing the deferred frees it sees the inconsistency and panics. Usually, I tend to suspect the software first, but in this case I see that the data has got other inconsistencies in the last TXG(s) before the crash. That's why import -F is required. So, I suspect that either the storage controller is misconfigured with respect to caches (its own and disks) or it otherwise misbehaves in that respect. As to the recovery. The proper way would be to import the pool read-only and transfer the data to a new pool. The more risky way would be to import the pool on a system where that consistency check is simply disabled. One way to do that is to clear bit 6 (mask 0x40) from ZFS debug flags. Or to use a STABLE FreeBSD image for an import. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
error: yacc.h: No such file or directory
Dear all, I'm trying to run sudo make buildworld in a directory with r349168. The result is: cc -O2 -pipe -I/usr/home/tuexen/head/usr.bin/mkesdb_static -I/usr/home/tuexen/head/usr.bin/mkesdb_static/../mkesdb -I/usr/home/tuexen/head/usr.bin/mkesdb_static/../../lib/libc/iconv -g -MD -MF.depend.lex.o -MTlex.o -std=gnu99 -I/usr/obj/usr/home/tuexen/head/powerpc.powerpc64/tmp/legacy/usr/include -c lex.c -o lex.o /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:46:18: error: yacc.h: No such file or directory /usr/home/tuexen/head/usr.bin/mkesdb/lex.l: In function 'yylex': /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: 'R_LN' undeclared (first use in this function) /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: (Each undeclared identifier is reported only once /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: for each function it appears in.) /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:72: error: 'yylval' undeclared (first use in this function) /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:73: error: 'L_IMM' undeclared (first use in this function) /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:76: error: 'R_NAME' undeclared (first use in this function) /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:77: error: 'R_ENCODING' undeclared (first use in this function) /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:78: error: 'R_VARIABLE' undeclared (first use in this function) /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:79: error: 'R_DEFCSID' undeclared (first use in this function) /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:80: error: 'R_INVALID' undeclared (first use in this function) /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:88: error: 'L_STRING' undeclared (first use in this function) *** Error code 1 Stop. make[3]: stopped in /usr/home/tuexen/head/usr.bin/mkesdb_static *** Error code 1 Stop. make[2]: stopped in /usr/home/tuexen/head *** Error code 1 Stop. make[1]: stopped in /usr/home/tuexen/head *** Error code 1 Stop. make: stopped in /usr/home/tuexen/head This is on a 64 bit PPC system. Doing sudo rm -rf /usr/obj does not resolve the issue. Any idea what is going wrong? Best regards Michael ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
