Fatal trap 9 when rebooting after installkernel on VirtualBox VM
Hello. I'm tracking head with VirtualBox VM. Everytime new snapshot is released I update to same revision. So buildworld, buildkernel and installkernel always completes sucsessfully. But when rebooting system always crashes with 'Fatal trap 9: general protection fault while in kernel mode' message. And I closed VM window and restart VM, new kernel start up without any problem. https://www.utahime.org/FreeBSD/VirtualBox_FreeBSD_12.0-ALPHA3.png This is a screenshot of latest update (ALPHA3 -> ALPHA4). Does anyone else experienced it? Conditions about VM and host are following: VM: CPU: x4 Memory: 8GB Disk: 100GB SATA Host: CPU: Intel Core i7 4770S Memory: 16GB Disk: 2TB SATA OS: 64bit Windows 10 Enterprise 1803 Best Regards. --- Yasuhiro KIMURA ___ 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: Fatal trap 9 when rebooting after installkernel on VirtualBox VM
From: Yasuhiro KIMURA Subject: Fatal trap 9 when rebooting after installkernel on VirtualBox VM Date: Sun, 02 Sep 2018 23:51:45 +0900 (JST) > I'm tracking head with VirtualBox VM. Everytime new snapshot is > released I update to same revision. So buildworld, buildkernel and > installkernel always completes sucsessfully. But when rebooting system > always crashes with 'Fatal trap 9: general protection fault while in > kernel mode' message. And I closed VM window and restart VM, new > kernel start up without any problem. > https://www.utahime.org/FreeBSD/VirtualBox_FreeBSD_12.0-ALPHA3.png > This is a screenshot of latest update (ALPHA3 -> ALPHA4). > Does anyone else experienced it? I submitted this problem to bugzilla. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231430 Screenshots when updateing to ALPHA5, ALPHA6 and ALPHA7 are also attached. According to the advice of Mark Johnston (ma...@freebsd.org) they include output of 'bt' command. Just FYI. --- Yasuhiro KIMURA ___ 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"
Regression of dtrace on 13-CURRENT
Hello.
On 13-CURRENT r339548 build of lang/perl5.26 fails with configure error.
--
yasu@rolling-vm-freebsd1[2100]% uname -a
FreeBSD rolling-vm-freebsd1.home.utahime.org 13.0-CURRENT FreeBSD 13.0-CURRENT
r339548 GENERIC_UTAHIME amd64
yasu@rolling-vm-freebsd1[2101]% pwd
/usr/ports/lang/perl5.26
yasu@rolling-vm-freebsd1[2102]% make
===> License ART10 GPLv1+ accepted by the user
===> perl5.26-5.26.2 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by perl5.26-5.26.2 for building
===> Extracting for perl5.26-5.26.2
=> SHA256 Checksum OK for perl/perl-5.26.2.tar.xz.
/bin/ln -s libperl.so.5.26.2
/usr0/freebsd/ports/work/net/freebsd/ports/head/lang/perl5.26/work/perl-5.26.2/libperl.so
/bin/ln -s libperl.so.5.26.2
/usr0/freebsd/ports/work/net/freebsd/ports/head/lang/perl5.26/work/perl-5.26.2/libperl.so.5.26
===> Patching for perl5.26-5.26.2
===> Applying FreeBSD patches for perl5.26-5.26.2
/usr/bin/sed -i.bak -e 's|/usr/local|/usr/local|g'
/usr0/freebsd/ports/work/net/freebsd/ports/head/lang/perl5.26/work/perl-5.26.2/Configure
/usr0/freebsd/ports/work/net/freebsd/ports/head/lang/perl5.26/work/perl-5.26.2/hints/freebsd.sh
/usr/bin/sed -i.bak -e '/do_installprivlib = 0 if .versiononly/d;
/^if.*nopods.*versiononly || /s/.*/if (1) {/'
/usr0/freebsd/ports/work/net/freebsd/ports/head/lang/perl5.26/work/perl-5.26.2/installperl
===> Configuring for perl5.26-5.26.2
First let's make sure your kit is complete. Checking...
(snip)
Colon-separated list of additional directories for perl to search? [none]
Checking out function prototypes...
Support DTrace if available? [y]
Where is the dtrace executable? (~name ok) [/usr/sbin/dtrace]
*** Configure: Fatal Error: /usr/sbin/dtrace doesn't support -h flag
***
*** Your installed dtrace doesn't support the -h switch to compile a D
*** program into a C header. Can't continue.
===> Script "Configure" failed unexpectedly.
Please report the problem to m...@freebsd.org [maintainer] and attach the
"/usr0/freebsd/ports/work/net/freebsd/ports/head/lang/perl5.26/work/perl-5.26.2/config.log"
including the output of the failure of your make command. Also, it might be
a good idea to provide an overview of all packages installed on your system
(e.g. a /usr/local/sbin/pkg-static info -g -Ea).
*** Error code 1
Stop.
make: stopped in /net/freebsd/ports/head/lang/perl5.26
yasu@rolling-vm-freebsd1[2103]%
--
In perl-5.26.2/Configure there is following test.
--
if $test -f $dtrace
then
if $dtrace -h -s ../perldtrace.d \
-o perldtrace.tmp >/dev/null 2>&1 \
&& rm -f perldtrace.tmp
then
echo " "
echo "Good: your $dtrace knows about the -h flag."
else
cat >&2
Re: Regression of dtrace on 13-CURRENT
From: Yasuhiro KIMURA Subject: Regression of dtrace on 13-CURRENT Date: Thu, 25 Oct 2018 14:46:00 +0900 (JST) > So there is regression about dtrace between r339436 and r339548. I submitted this problem to Bugzilla. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232675 --- Yasuhiro KIMURA ___ 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"
Getting value of MAKEOBJDIRPREFIX with 'make -V MAKEOBJDIRPREFIX'
Hello, I'm writing shell script to build and install base system from source and -V option of make(1) is used in it to get value of MAKEOBJDIRPREFIX. By default it works fine with all of head, releng/11.2, releng/12.0, stable/11 and stable/12. yasu@eastasia[2389]% svn info /usr0/freebsd/base/head Path: /usr0/freebsd/base/head Working Copy Root Path: /usr0/freebsd/base/head URL: https://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: https://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 340474 Node Kind: directory Schedule: normal Last Changed Author: karels Last Changed Rev: 340474 Last Changed Date: 2018-11-16 12:42:29 +0900 (Fri, 16 Nov 2018) yasu@eastasia[2390]% make -V MAKEOBJDIRPREFIX -C /usr0/freebsd/base/head /usr/obj yasu@eastasia[2391]% svn info /usr0/freebsd/base/releng/11.2 Path: /usr0/freebsd/base/releng/11.2 Working Copy Root Path: /usr0/freebsd/base/releng/11.2 URL: https://svn.freebsd.org/base/releng/11.2 Relative URL: ^/releng/11.2 Repository Root: https://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 338990 Node Kind: directory Schedule: normal Last Changed Author: gordon Last Changed Rev: 338981 Last Changed Date: 2018-09-28 03:36:30 +0900 (Fri, 28 Sep 2018) yasu@eastasia[2392]% make -V MAKEOBJDIRPREFIX -C /usr0/freebsd/base/releng/11.2 /usr/obj yasu@eastasia[2393]% svn info /usr0/freebsd/base/releng/12.0 Path: /usr0/freebsd/base/releng/12.0 Working Copy Root Path: /usr0/freebsd/base/releng/12.0 URL: https://svn.freebsd.org/base/releng/12.0 Relative URL: ^/releng/12.0 Repository Root: https://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 340471 Node Kind: directory Schedule: normal Last Changed Author: gjb Last Changed Rev: 340470 Last Changed Date: 2018-11-16 09:00:59 +0900 (Fri, 16 Nov 2018) yasu@eastasia[2394]% make -C /usr0/freebsd/base/releng/12.0 -V MAKEOBJDIRPREFIX /usr/obj yasu@eastasia[2395]% svn info /usr0/freebsd/base/stable/11 Path: /usr0/freebsd/base/stable/11 Working Copy Root Path: /usr0/freebsd/base/stable/11 URL: https://svn.freebsd.org/base/stable/11 Relative URL: ^/stable/11 Repository Root: https://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 340473 Node Kind: directory Schedule: normal Last Changed Author: ygy Last Changed Rev: 340449 Last Changed Date: 2018-11-15 17:43:17 +0900 (Thu, 15 Nov 2018) yasu@eastasia[2396]% make -V MAKEOBJDIRPREFIX -C /usr0/freebsd/base/stable/11 /usr/obj yasu@eastasia[2397]% svn info /usr0/freebsd/base/stable/12 Path: /usr0/freebsd/base/stable/12 Working Copy Root Path: /usr0/freebsd/base/stable/12 URL: https://svn.freebsd.org/base/stable/12 Relative URL: ^/stable/12 Repository Root: https://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 340474 Node Kind: directory Schedule: normal Last Changed Author: gjb Last Changed Rev: 340471 Last Changed Date: 2018-11-16 09:03:31 +0900 (Fri, 16 Nov 2018) yasu@eastasia[2398]% make -V MAKEOBJDIRPREFIX -C /usr0/freebsd/base/stable/12 /usr/obj But if I customize value of MAKEOBJDIRPREFIX then it still works with releng/11.2 and stable/11 but doesn't with head, releng/12.0 and stable/12. yasu@eastasia[2399]% env MAKEOBJDIRPREFIX=/usr0/freebsd/base/ogj make -V MAKEOBJDIRPREFIX -C /usr0/freebsd/base/head yasu@eastasia[2400]% env MAKEOBJDIRPREFIX=/usr0/freebsd/base/ogj make -V MAKEOBJDIRPREFIX -C /usr0/freebsd/base/releng/11.2 /usr0/freebsd/base/ogj yasu@eastasia[2401]% env MAKEOBJDIRPREFIX=/usr0/freebsd/base/ogj make -V MAKEOBJDIRPREFIX -C /usr0/freebsd/base/releng/12.0 yasu@eastasia[2402]% env MAKEOBJDIRPREFIX=/usr0/freebsd/base/ogj make -V MAKEOBJDIRPREFIX -C /usr0/freebsd/base/stable/11 /usr0/freebsd/base/ogj yasu@eastasia[2403]% env MAKEOBJDIRPREFIX=/usr0/freebsd/base/ogj make -V MAKEOBJDIRPREFIX -C /usr0/freebsd/base/stable/12 yasu@eastasia[2404]% I used env(1) to customize but I got same results when I use src-env.conf. Then is this just bug? Or are there any reason that behavior is changed from 11.x to 12.x and later? Best Regards. --- Yasuhiro KIMURA ___ 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: Getting value of MAKEOBJDIRPREFIX with 'make -V MAKEOBJDIRPREFIX'
From: Yasuhiro KIMURA Subject: Getting value of MAKEOBJDIRPREFIX with 'make -V MAKEOBJDIRPREFIX' Date: Sat, 17 Nov 2018 01:57:58 +0900 (JST) > Then is this just bug? Or are there any reason that behavior is > changed from 11.x to 12.x and later? To find when behavior changed I bisected head from r302408 (revision that stable/11 is cleated) to r340439 and got following result. Order RevisionDoes 'make -V MAKEOBJDIRPREFIX` work? -- 1 302408 Yes 2 340439 No 3 323176 Yes 4 332305 No 5 327441 No 6 325415 No 7 324362 Yes 8 324940 Yes 9 325181 Yes 10 325295 No 11 325248 Yes 12 325271 Yes 13 325285 Yes 14 325290 No 15 325288 No 16 325287 Yes That is, behavior changed at r325288. And commit message says as following. -- Add option UNIFIED_OBJDIR, on by default, which moves the default build OBJDIR. This changes the build OBJDIR from the older style of /usr/obj/ for native builds, and /usr/obj/./ for cross builds to a new simpler format of /usr/obj//.. This new format is used regardless of cross or native build. It allows easier management of multiple source tree object directories. The UNIFIED_OBJDIR option will be removed and its feature made permanent for the 12.0 release. -- As far as I read this, behavior change of 'make -V MAKEOBJDIRPREFIX` doesn't seem intentional. So I'll submit bug report. --- Yasuhiro KIMURA ___ 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: Getting value of MAKEOBJDIRPREFIX with 'make -V MAKEOBJDIRPREFIX'
From: Yasuhiro KIMURA Subject: Re: Getting value of MAKEOBJDIRPREFIX with 'make -V MAKEOBJDIRPREFIX' Date: Sat, 17 Nov 2018 09:18:53 +0900 (JST) > As far as I read this, behavior change of 'make -V MAKEOBJDIRPREFIX` > doesn't seem intentional. So I'll submit bug report. Submitted. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233265 --- Yasuhiro KIMURA ___ 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"
Ports build fails on 13-CURRENT r341690
Hello, yasu@rolling-vm-freebsd1[2018]% uname -a FreeBSD rolling-vm-freebsd1.home.utahime.org 13.0-CURRENT FreeBSD 13.0-CURRENT r341690 GENERIC amd64 yasu@rolling-vm-freebsd1[2019]% LANG=C svn info /usr/src Path: /usr/src Working Copy Root Path: /usr/src URL: https://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: https://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 341690 Node Kind: directory Schedule: normal Last Changed Author: kib Last Changed Rev: 341690 Last Changed Date: 2018-12-08 00:19:00 +0900 (Sat, 08 Dec 2018) yasu@rolling-vm-freebsd1[2020]% LANG=C svn info /usr/ports Path: /usr/ports Working Copy Root Path: /usr/ports URL: https://svn.freebsd.org/ports/head Relative URL: ^/head Repository Root: https://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 487116 Node Kind: directory Schedule: normal Last Changed Author: yuri Last Changed Rev: 487116 Last Changed Date: 2018-12-10 10:06:34 +0900 (Mon, 10 Dec 2018) Build of ports-mgmt/pkg fails as following. -- > Compressing man pages (compress-man) === === ===> Building package for pkg-1.10.5_5 install -l rs /.npkg/All/pkg-1.10.5_5.txz /.npkg/Latest/pkg.txz install: /.npkg/All/pkg-1.10.5_5.txz: realpath: No such file or directory *** Error code 71 Stop. make[1]: stopped in /usr/ports/ports-mgmt/pkg *** Error code 1 Stop. make: stopped in /usr/ports/ports-mgmt/pkg =>> Cleaning up wrkdir ===> Cleaning for pkg-1.10.5_5 build of ports-mgmt/pkg | pkg-1.10.5_5 ended at Mon Dec 10 16:49:35 JST 2018 build time: 00:03:50 !!! build failure encountered !!! -- Full build log: https://www.utahime.org/FreeBSD/poudriere/data/logs/bulk/curamd64-local/2018-12-10_16h45m20s/logs/errors/pkg-1.10.5_5.log And this prevent any other ports from building. Does anyone else experience it? Best Regards. --- Yasuhiro KIMURA ___ 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: Ports build fails on 13-CURRENT r341690
From: Justin Hibbits Subject: Re: Ports build fails on 13-CURRENT r341690 Date: Wed, 12 Dec 2018 10:37:25 -0600 > I see the exact same problem on one of my powerpc64 machines (a > P5020-based machine). I see it intermittently on my POWER9, so thought > it was a race condition, but it's 100% reproducible on my P5020 machine. Thank you for reply. I updated my system to r342006 and now the problem disappeared. Just FYI. --- Yasuhiro KIMURA ___ 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: Control-T during poudriere: sed: 1: "s, ^\[( *[0-9]+%|[0-9]+/ ...": RE error: repetition-operator operand invalid
From: Graham Perrin Subject: Control-T during poudriere: sed: 1: "s, ^\[( *[0-9]+%|[0-9]+/ ...": RE error: repetition-operator operand invalid Date: Mon, 4 Mar 2019 08:49:05 + > Recently I sometimes get the effect below when keying Control-T during > a run of poudriere. It is fixed with poudriere 3.3.1. --- Yasuhiro KIMURA ___ 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"
Bug report commit request
Dear Committers, Would someone please commit following bug report? Bug 236564 - periodic.sh: Anticongestion function does not work as is expected. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236564 Best Regards. --- Yasuhiro KIMURA ___ 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"
panic: sched_pickcpu: Failed to find a cpu.
yasu@rolling-vm-freebsd1[2001]% uname -a ~ FreeBSD rolling-vm-freebsd1.home.utahime.org 13.0-CURRENT FreeBSD 13.0-CURRENT r352351 GENERIC amd64 After update to r352669, boot fails as following. https://www.utahime.org/FreeBSD/FreeBSD.13-CURRENT.amd64.r352669.screenshot.1.png https://www.utahime.org/FreeBSD/FreeBSD.13-CURRENT.amd64.r352669.screenshot.2.png Any idea? Regards. --- Yasuhiro KIMURA ___ 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: panic: sched_pickcpu: Failed to find a cpu.
From: David Wolfskill Subject: Re: panic: sched_pickcpu: Failed to find a cpu. Date: Wed, 25 Sep 2019 08:08:15 -0700 > Yes; mav@ fixed it with r352677. Thanks. I'll update source tree and rebuild kernel. Regards. --- Yasuhiro KIMURA ___ 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: panic: sched_pickcpu: Failed to find a cpu.
From: Yasuhiro KIMURA Subject: Re: panic: sched_pickcpu: Failed to find a cpu. Date: Thu, 26 Sep 2019 00:12:48 +0900 (JST) >> Yes; mav@ fixed it with r352677. > > Thanks. I'll update source tree and rebuild kernel. I updated kernel to r352685 and now system boots successfully. --- Yasuhiro KIMURA ___ 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"
/etc/os-release isn't created
Hello, Yesterday I updated my 13-CURRENT host from r354592 to r355028 and /etc/os-release symbolic link wasn't created. yasu@rolling-vm-freebsd1[2061]% uname -a FreeBSD rolling-vm-freebsd1.home.utahime.org 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r355028: Sat Nov 23 22:35:58 JST 2019 ro...@rolling-vm-freebsd1.home.utahime.org:/usr0/freebsd/base/obj/usr0/freebsd/base/head/amd64.amd64/sys/GENERIC amd64 yasu@rolling-vm-freebsd1[2062]% ls -l /etc/os-release ls: /etc/os-release: No such file or directory yasu@rolling-vm-freebsd1[2063]% But after that I made same update of 13-CURRENT poudriere jail and then /etc/os-release was created in it. yasu@rolling-vm-freebsd1[2063]% ls -l /usr/local/poudriere/jails/curamd64/etc/os-release lrwxr-xr-x 1 root wheel 21 Nov 24 05:04 /usr/local/poudriere/jails/curamd64/etc/os-release@ -> ../var/run/os-releaseyasu@rolling-vm-freebsd1[2064]% Why such difference happens? --- Yasuhiro KIMURA ___ 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: /etc/os-release isn't created
From: Conrad Meyer
Subject: Re: /etc/os-release isn't created
Date: Sun, 24 Nov 2019 12:51:03 -0800
> Did you run etcupdate or mergemaster as part of updating your host?
Yes. I run 'mergemaster -Fi' after 'make installworld'
I recieved report by private mail that /etc/os-release is created only
when 'make distribution' is executed. And I found that's exactly what
is written in /usr/src/etc/Makefile.
yasu@rolling-vm-freebsd1[2103]% grep '\$FreeBSD' /usr/src/etc/Makefile
# $FreeBSD: head/etc/Makefile 354922 2019-11-20 23:45:31Z imp $
yasu@rolling-vm-freebsd1[2104]% tail +50 /usr/src/etc/Makefile | head -n 12
distribution:
.if !defined(DESTDIR)
@echo "set DESTDIR before running \"make ${.TARGET}\""
@false
.endif
${_+_}cd ${.CURDIR}/gss; ${MAKE} install
${_+_}cd ${.CURDIR}/mtree; ${MAKE} install
${_+_}cd ${SRCTOP}/share/termcap; ${MAKE} etc-termcap
${_+_}cd ${SRCTOP}/usr.sbin/rmt; ${MAKE} etc-rmt
${INSTALL_SYMLINK} ../var/run/os-release \
${DESTDIR}/etc/os-release
yasu@rolling-vm-freebsd1[2105]%
But 'make distribution' isn't executed by normal upgrade steps. So
it's a bug and should be fixed.
---
Yasuhiro KIMURA
___
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: /etc/os-release isn't created
From: Yasuhiro KIMURA
Subject: Re: /etc/os-release isn't created
Date: Mon, 25 Nov 2019 08:13:19 +0900 (JST)
> I recieved report by private mail that /etc/os-release is created only
> when 'make distribution' is executed. And I found that's exactly what
> is written in /usr/src/etc/Makefile.
>
> yasu@rolling-vm-freebsd1[2103]% grep '\$FreeBSD' /usr/src/etc/Makefile
> # $FreeBSD: head/etc/Makefile 354922 2019-11-20 23:45:31Z imp $
> yasu@rolling-vm-freebsd1[2104]% tail +50 /usr/src/etc/Makefile | head -n 12
>
> distribution:
> .if !defined(DESTDIR)
> @echo "set DESTDIR before running \"make ${.TARGET}\""
> @false
> .endif
> ${_+_}cd ${.CURDIR}/gss; ${MAKE} install
> ${_+_}cd ${.CURDIR}/mtree; ${MAKE} install
> ${_+_}cd ${SRCTOP}/share/termcap; ${MAKE} etc-termcap
> ${_+_}cd ${SRCTOP}/usr.sbin/rmt; ${MAKE} etc-rmt
> ${INSTALL_SYMLINK} ../var/run/os-release \
> ${DESTDIR}/etc/os-release
> yasu@rolling-vm-freebsd1[2105]%
>
> But 'make distribution' isn't executed by normal upgrade steps. So
> it's a bug and should be fixed.
I submitted bug report about this problem to Bugzilla.
Bug 242212 /etc/os-release isn't created when you upgrade an existing
13-CURRENT host
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242212
---
Yasuhiro KIMURA
___
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: /etc/os-release isn't created
From: "Herbert J. Skuhra"
Subject: Re: /etc/os-release isn't created
Date: Mon, 25 Nov 2019 02:11:35 +0100
> - mergemaster runs 'make distribution':
> ${MM_MAKE} DESTDIR=${TEMPROOT} distribution >/dev/null;} ||
> - the link etc/os-release is created in /var/tmp/temproot when running
> mergemaster but not moved to /
Thank you for investigation. Then is is bug of mergemaster?
---
Yasuhiro KIMURA
___
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: FreeBSD 10 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf
From: Erwin Lansing Subject: Re: FreeBSD 10 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf Date: Tue, 12 Nov 2013 12:13:23 +0100 > Sorry about the delay, but I did finally update all three dns/bind9* > ports today. I have dropped the complicated chroot, and related > symlinking, logic from the default rc script as I don't think that > is the right place to implement things. I would recommend users > who want the extra security to use jail(8) instead of a mere chroot. > > This change should not affect the installed base of FreeBSD 9.x and > earlier systems, but new installations there should note that the > symlink option is no longer turned on by default, but still supported. > > I tested some default cases, but by no means can test every corner case, > so please let me know how this works out. Please merge r257694 to stable/10 because remnants of BIND are still left. Best Regards. --- Yasuhiro KIMURA ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [HEADSUP] recursive dependency registration is gone for pkgng users
From: Baptiste Daroussin Subject: [HEADSUP] recursive dependency registration is gone for pkgng users Date: Sat, 28 Dec 2013 15:52:50 +0100 > as a side effect, > tinderbox and poudriere users do need to rebuild all their packages from > scratch. Does this mean rebuilding is necessary only if either tinderbox or poudriere are used, or all packages have to be rebuilt anyway if pkgng is used? Best Regards. --- Yasuhiro KIMURA ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Version of OpenSSL included in upcoming 14.0-RELEASE
Dear developers of base system, Though release process of 13.2-RELEASE has just started, please let me talk about one more next one. According to the initial schedule of 14.0-RELEASE, release process will start on April 25 and 14.0-RELEASE will be released on July 17. https://www.freebsd.org/releases/14.0R/schedule/ So it means release process will start about 3 months later and 14.0-RELEASE will be released about 5.5 months later. And I would like to ask a question. Is it planned (or considered, scheduled, etc.) to upgrade version of OpenSSL included in 14-CURRENT from 1.1.1 to 3.0? According to the "Release Strategy" page of upstream (https://www.openssl.org/policies/releasestrat.html), OpenSSL 1.1.1 will reach its EoL on September 11, 2023 and OpenSSL 3.0 will be supported until September 7, 2026. Since EoL of OpenSSL 1.1.1 is only after 2 months of the release of 14.0-RELEASE, it doesn't seems realistic to include OpenSSL 1.1.1 in 14.0-RELEASE and upgrading to OpenSSL 3.0 is inevitable. Though I'm not familiar with the incompatibility between OpenSSL 1.1.1 and 3.0, I believe it is too optimistic to regard that build of 14-CURRENT succeeds without any error just by updating /usr/src/crypto/openssl from 1.1.1 to 3.0. So it will take for a while (a few weeks?) to finish it. And it also affects build of ports. To be honest, it is rather my main concern as ports committer. I checked Bugzilla and found following PR. Bug 258413 [exp-run] OpenSSL 3.0 upgrade https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258413 Though it intends to check how many ports fails to be built if security/openssl is updated to 3.0 and 'DEFAULT_VERSIONS+= openssl' is set in /etc/make.conf, it is also applicable to after OpenSSL in 14-CURRENT is updated to 3.0. And according to the result of exp-run, it doesn't seem to be easy job to adapt ports tree to OpenSSL 3.0. So it probably will take longer than updating base system. And considering these points, 3 months are not necessarily so long. So I asked a question as above. Please let me know current status about it. Best Regards. --- Yasuhiro Kimura
Re: Boot hangs up with Alderlake's intel GbE NIC
From: Yasuhiro Kimura Subject: Re: Boot hangs up with Alderlake's intel GbE NIC Date: Tue, 24 May 2022 02:02:20 +0900 (JST) >> 2 months ago I updated my home server to Intel Alderlake Core i3 12100 >> and GIGABYTE H610I DDR4 (rev. 1.0) motherboard. >> >> The latter has onboard Intel GbE NIC. But unfortunately 13.0-RELEASE >> doesn't detect it. So I inserted Intel PCI-E GbE adaptor to the PCI-E >> slot of the motherbord and used it as network interface of the server. >> >> And now 13.1-RELEASE is released. I tried updating with >> `freebsd-update update -r 13.1-RELEASE`, `freebsd install` and >> `shutdown -r now`. But after that system hangs up in the middle of >> boot. >> >> At first boot stops after onboard Intel GbE NIC is detected. >> >> https://people.freebsd.org/~yasu/Alderlake-GbE-boot-hangup.01.jpg >> >> It keeps about a minute and then boot process resumes. But soon it >> stops again. >> >> https://people.freebsd.org/~yasu/Alderlake-GbE-boot-hangup.02.jpg >> >> I waited about 20 minites in this state but boot never go ahead. >> >> Removing PCE-E GbE adopter doesn't change the situation. >> >> I also tried boot image of 14.0-CURRENT 20220519 snapshot and boot >> hangs up just same as 13.1-RELEASE. >> >> --- >> Yasuhiro Kimura >> > > I submitted the problem to Bugzilla. > > Bug 264179 Boot hangs up with Alderlake's intel GbE NIC > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264179 Recently some commits that change files under sys/dev/e1000 are made to main branch. So I built install image from c8f47b28827c of main and tried booting my home server with it. Then system boots without hang up but onboard Intel GbE NIC failed to be detected with following message. -- em1: mem 0x4230-0x4231ffff at device 31.6 on pci0 em1: Setup of Shared code failed. error -1 em1: IFDI_ATTACH_PRE failed 6 device_attach: em1 attach returned 6 -- --- Yasuhiro Kimura
Re: ld-elf.so.1: Shared object "libssl.so.111" not found, required by "pkg" and others
From: Nuno Teixeira
Subject: ld-elf.so.1: Shared object "libssl.so.111" not found, required by
"pkg" and others
Date: Sun, 2 Jul 2023 06:22:48 +0100
> Hello all,
>
> I'm returning to current and installed from
> 20230622-b95d2237af40-263748-bootonly.iso and upgraded to cab2d43b83b (amd64).
>
> Did a magnific delete-old and delete-old-libs and now a lot of packages
> complain about "ld-elf.so.1: Shared object "libssl.so.111" not found,
> required by..."
>
> To fix it I rebooted with BE from first instalation since I used beinstall.sh
> for upgrade.
>
> I know that a lot of things happened in the last days with llvm15->llvm16,
> openssl3, etc.
>
> My question is when can I do a delete-old{-libs}?
> I'm thinking building pkgs with a updated current on poudriere and then clean
> up libs?
>
> Thanks,
The source of the issue is the migration from OpenSSL 1.1.1 to 3.0.
So if you use packages built by yourself (e,g. by using poudriere,
portmaster, porupgrade, etc. or simply 'make install'), then you
should rebuild and reinstall all packages and then should do
`make delete-old-libs`.
If you use official binary packages, then you should wait until all
packages are built with OpenSSL 3.0.
HTH.
---
Yasuhiro Kimura
Kernel panic after updating 14-CURRENT amd64 to main-n264268-ff4633d9f89
After updating my 14.0-CURRENT amd64 system from main-n264162-f58378393fb to main-n264268-ff4633d9f89, kernel crashes with panic as following. https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-main-n264268-ff4633d9f89.20230721.panic.png --- Yasuhiro Kimura
Re: Kernel panic after updating 14-CURRENT amd64 to main-n264268-ff4633d9f89
From: Yasuhiro Kimura Subject: Kernel panic after updating 14-CURRENT amd64 to main-n264268-ff4633d9f89 Date: Sat, 22 Jul 2023 02:50:23 +0900 (JST) > After updating my 14.0-CURRENT amd64 system from > main-n264162-f58378393fb to main-n264268-ff4633d9f89, kernel crashes > with panic as following. > > https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-main-n264268-ff4633d9f89.20230721.panic.png According to the result of bisect, kernel panic starts with following commit. -- commit 95f7b36e8fac45092b9a4eea5e32732e979989f0 Author: Kevin Bowling Date: Thu Jul 20 20:30:00 2023 -0700 e1000: lem(4)/em(4) ifcaps, TSO and hwcsum fixes * em(4) obey administrative ifcaps for using hwcsum offload * em(4) obey administrative ifcaps for hw vlan receive tagging * em(4) add additional TSO6 ifcap, but disabled by default as is TSO4 * lem(4) obey administrative ifcaps for using hwcsum offload * lem(4) add support for hw vlan receive tagging * lem(4) Add ifcaps for TSO offload experimentation, but disabled by default due to errata and possibly missing txrx code. * lem(4) disable HWCSUM ifcaps by default on 82547 due to errata around full duplex links. It may still be administratively enabled. Reviewed by:markj (previous version) MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D30072 -- Cc-ing to its committer. --- Yasuhiro Kimura
Re: Kernel panic after updating 14-CURRENT amd64 to main-n264268-ff4633d9f89
From: Kevin Bowling Subject: Re: Kernel panic after updating 14-CURRENT amd64 to main-n264268-ff4633d9f89 Date: Fri, 21 Jul 2023 21:44:13 -0700 > Thanks, I have reverted for now. Can you tell me which NIC is > implemented there? Output of `pciconf -lv` says as following. em0@pci0:0:3:0: class=0x02 rev=0x02 hdr=0x00 vendor=0x8086 device=0x100e subvendor=0x8086 subdevice=0x001e vendor = 'Intel Corporation' device = '82540EM Gigabit Ethernet Controller' class = network subclass = ethernet Regards. --- Yasuhiro Kimura
Re: security/openvpn does not compile in 14-CURRENT w/ poudriere
From: Matthias Apitz Subject: security/openvpn does not compile in 14-CURRENT w/ poudriere Date: Tue, 15 Aug 2023 08:16:38 +0200 > > security/openvpn fails to build with an error message in the log: > > ... > libc.so.7 > libcrypto.so.11 > libcrypto.so.30 > libdl.so.1 > liblz4.so.1 > liblzo2.so.2 > libnv.so.1 > libpkcs11-helper.so.1 > libssl.so.11 > libthr.so.3 > /usr/ports/security/openvpn FAILED: either of libssl libcrypto libraries > linked multiple times > *** Error code 1 > > The full log is at http://www.unixarea.de/openvpn-2.6.5.log > > The job uses via make.conf the SSL from the base: > > ---Begin OPTIONS List--- > ===> The following configuration options are available for openvpn-2.6.5: > ASYNC_PUSH=off: Enable async-push support > DCO=on: Build with Data Channel Offload (ovpn(4)) support > DOCS=on: Build and/or install documentation > EASYRSA=on: Install security/easy-rsa RSA helper package > EXAMPLES=on: Build and/or install examples > LZ4=on: LZ4 compression support > LZO=on: LZO compression (incompatible with LibreSSL) > PKCS11=on: Use security/pkcs11-helper, needs same SSL lib! > SMALL=off: Build a smaller executable with fewer features > TEST=on: Build and/or run tests > UNITTESTS=off: Enable unit tests > X509ALTUSERNAME=off: Enable --x509-username-field > ===> Use 'make config' to modify these settings > ---End OPTIONS List--- > > --MAKE_ENV-- > OPENSSLBASE=/usr OPENSSLDIR=/etc/ssl OPENSSLINC=/usr/include > OPENSSLLIB=/usr/lib ... > > There is a similar, but closed PR: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254323 > > What can I do? > > matthias I tried build of security/openvpn with following conditions. * Host: 14.0-ALPHA1 amd64 main-n264690-54cfeb84846 GENERIC * Poudriere: 3.3.7 * Jail: same as host * Ports tree: d5418d0957ad (main branch) * Default options setting including all dependencies And it finished successfully. Full build log: https://people.freebsd.org/~yasu/poudriere/data/logs/bulk/curamd64-default/2023-08-15_15h42m59s/logs/openvpn-2.6.5.log HTH. --- Yasuhiro Kimura
Panic with 15.0-CURRENT
Hello, I made regular update of my amd64 system from main-n264870-e5e6a865358 to main-n265022-1554ba03b65 and system crashed with panic while building packages with poudriere. Screenshot of console: https://people.freebsd.org/~yasu/FreeBSD-15-CURRENT-amd64-main-n265022-1554ba03b65.20230825.panic.png --- Yasuhiro Kimura
Re: FreeBSD 14.0-BETA3 Now Available
From: Glen Barber Subject: FreeBSD 14.0-BETA3 Now Available Date: Fri, 22 Sep 2023 22:50:08 + > The third BETA build of the 14.0-RELEASE release cycle is now available. I tried to update from 14.0-BETA2 to 14.0-BETA3 with freebsd-update(8) but it fails as following. root@rolling-vm-freebsd4[180]# uname -a FreeBSD rolling-vm-freebsd4.home.utahime.org 14.0-BETA2 FreeBSD 14.0-BETA2 #0 releng/14.0-n265096-dfd44f2f0143: Fri Sep 15 05:46:35 UTC 2023 r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 root@rolling-vm-freebsd4[181]# freebsd-update -r 14.0-BETA3 upgrade Looking up update.FreeBSD.org mirrors... 2 mirrors found. Fetching metadata signature for 14.0-BETA2 from update1.freebsd.org... done. Fetching metadata index... done. Inspecting system... done. The following components of FreeBSD seem to be installed: kernel/generic world/base world/lib32 The following components of FreeBSD do not seem to be installed: Does this look reasonable (y/n)? y Fetching metadata signature for 14.0-BETA3 from update1.freebsd.org... failed. Fetching metadata signature for 14.0-BETA3 from update2.freebsd.org... failed. No mirrors remaining, giving up. This may be because upgrading from this platform (amd64) or release (14.0-BETA3) is unsupported by freebsd-update. Only platforms with Tier 1 support can be upgraded by freebsd-update. See https://www.freebsd.org/platforms/ for more info. If unsupported, FreeBSD must be upgraded by source. root@rolling-vm-freebsd4[182]# What is wrong? --- Yasuhiro Kimura
Re: FreeBSD 14.0-BETA3 Now Available
From: Glen Barber Subject: Re: FreeBSD 14.0-BETA3 Now Available Date: Fri, 22 Sep 2023 23:32:53 + > On Sat, Sep 23, 2023 at 08:16:47AM +0900, Yasuhiro Kimura wrote: >> I tried to update from 14.0-BETA2 to 14.0-BETA3 with freebsd-update(8) >> but it fails as following. >> > [...] > > -- begin quoted text --- > === Upgrading === > > Due to a known delay, freebsd-update(8) binary update builds are not yet > ready for BETA3. A separate email will be sent once they are available. > --- end quoted text > > Glen > Oops, I should have read more carefully. Anyway thanks for quick reply. --- Yasuhiro Kimura
Re: Updating motherboard BIOS without MS Windows
From: Nuno Teixeira Subject: Updating motherboard BIOS without MS Windows Date: Sat, 11 Nov 2023 10:56:58 + > Hello all, > > Maybe not the best mailing to ask it but... > > How do you update BIOS without Windows since most brands only have bios > software to windows? > > I'm about to buy a new pc without windows license and I'm looking for brands > that have bios-cli that work in FreeBSD. > > Thanks, I always buy PC parts and assemble them by myself. Currently I have 3 PCs that use motherboard of different brands. And BIOS of all 3 motherbords includes the way to update itself without the help of OS and/or utility program. Typically it works as following. 1. Enter BIOS menu. 2. Invoke the way to update BIOS. 3. Read input file from the media formatted with FAT file system. 4. Start updating BIOS. 5. After finished PC is rebooted. On the other hand, new versions of BIOS are provided on the web site of each brand as zip archive. So BIOS of motherboard can be updated with following steps. 1. Download zip archive of BIOS file from web site of motherboard brand. 2. Extract BIOS file from the archive with `unzip`. 3. Insert USB memstick. 4. Format the memstick with `newfs_msdos`. 5. Mount the partion with `mount -t msdosfs` and copy BIOS file to it. 6. Reboot PC and enter BIOS menu. 7. Invoke the way to update BIOS. 8. Select BIOS file in the memstick as input. 9. Start update of BIOS. Though I haven't check motherboards of eatch brand in detail, I think it rather common for recent motherboards to provide similar functionality. It seems you are going to buy already assembled PC. And I'm not sure if it's easy to know the brand and model of the motherboard used with the PC. But if it isn't diffcult there is good chance you can select and buy the PC that can update BIOS with similar way as above. HTH. --- Yasuhiro Kimura
Re: /etc/os-release isn't created
From: Yasuhiro KIMURA
Subject: Re: /etc/os-release isn't created
Date: Mon, 25 Nov 2019 10:27:36 +0900 (JST)
> From: "Herbert J. Skuhra"
> Subject: Re: /etc/os-release isn't created
> Date: Mon, 25 Nov 2019 02:11:35 +0100
>
>> - mergemaster runs 'make distribution':
>> ${MM_MAKE} DESTDIR=${TEMPROOT} distribution >/dev/null;} ||
>> - the link etc/os-release is created in /var/tmp/temproot when running
>> mergemaster but not moved to /
>
> Thank you for investigation. Then is is bug of mergemaster?
I created patch adding logic that handles symbolik link to mergemaster
and submitted it to following bug report.
Bug 242212 usr.sbin/mergemaster/mergemaster.sh: There is no logic to handle
symbolic
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242212
So please review and/or test it.
Best Regards.
---
Yasuhiro KIMURA
___
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"
After update to r357104 build of poudriere jail fails with 'out of swap space'
Hello. I use VirtualBox to run 13-CURRENT. Host is 64bit Windows 10 1909 and spec of VM is as following. * 4 CPU * 8GB memory * 100GB disk - 92GB ZFS pool (zroot) - 8GB swap Today I updated this VM to r357104. And after that I tried to update poudriere jail with `poudriere jail -u -j jailname -b`. But it failed at install stage. After the failure I found following message is written to syslog. Jan 25 19:18:25 rolling-vm-freebsd1 kernel: pid 7963 (strip), jid 0, uid 0, was killed: out of swap space To make sure I shutdown both VM and host, restarted them and tried update of jail again. Then the problem was reproduced. Does anybody else experience it? --- Yasuhiro KIMURA ___ 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: After update to r357104 build of poudriere jail fails with 'out of swap space'
From: Yasuhiro KIMURA Subject: After update to r357104 build of poudriere jail fails with 'out of swap space' Date: Sat, 25 Jan 2020 23:43:28 +0900 (JST) > I use VirtualBox to run 13-CURRENT. Host is 64bit Windows 10 1909 and > spec of VM is as following. > > * 4 CPU > * 8GB memory > * 100GB disk > - 92GB ZFS pool (zroot) > - 8GB swap > > Today I updated this VM to r357104. And after that I tried to update > poudriere jail with `poudriere jail -u -j jailname -b`. But it failed > at install stage. After the failure I found following message is > written to syslog. > > Jan 25 19:18:25 rolling-vm-freebsd1 kernel: pid 7963 (strip), jid 0, uid 0, > was killed: out of swap space > > To make sure I shutdown both VM and host, restarted them and tried > update of jail again. Then the problem was reproduced. > > Does anybody else experience it? Thank you everyone for explanation, suggestion, advice and investigation about this problem, and sorry for late response. I couldn't handle this problem this week because H/W trouble happend to host machine last sunday. And while I waited for the host machine to finish repairing, the problem is fixed with r357253. So today I updated this VM to r357333 and confirmed update of poudriere jail succeed without error. But at the same time I faced a new kernel panic and am investigating which revision causes it. I will report this as a new matter. --- Yasuhiro KIMURA ___ 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: Is amd automount still supported in 13.0 or not?
From: Bob Willcox Subject: Is amd automount still supported in 13.0 or not? Date: Mon, 3 Feb 2020 17:23:33 -0600 > I've recently installed a 13.0 snapshot on one of my system to get some > experience with it > and am having trouble trying to setup the amd automount program. In fact, I > can't find amd > on this system. Has amd been removed and all we have for automatically > mounting > filesystems autofs? Amd is not build by default now and will be removed from base. But you can continue using it by installing sysutils/am-utils from port. --- Yasuhiro KIMURA ___ 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 panciks right after kernel load (r357966)
From: Lev Serebryakov Subject: CURRENT panciks right after kernel load (r357966) Date: Sat, 15 Feb 2020 20:54:15 +0300 > CURRENT r357966 on amd64, on host with 4G of memory (and Atom CPU) panics > with page fault right after kernel load (before any kernel output). I tried kernel update from r357653 to r357969 and boot completes successfully. My environment is guest of VirtualBox on Windows, 4 CPUs and 8GB of memory. And root is ZFS. --- Yasuhiro KIMURA ___ 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 panciks right after kernel load (r357966)
From: Lev Serebryakov Subject: Re: CURRENT panciks right after kernel load (r357966) Date: Sat, 15 Feb 2020 21:12:27 +0300 > I didn't update this "firmware" for almost a year, and don't have results > for revision between r349299 (works) and r357763 (panics). It is too much > for bi-sect :-( Then why don't you try FreeBSD snapshot? https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/13.0/ Currently there are r357276, r357606 and r357847 of boot images. If your H/W boots successfully with r357276 you can narrow range of bisect. --- Yasuhiro KIMURA ___ 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: r358062(ncurses) breaks installed ports, howto check?
From: "O. Hartmann" Subject: r358062(ncurses) breaks installed ports, howto check? Date: Mon, 24 Feb 2020 20:19:59 +0100 > After r358062, many installed ports do not work anymore on several running > systems (CURRENT). > /usr/src/UPDATING states one should reinstall all ncurses depending ports, > but no hint is > given! Can someone mitigate this lack of information? Is there a simple way > to check what > ports installed on a system rely on ncurses provided by the system? Check thread starting with following message. https://lists.freebsd.org/pipermail/freebsd-ports/2020-February/117710.html --- Yasuhiro KIMURA ___ 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"
`shutdown -p now` fails to power off with VirtualBox UEFI boot
I have VirtualBox VM running 13-CURRENT. In order to switch from legacy BIOS to UEFI I reinstalled OS by using FreeBSD-13.0-CURRENT-amd64-20200611-r362037-disc1.iso. After that `shutdow -p now` (or select 'ACPI shutdown' in VM menu) fails to power off. Shutdown itself completes successfully. But power off never happens and CPU usage keeps high until either closing or resetting VM. I reinstalled OS by using FreeBSD-13.0-CURRENT-amd64-20200618-r362292-disc1.iso but the problem still happens. If I switch back to legacy BIOS then the problem disappears. And it doesn't happen with either 11.4-RELEASE and 12.1-RELEASE. --- Yasuhiro KIMURA ___ 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: `shutdown -p now` fails to power off with VirtualBox UEFI boot
From: Yasuhiro KIMURA Subject: `shutdown -p now` fails to power off with VirtualBox UEFI boot Date: Fri, 19 Jun 2020 05:23:48 +0900 (JST) > I have VirtualBox VM running 13-CURRENT. In order to switch from > legacy BIOS to UEFI I reinstalled OS by using > FreeBSD-13.0-CURRENT-amd64-20200611-r362037-disc1.iso. After that > `shutdow -p now` (or select 'ACPI shutdown' in VM menu) fails to power > off. Shutdown itself completes successfully. But power off never > happens and CPU usage keeps high until either closing or resetting VM. > > I reinstalled OS by using > FreeBSD-13.0-CURRENT-amd64-20200618-r362292-disc1.iso but the problem > still happens. If I switch back to legacy BIOS then the problem > disappears. And it doesn't happen with either 11.4-RELEASE and > 12.1-RELEASE. I tried bisect and found this problem happens with r342108 and after. Commit message of r342108 says as following. yasu@rolling-vm-freebsd5[1012]% LANG=C svn log -c 342108 r342108 | cem | 2018-12-15 14:46:04 +0900 (Sat, 15 Dec 2018) | 7 lines efirt: When present, attempt to use EFI runtime services to shutdown PR: maybe related to 233998 (inconclusive at this time) Submitted by: byuu (previous version) Reviewed by:imp Differential Revision: https://reviews.freebsd.org/D18506 yasu@rolling-vm-freebsd5[1013]% Judging from it, I think it's very likely that this commit caused the problem. Then is there anything I can do for further investigation? --- Yasuhiro KIMURA ___ 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: `shutdown -p now` fails to power off with VirtualBox UEFI boot
From: Yasuhiro KIMURA Subject: Re: `shutdown -p now` fails to power off with VirtualBox UEFI boot Date: Mon, 22 Jun 2020 16:45:23 +0900 (JST) > I tried bisect and found this problem happens with r342108 and > after. Commit message of r342108 says as following. > > yasu@rolling-vm-freebsd5[1012]% LANG=C svn log -c 342108 > > r342108 | cem | 2018-12-15 14:46:04 +0900 (Sat, 15 Dec 2018) | 7 lines > > efirt: When present, attempt to use EFI runtime services to shutdown > > PR: maybe related to 233998 (inconclusive at this time) > Submitted by: byuu (previous version) > Reviewed by:imp > Differential Revision: https://reviews.freebsd.org/D18506 > > > yasu@rolling-vm-freebsd5[1013]% > > Judging from it, I think it's very likely that this commit caused the > problem. > > Then is there anything I can do for further investigation? I submitted this problem to Bugzilla. Bug 247474 - `shutdown -p now` fails to power off with VirtualBox UEFI boot https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247474 --- Yasuhiro KIMURA ___ 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: `shutdown -p now` fails to power off with VirtualBox UEFI boot
From: Warner Losh Subject: Re: `shutdown -p now` fails to power off with VirtualBox UEFI boot Date: Mon, 22 Jun 2020 08:57:24 -0600 > Does setting the tunable hw.efi.poweroff=0 help you? I add it to /boot/loader.conf and then `shutdown -p now` successfully powers off system. Does existence of this tunable mean that there are some UEFI implementations that have problem with power off functionality? (And VirtualBox is unfortunately one of such implementations?) --- Yasuhiro KIMURA ___ 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: `shutdown -p now` fails to power off with VirtualBox UEFI boot
From: Warner Losh Subject: Re: `shutdown -p now` fails to power off with VirtualBox UEFI boot Date: Mon, 22 Jun 2020 10:12:47 -0600 > I believe so. However, I've not dived deeply enough into this problem to > understand if it is a bug in our code or theirs. I got it. Thank you for reply. --- Yasuhiro KIMURA ___ 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"
Why ld-elf32.so.1 is included not in lib32.txz but in base.txz?
Hello. Let me assume I make clean install of 13-CURRENT amd64 by using latest snapshot install media (right now 20200730-r363681). At "Distribution Selection" stage I unselect "lib32". Then 32bit libraries are not installed after installation is completed. Next, I add 'WITHOUT_LIB32=yes' to /etc/src.conf, check out base source tree to /usr/src, cd there and execute 'make delete-old'. Then following files and directories are asked to be removed. /etc/mtree/BSD.lib32.dist /libexec/ld-elf32.so.1 /usr/lib32/libxo/encoder /usr/lib32/libxo /usr/lib32/i18n /usr/lib32/geom /usr/lib32/engines /usr/lib32/dtrace /usr/lib32 I accept to remove all of them and they are removed. After that I reboot system. Then it starts up without any error. Now I have one question. Why ld-elf32.so.1 is included not in lib32.txz but in base.txz? Is there any reason it is necessary when installing OS even if 32bit libraries aren't instlled? Best Regards. --- Yasuhiro KIMURA ___ 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"
Build of poudriere 13-CURRENT jail is failed
Hello, I made regular update of my 13-CUREENT amd64 environment from r365330 to r365634. Host OS is successfully updated with regular steps written in /usr/src/Makefile. But update of poudriere jail is failed with error. The jail was created with following command. % sudo -i poudriere jail -c -j curamd64 -m src=/usr0/freebsd/base/head -b So I updated it with following command. % sudo -i poudriere jail -u -j curamd64 -b And the update failed as follwoing. -- --- seed_cbc.po --- cc -target x86_64-unknown-freebsd13.0 --sysroot=/usr0/freebsd/base/obj/usr/local/poudriere/jails/curamd64/usr/src/amd64.amd64/tmp -B/usr0/freebsd/base/obj/usr/local/poudriere/jails/curamd64/usr/src/amd64.amd64/tmp/usr/bin -pg -O2 -pipe -fno-common -I/usr/local/poudriere/jails/curamd64/usr/src/crypto/openssl -I/usr/local/poudriere/jails/curamd64/usr/src/crypto/openssl/crypto/include -I/usr/local/poudriere/jails/curamd64/usr/src/crypto/openssl/include -DL_ENDIAN -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/etc/ssl\"" -DENGINESDIR="\"/usr/lib/engines\"" -DNDEBUG -I/usr/local/poudriere/jails/curamd64/usr/src/crypto/openssl/crypto -I/usr/local/poudriere/jails/curamd64/usr/src/crypto/openssl/crypto/ec/curve448 -I/usr/local/poudriere/jails/curamd64/usr/s rc/crypto/openssl/crypto/ec/curve448/arch_32 -I/usr/local/poudriere/jails/curamd64/usr/src/crypto/openssl/crypto/modes -I/usr0/freebsd/base/obj/usr/local/poudriere/jails/curamd64/usr/src/amd64.amd64/secure/lib/libcrypto -g -MD -MF.depend.seed_cbc.po -MTseed_cbc.po -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments-c /usr/local/poudriere/jails/curamd64/usr/src/crypto/openssl/crypto/seed/seed_cbc.c -o seed_cbc.po --- all_subdir_lib --- --- acl_copy_entry.3.gz --- gzip -cn /usr/local/poudriere/jails/curamd64/usr/src/lib/libc/posix1e/acl_copy_entry.3 > acl_copy_entry.3.gz --- acl_create_entry.3.gz --- gzip -cn /usr/local/poudriere/jails/curamd64/usr/src/lib/libc/posix1e/acl_create_entry.3 > acl_create_entry.3.gz --- all_subdir_stand --- cp: /dev/null: Invalid argument *** [beforedepend] Error code 1 make[4]: stopped in /usr/local/poudriere/jails/curamd64/usr/src/stand/libsa --- all_subdir_lib --- --- all_subdir_secure --- --- all_subdir_share --- [01:31:23] Error: Failed to 'make buildworld' yasu@rolling-vm-freebsd1[1004]% ------ What is wrong? --- Yasuhiro KIMURA ___ 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: Build of poudriere 13-CURRENT jail is failed
From: Michael Gmelin Subject: Re: Build of poudriere 13-CURRENT jail is failed Date: Fri, 11 Sep 2020 22:16:56 +0200 >> I made regular update of my 13-CUREENT amd64 environment from r365330 >> to r365634. Host OS is successfully updated with regular steps written >> in /usr/src/Makefile. But update of poudriere jail is failed with >> error. > > Please see: https://reviews.freebsd.org/D26395 Thank you for quick reply. Then I'll wait until this review is committed. --- Yasuhiro KIMURA ___ 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: Build of poudriere 13-CURRENT jail is failed
From: Alan Somers Subject: Re: Build of poudriere 13-CURRENT jail is failed Date: Fri, 11 Sep 2020 14:50:39 -0600 > Done. Thank you. I updated host OS to r365643 and now update of poudriere jail finished successfully. BTW there is an advice for those who faced same problem as me. After source tree is updated to r365643 or later, take following steps at first. # cd /usr/src/bin/cp # make # make install Otherwise `make buildworld` fails with same error as that of update of poudriere jail. --- Yasuhiro KIMURA ___ 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: Problem compiling world amd64
From: Filippo Moretti Subject: Problem compiling world amd64 Date: Fri, 18 Sep 2020 07:57:40 + (UTC) > [filippo@sting ~]$ uname -a > FreeBSD sting 13.0-CURRENT FreeBSD 13.0-CURRENT #11 r365578: Thu Sep 10 > 19:38:51 CEST 2020 root@sting:/usr/obj/usr/src/amd64.amd64/sys/STING > amd64 > (snip) > --- beforedepend --- > mkdir -p xlocale arpa; for i in a.out.h assert.h elf.h limits.h nlist.h > setjmp.h stddef.h stdbool.h string.h strings.h time.h unistd.h uuid.h; do ln > -sf /usr/src/include/$i $i; done; ln -sf > /usr/src/sys/amd64/include/stdarg.h stdarg.h; ln -sf > /usr/src/sys/sys/errno.h errno.h; ln -sf /usr/src/sys/sys/stdint.h stdint.h; > ln -sf /usr/src/include/arpa/inet.h arpa/inet.h; ln -sf > /usr/src/include/arpa/tftp.h arpa/tftp.h; for i in _time.h _strings.h > _string.h; do [ -f  xlocale/$i ] || cp /dev/null xlocale/$i; done; for i > in ctype.h fcntl.h signal.h stdio.h stdlib.h; do ln -sf > /usr/src/stand/libsa/stand.h $i; done > cp: /dev/null: Invalid argument > *** [beforedepend] Error code 1 > > make[4]: stopped in /usr/src/stand/libsa > --- all_subdir_secure --- > --- all_subdir_share --- > --- all_subdir_lib --- > > The error is recurringFilippo 1. Update source tree to r365643 or later. 2. cd /usr/src/bin/cp 3. make 4. make install 5. cd /usr/src 6. make buildworld --- Yasuhiro KIMURA ___ 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"
Building packages with poudriere fails after `zfs upgrade`
Hello, I tried `zfs upgrade zroot` on my 13-CURRENT r366977 host and after that building packages with poudriere fails as following. [00:04:55] [02] [00:00:00] Building security/libtasn1 | libtasn1-4.16.0 [00:05:10] [02] [00:00:15] Finished security/libtasn1 | libtasn1-4.16.0: Success [00:05:10] [02] [00:00:00] Building devel/libunistring | libunistring-0.9.10_1 cannot rollback 'zroot/poudriere/jails/curamd64-original-ref/02': dataset is busy [00:05:11] [02] [00:00:01] Error: Unable to rollback zroot/poudriere/jails/curamd64-original-ref/02 to prepkg =>> Error: Unable to rollback zroot/poudriere/jails/curamd64-original-ref/02 to prepkg How should I fix it? Best Regards. --- Yasuhiro KIMURA ___ 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: Building packages with poudriere fails after `zfs upgrade`
From: Samy Mahmoudi Subject: Re: Building packages with poudriere fails after `zfs upgrade` Date: Thu, 29 Oct 2020 20:54:13 -0400 > Have you tried to work around the issue by creating a new jail with > poudriere, > or even by changing the value of ZROOTFS in poudriere.conf ? Thanks for suggestion. But I already fixed the problem by making clean install of base system with latest snapshot. --- Yasuhiro KIMURA ___ 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"
Fails to load linprocfs
Hello, I updated both host and poudriere jail from r367172 to r367418. But after that `poudriere bulk` fails as following. -- yasu@rolling-vm-freebsd1[1014]% uname -a FreeBSD rolling-vm-freebsd1.home.utahime.org 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r367418: Sat Nov 7 02:00:32 JST 2020 ro...@rolling-vm-freebsd1.home.utahime.org:/usr0/freebsd/base/obj/usr0/freebsd/base/head/amd64.amd64/sys/GENERIC amd64 yasu@rolling-vm-freebsd1[1014]% sudo -i poudriere bulk -j curamd64 -z LocalSetting -f /usr/local/etc/ports-list.txt kldload: an error occurred while loading module linprocfs. Please check dmesg(8) for more details. [00:00:00] Error: Required kernel module 'linprocfs' not found yasu@rolling-vm-freebsd1[1015]% -- Executing `sudo -i kldload linprocfs.ko` results in same error. -- yasu@rolling-vm-freebsd1[1016]% sudo -i kldload linprocfs.ko kldload: an error occurred while loading module linprocfs.ko. Please check dmesg(8) for more details. yasu@rolling-vm-freebsd1[1017]% -- dmesg(8) shows following error messages. -- link_elf_obj: symbol sdt_provider_linuxulator undefined linker_load_file: /boot/kernel/linux_common.ko - unsupported file type KLD linprocfs.ko: depends on linux_common - not available or version mismatch linker_load_file: /boot/kernel/linprocfs.ko - unsupported file type -- What's wrong? Best Regards. --- Yasuhiro KIMURA ___ 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: Fails to load linprocfs
From: Yasuhiro KIMURA Subject: Fails to load linprocfs Date: Sat, 07 Nov 2020 05:11:20 +0900 (JST) > I updated both host and poudriere jail from r367172 to r367418. But > after that `poudriere bulk` fails as following. > (snip) > > What's wrong? Two people told me following bug report by private mail. linux_common fails to load as a module after r367395: link_elf_obj: symbol sdt_provider_linuxulator undefined https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250897 Just FYI. --- Yasuhiro KIMURA ___ 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: svn.freebsd.org
From: Cy Schubert Subject: svn.freebsd.org Date: Wed, 11 Nov 2020 10:20:55 -0800 > I've noticed that svn.freebsd.org has been lagging with commits from > repo.freebsd.org. Is this a change or is there something broken? (I use > svn.freebsd.org as the source of truth at $JOB.) > > At the moment svn.freebsd.org is at r367589 while repo.freebsd.org is at > r367596. Not only src but also ports has been lagging. Currently https://svn.freebsd.org/ports/ is r554896 but I received commit message of r554908 from svn-ports-all ML. Also this is not first time. Though I can't remember exactly when, similar situation happened within a week. --- Yasuhiro KIMURA ___ 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: svn.freebsd.org
At first, lagging has disappeared now. From: "Bjoern A. Zeeb" Subject: Re: svn.freebsd.org Date: Wed, 11 Nov 2020 19:12:06 + > svn.freebsd.org is geolocated imho; so unless you’ll tell people to > which IPv6/IPv4 address you are connecting it’ll be harder to track > this down if it is not all mirrors. I use 192.50.199.249. But svnweb.freebsd.org had also been lagging. So It doesn't seem the problem was specific to one mirror. --- Yasuhiro KIMURA ___ 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: Shutdown errors and timeout
From: Johan Hendriks
Subject: Shutdown errors and timeout
Date: Fri, 13 Nov 2020 11:35:53 +0100
> Hello all, i have two FreeBSD 13 machines, one is a bare metal and one
> is virtualbox machine which i both update about once a week.
>
> The vritual machine seems to fail stopping something and gives a
> timeout after 90 sec.
>
> The console ends with
>
> Writing entropy file: .
> Writing early boot entropy file: .
>
> 90 second watchdog timeout expired. Shutdown terminated.
> Fri Nov13 11:20:40 CEST 2020
> Nov 13 11:20:40 test-head init[1]: /etc/rc.shutdown terminated
> abnormally, going to single user mode
> ...
>
> On the bare metal machine i see the following.
> Writing entropy file: .
> Writing early boot entropy file: .
> cannot unmount '/var/run': umount failed
> cannot unmount '/var/log': umount failed
> cannot unmount '/var': umount failed
> cannot unmount '/usr/home': umount failed
> cannot unmount '/usr': umount failed
> cannot unmount '/': umount failed
>
(snip)
>
> The pools have not been upgraded after the latest openzfs import,
> maybe that is related?
>
> FreeBSD test-freebsd-head 13.0-CURRENT FreeBSD 13.0-CURRENT #2
> r367585:
>
> First thing i noticed is about a week ago.
I'm facing same problem with 13.0-CURRENT amd64 r367487 and
virtualbox. In my case I use autofs to mount remote file system of
12.2-RELEASE amd64 server with NFSv4. When there is still filesystem
mounted by autofs, then watchdog timeout happens while shutdown. The
watchdog timeout can be worked around by executing `automount -fu`
before shutting down. But 'cannot unmount ...' error messages are
still displayed.
I added 'rc_debug="YES"' to /etc/rc.conf and checked which rc script
causes this message. Then it is displayed when following `zfs_stop`
function of /etc/rc.d/zfs is executed.
--
zfs_stop_main()
{
zfs unshare -a
zfs unmount -a
}
--
At this point syslog process still running and it opens some files
under /var/log. So it make sence that `zfs unmount -a` results in the
message.
Probably order of executing each rc script in shutdown time should be
changed so `/etc/rc.d/zfs faststop` is executed after all processes
other than `init' are exited.
---
Yasuhiro KIMURA
___
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: /etc/os-release isn't created
Dear Committers, From: Yasuhiro KIMURA Subject: Re: /etc/os-release isn't created Date: Wed, 22 Jan 2020 15:56:54 +0900 (JST) > I created patch adding logic that handles symbolik link to mergemaster > and submitted it to following bug report. > > Bug 242212 usr.sbin/mergemaster/mergemaster.sh: There is no logic to handle > symbolic > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242212 > > So please review and/or test it. Would someone please commit it? As is explained currently mergemaster doesn't handle symbolic links. And it causes that /etc/os-release symbolink link isn't created when it doesn't exit before upgrade and you upgrade base system with steps described in /usr/src/Makefile. It happens such cases as following. * 13-CURRENT before r354922 -> 13-CURRENT r354922 or later * 12.1-RELEASE -> 12.2-RELEASE * 11.4-RELEASE -> 12.2-RELEASE Best Regards. --- Yasuhiro KIMURA ___ 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: poudriere && moving from svn to git for downloading source
From: Matthias Apitz Subject: poudriere && moving from svn to git for downloading source Date: Thu, 7 Jan 2021 09:27:59 +0100 > > Hello, > > I use poudriere to compile my used ports. Could someone please explain > or point me to a document which explains the now to be used syntax to > create (i.e. checkout) the jail and the ports tree. Actually I'm using > something like: > > # poudriere jail -c -j freebsd-r368166 -m svn+http -v head@r368166 > > or > > # poudriere jail -c -j freebsd-head -m svn+http > > and for the ports tree > > # poudriere ports -c -p ports-20201130 -m svn -U svn://svn.freebsd.org/ports/ > > Thanks > > matthias At first I don't necessarily recommend it. But you can use following steps. 1. Clone src repository somewhere you prefer git clone https://git.freebsd.org/src.git /somewhere/you/want/to/chechout 2. Build poudriere jail with source tree checked out at step 1 poudriere jail -c jailname -m src=/somewhere/you/want/to/chechout -b Then you can update jail to any commit hash with following command. git -C /somewhere/you/want/to/chechout checkout (hash value you want to use) poudriere jail -u -j jailname -b --- Yasuhiro Kimura ___ 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: Waiting for bufdaemon
From: Jakob Alvermark Subject: Waiting for bufdaemon Date: Fri, 15 Jan 2021 11:26:47 +0100 > When rebooting my thinkpad the 'bufdaemon' times out: > > Waiting (max 60 seconds) for system thread 'bufdaemon' to stop > ... timed out > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to stop > ... timed out > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to stop > ... timed out > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to stop > ... timed out > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to stop > ... timed out > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to stop > ... timed out > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to stop > ... timed out > > > This started happening recently (within the last week I think). > > > Any ideas? I have been experiencing same problem with my 13-CURRENT amd64 VirtualBox VM for about a month. The conditions that the problem happens are unclear and all what I can say is * It happens only after I login in the VM and do something for a while. If I boot the VM and shut it down immediately, it never happens. * When the problem happens, one or more unkillable processes seem to be left. --- Yasuhiro Kimura ___ 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: Waiting for bufdaemon
From: Yasuhiro Kimura Subject: Re: Waiting for bufdaemon Date: Fri, 15 Jan 2021 20:10:30 +0900 (JST) > I have been experiencing same problem with my 13-CURRENT amd64 > VirtualBox VM for about a month. The conditions that the problem > happens are unclear and all what I can say is > > * It happens only after I login in the VM and do something for a > while. If I boot the VM and shut it down immediately, it never > happens. > * When the problem happens, one or more unkillable processes seem to > be left. CPU of my host is not AMD but Intel. According to the /var/run/dmesg.boot of VM, information of CPU is as following. CPU: Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz (3000.09-MHz K8-class CPU) Origin="GenuineIntel" Id=0x906ed Family=0x6 Model=0x9e Stepping=13 Features=0x1783fbff Features2=0x5eda2203 AMD Features=0x28100800 AMD Features2=0x121 Structured Extended Features=0x842421 Structured Extended Features3=0x3400 IA32_ARCH_CAPS=0x29 TSC: P-state invariant Just FYI. --- Yasuhiro Kimura ___ 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: WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0.
From: Mark Millard
Subject: Re: WARNING: Device "kbd" is Giant locked and may be deleted before
FreeBSD 13.0.
Date: Fri, 15 Jan 2021 16:54:26 -0800
> Other examples for the general type of question . . .
>
>
> For example, various aarch64, armv7, and powerpc*:
>
> WARNING: Device "openfirm" is Giant locked and may be deleted before
> FreeBSD 13.0.
>
>
> RPi4B and RPi3B:
>
> WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD 13.0.
>
>
> powerpc (old PowerMac G4):
>
> WARNING: Device "agp" is Giant locked and may be deleted before FreeBSD
> 13.0.
>
> WARNING: Device "consolectl" is Giant locked and may be deleted before
> FreeBSD 13.0.
>
>
> Note: FreeBSD has boot problems for various powerpc64 and 32-bit
> powerpc PowerMacs, so some material is from somewhat older vintages
> of 13. (I've not looked at the old PowerMac G3 at all for this.)
Following files are the source of this warning messages.
yasu@rolling-vm-freebsd1[1009]% git grep -F D_NEEDGIANT
sys/cam/scsi/scsi_target.c: .d_flags = D_NEEDGIANT,
sys/contrib/ipfilter/netinet/mlfk_ipl.c:.d_flags = 0, /*
D_NEEDGIANT - Should be SMP safe */
sys/dev/adlink/adlink.c:.d_flags = D_NEEDGIANT,
sys/dev/agp/agp.c: .d_flags = D_NEEDGIANT,
sys/dev/amr/amr.c: .d_flags = D_NEEDGIANT,
sys/dev/atkbdc/psm.c: .d_flags = D_NEEDGIANT,
sys/dev/ce/if_ce.c: .d_flags= D_NEEDGIANT,
sys/dev/fb/fb.c:.d_flags = D_NEEDGIANT,
sys/dev/fb/fbd.c: .d_flags = D_NEEDGIANT,
sys/dev/kbd/kbd.c: .d_flags = D_NEEDGIANT,
sys/dev/ofw/openfirmio.c: .d_flags = D_NEEDGIANT,
sys/dev/ofw/openpromio.c: .d_flags = D_NEEDGIANT,
sys/dev/pbio/pbio.c:.d_flags = D_NEEDGIANT,
sys/dev/speaker/spkr.c: .d_flags = D_NEEDGIANT,
sys/dev/syscons/syscons.c: .d_flags = D_NEEDGIANT | D_TRACKCLOSE,
sys/dev/tdfx/tdfx_pci.c:.d_flags = D_NEEDGIANT,
sys/dev/tpm/tpm.c: .d_flags = D_NEEDGIANT,
sys/dev/vkbd/vkbd.c:.d_flags = D_NEEDGIANT | D_NEEDMINOR,
sys/i386/bios/smapi.c: .d_flags = D_NEEDGIANT,
sys/i386/i386/elan-mmcr.c: .d_flags = D_NEEDGIANT,
sys/i386/i386/perfmon.c:.d_flags = D_NEEDGIANT,
sys/isa/vga_isa.c: .d_flags = D_NEEDGIANT,
sys/kern/kern_conf.c: if (devsw->d_flags & D_NEEDGIANT) {
sys/kern/kern_conf.c: if (devsw->d_flags & D_NEEDGIANT) {
sys/kern/kern_conf.c: } else if (devsw->d_flags & D_NEEDGIANT)
\
sys/sys/conf.h:#define D_NEEDGIANT 0x0040 /* driver want Giant */
yasu@rolling-vm-freebsd1[1010]%
---
Yasuhiro Kimura
___
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: Waiting for bufdaemon
From: Konstantin Belousov Subject: Re: Waiting for bufdaemon Date: Sun, 17 Jan 2021 11:49:40 +0200 > I am working on it, no ETA. > > Interesting point would be to check on machines of other testers, > if the following hides the problem. I tried this patch but unfortunately the problem still happens with my environment. --- Yasuhiro Kimura ___ 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: Which branch in git is 13.0-current?
From: Malcolm Matalka Subject: Re: Which branch in git is 13.0-current? Date: Sat, 23 Jan 2021 18:16:21 +0100 >> Build pkg from ports or wait a bit till the clusters have caught up building >> the packages with the base version change. > > Does that mean CURRENT is now 14.0? I must have missed the > announcement. https://lists.freebsd.org/pipermail/dev-commits-src-all/2021-January/001588.html --- Yasuhiro Kimura ___ 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: Getting /usr/src to match specific git hash?
From: Steve Kargl Subject: Getting /usr/src to match specific git hash? Date: Sat, 23 Jan 2021 19:58:52 -0800 > Suppose one has an empty /usr/src. > > Suppose further that one had to re-install a 32-bit > i386-*-freebsd with the 24 Dec 2020 image available > from freebsd.org. > > uname -a for the booted kernel shows > > % uname -a > FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT #0 \ > 3cc0c0d66a0-c255241(main)-dirty: Thu Dec 24 05:43:23 UTC 2020 \ > r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/i386.i386/sys/GENERIC i386 > > How does one use git to pull the exact sources that match > this specifc kernel? cd /usr git clone https://git.freebsd.org/src.git cd src git checkout 3cc0c0d66a0 --- Yasuhiro Kimura ___ 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: pkg for 14-current
From: Masachika ISHIZUKA Subject: pkg for 14-current Date: Sun, 24 Jan 2021 19:11:28 +0900 (JST) > Hi. > > I updated to 14-current from 13-current and reinstalled ports-mgmt/pkg. > I cannot get meta files for 14-current. > How can I use pkg on 14-current ? > >> # pkg update >> Updating FreeBSD repository catalogue... >> pkg: http://pkgmir.geo.freebsd.org/FreeBSD:14:amd64/latest/meta.txz: Not >> Found >> repository FreeBSD has no meta file, using default settings >> pkg: http://pkgmir.geo.freebsd.org/FreeBSD:14:amd64/latest/packagesite.txz: >> Not Found >> Unable to update repository FreeBSD >> Error updating repositories! All what you can do is to wait until build of offical packages for 14-CURRENT has completed unless you build them by yourself. --- Yasuhiro Kimura ___ 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: pkg for 14-current
From: Yasuhiro Kimura Subject: Re: pkg for 14-current Date: Sun, 24 Jan 2021 19:18:29 +0900 (JST) >> I updated to 14-current from 13-current and reinstalled ports-mgmt/pkg. >> I cannot get meta files for 14-current. >> How can I use pkg on 14-current ? >> > All what you can do is to wait until build of offical packages for > 14-CURRENT has completed unless you build them by yourself. By the way, when -CURRENT was bumped from 12 to 13, there were some ports that failed to be built on 13-CURRENT simply because they don't expect there is version 13.x of FreeBSD. And probably such ports fails to be built on 14-CURRENT with same reason. So it may takes for a while until offical packages for 14-CURRENT are provided with same level as 13-CURRENT. --- Yasuhiro Kimura ___ 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: Getting /usr/src to match specific git hash?
From: "Simon J. Gerraty" Subject: Re: Getting /usr/src to match specific git hash? Date: Sun, 24 Jan 2021 10:05:38 -0800 > As others have described, you can clone and 'git checkout 3cc0c0d66a0' > but that "-dirty" above implies the tree had changes, so you cannot > reproduce "the exact sources". There was bug in sys/conf/newvers.sh that reports the result of dirtyness check in reverse. It was introduced at commit 029ca1842fa on 2002/12/17 and fixed at commit 17eba5e32a2 on 2020/12/23. And commit 3cc0c0d66a0 is between them. So in this case "3cc0c0d66a0-c255241(main)-dirty" means there isn't any change in src tree. Just FYI. --- Yasuhiro Kimura ___ 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: pkg for 14-current
From: Mark Linimon Subject: Re: pkg for 14-current Date: Mon, 25 Jan 2021 03:41:26 + > On Sun, Jan 24, 2021 at 07:45:08PM +0900, Yasuhiro Kimura wrote: >> By the way, when -CURRENT was bumped from 12 to 13, there were some >> ports that failed to be built on 13-CURRENT simply because they don't >> expect there is version 13.x of FreeBSD. And probably such ports fails >> to be built on 14-CURRENT with same reason. So it may takes for a >> while until offical packages for 14-CURRENT are provided with same >> level as 13-CURRENT. > > Do you remember which they were, please? What I can remember are mail/postfix and sysutils/lsof. I've been using them and when -CURRENT was bumped from 12 to 13 they were broken with -CURRENT for a while. And at that time I also saw some other ports were updated with the commit message such as "Fix build with 13-CURRENT" on FreshPorts but I don't remember what they were. --- Yasuhiro Kimura ___ 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: using git to get a particular version of src
From: Chris Subject: Re: using git to get a particular version of src Date: Mon, 25 Jan 2021 09:21:44 -0800 >> Hi, >> I have this version installed: >> 13.0-CURRENT #0 2ed50808d2b-c254384(main): Thu Nov 12 10:03:35 UTC >> 2020 >> I'd like to get the sources for this (want to make a no-debug kernel) >> as I know >> this version works on this hardware. >> But -current has gone to 14 and what was -current is now >> 13-stable. What git >> incantation is required to get 2ed50808d2b-c254384 sources, given an >> empty >> /usr/src and git method of ssh://anon...@git.freebsd.org ? > I am by *no* means a GIT expert > but will > cd /usr/src > git up 2ed50808d2b > accomplish your intended task? Unfortunately it doesn't work as is expected in this case because hashes of src repostory changed on Dec 6 when it was still beta. HEADS UP: src hashes will respin/change this Sunday https://lists.freebsd.org/pipermail/freebsd-git/2020-December/000548.html In original case it was after this change so hash value can be used to checkout it. But this case is befere hash change. So there isn't hash 2ed50808d2b in current src repository any more. I also faced this problem when I tried to checkout source tree that corresponds to 20201119 snapshot of 13-CURRENT. Fortunately I still kept ISO image of it. So I did following steps to get the source tree. 1. Mount the ISO image 2. Extract src.txz in the ISO image to somewhere (e.g. /tmp/usr/src) 3. cd /usr 4. git clone https://git.freebsd.org/src.git 5. cd src 6. Checkout 65c207758a9 that was committed at Thu Nov 19 21:10:36 2020 + (the last one committed on Nov 19, 2020) 7. diff -ru /tmp/usr/src /usr/src 8. If there are any differences, checkout f9fe7b28bc2 that is just previous commit of 65c207758a9 9. Repeat step 7 and 8 until there is no difference between /tmp/usr/src and /usr/src. --- Yasuhiro Kimura ___ 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: Waiting for bufdaemon
From: Yasuhiro Kimura Subject: Re: Waiting for bufdaemon Date: Sat, 16 Jan 2021 04:03:23 +0900 (JST) > From: Yasuhiro Kimura > Subject: Re: Waiting for bufdaemon > Date: Fri, 15 Jan 2021 20:10:30 +0900 (JST) > >> I have been experiencing same problem with my 13-CURRENT amd64 >> VirtualBox VM for about a month. The conditions that the problem >> happens are unclear and all what I can say is >> >> * It happens only after I login in the VM and do something for a >> while. If I boot the VM and shut it down immediately, it never >> happens. >> * When the problem happens, one or more unkillable processes seem to >> be left. > > CPU of my host is not AMD but Intel. According to the > /var/run/dmesg.boot of VM, information of CPU is as following. > > CPU: Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz (3000.09-MHz K8-class CPU) > Origin="GenuineIntel" Id=0x906ed Family=0x6 Model=0x9e Stepping=13 > > Features=0x1783fbff > > Features2=0x5eda2203 > AMD Features=0x28100800 > AMD Features2=0x121 > Structured Extended > Features=0x842421 > Structured Extended Features3=0x3400 > IA32_ARCH_CAPS=0x29 > TSC: P-state invariant > > Just FYI. It took for a while to investigate, but according to the result of bisect following commit is the source of problem in my case. -- commit 84eaf2ccc6a Author: Konstantin Belousov Date: Mon Dec 21 19:02:31 2020 +0200 x86: stop punishing VMs with low priority for TSC timecounter I suspect that virtualization techniques improved from the time when we have to effectively disable TSC use in VM. For instance, it was reported (complained) in https://github.com/JuliaLang/julia/issues/38877 that FreeBSD is groundlessly slow on AWS with some loads. Remove the check and start watching for complaints. Reviewed by:emaste, grehan Discussed with: cperciva Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D27629 ------ I confirmed the problem still happens with 5c325977b11 but reverting above commit fixes it. --- Yasuhiro Kimura ___ 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: Waiting for bufdaemon
From: Yasuhiro Kimura Subject: Re: Waiting for bufdaemon Date: Thu, 28 Jan 2021 05:02:42 +0900 (JST) > It took for a while to investigate, but according to the result of > bisect following commit is the source of problem in my case. > > -- > commit 84eaf2ccc6a > Author: Konstantin Belousov > Date: Mon Dec 21 19:02:31 2020 +0200 > > x86: stop punishing VMs with low priority for TSC timecounter > > I suspect that virtualization techniques improved from the time when we > have to effectively disable TSC use in VM. For instance, it was reported > (complained) in https://github.com/JuliaLang/julia/issues/38877 that > FreeBSD is groundlessly slow on AWS with some loads. > > Remove the check and start watching for complaints. > > Reviewed by:emaste, grehan > Discussed with: cperciva > Sponsored by: The FreeBSD Foundation > Differential Revision: https://reviews.freebsd.org/D27629 > -- > > I confirmed the problem still happens with 5c325977b11 but reverting > above commit fixes it. I submitted this problem to Bugzilla. Timeout of bufdaemon happens at shutdown time with -CURRENT amd64 and VirtulaBox VM https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253087 --- Yasuhiro Kimura ___ 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"
Failure of release build with release.sh on 14-CURRENT amd64
Hello, I tried release build with /usr/src/release/release.sh on 14-CURRENT amd64 under followin conditions. * 14-CURRENT amd64 * f17fc5439f5 + revert of 84eaf2ccc6a (Workaroud of the problem reported as bug 253087 on Bugzilla) * No release.conf, everithing is default * /scratch is empty when build starts * /scratch/usr/doc is ba0831043d of main * /scratch/usr/ports is r563439 of head * /scratch/usr/src is 151ec796a23 of main * devel/git is installed but devel/subversion isn't And the result is failure with following error messages. -- cd /usr/doc/en_US.ISO8859-1/htdocs/releases/14.0R && env MAN4DIR=/usr/src/release/../share/man/man4 _BRANCH=CURRENT make all install clean "FORMATS=html txt" INSTALL_COMPRESSED='' URLS_ABSOLUTE=YES DOCDIR=/usr/obj/usr/src/amd64.amd64/ release/rdoc WEBDIR=/usr/doc DESTDIR=/usr/obj/usr/src/amd64.amd64/release/rdoc cd: /usr/doc/en_US.ISO8859-1/htdocs/releases/14.0R: No such file or directory *** Error code 2 Stop. make[1]: stopped in /usr/src/release *** Error code 1 Stop. make: stopped in /usr/src/release -- Full buld log is https://www.utahime.org/FreeBSD/release.sh.2021-01-31-09-10-35.log (Caution: Size of the file is about 75MB) Does this mean that release.sh is simply broken right now or I did something wrong? Best Regards. --- Yasuhiro Kimura ___ 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"
Setting for displaying utf8 characters on all vt consoles results in panic on 14-CURRENT and 13.0-ALPHA3
To display utf8 characters on all vt console I did following settings. 1. Download GNU Unifont BDF file (http://unifoundry.com/pub/unifont/unifont-13.0.05/font-builds/unifont-13.0.05.bdf.gz) 2. gunzip unifont-13.0.05.bdf.gz 3. vtfontcvt unifont-13.0.05.bdf unifont.fnt 4. cp unifont.fnt /usr/share/vt/fonts 5. Add 'allscreens_flags="-f 8x16 unifont.fnt"' to /etc/rc.conf 6. Add 'hw.vga.textmode=0' to /boot/loader.conf.local 7. shutdown -r now On 12.2-RELEASE and 11.4-RELEASE it works as is expected. But on 14-CURRENT(man) and 13.0-ALPHA3(stable/13) it result in kernel panic. Screen shot of 14-CURRENT. https://www.utahime.org/FreeBSD/panic.20210201.14-CURRENT.png 14-CURRENT(main): yasu@rolling-vm-freebsd1[1006]% uname -a FreeBSD rolling-vm-freebsd1.home.utahime.org 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n244517-f17fc5439f5: Mon Feb 1 10:55:51 JST 2021 ro...@rolling-vm-freebsd1.home.utahime.org:/usr0/freebsd/src/obj/usr0/freebsd/src/git/amd64.amd64/sys/GENERIC amd64 13.0-ALPHA3(stable/13): yasu@rolling-vm-freebsd5[1005]% uname -a FreeBSD rolling-vm-freebsd5.home.utahime.org 13.0-ALPHA3 FreeBSD 13.0-ALPHA3 #0 stable/13-c256214-g40cb0344eb2: Mon Feb 1 11:30:28 JST 2021 ro...@rolling-vm-freebsd5.home.utahime.org:/usr0/freebsd/src/obj/usr0/freebsd/src/git/amd64.amd64/sys/GENERIC amd64 --- Yasuhiro Kimura ___ 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: Setting for displaying utf8 characters on all vt consoles results in panic on 14-CURRENT and 13.0-ALPHA3
From: Yasuhiro Kimura Subject: Setting for displaying utf8 characters on all vt consoles results in panic on 14-CURRENT and 13.0-ALPHA3 Date: Mon, 01 Feb 2021 11:41:35 +0900 (JST) > To display utf8 characters on all vt console I did following settings. > > 1. Download GNU Unifont BDF file > > (http://unifoundry.com/pub/unifont/unifont-13.0.05/font-builds/unifont-13.0.05.bdf.gz) > 2. gunzip unifont-13.0.05.bdf.gz > 3. vtfontcvt unifont-13.0.05.bdf unifont.fnt > 4. cp unifont.fnt /usr/share/vt/fonts > 5. Add 'allscreens_flags="-f 8x16 unifont.fnt"' to /etc/rc.conf > 6. Add 'hw.vga.textmode=0' to /boot/loader.conf.local > 7. shutdown -r now > > On 12.2-RELEASE and 11.4-RELEASE it works as is expected. But on > 14-CURRENT(man) and 13.0-ALPHA3(stable/13) it result in kernel panic. > > Screen shot of 14-CURRENT. > https://www.utahime.org/FreeBSD/panic.20210201.14-CURRENT.png > > 14-CURRENT(main): > yasu@rolling-vm-freebsd1[1006]% uname -a > FreeBSD rolling-vm-freebsd1.home.utahime.org 14.0-CURRENT FreeBSD > 14.0-CURRENT #0 main-n244517-f17fc5439f5: Mon Feb 1 10:55:51 JST 2021 > ro...@rolling-vm-freebsd1.home.utahime.org:/usr0/freebsd/src/obj/usr0/freebsd/src/git/amd64.amd64/sys/GENERIC > amd64 > > 13.0-ALPHA3(stable/13): > yasu@rolling-vm-freebsd5[1005]% uname -a > FreeBSD rolling-vm-freebsd5.home.utahime.org 13.0-ALPHA3 FreeBSD 13.0-ALPHA3 > #0 stable/13-c256214-g40cb0344eb2: Mon Feb 1 11:30:28 JST 2021 > ro...@rolling-vm-freebsd5.home.utahime.org:/usr0/freebsd/src/obj/usr0/freebsd/src/git/amd64.amd64/sys/GENERIC > amd64 I submitted this problem to Bugzilla. Bug 253147 - Setting for displaying utf8 characters on all vt consoles results in panic on 14-CURRENT and 13.0-ALPHA3 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253147 --- Yasuhiro Kimura ___ 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: Setting for displaying utf8 characters on all vt consoles results in panic on 14-CURRENT and 13.0-ALPHA3
From: Toomas Soome via freebsd-current Subject: Re: Setting for displaying utf8 characters on all vt consoles results in panic on 14-CURRENT and 13.0-ALPHA3 Date: Tue, 2 Feb 2021 00:35:49 +0200 > Should be fixed on current now. Confirmed. Would you please MFC to stable/13? Best Regards. --- Yasuhiro Kimura ___ 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: Failure of release build with release.sh on 14-CURRENT amd64
From: Glen Barber Subject: Re: Failure of release build with release.sh on 14-CURRENT amd64 Date: Mon, 1 Feb 2021 21:26:23 + > Setting NODOC=1 should workaround the problem for now, Thanks, Release build successfully completed with it. > until the > conversion from XML to ASCIIDoc/Hugo is 100% complete. (It is > effectively complete, but there are a few nits here and there that need > to be resolved.) I got it. Since textproj/docproj is meta port, it also need to be updated to depend on new required tools. --- Yasuhiro Kimura ___ 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: Failure of release build with release.sh on 14-CURRENT amd64
It's a bit off topic from the first question, but please let me ask another one. When everything is default, devel/git and textproc/docproj are installed in chroot environment after building userland and installing it to chroot has completed. While the former is installed by using official package, the latter is installed by using ports tree checked out in chroot. Then is there any reason doing so? Why aren't both of them installed by using offical package nor by using ports tree? --- Yasuhiro Kimura ___ 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"
Installer of 20210225 snapshot works with monochrome mode
I created VirtualBox VM on Windows host and tried to make clean install of 14-CURRENT with iso image of 20210225 snapshot (FreeBSD-14.0-CURRENT-amd64-20210225-bf667f282a7-256946-disc1.iso). Then installer worked with monochrome mode as following. https://www.utahime.org/FreeBSD/install-snapshot-020210225.01.png https://www.utahime.org/FreeBSD/install-snapshot-020210225.02.png https://www.utahime.org/FreeBSD/install-snapshot-020210225.03.png If I start `bsdinstall` after installation is completed, then it works normal color mode. So it seems bug of install image. --- Yasuhiro Kimura ___ 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: Installer of 20210225 snapshot works with monochrome mode
From: Yasuhiro Kimura Subject: Installer of 20210225 snapshot works with monochrome mode Date: Tue, 02 Mar 2021 16:02:37 +0900 (JST) > I created VirtualBox VM on Windows host and tried to make clean > install of 14-CURRENT with iso image of 20210225 snapshot > (FreeBSD-14.0-CURRENT-amd64-20210225-bf667f282a7-256946-disc1.iso). Then > installer worked with monochrome mode as following. > > https://www.utahime.org/FreeBSD/install-snapshot-020210225.01.png > https://www.utahime.org/FreeBSD/install-snapshot-020210225.02.png > https://www.utahime.org/FreeBSD/install-snapshot-020210225.03.png > > If I start `bsdinstall` after installation is completed, then it works > normal color mode. So it seems bug of install image. I tried 20210218 snapshot and the problem didn't happen. So I'm now bisecting and will report which commit causes it. --- Yasuhiro Kimura ___ 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: Installer of 20210225 snapshot works with monochrome mode
From: Yasuhiro Kimura Subject: Re: Installer of 20210225 snapshot works with monochrome mode Date: Wed, 03 Mar 2021 00:43:24 +0900 (JST) >> I created VirtualBox VM on Windows host and tried to make clean >> install of 14-CURRENT with iso image of 20210225 snapshot >> (FreeBSD-14.0-CURRENT-amd64-20210225-bf667f282a7-256946-disc1.iso). Then >> installer worked with monochrome mode as following. >> >> https://www.utahime.org/FreeBSD/install-snapshot-020210225.01.png >> https://www.utahime.org/FreeBSD/install-snapshot-020210225.02.png >> https://www.utahime.org/FreeBSD/install-snapshot-020210225.03.png >> >> If I start `bsdinstall` after installation is completed, then it works >> normal color mode. So it seems bug of install image. > > I tried 20210218 snapshot and the problem didn't happen. So I'm now > bisecting and will report which commit causes it. According to the result of bisecting, following commit is the cause of the problem. -- commit 77e1ccbee3ed6c837929e4e232fd07f95bfc8294 Author: Rick Parrish AuthorDate: Sun Feb 7 07:15:21 2021 +0100 Commit: Baptiste Daroussin CommitDate: Tue Feb 23 11:16:53 2021 +0100 rc: implement parallel boot take advantage of the rcorder -p argument to implement parallel booting in rc. According to the author non scientific tests: on a Core 2 Duo with spinning disk: | Services enabled | before | after | saving | | 0| 8s | 8s| 0 | | 1| 13s| 13s | 0 | | 2| 17s| 13s | 5 | | 3| 23s| 13s | 10 | | 4| 28s| 13s | 15 | | 5| 33s| 13s | 20 | PR: 249192 MFC after: 3 weeks -- When I saw it I remembered some fixes related to it were committed. So I tried release build with aff9b9ee89 of main and tested created iso image. But the problem still happens. I submitted the problem to Bugzilla as following bug report. Bug 253997 - Installer of 20210225 snapshot works with monochrome mode https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253997 --- Yasuhiro Kimura ___ 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: Installer of 20210225 snapshot works with monochrome mode
From: Yasuhiro Kimura Subject: Re: Installer of 20210225 snapshot works with monochrome mode Date: Thu, 04 Mar 2021 06:15:34 +0900 (JST) > From: Yasuhiro Kimura > Subject: Re: Installer of 20210225 snapshot works with monochrome mode > Date: Wed, 03 Mar 2021 00:43:24 +0900 (JST) > >>> I created VirtualBox VM on Windows host and tried to make clean >>> install of 14-CURRENT with iso image of 20210225 snapshot >>> (FreeBSD-14.0-CURRENT-amd64-20210225-bf667f282a7-256946-disc1.iso). Then >>> installer worked with monochrome mode as following. >>> >>> https://www.utahime.org/FreeBSD/install-snapshot-020210225.01.png >>> https://www.utahime.org/FreeBSD/install-snapshot-020210225.02.png >>> https://www.utahime.org/FreeBSD/install-snapshot-020210225.03.png >>> >>> If I start `bsdinstall` after installation is completed, then it works >>> normal color mode. So it seems bug of install image. >> >> I tried 20210218 snapshot and the problem didn't happen. So I'm now >> bisecting and will report which commit causes it. > > According to the result of bisecting, following commit is the cause of > the problem. > > -- > commit 77e1ccbee3ed6c837929e4e232fd07f95bfc8294 > Author: Rick Parrish > AuthorDate: Sun Feb 7 07:15:21 2021 +0100 > Commit: Baptiste Daroussin > CommitDate: Tue Feb 23 11:16:53 2021 +0100 > > rc: implement parallel boot > > take advantage of the rcorder -p argument to implement parallel > booting in rc. > > According to the author non scientific tests: > on a Core 2 Duo with spinning disk: > > | Services enabled | before | after | saving | > | 0| 8s | 8s| 0 | > | 1| 13s| 13s | 0 | > | 2| 17s| 13s | 5 | > | 3| 23s| 13s | 10 | > | 4| 28s| 13s | 15 | > | 5| 33s| 13s | 20 | > > PR: 249192 > MFC after: 3 weeks > -- > > When I saw it I remembered some fixes related to it were committed. So > I tried release build with aff9b9ee89 of main and tested created iso > image. But the problem still happens. I reverted following 5 commits from aff9b9ee89 of main and made release build. 763db589328 rc: save and restore $IFS f1ab799927c rc: fix rc script parsing 6e822e99570 rc: fix parse of $local_startup d27999e5139 Create dhclient pid directory if it doesn't exist 77e1ccbee3e rc: implement parallel boot Then iso image works with normal color mode. --- Yasuhiro Kimura ___ 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: Waiting for bufdaemon
Dear src committers, From: Yasuhiro Kimura Subject: Re: Waiting for bufdaemon Date: Thu, 28 Jan 2021 05:02:42 +0900 (JST) >>> I have been experiencing same problem with my 13-CURRENT amd64 >>> VirtualBox VM for about a month. The conditions that the problem >>> happens are unclear and all what I can say is >>> >>> * It happens only after I login in the VM and do something for a >>> while. If I boot the VM and shut it down immediately, it never >>> happens. >>> * When the problem happens, one or more unkillable processes seem to >>> be left. >> >> CPU of my host is not AMD but Intel. According to the >> /var/run/dmesg.boot of VM, information of CPU is as following. >> >> CPU: Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz (3000.09-MHz K8-class CPU) >> Origin="GenuineIntel" Id=0x906ed Family=0x6 Model=0x9e Stepping=13 >> >> Features=0x1783fbff >> >> Features2=0x5eda2203 >> AMD Features=0x28100800 >> AMD Features2=0x121 >> Structured Extended >> Features=0x842421 >> Structured Extended Features3=0x3400 >> IA32_ARCH_CAPS=0x29 >> TSC: P-state invariant >> >> Just FYI. > > It took for a while to investigate, but according to the result of > bisect following commit is the source of problem in my case. > > -- > commit 84eaf2ccc6a > Author: Konstantin Belousov > Date: Mon Dec 21 19:02:31 2020 +0200 > > x86: stop punishing VMs with low priority for TSC timecounter > > I suspect that virtualization techniques improved from the time when we > have to effectively disable TSC use in VM. For instance, it was reported > (complained) in https://github.com/JuliaLang/julia/issues/38877 that > FreeBSD is groundlessly slow on AWS with some loads. > > Remove the check and start watching for complaints. > > Reviewed by:emaste, grehan > Discussed with: cperciva > Sponsored by: The FreeBSD Foundation > Differential Revision: https://reviews.freebsd.org/D27629 > -- > > I confirmed the problem still happens with 5c325977b11 but reverting > above commit fixes it. Would someone please revert above commit from main, stable/13 and releng/13.0? As I wrote previous mail I submitted this problem to Bugzilla as bug 253087 and added the committer to Cc. But there is no response for 34 days. I confirmed the problem still happens with 37cd6c20dbc of main and 13.0-RC1. Best Regards. --- Yasuhiro Kimura ___ 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: Waiting for bufdaemon
From: Konstantin Belousov Subject: Re: Waiting for bufdaemon Date: Fri, 5 Mar 2021 22:43:58 +0200 > My belief is that this commit helps more users than it hurts. Namely, > the VMWare and KVM users, which are majority, use fast timecounter, > comparing to the more niche hypervisors like VirtualBox. > > For you, a simple but manual workaround, setting the timecounter to > ACPI (?) or might be HPET, with a loader tunable, should do it. Then please let me know the name of it. I have experienced same situation several time. That is, I faced a problem and asked for it on ML. Then I was told to try some tunable. So I thought there may be tunable that can be used as workaround in this case. But for those who isn't familiar with kernel internal, it it quite hard to find it without knowing its name. If all tunable were listed with brief explanation in one document, then I saw it and could pick up possible candidates. But actually they are documented separately among many man pages. So the first difficulty is to find man page in which possible tunable may be explained. If the problem is releted to some device, it is most hopeful to check its man page. But in this case, even after reading the commit message, I had no idea which man page to check. --- Yasuhiro Kimura ___ 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: Waiting for bufdaemon
From: Yasuhiro Kimura Subject: Re: Waiting for bufdaemon Date: Sat, 06 Mar 2021 08:33:23 +0900 (JST) >> My belief is that this commit helps more users than it hurts. Namely, >> the VMWare and KVM users, which are majority, use fast timecounter, >> comparing to the more niche hypervisors like VirtualBox. >> >> For you, a simple but manual workaround, setting the timecounter to >> ACPI (?) or might be HPET, with a loader tunable, should do it. > > Then please let me know the name of it. From: Michael Gmelin Subject: Re: Waiting for bufdaemon Date: Sat, 6 Mar 2021 00:56:43 +0100 > see `man 4 timecounters': > > https://www.freebsd.org/cgi/man.cgi?query=timecounters From: Mark Millard via freebsd-current Subject: Re: Waiting for bufdaemon Date: Fri, 5 Mar 2021 17:35:14 -0800 > Its somewhat messy but there is a technique of using > the "timecounter" in kib's wording to explore: ... From: Chris Subject: Re: Waiting for bufdaemon Date: Fri, 05 Mar 2021 18:54:05 -0800 > Not exactly what you're asking for. But sysctl sysctl(3) and loader(8) > will provide some good clues. Thank you for reply. On the system in question 'kern.timecounter.choice' and 'kern.timecounter.hardware' tunables have following values. -- yasu@rolling-vm-freebsd1[1002]% sysctl kern.timecounter.choice kern.timecounter.choice: ACPI-fast(900) i8254(0) TSC-low(-100) dummy(-100) yasu@rolling-vm-freebsd1[1003]% sysctl kern.timecounter.hardware kern.timecounter.hardware: ACPI-fast yasu@rolling-vm-freebsd1[1004]% -- So I tried setting the latter to 'i8254', 'TSC-low' and 'dummy', and checked if the problem disappear. But unfortunately it still happened. On the contrary changing the value from default made thing worse. If it is set to either 'i8254' or 'TSC-low', timeout of bufdaemon also happens when I shutdown the system just after bootstrap is completed. And if it is set to 'dummy', the sytem hung up in the middle of bootstrap. So setting 'kern.timecounter.hardware' tunable doesn't work in my case. Then is there any way to try? --- Yasuhiro Kimura ___ 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: Waiting for bufdaemon
freebsd1[1002]% -- Comparing two output there are two notable differences. The first is the value of kern.timecounter.hardware. With unpatched kernel it is 'ACPI-fast'. On the other hand, with patched kernel it is 'TSC-low'. It means the initial value is changed by applying the patch. it explains why results of 2nd case and 3rd one are different. The second is the value of kern.timecounter.tc.ACPI-fast.counter. With unpatched kernel it is '1311282421' and with patch one it is '401131388'. I don't know what this value means. But I guess the difference is the reason that the result of 2nd case is different from the one of unpatched kernel. So now I know why unexpected result (a) and (b) happen. Furthermore, I comfirmed that setting kern.timecounter.hardware to either 'i8254' or 'ACPI-fast' works as workround of the problem. It is good news anyway. But still one question remains. Why have the value of kern.timecounter.hardware and kern.timecounter.tc.ACPI-fast.counter changed by applying the patch? My understanding is that it only makes 'kern.timecounter.hardware' loader tunable that can be configured with loader.conf. Is it unexpected side effect? Or is everything expected result? --- Yasuhiro Kimura ___ 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: Waiting for bufdaemon
From: Yasuhiro Kimura Subject: Re: Waiting for bufdaemon Date: Tue, 09 Mar 2021 00:57:32 +0900 (JST) > But still one question remains. Why have the value of > kern.timecounter.hardware and kern.timecounter.tc.ACPI-fast.counter > changed by applying the patch? My understanding is that it only makes > 'kern.timecounter.hardware' loader tunable that can be configured with > loader.conf. Is it unexpected side effect? Or is everything expected > result? Oops, I made a mistake. > If I do it with unpatched kernel, I get following result. This isn't correct. I did it with reverted kernel (i.e. 705d06b289e of main + revert of 84eaf2ccc6a). If I do it with really unpatch kernel, I get same result as patched one. Sorry for noise. --- Yasuhiro Kimura ___ 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: Waiting for bufdaemon
From: Kyle Evans
Subject: Re: Waiting for bufdaemon
Date: Mon, 8 Mar 2021 11:07:23 -0600
> I've tried tracking down exactly what the problem is that causes the
> symptoms we're seeing, but no luck so far. I'm eyeballing the
> following patch which partially reverts kib's 84eaf2ccc6aa05 ("x86:
> stop punishing VMs with low priority for TSC timecounter") and only
> punishes VirtualBox guests.
>
> diff --git a/sys/x86/x86/tsc.c b/sys/x86/x86/tsc.c
> index 68fc57e6ea7..6f25360a67c 100644
> --- a/sys/x86/x86/tsc.c
> +++ b/sys/x86/x86/tsc.c
> @@ -501,7 +501,12 @@ test_tsc(int adj_max_count)
> uint64_t *data, *tsc;
> u_int i, size, adj;
>
> - if ((!smp_tsc && !tsc_is_invariant) || vm_guest)
> + /*
> +* Misbehavior of TSC under VirtualBox has been observed. In
> +* particular, threads doing small (~1 second) sleeps may miss their
> +* wakeup and hang around in sleep state, causing hangs on shutdown.
> +*/
> + if ((!smp_tsc && !tsc_is_invariant) || vm_guest == VM_GUEST_VBOX)
> return (-100);
> size = (mp_maxid + 1) * 3;
> data = malloc(sizeof(*data) * size * N, M_TEMP, M_WAITOK);
After updating to 6ffdaa5f2d4, I confirmed timeout of bufdaemon
dosen't happen even if I don't set kern.timecounter.hardware at all in
loader.conf.
Thank you for fixing the problem.
---
Yasuhiro Kimura
___
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: poudriere jail: specific commit
From: Nuno Teixeira Subject: poudriere jail: specific commit Date: Sat, 13 Mar 2021 09:49:50 + > I'm running 14.0-CURRENT #0 fb3edd4f3 and I need a poudriere jail with same > commit fb3edd4f3. > > porters handbook says: > --- > If a specific Subversion revision is needed, append it to the version > string. For example: > > # poudriere jail -c -j 11i386 -v stable/11@123456 -a i386 -m svn+https > --- > How can I tell poudriere to fetch git commit fb3edd4f3? > > I'm asking this because I need poudriere testport, and I will like that > jailed version is same as installed OS. > > Thanks, You updated your host OS to 14.0-CURRENT fb3edd4f3 with regular steps described in /usr/src/Makefile. Right? If so you can create jail of same commit as host with following command. # poudriere jail -c -j jailname -m src=/usr/src In this case files under /usr/obj are used to create jail. So you need not do 'make buildworld' again for jail. --- Yasuhiro Kimura ___ 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: poudriere jail: specific commit
From: Nuno Teixeira Subject: Re: poudriere jail: specific commit Date: Sat, 13 Mar 2021 10:57:27 + > And next time I upgrade my host OS should this command work? > > # poudriere jail -u -j jailname -m src=/usr/src Once you create jail you can update jail with # poudriere jail -u -j jailname --- Yasuhiro Kimura ___ 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"
Build of some ports hang up on recent 14-CURRENT amd64
yasu@rolling-vm-freebsd1[1044]% uname -a FreeBSD rolling-vm-freebsd1.home.utahime.org 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n245912-f2400e6e832: Sat Apr 10 01:42:33 JST 2021 ro...@rolling-vm-freebsd1.home.utahime.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 After the update from 36d6e65722e to f2400e6e832 I noticed build of some ports hang up in the middle of it on my 14-CURRENT amd64 host. One of such examples is security/py-cryptography. -- root@rolling-vm-freebsd1[1008]# make ===> License APACHE20 BSD3CLAUSE accepted by the user ===> py39-cryptography-3.3.2 depends on file: /usr/local/sbin/pkg - found ===> Fetching all distfiles required by py39-cryptography-3.3.2 for building ===> Extracting for py39-cryptography-3.3.2 => SHA256 Checksum OK for cryptography-3.3.2.tar.gz. ===> Patching for py39-cryptography-3.3.2 ===> py39-cryptography-3.3.2 depends on package: py39-cffi>=1.8 - found ===> py39-cryptography-3.3.2 depends on package: py39-setuptools>0 - found ===> py39-cryptography-3.3.2 depends on file: /usr/local/bin/python3.9 - found ===> Configuring for py39-cryptography-3.3.2 running config -- And another one is devel/arcanist-lib. -- root@rolling-vm-freebsd1[1023]# make ===> License APACHE20 accepted by the user ===> arcanist-lib-php74-20210113 depends on file: /usr/local/sbin/pkg - found ===> Fetching all distfiles required by arcanist-lib-php74-20210113 for building ===> Extracting for arcanist-lib-php74-20210113 => SHA256 Checksum OK for phacility-arcanist-20210113-b2e715f_GH0.tar.gz. ===> Patching for arcanist-lib-php74-20210113 ===> Applying FreeBSD patches for arcanist-lib-php74-20210113 from /usr/ports/devel/arcanist-lib/files ===> Configuring for arcanist-lib-php74-20210113 ===> Staging for arcanist-lib-php74-20210113 ===> arcanist-lib-php74-20210113 depends on file: /usr/local/include/php/main/php.h - found ===> arcanist-lib-php74-20210113 depends on file: /usr/local/lib/php/20190902/curl.so - found ===> arcanist-lib-php74-20210113 depends on file: /usr/local/lib/php/20190902/dom.so - found ===> arcanist-lib-php74-20210113 depends on file: /usr/local/lib/php/20190902/json.so - found ===> arcanist-lib-php74-20210113 depends on file: /usr/local/lib/php/20190902/simplexml.so - found ===> arcanist-lib-php74-20210113 depends on file: /usr/local/lib/php/20190902/zlib.so - found ===> arcanist-lib-php74-20210113 depends on file: /usr/local/lib/php/20190902/mbstring.so - found ===> Generating temporary packing list cd /usr/ports/devel/arcanist-lib/work-php74/arcanist-b2e715f ; /bin/pax -rw * /usr/ports/devel/arcanist-lib/work-php74/stage/usr/local/lib/php/arcanist install -l rs /usr/ports/devel/arcanist-lib/work-php74/stage/usr/local/lib/php/arcanist/support/shell/hooks/bash-completion.sh /usr/ports/devel/arcanist-lib/work-php74/stage/usr/local/share/bash-completion/completions/arc /usr/ports/devel/arcanist-lib/work-php74/stage/usr/local/lib/php/arcanist/bin/arc shell-complete --generate GENERATE Generating shell completion rules... RULES Wrote updated completion rules for "bash" to: work-php74/stage/usr/local/lib/php/arcanist/support/shell/rules/bash-rules.sh. NOTE You may need to open a new terminal window or launch a new shell before the changes take effect. -- The problem also happens with poudriere. I tried boot with old 36d6e65722e kernel but the problem still happens. So the cause may be older than it. Does anyone else have the same problem? Best Regards. --- Yasuhiro Kimura ___ 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: Build of some ports hang up on recent 14-CURRENT amd64
From: Michael Butler via freebsd-current Subject: Re: Build of some ports hang up on recent 14-CURRENT amd64 Date: Fri, 9 Apr 2021 17:20:44 -0400 > This is likely fixed as of ~30 mins ago on commit > e8b9c508b7ae5be618ada089103468c400e465cd > > The cause appears to have been commit d36d6816151705907393889 > > imb Thanks for information. I'll try another update. --- Yasuhiro Kimura ___ 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: Build of some ports hang up on recent 14-CURRENT amd64
From: Yasuhiro Kimura Subject: Re: Build of some ports hang up on recent 14-CURRENT amd64 Date: Sat, 10 Apr 2021 06:30:22 +0900 (JST) > From: Michael Butler via freebsd-current > Subject: Re: Build of some ports hang up on recent 14-CURRENT amd64 > Date: Fri, 9 Apr 2021 17:20:44 -0400 > >> This is likely fixed as of ~30 mins ago on commit >> e8b9c508b7ae5be618ada089103468c400e465cd >> >> The cause appears to have been commit d36d6816151705907393889 >> >> imb > > Thanks for information. I'll try another update. After the update to 1a7fe55ab8c I confirmed build of the ports completes successfuly. --- Yasuhiro Kimura ___ 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: How to delete comment spam from bugzilla?
Hello, From: Alan Somers Subject: How to delete comment spam from bugzilla? Date: Fri, 23 Apr 2021 09:31:01 -0600 > Somebody, or more likely some bot, is posting comment spam in our > bugzilla. How can we delete spammy comments ? I faced same situation before and was told to send mail to bugmeis...@freebsd.org. --- Yasuhiro Kimura ___ 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"
Loading zfs module results in hangup on i386 (Re: Install of 13.0-RELEASE i386 with ZFS root hangs up)
From: Yasuhiro Kimura Subject: Install of 13.0-RELEASE i386 with ZFS root hangs up Date: Fri, 07 May 2021 21:47:59 +0900 (JST) > Hello, > > Does anyone succeed to install 13.0-RELEASE i386 with ZFS root? > > I tried this with VirtualBox and VMware Player on Windows with > following VM condition. > > * 4 CPUs > * 8GB memory > * 100GB disk > * Bridge mode NIC > > But in both cases, VM gets high CPU load and hangs up after I moved > to 'YES' at 'ZFS Configuration' menu and type return key. > > If I select UFS root installation completes successfully. So the > problem is specific to ZFS root. Now I think I know what is the source of problem. After all, on 13.0-RELEASE i386 system simply loading zfs module results in system hang up. The steps to reproduce it are, 1. Boot with install media of 13.0-RELEASE i386 2. At the first menu of FreeBSD installer, select 'Shell'. 3. At the shell prompt, type `kldload zfs` and return key. I confirmed hangup happens with VirtualBox, VMware Player and my bare metal PC environement. So the problem doesn't depend on hardware. And hangup also happens with 13-STABLE and 14-CURRENT. --- Yasuhiro Kimura ___ 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: Loading zfs module results in hangup on i386
From: Yasuhiro Kimura Subject: Loading zfs module results in hangup on i386 (Re: Install of 13.0-RELEASE i386 with ZFS root hangs up) Date: Sat, 08 May 2021 07:31:47 +0900 (JST) > Now I think I know what is the source of problem. After all, on > 13.0-RELEASE i386 system simply loading zfs module results in system > hang up. > > The steps to reproduce it are, > > 1. Boot with install media of 13.0-RELEASE i386 > 2. At the first menu of FreeBSD installer, select 'Shell'. > 3. At the shell prompt, type `kldload zfs` and return key. > > I confirmed hangup happens with VirtualBox, VMware Player and my bare > metal PC environement. So the problem doesn't depend on hardware. > > And hangup also happens with 13-STABLE and 14-CURRENT. This problem is already reported to Bugzilla. Bug 254177 When ZFS is recognized, An i386 machine with a lot of memory hangs. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254177 --- Yasuhiro Kimura ___ 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: Loading zfs module results in hangup on i386
From: Yasuhiro Kimura
Subject: Re: Loading zfs module results in hangup on i386
Date: Sat, 08 May 2021 07:44:15 +0900 (JST)
>> Now I think I know what is the source of problem. After all, on
>> 13.0-RELEASE i386 system simply loading zfs module results in system
>> hang up.
>>
>> The steps to reproduce it are,
>>
>> 1. Boot with install media of 13.0-RELEASE i386
>> 2. At the first menu of FreeBSD installer, select 'Shell'.
>> 3. At the shell prompt, type `kldload zfs` and return key.
>>
>> I confirmed hangup happens with VirtualBox, VMware Player and my bare
>> metal PC environement. So the problem doesn't depend on hardware.
>>
>> And hangup also happens with 13-STABLE and 14-CURRENT.
>
> This problem is already reported to Bugzilla.
>
> Bug 254177 When ZFS is recognized, An i386 machine with a lot of memory hangs.
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254177
Referencing the bug report, I applied attached patch to d474440ab33 of
main (14-CURRENT). built install image and tried install of ZFS root
i386 system with it. Then it completed successfully with 8GB memory.
Additionally GENERIC kernel recognizes 8GB of memory. And ZFS root
system works fine without any tuning.
--
diff --git a/sys/contrib/openzfs/module/zfs/dbuf.c
b/sys/contrib/openzfs/module/zfs/dbuf.c
index d48dc7943a2..c85500453fb 100644
--- a/sys/contrib/openzfs/module/zfs/dbuf.c
+++ b/sys/contrib/openzfs/module/zfs/dbuf.c
@@ -796,7 +796,7 @@ dbuf_init(void)
* By default, the table will take up
* totalmem * sizeof(void*) / 8K (1MB per GB with 8-byte pointers).
*/
- while (hsize * zfs_arc_average_blocksize < physmem * PAGESIZE)
+ while (hsize * zfs_arc_average_blocksize < (uint64_t)physmem * PAGESIZE)
hsize <<= 1;
retry:
--
---
Yasuhiro Kimura
___
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"
Should /usr/share/man/man7/zpool-features.7.gz be removed or not?
Hello, Recently `make delete-old` ask if it removes /usr/share/man/man7/zpool-features.7.gz when I take regular update step. But even if I answer 'y' and the file is removed, it happens again when I do next update. Should the file be removed or not? Best Regards. --- Yasuhiro Kimura
Re: Should /usr/share/man/man7/zpool-features.7.gz be removed or not?
From: Yasuhiro Kimura Subject: Should /usr/share/man/man7/zpool-features.7.gz be removed or not? Date: Sat, 26 Jun 2021 10:20:09 +0900 (JST) > Recently `make delete-old` ask if it removes > /usr/share/man/man7/zpool-features.7.gz when I take regular update > step. But even if I answer 'y' and the file is removed, it happens > again when I do next update. > > Should the file be removed or not? > > Best Regards. I submitted following bug report to Bugzilla Bug 256852 - While `make installworld` installs /usr/share/man/man7/zpool-features.7.gz, `make delete-old` suggests to remove it https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256852 Just FYI. --- Yasuhiro Kimura
Build of devel/ninja and lang/gcc11 fails with latest 14-CURRENT amd64
314 | #define BITSET_ALLOC(_s, mt, mf)malloc(BITSET_SIZE((_s)), mt, (mf)) | ^ gmake[4]: *** [Makefile:1142: jit/libgccjit.o] Error 1 gmake[4]: *** Waiting for unfinished jobs rm gcc.pod gfortran.pod gmake[4]: Leaving directory '/wrkdirs/usr/ports/lang/gcc11/work/.build/gcc' gmake[3]: *** [Makefile:4819: all-stage2-gcc] Error 2 gmake[3]: Leaving directory '/wrkdirs/usr/ports/lang/gcc11/work/.build' gmake[2]: *** [Makefile:24753: stage2-bubble] Error 2 gmake[2]: Leaving directory '/wrkdirs/usr/ports/lang/gcc11/work/.build' gmake[1]: *** [Makefile:24976: bootstrap-lean] Error 2 gmake[1]: Leaving directory '/wrkdirs/usr/ports/lang/gcc11/work/.build' ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 Stop. make: stopped in /usr/ports/lang/gcc11 -- Full build logs: https://www.utahime.org/FreeBSD/poudriere/data/logs/bulk/curamd64-default/2021-11-13_04h10m35s/logs/ninja-1.10.2,2.log https://www.utahime.org/FreeBSD/poudriere/data/logs/bulk/curamd64-default/2021-11-13_04h18m54s/logs/gcc11-11.2.0.log I checked commit messages between 517e52b6c21 and b39a93b18ef and found following commit. -- commit 160b4b922b6 Author: Konstantin Belousov Date: Sat Oct 23 00:17:21 2021 Add real sched.h It is required by IEEE Std 1003.1-2008 AKA POSIX. Put some Linux compatibility stuff under BSD_VISIBLE namespace, in particular, sys/cpuset.h definitions. Also, if user really want Linux compatibility, she can request cpu_set_t typedef with _WITH_CPU_SET_T define. Reviewed by:jhb Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D32901 -- It seems likely this is the cause of build error. --- Yasuhiro Kimura
Re: Build of devel/ninja and lang/gcc11 fails with latest 14-CURRENT amd64
From: Konstantin Belousov Subject: Re: Build of devel/ninja and lang/gcc11 fails with latest 14-CURRENT amd64 Date: Sat, 13 Nov 2021 00:56:16 +0200 > Ninja builds with the following patch, other failing ports have a chance > as well. I tried it and build of devel/ninja is surely fixed. But build of lang/gcc11 still failed with same error. --- Yasuhiro Kimura
Re: Build of devel/ninja and lang/gcc11 fails with latest 14-CURRENT amd64
From: Yasuhiro Kimura
Subject: Re: Build of devel/ninja and lang/gcc11 fails with latest 14-CURRENT
amd64
Date: Sat, 13 Nov 2021 12:21:40 +0900 (JST)
> I tried it and build of devel/ninja is surely fixed. But build of
> lang/gcc11 still failed with same error.
With the commit of 90fa9705d5c build of lang/gcc11 is also fixed. But
build of graphics/cairo, which was previously skipped due to build
error of devel/ninja, fails as following.
--
--- cairo-perf-micro.o ---
cc -DHAVE_CONFIG_H -I. -I.. -I.
-I../boilerplate-I../src -I../util/cairo-missing
-I../util/cairo-script -I../src-D_REENTRANT
-I/usr/local/include/pixman-1 -I/usr/local/include
-I/usr/local/include/freetype2 -I/usr/local/include/libpng16
-I/usr/local/include/freetype2 -I/usr/local/include/libpng16
-I/usr/local/include -I/usr/local/include -I/usr/local/include/libpng16
-I/usr/local/include -pthread -I/usr/local/include -pthread
-I/usr/local/include -D_THREAD_SAFE -pthread -I/usr/local/include
-D_THREAD_SAFE -pthread-Wall -Wextra -Wmissing-declarations
-Werror-implicit-function-declaration -Wpointer-arith -Wwrite-strings
-Wsign-compare -Wpacked -Wswitch-enum -Wmissing-format-attribute
-Wvolatile-register-var -Wstrict-aliasing=2 -Winit-self
-Wno-missing-field-initializers -Wno-unused-parameter -Wno-attributes
-Wno-long-long -Winline -fno-strict-aliasing -fno-common
-Wp,-D_FORTIFY_SOURCE=2-O2 -pipe -fstack-protector-strong
-fno-strict-aliasing -MT cairo-perf-micro.o -MD -MP -MF
.deps/cairo-perf-micro.Tpo -c -o cairo-perf-micro.o cairo-perf-micro.c
--- cairo-perf-report.lo ---
mv -f .deps/cairo-perf-report.Tpo .deps/cairo-perf-report.Plo
--- libcairoperf.la ---
/bin/sh ../libtool --tag=CC--mode=link cc -O2 -pipe
-fstack-protector-strong -fno-strict-aliasing -fstack-protector-strong -o
libcairoperf.la cairo-perf.lo cairo-perf-report.lo cairo-stats.lo
cairo-time.lo-lrt -lm
--- cairo-perf-micro.o ---
cairo-perf-micro.c:418:5: error: unknown type name 'cpu_set_t'; did you mean
'cpusetid_t'?
cpu_set_t affinity;
^
cpusetid_t
/usr/include/sys/types.h:86:22: note: 'cpusetid_t' declared here
typedef __cpusetid_tcpusetid_t;
^
cairo-perf-micro.c:421:9: error: implicit declaration of function
'sched_getaffinity' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
if (sched_getaffinity(0, sizeof(affinity), &affinity)) {
^
cairo-perf-micro.c:426:35: error: use of undeclared identifier 'CPU_SETSIZE'
for(i = 0, cpu_count = 0; i < CPU_SETSIZE; ++i) {
^
cairo-perf-micro.c:427:6: error: implicit declaration of function 'CPU_ISSET'
is invalid in C99 [-Werror,-Wimplicit-function-declaration]
if (CPU_ISSET(i, &affinity))
^
4 errors generated.
*** [cairo-perf-micro.o] Error code 1
make[5]: stopped in /wrkdirs/usr/ports/graphics/cairo/work/cairo-1.17.4/perf
--- cairo-perf-trace.o ---
mv -f .deps/cairo-perf-trace.Tpo .deps/cairo-perf-trace.Po
--- libcairoperf.la ---
libtool: link: ar cru .libs/libcairoperf.a .libs/cairo-perf.o
.libs/cairo-perf-report.o .libs/cairo-stats.o .libs/cairo-time.o
libtool: link: ranlib .libs/libcairoperf.a
libtool: link: ( cd ".libs" && rm -f "libcairoperf.la" && ln -s
"../libcairoperf.la" "libcairoperf.la" )
--- cairo-hash.o ---
mv -f .deps/cairo-hash.Tpo .deps/cairo-hash.Po
1 error
make[5]: stopped in /wrkdirs/usr/ports/graphics/cairo/work/cairo-1.17.4/perf
make[4]: stopped in /wrkdirs/usr/ports/graphics/cairo/work/cairo-1.17.4/perf
make[3]: stopped in /wrkdirs/usr/ports/graphics/cairo/work/cairo-1.17.4/perf
make[2]: stopped in /wrkdirs/usr/ports/graphics/cairo/work/cairo-1.17.4
make[1]: stopped in /wrkdirs/usr/ports/graphics/cairo/work/cairo-1.17.4
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1
Stop.
make: stopped in /usr/ports/graphics/cairo
--
Full build log:
https://www.utahime.org/FreeBSD/poudriere/data/logs/bulk/curamd64-default/2021-11-14_12h35m18s/logs/cairo-1.17.4,3.log
---
Yasuhiro Kimura
