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: 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: 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
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: 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
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: 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
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: 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
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-0x4231 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
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: Updating EFI boot loader results in boot hangup
From: Yasuhiro Kimura Subject: Re: Updating EFI boot loader results in boot hangup Date: Tue, 16 Aug 2022 12:01:42 +0900 (JST) >>> I made regular update of my 14-CURRENT amd64 system from >>> main-n257134-a69c0964625 to main-n257316-9d16275c65b. I also updated >>> EFI boot loader (/boot/efi/efi/freebsd/loader.efi) but it results in >>> boot hangup as following. >>> >>> https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220813-boot-hangup.png >>> >>> If I restore previous loader file (that is, loader.efi of >>> main-n257134-a69c0964625 and kernel of main-n257316-9d16275c65b), then >>> system boots successfully. >> >> I submitted the problem to FreeBSD Bugzilla. >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265825 >> >> Best Regards. > > d98de744050 is committed. So I tested it with following steps. > > 1. Check out the commit. > 2. cd /usr/src/stand > 3. make > 4. make install > 5. install -m 755 -p /boot/loader.efi /boot/efi/efi/freebsd > 6. shutdown -r now > > And system boots successfully. But while efi loader is workding a lot > of messages are displayed as following. > > https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64.20220816.efi-loader-message.png Today I made regular weekly update to main-n257521-97be6fced7d and now loader.efi works fine without extra messages. --- Yasuhiro Kimura
Re: Updating EFI boot loader results in boot hangup
From: Warner Losh Subject: Re: Updating EFI boot loader results in boot hangup Date: Mon, 15 Aug 2022 21:35:52 -0600 > Would you be able to share camcontrol devlist output? Privately if > need be. root@rolling-vm-freebsd1[1001]# camcontrol devlist at scbus0 target 0 lun 0 (pass0,ada0) at scbus1 target 0 lun 0 (cd0,pass1) root@rolling-vm-freebsd1[1002]# > And have any of these disks ever held ufs filesystems?? No. ada0 consists of ESP, swap and ZFS. root@rolling-vm-freebsd1[1002]# gpart show ada0 => 40 209715120 ada0 GPT (100G) 40 532480 1 efi (260M) 532520 2008- free - (1.0M) 534528 67108864 2 freebsd-swap (32G) 67643392 142069760 3 freebsd-zfs (68G) 209713152 2008- free - (1.0M) root@rolling-vm-freebsd1[1003]# --- Yasuhiro Kimura
Re: Updating EFI boot loader results in boot hangup
From: Yasuhiro Kimura Subject: Re: Updating EFI boot loader results in boot hangup Date: Sun, 14 Aug 2022 06:34:40 +0900 (JST) > From: Yasuhiro Kimura > Subject: Updating EFI boot loader results in boot hangup > Date: Sat, 13 Aug 2022 01:54:26 +0900 (JST) > >> I made regular update of my 14-CURRENT amd64 system from >> main-n257134-a69c0964625 to main-n257316-9d16275c65b. I also updated >> EFI boot loader (/boot/efi/efi/freebsd/loader.efi) but it results in >> boot hangup as following. >> >> https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220813-boot-hangup.png >> >> If I restore previous loader file (that is, loader.efi of >> main-n257134-a69c0964625 and kernel of main-n257316-9d16275c65b), then >> system boots successfully. > > I submitted the problem to FreeBSD Bugzilla. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265825 > > Best Regards. d98de744050 is committed. So I tested it with following steps. 1. Check out the commit. 2. cd /usr/src/stand 3. make 4. make install 5. install -m 755 -p /boot/loader.efi /boot/efi/efi/freebsd 6. shutdown -r now And system boots successfully. But while efi loader is workding a lot of messages are displayed as following. https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64.20220816.efi-loader-message.png --- Yasuhiro Kimura
Re: Updating EFI boot loader results in boot hangup
From: Warner Losh Subject: Re: Updating EFI boot loader results in boot hangup Date: Sat, 13 Aug 2022 20:01:03 -0600 > UFS or ZFS? > > Warner ZFS in my case. --- Yasuhiro Kimura
Re: Updating EFI boot loader results in boot hangup
From: Oleg Lelchuk Subject: Re: Updating EFI boot loader results in boot hangup Date: Sat, 13 Aug 2022 20:28:09 -0400 > I can already see that commit > > c32dde3166922f55927764464d13f1bc9640f5f6 causes breakage, but the commit that > precedes it > > f197c0bf3e075286ccea32cd12023f3317474c5a doesn't cause breakage and the > system boots just fine with it. But > the error that the c32dd commit causes is different from the error that we > see now, so maybe there is a > possibility that one of the commits that follow it fixed the breakage, but > then yet another commit caused a > different kind of breakage again. With the command `git bisect start --first-parent 9d16275c65b a69c0964625 -- stand` I got just same result. --- Yasuhiro Kimura
Re: Updating EFI boot loader results in boot hangup
From: Oleg Lelchuk Subject: Re: Updating EFI boot loader results in boot hangup Date: Sat, 13 Aug 2022 19:32:16 -0400 > You can do make and make install in /usr/src/stand Thanks for letting me know. I'll try it. --- Yasuhiro Kimura
Re: Updating EFI boot loader results in boot hangup
From: Warner Losh Subject: Re: Updating EFI boot loader results in boot hangup Date: Sat, 13 Aug 2022 16:59:55 -0600 > Any chance of a bisect of which revision starts to fail? > > Warner I'll try it. Is it possbile to build only loader.efi without doing buildworld? I'd like to shorten the time to take for single step of bisect. --- Yasuhiro Kimura
Re: Updating EFI boot loader results in boot hangup
From: Yasuhiro Kimura Subject: Updating EFI boot loader results in boot hangup Date: Sat, 13 Aug 2022 01:54:26 +0900 (JST) > I made regular update of my 14-CURRENT amd64 system from > main-n257134-a69c0964625 to main-n257316-9d16275c65b. I also updated > EFI boot loader (/boot/efi/efi/freebsd/loader.efi) but it results in > boot hangup as following. > > https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220813-boot-hangup.png > > If I restore previous loader file (that is, loader.efi of > main-n257134-a69c0964625 and kernel of main-n257316-9d16275c65b), then > system boots successfully. I submitted the problem to FreeBSD Bugzilla. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265825 Best Regards. --- Yasuhiro Kimura
Re: Updating EFI boot loader results in boot hangup
From: Nuno Teixeira Subject: Re: Updating EFI boot loader results in boot hangup Date: Fri, 12 Aug 2022 21:03:02 +0100 > I'm searching without success to load a bkp loader in case of boot failure. > > Upgrade process willl be like: > --- > mount -t msdosfs /dev/nvd0p1 /mnt > cp /mnt/efi/boot/bootx64.efi /mnt/efi/boot/bootx64.old > cp /boot/loader.efi /mnt/efi/boot/bootx64.efi > --- > > I can't find the right docs to load bootx64.old. > Could you tell me what you did to solve your boot? > > Thanks I use VirturalBox to run 14-CURRENT system. UEFI BIOS of VirtualBox provides a way to select loader file and boot from it. So I take following steps when updating loader file. 1. cd /boot/efi/efi/freebsd 2. mv loader.efi loader.backup.efi 3. cp -a /boot/loader.efi . And when boot from new loader file fails, I enter UEFI BIOS, select loader.backup.efi and boot from it. As you can see, above way depends on the feature of VirturalBox. So it depends on your hardware whether or not you can adopt it. As Larry pointed out, surest way is to boot from install media such as memstick or cdrom. --- Yasuhiro Kimura
Re: Updating EFI boot loader results in boot hangup
From: Nuno Teixeira Subject: Re: Updating EFI boot loader results in boot hangup Date: Fri, 12 Aug 2022 18:26:11 +0100 > Hello Yasu, > > Does it needes to update boot loader everytime that we upgrade current? No, you need not. > The only time that I updated was a month ago because of zfs upgrade and I > need to practice how to boot > loader bkp file :) I update boot loader everytime because I'd like to do it :-). And sometimes problem hits upon me like this time and I contribute to debugging base system :-):-). --- Yasuhiro Kimura
Updating EFI boot loader results in boot hangup
Hello, I made regular update of my 14-CURRENT amd64 system from main-n257134-a69c0964625 to main-n257316-9d16275c65b. I also updated EFI boot loader (/boot/efi/efi/freebsd/loader.efi) but it results in boot hangup as following. https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220813-boot-hangup.png If I restore previous loader file (that is, loader.efi of main-n257134-a69c0964625 and kernel of main-n257316-9d16275c65b), then system boots successfully. Best Regards. --- Yasuhiro Kimura
Re: Kernel crashed with "panic: VERIVY(e->lse-mscount != 0) failed"
From: Alexander Motin Subject: Re: Kernel crashed with "panic: VERIVY(e->lse-mscount != 0) failed" Date: Sun, 5 Jun 2022 09:33:21 -0400 > Hi, > > Please update your system once more. That wrong assertion was removed > soon after your checkout at e3aa18ad717. Thanks. After updating latest commit `poudriere bulk` completed successfully. --- Yasuhiro Kimura
Kernel crashed with "panic: VERIVY(e->lse-mscount != 0) failed"
Hello, yasu@rolling-vm-freebsd1[1154]% uname -a FreeBSD rolling-vm-freebsd1.home.utahime.org 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n255944-645886d028c: Sat Jun 4 01:44:38 JST 2022 ro...@rolling-vm-freebsd1.home.utahime.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 While building packages with poudriere kernel crashed with following message. panic: VERIVY(e->lse-mscount != 0) failed Snapshot of console: https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220604.png Best Regards. --- Yasuhiro Kimura
Re: 20220519 snapshot: loader fails to find bootable partition of zfs-root system
From: Navdeep Parhar Subject: Re: 20220519 snapshot: loader fails to find bootable partition of zfs-root system Date: Mon, 23 May 2022 22:03:57 -0700 > On Mon, May 23, 2022 at 8:40 PM Yasuhiro Kimura wrote: >> >> Hello, >> >> I made clean install of zfs-root 14-CURRENT amd64 system with install >> image of 20220519 snapshop. After installation completed and system is >> rebooted, boot fails as loader fails to find bootable partition as >> following. >> >> https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220519snapshot.png >> >> If I use 20220512 snapshop instead, then system starts up >> successfully. > > You need a loader with commit 9cd45772a44f268ccb3e20caf7f3f764f6b5e1a1 > to deal with the latest OpenZFS. > > Regards, > Navdeep > Thanks for reply. I installed system with 20220512 snapshot, update it to latest commit and upgraded zroot with `zpool upgrade zroot`. Then it boots successfully. --- Yasuhiro Kimura
20220519 snapshot: loader fails to find bootable partition of zfs-root system
Hello, I made clean install of zfs-root 14-CURRENT amd64 system with install image of 20220519 snapshop. After installation completed and system is rebooted, boot fails as loader fails to find bootable partition as following. https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220519snapshot.png If I use 20220512 snapshop instead, then system starts up successfully. --- Yasuhiro Kimura
Re: Considering stepping down from all of my FreeBSD responsibilities
Hi Glen, From: Glen Barber Subject: Considering stepping down from all of my FreeBSD responsibilities Date: Fri, 1 Apr 2022 00:15:02 + > Dear community, > > Given the mental toll the past two years or so have taken on me, I have > decided to step down from all of my "hats" within the Project, and take > some time to sort out what my future looks like going forward. > > Happy April 1st. I'm not going anywhere. :-) > > Glen We are waiting for the announce of FreeBSD 2.2.10-RELEASE. :-) Cf. https://lists.freebsd.org/pipermail/freebsd-announce/2006-April/001055.html --- Yasuhiro Kimura
Re: getnetgrent(3) fails to parse long netgroup entry if it is stored in NIS
From: Rick Macklem Subject: Re: getnetgrent(3) fails to parse long netgroup entry if it is stored in NIS Date: Tue, 15 Mar 2022 23:15:30 + > "man 5 netgroup" notes that a netgroup line is limited to > 1024bytes. > > Are you sure you haven't just exceeded this limit? Thanks for pointing out. It's exactly the cause of my problem. I didn't know there is such limit. From: Rick Macklem Subject: Re: getnetgrent(3) fails to parse long netgroup entry if it is stored in NIS Date: Wed, 16 Mar 2022 05:12:49 + > Oh, and you can have netgroups in netgroups, so you can > do something like... > > net0 net1,net2 > net1 (host1,,),(host2,,) > net2 (host3,,),(host4,,) > > then net0 has all 4 hosts in it. > > I think you need to break the large netgroup up into sub netgroups > where each one is <= 1024 bytes long. I fixed the problem in this way. Thank you so much! --- Yasuhiro Kimura
getnetgrent(3) fails to parse long netgroup entry if it is stored in NIS
t21.long.long.long.example.com,,) (host22.long.long.long.example.com,,) (host23.long.long.long.example.com,,) (host24.long.long.long.example.com,,) (host25.long.long.long.example.com,,) (host26.long.long.long.example.com,,) (host27.long.long.long.example.com,,) (host28.long.long.long.example.com,,) (host29.long.long.long.example.com,,) (host30.long.long.long.example.com,,) yasu@server[1064]% ./list_netgroup_entry very_long_nis_entry netgroup: very_long_nis_entry host: host25.long.long.long.examp, user: , domain: host: host24.long.long.long.example.com, user: , domain: host: host23.long.long.long.example.com, user: , domain: host: host22.long.long.long.example.com, user: , domain: host: host21.long.long.long.example.com, user: , domain: host: host20.long.long.long.example.com, user: , domain: host: host19.long.long.long.example.com, user: , domain: host: host18.long.long.long.example.com, user: , domain: host: host17.long.long.long.example.com, user: , domain: host: host16.long.long.long.example.com, user: , domain: host: host15.long.long.long.example.com, user: , domain: host: host14.long.long.long.example.com, user: , domain: host: host13.long.long.long.example.com, user: , domain: host: host12.long.long.long.example.com, user: , domain: host: host11.long.long.long.example.com, user: , domain: host: host10.long.long.long.example.com, user: , domain: host: host9.long.long.long.example.com, user: , domain: host: host8.long.long.long.example.com, user: , domain: host: host7.long.long.long.example.com, user: , domain: host: host6.long.long.long.example.com, user: , domain: host: host5.long.long.long.example.com, user: , domain: host: host4.long.long.long.example.com, user: , domain: host: host3.long.long.long.example.com, user: , domain: host: host2.long.long.long.example.com, user: , domain: host: host1.long.long.long.example.com, user: , domain: yasu@server[1065]% -- So it seems getnetgrent(3) fails to parse long netgroup entry if it is stored in NIS. --- Yasuhiro Kimura
Re: Buildworld fails with external GCC toolchain
From: Yasuhiro Kimura Subject: Re: Buildworld fails with external GCC toolchain Date: Tue, 15 Feb 2022 08:26:00 +0900 (JST) >> I have amd64 world + kernel building with GCC 9 and the only remaining >> open review not merged yet is https://reviews.freebsd.org/D34147. >> >> It is work to keep it working though and I hadn't worked on it again >> until recently. > > Thanks for letting me know. I tried patch of the review and confirmed > both buildworld and buildkernel succeed with GCC 9 and binutils 2.37. > So I reached start point now and can test binutils 2.38. I tried buildworld and buildkernel with binutils 2.38 and they completed successfully. Just FYI. --- Yasuhiro Kimura
Re: Buildworld fails with external GCC toolchain
From: John Baldwin
Subject: Re: Buildworld fails with external GCC toolchain
Date: Mon, 14 Feb 2022 10:46:29 -0800
>>> Not really, the gcc 9 build has been broken for months, as far as I
>>> know.
>>>
>>> See also: https://ci.freebsd.org/job/FreeBSD-main-amd64-gcc9_build/
>>>
>>> The last build(s) show a different error from yours, though:
>>>
>>> /workspace/src/tests/sys/netinet/libalias/util.c: In function
>>> 'set_udp':
>>> /workspace/src/tests/sys/netinet/libalias/util.c:112:2: error:
>>> converting a packed 'struct ip' pointer (alignment 2) to a 'uint32_t'
>>> {aka 'unsigned int'} pointer (alignment 4) may result in an unaligned
>>> pointer value [-Werror=address-of-packed-member]
>>>112 | uint32_t *up = (void *)p;
>>>| ^~~~
>>> In file included from
>>> /workspace/src/tests/sys/netinet/libalias/util.h:37,
>>> from /workspace/src/tests/sys/netinet/libalias/util.c:39:
>>> /workspace/src/sys/netinet/ip.h:51:8: note: defined here
>>> 51 | struct ip {
>>>|^~
>>>
>>> -Dimitry
>>>
>> Thanks for information. I went back the commit history of main branch
>> about every month and check if buildworld succeeds with GCC. But it
>> didn't succeed even if I went back about a year. And devel/binutils
>> port was update to 2.37 on last August. So I suspect external GCC
>> toolchain doesn't work well after binutils is updated to current
>> version.
>
> I have amd64 world + kernel building with GCC 9 and the only remaining
> open review not merged yet is https://reviews.freebsd.org/D34147.
>
> It is work to keep it working though and I hadn't worked on it again
> until recently.
Thanks for letting me know. I tried patch of the review and confirmed
both buildworld and buildkernel succeed with GCC 9 and binutils 2.37.
So I reached start point now and can test binutils 2.38.
---
Yasuhiro Kimura
Re: Buildworld fails with external GCC toolchain
From: Dimitry Andric
Subject: Re: Buildworld fails with external GCC toolchain
Date: Fri, 11 Feb 2022 22:53:44 +0100
> Not really, the gcc 9 build has been broken for months, as far as I know.
>
> See also: https://ci.freebsd.org/job/FreeBSD-main-amd64-gcc9_build/
>
> The last build(s) show a different error from yours, though:
>
> /workspace/src/tests/sys/netinet/libalias/util.c: In function 'set_udp':
> /workspace/src/tests/sys/netinet/libalias/util.c:112:2: error: converting a
> packed 'struct ip' pointer (alignment 2) to a 'uint32_t' {aka 'unsigned int'}
> pointer (alignment 4) may result in an unaligned pointer value
> [-Werror=address-of-packed-member]
> 112 | uint32_t *up = (void *)p;
> | ^~~~
> In file included from /workspace/src/tests/sys/netinet/libalias/util.h:37,
> from /workspace/src/tests/sys/netinet/libalias/util.c:39:
> /workspace/src/sys/netinet/ip.h:51:8: note: defined here
>51 | struct ip {
> |^~
>
> -Dimitry
>
Thanks for information. I went back the commit history of main branch
about every month and check if buildworld succeeds with GCC. But it
didn't succeed even if I went back about a year. And devel/binutils
port was update to 2.37 on last August. So I suspect external GCC
toolchain doesn't work well after binutils is updated to current
version.
---
Yasuhiro Kimura
Buildworld fails with external GCC toolchain
Hello, I'm tring to update devel/binutils port to 2.38. When it was updated to 2.37.1, there was a suggestion that it should also be checked if building base system with GCC succeeds as binutils is a part of external GCC toolchain. So I'd like to do it with binutils 2.38 before updating the port. And as a preparation for it, I tried building base system with current external GCC toolchain (that is, with binutils 2.37.1). At first I read following wiki pages. https://wiki.freebsd.org/ExternalToolchain https://wiki.freebsd.org/ExternalGCC Next I took following steps. 1. Make clean install of 14-CURRENT amd64 with the install image of 20220210 snapshot. 2. Checkout latest main of src repository (d4b0fa45dc1 at that time). 3. pkg install amd64-gcc9 4. cd /usr/src 5. make -j 4 CROSS_TOOLCHAIN=amd64-gcc9 buildworld buildkernel Then step 5 failed as following. -- --- all_subdir_rescue --- /usr/local/bin/x86_64-unknown-freebsd14.0-ld: nc.lo: in function `_$$hide$$ nc.lo main': (.text.startup+0xd42): warning: warning: mktemp() possibly used unsafely; consider using mkstemp() /usr/local/bin/x86_64-unknown-freebsd14.0-ld: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libncursesw_real.a(lib_set_term.o): in function `_nc_setupscreen_sp': /usr/src/contrib/ncurses/ncurses/base/lib_set_term.c:415: undefined reference to `_nc_set_buffer_sp' /usr/local/bin/x86_64-unknown-freebsd14.0-ld: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libncursesw_real.a(lib_tstp.o): in function `handle_SIGTSTP': /usr/src/contrib/ncurses/ncurses/tty/lib_tstp.c:222: undefined reference to `flushinp_sp' /usr/local/bin/x86_64-unknown-freebsd14.0-ld: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libncursesw_real.a(lib_getch.o): in function `check_mouse_activity': /usr/src/contrib/ncurses/ncurses/base/lib_getch.c:188: undefined reference to `_nc_timed_wait' /usr/local/bin/x86_64-unknown-freebsd14.0-ld: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libncursesw_real.a(lib_getstr.o): in function `wgetnstr': /usr/src/contrib/ncurses/ncurses/base/lib_getstr.c:106: undefined reference to `erasechar_sp' /usr/local/bin/x86_64-unknown-freebsd14.0-ld: /usr/src/contrib/ncurses/ncurses/base/lib_getstr.c:107: undefined reference to `killchar_sp' collect2: error: ld returned 1 exit status *** [rescue] Error code 1 make[5]: stopped in /usr/obj/usr/src/amd64.amd64/rescue/rescue --- all_subdir_stand --- make[2]: stopped in /usr/src --- all_subdir_share --- make[2]: stopped in /usr/src --- all_subdir_rescue --- 1 error make[5]: stopped in /usr/obj/usr/src/amd64.amd64/rescue/rescue *** [rescue] Error code 2 make[4]: stopped in /usr/src/rescue/rescue 1 error make[4]: stopped in /usr/src/rescue/rescue make[3]: stopped in /usr/src/rescue make[2]: stopped in /usr/src --- all_subdir_lib --- make[2]: stopped in /usr/src 167.49 real 492.07 user94.42 sys make[1]: stopped in /usr/src make: stopped in /usr/src -- If I check commit messages of main branch over the last few months, I can find some commits that fix warning message displayed by GCC. So currently external GCC toolchain seems to work fine. Then what is the cause of my build failure? Did I do something wrong? Best Regards. --- Yasuhiro Kimura
Re: Kernel panic by executing `poudriere bulk`
From: Mateusz Guzik Subject: Re: Kernel panic by executing `poudriere bulk` Date: Fri, 26 Nov 2021 20:33:22 +0100 > On 11/26/21, Yasuhiro Kimura wrote: >> yasu@rolling-vm-freebsd1[1015]% uname -a >> ~ >> FreeBSD rolling-vm-freebsd1.home.utahime.org 14.0-CURRENT FreeBSD >> 14.0-CURRENT #0 main-n251115-ae92ace05fd: Sat Nov 27 01:47:15 JST 2021 >> ro...@rolling-vm-freebsd1.home.utahime.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC >> amd64 >> yasu@rolling-vm-freebsd1[1016]% >> >> After regular weekly update of my 14-current amd64 system, kernel >> panic happens when I execute `poudriere bulk`. >> >> Snapshot of console: >> https://www.utahime.org/FreeBSD/FreeBSD-14-CURRENT-amd64-main-n251115-ae92ace05fd.panic.png >> > > Should be fixed by > https://cgit.freebsd.org/src/commit?id=1879021942f56c8b264f4aeb1966b3733908ef62 Confirmed. Thanks for quick fix! --- Yasuhiro Kimura
Kernel panic by executing `poudriere bulk`
yasu@rolling-vm-freebsd1[1015]% uname -a ~ FreeBSD rolling-vm-freebsd1.home.utahime.org 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n251115-ae92ace05fd: Sat Nov 27 01:47:15 JST 2021 ro...@rolling-vm-freebsd1.home.utahime.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 yasu@rolling-vm-freebsd1[1016]% After regular weekly update of my 14-current amd64 system, kernel panic happens when I execute `poudriere bulk`. Snapshot of console: https://www.utahime.org/FreeBSD/FreeBSD-14-CURRENT-amd64-main-n251115-ae92ace05fd.panic.png --- 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), )) {
^
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, ))
^
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
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
Build of devel/ninja and lang/gcc11 fails with latest 14-CURRENT amd64
)) | ^ 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: 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
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: 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"
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"
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: 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"
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: 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"
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: 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"
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: 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: 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
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: 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
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
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: 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: 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: 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"
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: 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"
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: 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: 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"
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"
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"
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"
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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: /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: 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: 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: 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: 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"
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: 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"
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: 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"
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: 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"
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"
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"
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"
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: 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: 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"
`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: 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"
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: 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"
