Re: Re: Removing fdisk and bsdlabel (legacy partition tools)
> > Those are the only users in the tree, but not for long :) > > I have some reviews open to remove some old fdisk / diskabel / > bsdlabel invocations from the tree. > > With those applied, for fdisk I see the following references > (excluding sbin/fdisk/* and comments, old examples, etc.): > > contrib/netbsd-tests/sbin/gpt/t_gpt.sh > tests/sys/cddl/zfs/bin/zpool_smi.ksh > > For bsdlabel / disklabel: > > sbin/growfs/tests/legacy_test.pl > tools/regression/msdosfs/msdosfstest-2.sh > tools/regression/tmpfs/t_vnd > tools/tools/nanobsd/legacy.sh > contrib/netbsd-tests/kernel/t_umount.sh > contrib/netbsd-tests/kernel/t_umountstress.sh > contrib/netbsd-tests/sbin/gpt/t_gpt.sh > sbin/newfs/runtest00.sh > sbin/newfs/runtest01.sh i was looking at cd(4) today, and to my surprise, it was full of disklabel references. I haven't looked at the code itself yet, to see how far the documentation has drifted apart from reality, but to most users, our documentation is reality.
Re: 100% CPU time for sysctl command, not killable
procstat(1) kstack could be helpful here. Original Message On 20 Aug 2023, 17:29, Alexander Leidinger wrote: > Hi, sysctl kern.maxvnodes=1048576000 results in 100% CPU and a non-killable > sysctl program. This is somewhat unexpected... Bye, Alexander. -- > http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF > http://www.FreeBSD.org netch...@freebsd.org : PGP 0x8F31830F9F2772BF
Re: /usr/sbin/etcupdate -D/usr/obj/DESTDIRs/main-CA7-chroot -s /usr/main-src -M TARGET_ARCH=armv7 ends up building dtc !
from IRC, i have learned this is working as designed: etcupdate without -B does a build. Also, jrtc27 recently made it so bootstrapping, because otherwise BUILD_WITH_STRICT_TMPPATH doesn't work: https://github.com/freebsd/freebsd-src/commit/d81da4c98328d4ee3fe4c0a85f6874a3c69a1afd Kind regards, Mina Galić Original Message On 13 Aug 2023, 08:32, Mark Millard wrote: > I'd noticed that the etcupdate part of my build procedure has been taking > much time. So I looked with a ps -axldww while it was going on. An example > was: `-- /bin/sh /usr/sbin/etcupdate -D/usr/obj/DESTDIRs/main-CA7-chroot -s > /usr/main-src -M TARGET_ARCH=armv7 `-- make TARGET_ARCH=armv7 -DNO_FILEMON > buildetc `-- make -m /usr/main-src/share/mk -f Makefile.inc1 TARGET=arm > TARGET_ARCH=armv7 buildetc `-- make -f Makefile.inc1 _bootstrap-tools > MK_CROSS_COMPILER=no MK_TOOLCHAIN=no . . . `-- /bin/sh -e -c echo "===> > usr.bin/dtc (obj,all,install)"; cd /usr/main-src/usr.bin/dtc;. . . install > `-- make DIRPRFX=usr.bin/dtc/ all `-- c++ -O2 -pipe -fno-common -DNDEBUG . . > . -c /usr/main-src/usr.bin/dtc/fdt.cc -o fdt.o More may build. This is just > what was present when I happened to look. Seems an odd thing to be happening > for an etcupdate . I'll note that aarch64 targeting aarch64 (self hosted > build) also spends notable time and is likely doing similarly. === Mark > Millard marklmi at yahoo.com
Re: Delay in 14.0-RELEASE cycle and blocking items
> Is there a chance to get pkgbase into 14.0? If not it will take another X > years to have it in 15.0... PkgBase *is* in 14, like it is in 13. The question is just if re@ has the resources (people, time, Hardware) to provide a Repository. Mina Galić
Re: Build breakage with WITH_BEARSSL=1
taking Simon off the list, cuz his auto - reply indicates he's very busy. Either way, t should do it: https://github.com/freebsd/freebsd-src/pull/657 Mina Galić Try PkgBase: https://alpha.pkgbase.live/ Original Message On 23 Feb 2023, 09:57, Mina Galić wrote: > given that this isn't contrib code, we can just fix it in our tree: > > https://github.com/freebsd/freebsd-src/blob/main/sbin/veriexec/veriexec.c#L52 > > Mina Galić > > Try PkgBase: https://alpha.pkgbase.live/ > > Original Message > On 23 Feb 2023, 09:27, Gordon Bergling wrote: > >> Hi Simon, On Mon, Feb 20, 2023 at 09:23:48PM -0800, Simon J. Gerraty wrote: >> > This has been fixed upstream, I'll look at importing an update. Thanks for >> merging the upstream fix. BearSSL is now compiling, but I get a different >> error now while building veriexec. >> /boiler/nfs/src/sbin/veriexec/veriexec.c:53:15: error: a function >> declaration without a prototype is deprecated in all versio ns of C >> [-Werror,-Wstrict-prototypes] veriexec_usage() ^ void This looks to me, that >> the Makefile of veriexec should be updated as well. --Gordon
Re: Build breakage with WITH_BEARSSL=1
given that this isn't contrib code, we can just fix it in our tree: https://github.com/freebsd/freebsd-src/blob/main/sbin/veriexec/veriexec.c#L52 Mina Galić Try PkgBase: https://alpha.pkgbase.live/ Original Message On 23 Feb 2023, 09:27, Gordon Bergling wrote: > Hi Simon, On Mon, Feb 20, 2023 at 09:23:48PM -0800, Simon J. Gerraty wrote: > > This has been fixed upstream, I'll look at importing an update. Thanks for > merging the upstream fix. BearSSL is now compiling, but I get a different > error now while building veriexec. > /boiler/nfs/src/sbin/veriexec/veriexec.c:53:15: error: a function declaration > without a prototype is deprecated in all versio ns of C > [-Werror,-Wstrict-prototypes] veriexec_usage() ^ void This looks to me, that > the Makefile of veriexec should be updated as well. --Gordon
Re: Build breakage with WITH_BEARSSL=1
--- Original Message --- On Thursday, February 16th, 2023 at 08:30, Stephane Rochoy wrote: > Warner Losh i...@bsdimp.com writes: > > > On Wed, Feb 15, 2023, 1:09 PM Mina Galić free...@igalic.co > > wrote: > > > > > Would be nice if we could get upstream to actually fix this, > > > but i don't even know how to submit bugs there… > > > > Agreed. I didn't recall off of the top of my head, so I did the > > quick bandaid. > > > Hi, > > It may be worth contacting BearSSL's maintainer directly: Thomas > Pornin por...@bolet.org. The guy was very responsive and helpful > > back in 2020 :) > > Regards, > -- > Stéphane Rochoy > O: Stormshield after re-reading https://bearssl.org/contrib.html that's exactly what it says to do: "Suggestions, comments, patches and other contributions are welcome. They should simply be sent to me (por...@bolet.org) by email." (reading is hard)
Re: Build breakage with WITH_BEARSSL=1
Would be nice if we could get upstream to actually fix this, but i don't even
know how to submit bugs there…
Mina Galić
Try PkgBase: https://alpha.pkgbase.live/
Original Message
On 15 Feb 2023, 17:07, Warner Losh wrote:
> On Sun, Feb 12, 2023, 3:18 PM Warner Losh wrote:
>
>> On Sun, Feb 12, 2023 at 3:54 AM Gordon Bergling wrote:
>>
>>> Hi,
>>>
>>> I am currently seeing a build breakage when building -CURRENT with
>>> WITH_BEARSSL=1.
>>>
>>> The error is the following
>>>
>>> make[5]: "/boiler/nfs/src/lib/libsecureboot/local.trust.mk" line 109:
>>> warning: "cd /boiler/nfs/src/lib/libsecureboot && 'ls' -1 *.pem t*.asc 2>
>>> /dev/null" returned non-zero status
>>> /boiler/nfs/src/contrib/bearssl/src/rsa/rsa_i62_keygen.c:43:22: error: a
>>> function declaration without a prototype is deprecat ed in all versions of
>>> C [-Werror,-Wstrict-prototypes]
>>> br_rsa_i62_keygen_get()
>>> ^
>>> void
>>> 1 error generated.
>>> --- rsa_i62_keygen.pico ---
>>>
>>> When disabling BEARSSL in the src.conf the build succeeds as usual.
>>>
>>> Has anyone also seen this build error. Sources are very recent and the
>>> src.conf is the following:
>>>
>>> WITH_EXTRA_TCP_STACKS=1
>>> #WITH_BEARSSL=1
>>> WITH_PIE=1
>>> WITH_RETPOLINE=1
>>> WITH_INIT_ALL_ZERO=1
>>> WITH_OPENSSL_KTLS=1
>>> WITHOUT_CLEAN=1
>>>
>>> Any help is very appreciated.
>>
>> What does the following do for you? It's a cut and pasted patch, but it
>> should be clear enough what to do if the mailer mangles it.
>>
>> diff --git a/lib/libbearssl/Makefile.inc b/lib/libbearssl/Makefile.inc
>> index dd0e242c8ef0..2af4864d8441 100644
>> --- a/lib/libbearssl/Makefile.inc
>> +++ b/lib/libbearssl/Makefile.inc
>> @@ -4,4 +4,4 @@ BEARSSL?= ${SRCTOP}/contrib/bearssl
>> BEARSSL_SRC= ${BEARSSL}/src
>>
>> CFLAGS+= -I${BEARSSL}/inc
>> -
>> +CFLAGS+= ${NO_WDEPRECATED_NON_PROTOTYPE}
>
> I went ahead and committed this. Please let me know if the problem persists.
>
> Warner
>
>>
Re: Tooling Integration and Developer Experience
Hi folks, I'd like to first of all thank Warner for all his hard work. Working on infrastructure can seem like pretty thankless work. As an outsider to FreeBSD, but not an outsider to the workings of FLOSS organisations, I just want to remind everyone of one core issue: It's usually insiders, not outside contributors, who do the the thankless infrastructure work. That creates two bottlenecks: People who can work on infrastructure, and people who can review incoming patches and nominate new contributors to become committers. Having a spread out infrastructure that needs to be supported and upgraded means committer time is held up in software upgrade / migration tasks, but it also means that outside contributors spend an unnecessarily long time finding the right avenue to contribute to the right part of the code. Mina Galić Try PkgBase: https://alpha.pkgbase.live/ Original Message On 30 Jan 2023, 13:53, Warner Losh wrote: > On Mon, Jan 30, 2023 at 3:40 AM Kurt Jaeger wrote: > >> Hi, >> >>> > On 1/30/23 02:54, Julian H. Stacey wrote: >>> > The main idea: to prevent information fragmentation and improve >>> > discoverability, cross-referencing abilities, search, etc. >>> >>> With regards to improving discoverability, Phabricator's Owner >>> tool could be a good tactical move: it allow to bind code area to >>> peoples in order to automatically add them to reviews. >> >> If you know phabricator in more detail, is there any kind of tool >> to understand the activity going on ? >> >> In bugs.freebsd.org, there is the dashboard: >> >> https://bugs.freebsd.org/bugzilla/page.cgi?id=dashboard.html >> >> I think we might need something similar to help us understand >> the current state of the phabricator instance and the work >> being done. >> >> Phab allows Dashboards, but no-one had the time to configure some >> queries to provide relevant stats. > > Phab is a terrible tool for discovery. For example, how do I query all the > reviews I've ticked 'OK' that are still open, by non-committers? How do I > flag things as 'interesting to me'? I can tick a flag, but I can't query > flags. Also, I can't get an email address for submitter either. That makes it > more of a pain to land the commit. > > Buzilla is in many ways worse (it's absolutely terrible for doing code > reviews, though it's queryability is much better). In some ways it's better > for changes that are ready to go, since you can upload git format-patch > output, but it too has discoverability issues. > > Github and gitlab pull requests are better in some ways, but worse in others. > The review tool isn't as good as phab, and when you have a lot of them, they > are hard to organize. But it's my preferred way to land patches because it's > absolutely the easiest from a developer point of view to do so: It's one > command (though the commands differ between the two). > > The foundation is funding the CI aspect of this: Getting jobs that developers > and automation can run to gate in place. Until we have that in place and > integrated together, things will be harder. > > But there's two other issues: The FreeBSD project has had a long history of > being behind, regardless of the tools we use. There's a labor shortage to > process these things as well. Second, lots of people want to talk, but few > want to do the work. I tried leading an effort in this area,but grew weary of > the passive-aggressive comments about how I basically sucked for not having > it done already (from the same people that did 0 actual work on it). > > Warner
Re: Consequences of disabling vtrnd
Hi Max, > If this is not the appropriate place, I apologize. > > Installing on an instance on vultr.com from booting from the standard image > hangs. This is pretty well documented, and the equally well documented > workaround is disabling vtrnd. > > But are there lingering consequences from setting hint.vtrnd.disabled in the > boot menu? The man page says virtio_random supplies the guest with > high-quality random bits from the host. With this disabled, is the guest's > entropy pool populated from a different high quality source or does the > workaround leave the guest with only low entropy sources? The main consequence is that we go from: kern.random.random_sources: 'VirtIO Entropy Adapter','Intel Secure Key RNG' kern.random.harvest.mask_symbolic: PURE_VIRTIO,PURE_RDRAND,[CALLOUT],[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED to: kern.random.random_sources: 'Intel Secure Key RNG' kern.random.harvest.mask_symbolic: PURE_RDRAND,[CALLOUT],[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED That is: The virtual machine already had the capability of emulating Intel Secure Key RNG, and we're falling back to that scenario. > Thanks for any reply, > Max Baroi Kind regards, Mina Galić Try PkgBase: https://alpha.pkgbase.live/
Re: Building ZFS disk images
‐‐snip--- *puts on cloud-init contributor hat* > > No, because you might create a VM image once, then instantiate it > > dozens or thousands of times. The firstboot solution is great because > > it lets you reuse the same image file. > > I would continue to argue that the place to fix this is in the > "instantiate tool". ESXI vmfs deals with this all the time > when you clone a disk. And again the "fix at boot" does not > deal with the problem in that if I "instatiate" 10 copies of > a zpool for VM's and then try to mount 2 of them at once on > the host this problem rares it head. Fix the problem as close > to point of creation as possible for minimal issues in all > operations for everyone. a lot of folks use cloud-init for provisioning different Unices onto different virtualisation (cloud) platforms. We could fix it there. We already extend paritions, filesystems and ZFS pools in cloud-init. now, again, one could argue that's the wrong place to do any of that, and we should just be using firstboot. But the problem seems to be that a lot folks out there got into the habit of creating and publishing (FreeBSD) images, seem to have forgotten or never knew about firstboot, and don't to set it. Mina Galić Web: https://igalic.co/ PkgBase: https://alpha.pkgbase.live/
Re: Unofficial PkgBase Repository
On Tuesday, January 5th, 2021 at 23:03, Goran Mekić wrote: > > p.s.: if it feels slow, blame virtio + vnet > > This made it fast for me (rc.conf): > > ifconfig_vtnet0="DHCP -tso -lro" i already have those. see my setup over here: https://lists.freebsd.org/pipermail/freebsd-jail/2021-January/004009.html https://gist.github.com/87ba10c1c5611ed32367d5d48ef5f402 it still feels quite sluggish. I should measure my feelings. ___ 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: Enabling AESNI by default
On Thursday, December 31st, 2020 at 20:51, Allan Jude wrote: > We've had the AESNI module for quite a few years now, and it has not caused > any problems. > > I am wondering if there are any objections to including it in GENERIC, so > that users get the benefit without having to have the "tribal knowledge" that > 'to accelerate kernel crypto (GELI, ZFS, IPSEC, etc), you need to load > aesni.ko' This tribal knowledge is encoded in bsdinstall when you setup encryption on zfs: https://cgit.freebsd.org/src/tree/usr.sbin/bsdinstall/scripts/zfsboot#n1207 Mina ___ 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"
Unofficial PkgBase Repository
Hi folks, Recently I've been working on on building a PkgBase repository The repository is in good enough shape now that I believe it can be announced publicly! https://alpha.pkgbase.live/ is built with poudriere and serves -CURRENT packages for AMD64 and AARCH64. The host itself is still updated with https://up.bsd.lv/ but the jail serving the packages is built and updated with PkgBase. It's hosted on a vServer at Hetzner in Helsinki There's still a number of things to do before I'd consider the repository production quality, hence the domain name. Two of the most important ones are: - Package Signing: https://reviews.freebsd.org/D27690 - HTTP Caching of packages: https://github.com/freebsd/poudriere/pull/751 I will add more more architectures when I hear your feedback on what you would like to see. It would also be nice to add "production" builds `WITHOUT_LLVM_ASSERTIONS` and `WITH_MALLOC_PRODUCTION`. it just feels… wrong until 13 STABLE is branched Happy testing! Looking forward to your feedback. p.s.: if it feels slow, blame virtio + vnet Best regards, Mina Galić Web: https://igalic.co/ ___ 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"
