Re: nothing contributing entropy in Xen domUs? or dom0!!!
At Thu, 1 Apr 2021 04:13:59 + (UTC), RVP wrote:
Subject: Re: nothing contributing entropy in Xen domUs? or dom0!!!
>
> Does this /etc/entropy-file match what's there in your /boot.cfg?
>
> On my laptop $random_file is left at the default which is:
> /var/db/entropy-file
Yes I did change that as well (as /var isn't part of the root partition).
However that's not the problem for the dom0.
"rndseed" isn't currently used (at least not by me or any documentation
I'm aware of) when loading (multibooting) a Xen kernel and a NetBSD dom0
kernel.
/etc/rc.d/random_seed will do this (again) later anyway.
However since as I showed the hardware doesn't seem to be providing
entropy that can be "counted" ("estimated"), there's nothing to save,
and so nothing to load on the next boot either.
I know how to seed it -- but that's not the problem -- the hardware
should be providing plenty of entropy.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpfwaVZQJ63E.pgp
Description: OpenPGP Digital Signature
Re: -current tar(1) breakage
On Thu, 1 Apr 2021, Joerg Sonnenberger wrote:
This should be fixed in the kernel. Seriously, stop adding more code to
deal with garbage from the kernel.
Indeed. Bug #56083 is caused by the wrong function being called:
diff -u /usr/src/sys/fs/puffs/puffs_vfsops.c{.orig,}
--- /usr/src/sys/fs/puffs/puffs_vfsops.c.orig 2020-02-27 22:12:53.0
+
+++ /usr/src/sys/fs/puffs/puffs_vfsops.c2021-03-30 12:02:35.402544154
+
@@ -503,7 +503,7 @@
*/
copy_statvfs_info(sbp, mp);
if (!error) {
- statvfs_to_puffs_statvfs(sbp, _msg->pvfsr_sb);
+ puffs_statvfs_to_statvfs(_msg->pvfsr_sb, sbp);
}
PUFFS_MSG_RELEASE(statvfs);
The statvfs-filling sequence starting at line 219 doesn't look right
either:
219 struct statvfs *sb = STATVFSBUF_GET();
220 puffs_statvfs_to_statvfs(>pa_svfsb, sb);
221 copy_statvfs_info(sb, mp);
222 STATVFSBUF_PUT(sb);
223
224 statvfs_to_puffs_statvfs(>mnt_stat, >pa_svfsb);
-RVP
Re: nothing contributing entropy in Xen domUs? or dom0!!!
At Wed, 31 Mar 2021 21:58:48 -0400, Thor Lancelot Simon wrote: Subject: Re: nothing contributing entropy in Xen domUs? (causing python3.7 rebuild to get stuck in kernel in "entropy" during an "import" statement) > > On Wed, Mar 31, 2021 at 11:24:07AM +0200, Manuel Bouyer wrote: > > On Tue, Mar 30, 2021 at 10:42:53PM +, Taylor R Campbell wrote: > > > > > > There are no virtual RNG devices on the system in question, according > > > to the quoted `rndctl -l' output. Perhaps the VM host needs to be > > > taught to expose a virtio-rng device to the guest? > > > > There is no such thing in Xen. > > Is the CPU so old that it doesn't have RDRAND / RDSEED, or is Xen perhaps > masking these CPU features from the guest? So I don't quite know how to tell for sure (because "cpuid", for one, doesn't seem to even seem to include strings within it to report either of those features, and because figuring it out from the magic names given in places like Wikipedia is too hard), but in theory my CPU is very much new enough to have at least one of those features. In this particular example server it's in a Dell R510 with a pair of 6-core E5645 CPUs that "cpuid" shows the following for (in the dom0): # cpuid eax ineax ebx ecx edx 000b 756e6547 6c65746e 49656e69 0001 000206c2 20200800 029ee3ff bfebfbff 0002 55035a01 00f0b2ff 00ca 0003 0004 3c004121 01c0003f 003f 0005 0040 0040 0003 1120 0006 0007 0002 0001 0007 0008 0009 000a 07300403 0004 0603 000b 0001 0002 0100 0020 8000 8008 8001 0001 2c100800 8002 65746e49 2952286c 6f655820 2952286e 8003 55504320 20202020 20202020 45202020 8004 35343635 20402020 30342e32 007a4847 8005 8006 01006040 8007 0100 8008 3028 Vendor ID: "GenuineIntel"; CPUID level 11 Intel-specific functions: Version 000206c2: Type 0 - Original OEM Family 6 - Pentium Pro Model 12 - Stepping 2 Reserved 8 Extended brand string: "Intel(R) Xeon(R) CPU E5645 @ 2.40GHz" CLFLUSH instruction cache line size: 8 Initial APIC ID: 32 Hyper threading siblings: 32 Feature flags bfebfbff: FPUFloating Point Unit VMEVirtual 8086 Mode Enhancements DE Debugging Extensions PSEPage Size Extensions TSCTime Stamp Counter MSRModel Specific Registers PAEPhysical Address Extension MCEMachine Check Exception CX8COMPXCHG8B Instruction APIC On-chip Advanced Programmable Interrupt Controller present and enabled SEPFast System Call MTRR Memory Type Range Registers PGEPTE Global Flag MCAMachine Check Architecture CMOV Conditional Move and Compare Instructions FGPAT Page Attribute Table PSE-36 36-bit Page Size Extension CLFSH CFLUSH instruction DS Debug store ACPI Thermal Monitor and Clock Ctrl MMXMMX instruction set FXSR Fast FP/MMX Streaming SIMD Extensions save/restore SSEStreaming SIMD Extensions instruction set SSE2 SSE2 extensions SS Self Snoop HT Hyper Threading TM Thermal monitor 31 reserved TLB and cache info: 5a: unknown TLB/cache descriptor 03: Data TLB: 4KB pages, 4-way set assoc, 64 entries 55: unknown TLB/cache descriptor ff: unknown TLB/cache descriptor b2: unknown TLB/cache descriptor f0: unknown TLB/cache descriptor ca: unknown TLB/cache descriptor Processor serial: 0002-06C2---- Xen does indeed hide features in the vcpu it presents to a PV domU: $ cpuid eax ineax ebx ecx edx 000b 756e6547 6c65746e 49656e69 0001 000206c2 22200800 02982203 1fc9cbf5 0002 55035a01 00f0b2ff 00ca 0003 0004 3c004121 01c0003f 003f 0005 0040 0040 0003 1120 0006 0007 0002 0001 0007 0008 0009 000a 07300403 0004 0603 000b 0001 0002 0100 0022 8000 8008 8001 0001 20100800 8002 65746e49 2952286c 6f655820 2952286e 8003 55504320 20202020 20202020 45202020 8004 35343635 20402020 30342e32 007a4847 8005 8006 01006040 8007 0100 8008 3028 Vendor ID: "GenuineIntel"; CPUID level 11 Intel-specific functions: Version 000206c2: Type 0 - Original OEM Family 6 - Pentium Pro Model 12 - Stepping 2
Re: -current tar(1) breakage
On Wed, 31 Mar 2021, Christos Zoulas wrote: What is the NFS server? Because on NetBSD it returns 255... $ uname -a NetBSD x202e.localdomain 9.99.81 NetBSD 9.99.81 (GENERIC) #0: Sat Mar 27 02:58:39 UTC 2021 mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64 It doesn't happen usually. I was only able to reproduce Hauke's SEGV by mounting an ext2 FS on /mnt; exporting /mnt via NFS as /altroot; then unmounting and remounting /mnt: $ sudo mount -r -t ext2fs /dev/dk11 /mnt $ sudo mount -r -t nfs localhost:/mnt /altroot $ mount /dev/dk9 on / type ffs (log, noatime, local) kernfs on /kern type kernfs (local) ptyfs on /dev/pts type ptyfs (local) procfs on /proc type procfs (local) tmpfs on /var/shm type tmpfs (local) tmpfs on /tmp type tmpfs (local) /dev/dk11 on /mnt type ext2fs (read-only, local) localhost:/mnt on /altroot type nfs (read-only) $ /tmp/a.out /altroot/work/dmesg.txt a.out: /altroot/work/dmesg.txt: statvfs failed: Permission denied $ sudo pkill -HUP mountd $ /tmp/a.out /altroot/work/dmesg.txt svfs.f_frsize: 512 svfs.f_iosize: 32768 svfs.f_bsize: 512 svfs.f_namemax: 0 $ -RVP
daily CVS update output
Updating src tree: P src/distrib/sets/lists/base/mi P src/distrib/sets/lists/man/mi P src/etc/mtree/NetBSD.dist.base P src/etc/rc.d/named P src/external/cddl/osnet/dist/tools/ctf/cvt/dwarf.c P src/external/cddl/osnet/sbin/zfs/Makefile P src/external/cddl/osnet/sbin/zpool/Makefile P src/external/mpl/bind/Makefile U src/external/mpl/bind/libexec/Makefile U src/external/mpl/bind/libexec/plugin.mk U src/external/mpl/bind/libexec/filter-/Makefile P src/share/man/man4/man4.vax/Makefile U src/share/man/man4/man4.vax/covid.4 P src/share/mk/bsd.own.mk P src/sys/arch/luna68k/luna68k/locore.s P src/sys/arch/mvme68k/mvme68k/locore.s P src/sys/arch/sun2/sun2/locore.s P src/sys/arch/sun3/sun3/locore.s P src/sys/arch/sun3/sun3x/locore.s P src/sys/dev/pci/ixgbe/ix_txrx.c P src/sys/dev/pci/ixgbe/ixgbe.c P src/sys/dev/pci/ixgbe/ixv.c Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 41162478 Apr 1 03:04 ls-lRA.gz
Re: nothing contributing entropy in Xen domUs? (causing python3.7 rebuild to get stuck in kernel in "entropy" during an "import" statement)
On Wed, Mar 31, 2021 at 11:24:07AM +0200, Manuel Bouyer wrote: > On Tue, Mar 30, 2021 at 10:42:53PM +, Taylor R Campbell wrote: > > > > There are no virtual RNG devices on the system in question, according > > to the quoted `rndctl -l' output. Perhaps the VM host needs to be > > taught to expose a virtio-rng device to the guest? > > There is no such thing in Xen. Is the CPU so old that it doesn't have RDRAND / RDSEED, or is Xen perhaps masking these CPU features from the guest? Thor
Re: -current tar(1) breakage
On Wed, Mar 31, 2021 at 05:56:16PM -0400, Christos Zoulas wrote: > What is the NFS server? Because on NetBSD it returns 255... This should be fixed in the kernel. Seriously, stop adding more code to deal with garbage from the kernel. Joerg
Re: -current tar(1) breakage
What is the NFS server? Because on NetBSD it returns 255... statvfs.c Description: Binary data christos > On Mar 31, 2021, at 5:21 PM, RVP wrote: > > On Sat, 27 Mar 2021, Hauke Fath wrote: > >> [...] >> Reading symbols from /bin/tar... >> Reading symbols from /usr/libdata/debug//bin/tar.debug... >> [New process 10317] >> Core was generated by `tar'. >> Program terminated with signal SIGSEGV, Segmentation fault. >> #0 0x7f0a03467866 in _citrus_iconv_convert >> (nresults=0x7f7fff902d18, flags=0, outbytes=0x7f7fff902d98, >> out=0x7f7fff902d90, >> inbytes=0x7f7fff902d88, in=0x7f7fff902d80, cv=0x7f0a057c40e0) at >> /usr/src/lib/libc/citrus/citrus_iconv.h:61 >> 61 _DIAGASSERT(cv && cv->cv_shared && cv->cv_shared->ci_ops && >> (gdb) bt >> #0 0x7f0a03467866 in _citrus_iconv_convert >> (nresults=0x7f7fff902d18, flags=0, outbytes=0x7f7fff902d98, >> out=0x7f7fff902d90, >> inbytes=0x7f7fff902d88, in=0x7f7fff902d80, cv=0x7f0a057c40e0) at >> /usr/src/lib/libc/citrus/citrus_iconv.h:61 >> #1 _iconv (handle=handle@entry=0x7f0a057c40e0, >> in=in@entry=0x7f7fff902d80, szin=szin@entry=0x7f7fff902d88, >> out=out@entry=0x7f7fff902d90, >> szout=szout@entry=0x7f7fff902d98) at >> /usr/src/lib/libc/iconv/iconv.c:97 >> > > This iconv() trace is very misleading. The bug triggered by the > NFS server returning 0 for .f_namemax in a statvfs() call. > > Fix: > ---START--- > diff -urN a/libarchive/dist/libarchive/archive_read_disk_posix.c > b/libarchive/dist/libarchive/archive_read_disk_posix.c > --- a/libarchive/dist/libarchive/archive_read_disk_posix.c2019-07-24 > 13:50:23.0 + > +++ b/libarchive/dist/libarchive/archive_read_disk_posix.c2021-03-31 > 12:01:37.437510048 + > @@ -1713,7 +1713,7 @@ > t->current_filesystem->noatime = 0; > > /* Set maximum filename length. */ > - t->current_filesystem->name_max = sfs.f_namemax; > + t->current_filesystem->name_max = (sfs.f_namemax == 0) ? NAME_MAX : > sfs.f_namemax; > return (ARCHIVE_OK); > } > > ---END--- > > Isn't the NFS server supposed to return NFS_MAXNAMLEN? > > -RVP signature.asc Description: Message signed with OpenPGP
Re: -current tar(1) breakage
On Sat, 27 Mar 2021, Hauke Fath wrote: [...] Reading symbols from /bin/tar... Reading symbols from /usr/libdata/debug//bin/tar.debug... [New process 10317] Core was generated by `tar'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x7f0a03467866 in _citrus_iconv_convert (nresults=0x7f7fff902d18, flags=0, outbytes=0x7f7fff902d98, out=0x7f7fff902d90, inbytes=0x7f7fff902d88, in=0x7f7fff902d80, cv=0x7f0a057c40e0) at /usr/src/lib/libc/citrus/citrus_iconv.h:61 61 _DIAGASSERT(cv && cv->cv_shared && cv->cv_shared->ci_ops && (gdb) bt #0 0x7f0a03467866 in _citrus_iconv_convert (nresults=0x7f7fff902d18, flags=0, outbytes=0x7f7fff902d98, out=0x7f7fff902d90, inbytes=0x7f7fff902d88, in=0x7f7fff902d80, cv=0x7f0a057c40e0) at /usr/src/lib/libc/citrus/citrus_iconv.h:61 #1 _iconv (handle=handle@entry=0x7f0a057c40e0, in=in@entry=0x7f7fff902d80, szin=szin@entry=0x7f7fff902d88, out=out@entry=0x7f7fff902d90, szout=szout@entry=0x7f7fff902d98) at /usr/src/lib/libc/iconv/iconv.c:97 This iconv() trace is very misleading. The bug triggered by the NFS server returning 0 for .f_namemax in a statvfs() call. Fix: ---START--- diff -urN a/libarchive/dist/libarchive/archive_read_disk_posix.c b/libarchive/dist/libarchive/archive_read_disk_posix.c --- a/libarchive/dist/libarchive/archive_read_disk_posix.c 2019-07-24 13:50:23.0 + +++ b/libarchive/dist/libarchive/archive_read_disk_posix.c 2021-03-31 12:01:37.437510048 + @@ -1713,7 +1713,7 @@ t->current_filesystem->noatime = 0; /* Set maximum filename length. */ - t->current_filesystem->name_max = sfs.f_namemax; + t->current_filesystem->name_max = (sfs.f_namemax == 0) ? NAME_MAX : sfs.f_namemax; return (ARCHIVE_OK); } ---END--- Isn't the NFS server supposed to return NFS_MAXNAMLEN? -RVP
Re: python3.7 rebuild stuck in kernel in "entropy" during an "import" statement
Hi Greg
It’s not immediately obvious, but I think you have to seed entropy if there
isn’t “enough”.
It’s worth having a quick read of entropy(7) where there is a write-up. I had
to seed /dev/urandom to unblock a similar build on a headless system (just the
heads/tails output of a random script from another machine was enough).
Rgds
C
> On 30 Mar 2021, at 18:06, Greg A. Woods wrote:
>
> So I've been running a pkg-rolling_replace and one of the packages being
> rebuilt is python3.7, and it has got stuck, apparently on an "entropy"
> wait in the kernel, and it's been in this state for over 24hrs as you
> can see.
>
> The only things the process has open appear to be its stdio descriptors,
> two of which are are open on the log file I was directing all output to.
>
> This is on a Xen domU of a machine running:
>
> $ uname -a
> NetBSD xentastic 9.99.81 NetBSD 9.99.81 (XEN3_DOM0) #1: Tue Mar 23 14:39:55
> PDT 2021
> woods@xentastic:/build/woods/xentastic/current-amd64-amd64-obj/build/src/sys/arch/amd64/compile/XEN3_DOM0
> amd64
>
>
> 09:51 [504] $ ps -lwwp 19875
> UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
> 0 19875 11551 0 85 0 55412 11324 entropy Ipts/0 0:00.27 ./python -E
> -Wi
> /var/package-obj/root/lang/python37/work/.destdir/usr/pkg/lib/python3.7/compileall.py
> -d /usr/pkg/lib/python3.7 -f -x
> bad_coding|badsyntax|site-packages|lib2to3/tests/data
> /var/package-obj/root/lang/python37/work/.destdir/usr/pkg/lib/python3.7
> 09:51 [505] $ ps -uwwp 19875
> USER PID %CPU %MEM VSZ RSS TTY STAT STARTEDTIME COMMAND
> root 19875 0.0 0.1 55412 11324 pts/0 I 9:09PM 0:00.27 ./python -E -Wi
> /var/package-obj/root/lang/python37/work/.destdir/usr/pkg/lib/python3.7/compileall.py
> -d /usr/pkg/lib/python3.7 -f -x
> bad_coding|badsyntax|site-packages|lib2to3/tests/data
> /var/package-obj/root/lang/python37/work/.destdir/usr/pkg/lib/python3.7
> 09:51 [506] $ fstat -p 19875
> USER CMD PID FD MOUNT INUM MODE SZ|DV R/W
> root python 19875 wd /build10645634 drwxr-xr-x1024 r
> root python 198750 /dev/pts 3 crw--- pts/0 rw
> root python 198751 /build 3721223 -rw-r--r-- 28287492 w
> root python 198752 /build 3721223 -rw-r--r-- 28287492 w
> 09:51 [507] $ find /build -inum 3721223
> /build/packages/root/pkg_roll.out
> 09:51 [508] $
>
>
> It was killable -- I sent SIGINT from the tty and it died as expected.
>
>
> Running "make replace" gets it stuck in the same place again, an the
> SIGINT shows the following stack trace:
>
> PYTHONPATH=/var/package-obj/root/lang/python37/work/.destdir/usr/pkg/lib/python3.7
> LD_LIBRARY_PATH=/build/package-obj/root/lang/python37/work/Python-3.7.1
> ./python -E -Wi
> /var/package-obj/root/lang/python37/work/.destdir/usr/pkg/lib/python3.7/compileall.py
> -d /usr/pkg/lib/python3.7 -f -x
> 'bad_coding|badsyntax|site-packages|lib2to3/tests/data'
> /var/package-obj/root/lang/python37/work/.destdir/usr/pkg/lib/python3.7
> ^T
> [ 563859.5589422] load: 0.39 cmd: make 15726 [wait] 0.23u 0.07s 0% 9184k
> make: Working in: /build/package-obj/root/lang/python37/work/Python-3.7.1
> make[1]: Working in: /work/woods/m-NetBSD-pkgsrc-current/lang/python37
> make: Working in: /work/woods/m-NetBSD-pkgsrc-current/lang/python37
> ^T
> [ 563866.4606073] load: 0.36 cmd: make 15726 [wait] 0.23u 0.07s 0% 9184k
> make: Working in: /work/woods/m-NetBSD-pkgsrc-current/lang/python37
> make: Working in: /build/package-obj/root/lang/python37/work/Python-3.7.1
> make[1]: Working in: /work/woods/m-NetBSD-pkgsrc-current/lang/python37
> ^?Traceback (most recent call last):
> File
> "/var/package-obj/root/lang/python37/work/.destdir/usr/pkg/lib/python3.7/compileall.py",
> line 20, in
>from concurrent.futures import ProcessPoolExecutor
> File "", line 1032, in _handle_fromlist
> File
> "/build/package-obj/root/lang/python37/work/.destdir/usr/pkg/lib/python3.7/concurrent/futures/__init__.py",
> line 43, in __getattr__
>from .process import ProcessPoolExecutor as pe
> File
> "/build/package-obj/root/lang/python37/work/.destdir/usr/pkg/lib/python3.7/concurrent/futures/process.py",
> line 53, in
>import multiprocessing as mp
> File
> "/build/package-obj/root/lang/python37/work/.destdir/usr/pkg/lib/python3.7/multiprocessing/__init__.py",
> line 16, in
>from . import context
> File
> "/build/package-obj/root/lang/python37/work/.destdir/usr/pkg/lib/python3.7/multiprocessing/context.py",
> line 5, in
>from . import process
> File
> "/build/package-obj/root/lang/python37/work/.destdir/usr/pkg/lib/python3.7/multiprocessing/process.py",
> line 363, in
>_current_process = _MainProcess()
> File
> "/build/package-obj/root/lang/python37/work/.destdir/usr/pkg/lib/python3.7/multiprocessing/process.py",
> line 347, in __init__
>self._config = {'authkey':
Re: nothing contributing entropy in Xen domUs? (causing python3.7 rebuild to get stuck in kernel in "entropy" during an "import" statement)
> On Wed, Mar 31, 2021 at 12:12:31AM +, Taylor R Campbell wrote: >> This is false. If the VM host provided a viornd(4) device then NetBSD >> would automatically collect, and count, entropy from the host, with no >> manual intervention. > > I would love to see instructions how to do this - I have not seen a working > virond(4) in any of my Xen domU (but that is a very limited sample). While this isn't with Xen, and isn't on -current, but this is what I do for my emulated arm64 system, where the emulator runs on NetBSD/amd64 8.0: #!/bin/sh SMP=4 MEM=8g qemu-system-aarch64 -M virt -cpu cortex-a57 -smp $SMP -m $MEM \ -drive if=none,file=disk.img,id=hd0 -device virtio-blk-device,drive=hd0 \ -netdev type=user,id=net0,hostfwd=tcp::-:22,ipv6=off \ -nographic \ -device virtio-net-device,netdev=net0,mac=00:11:66:33:44:55 \ -device virtio-rng-device \ -kernel netbsd.img -append root=ld4a and the booted system is NetBSD/aarch64 9.0 with the unmodified GENERIC64 kernel: arm64# rndctl -l Source Bits Type Flags cpu3 7824 vm estimate, collect, v, t, dv cpu2 8983 vm estimate, collect, v, t, dv cpu1 8351 vm estimate, collect, v, t, dv cpu0 12436 vm estimate, collect, v, t, dv ld4 8440476 disk estimate, collect, v, t, dt viornd04096 rng estimate, collect, v system-power 0 power estimate, collect, v, t, dt autoconf 72 ??? estimate, collect, t, dt printf0 ??? collect callout 116 skew estimate, collect, v, dv arm64# arm64# dmesg | grep rnd [ 1.10] viornd0 at virtio29: Features: 0x1000 arm64# arm64# dmesg | grep virtio29 [ 1.10] virtio29 at simplebus0 [ 1.10] viornd0 at virtio29: Features: 0x1000 [ 1.10] virtio29: allocated 32768 byte for virtqueue 0 for Entropy request, size 1024 [ 1.10] virtio29: interrupting on GIC irq 77 arm64# When I get to booting a past-rng-rework kernel, I'm fairly certain that only the input from viornd0 will remain as a source with "estimate" in the flags field. Of course, any saved and restored entropy will also count towards the estimate. That said, it doesn't look like the amd64 XEN3_DOMU kernel has either of virtio* or viornd* configured, they're only in the GENERIC and ALL kernel configs. Also, I don't know what has to happen on the XEN "host side" to provide those devices; virtio* is apparently supposed to be made visible via the pci bus (looking at amd64's GENERIC), but by the looks of it, XEN only does "pci passthrough" to physical devices (looking at the comments near the commented-out "pci" config statements in XEN3_DOMU), so no "emulated" PCI bus where the host can provide the host-side of the randomness virtual device? Regards, - Håvard
Re: NVMM failure
On Wed, 31 Mar 2021 at 10:01, Reinoud Zandijk wrote: > > Hi, > > On Mon, Mar 29, 2021 at 10:57:36AM +0100, Chavdar Ivanov wrote: > > One of the patches needs patching... I thought nvmm was upstreamed and > > we didn't need the patches for it? > > > > Index: patch-target_i386_nvmm_all.c > > === > > RCS file: > > /cvsroot/pkgsrc/emulators/qemu/patches/patch-target_i386_nvmm_all.c,v > > Well, the last upstreaming of NVMM bounced and got side railed; the enhanced > version of NVMM adresses some of the issues found. I'm currently in the > process of re-upstreaming it. Could you please try out Qemu 5.2.0nb5 from > emulators/qemu in pkgsrc-current? It can then be pulled up to the latest > pkgsrc fork. 5.2nb5 works fine for me, thanks. > > With regards, > Reinoud > --
Re: nothing contributing entropy in Xen domUs? (causing python3.7 rebuild to get stuck in kernel in "entropy" during an "import" statement)
On Tue, Mar 30, 2021 at 10:42:53PM +, Taylor R Campbell wrote: > > Date: Tue, 30 Mar 2021 23:53:43 +0200 > > From: Manuel Bouyer > > > > On Tue, Mar 30, 2021 at 02:40:18PM -0700, Greg A. Woods wrote: > > > [...] > > > > > > Perhaps the answer is that nothing seems to be contributing anything to > > > the entropy pool. No matter what device I exercise, none of the numbers > > > in the following changes: > > > > yes, it's been this way since the rnd rototill. Virtual devices are > > not trusted. > > > > The only way is to manually seed the pool. > > This is false. The virtual RNG drivers (viornd(4) [1], rump > hyperentropy [2], maybe others) all assume the VM host provides > samples with full entropy. This has always been the case, and this > didn't change at all in the rototill last year. > > There are no virtual RNG devices on the system in question, according > to the quoted `rndctl -l' output. Perhaps the VM host needs to be > taught to expose a virtio-rng device to the guest? There is no such thing in Xen. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: NVMM failure
Hi, On Mon, Mar 29, 2021 at 10:57:36AM +0100, Chavdar Ivanov wrote: > One of the patches needs patching... I thought nvmm was upstreamed and > we didn't need the patches for it? > > Index: patch-target_i386_nvmm_all.c > === > RCS file: > /cvsroot/pkgsrc/emulators/qemu/patches/patch-target_i386_nvmm_all.c,v Well, the last upstreaming of NVMM bounced and got side railed; the enhanced version of NVMM adresses some of the issues found. I'm currently in the process of re-upstreaming it. Could you please try out Qemu 5.2.0nb5 from emulators/qemu in pkgsrc-current? It can then be pulled up to the latest pkgsrc fork. With regards, Reinoud
Automated report: NetBSD-current/i386 build success
The NetBSD-current/i386 build is working again. The following commits were made between the last failed build and the successful build: 2021.03.31.04.57.25 christos src/etc/rc.d/named,v 1.27 2021.03.31.04.58.01 christos src/etc/mtree/NetBSD.dist.base,v 1.234 Logs can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2021.03.html#2021.03.31.04.58.01
