Re: Entropy error blocks lang/python38 installation
On Wed, Jun 16, 2021 at 03:42:35AM +, Thomas Mueller wrote: > I believe I must apply the fix/workaround every time. The entropy state gets stored on shutdown and reloaded on next boot. Fixing it once is enough. > Last time I looked at the releng wiki page, I noticed that there were > issues that prevented the netbsd-10 branch, and no time estimate for > the branch. > > Entropy bug was not mentioned specifically, but clearly it is a blocker. It is there, in the top list of blockers: - handling of randomness and seed file need to be decided (more below, waiting for randot) Martin
Re: Entropy error blocks lang/python38 installation
from Martin Musemann: > On Tue, Jun 15, 2021 at 09:24:01AM +, Thomas Mueller wrote: > > This entropy thing seems crazy to me > It is! But it also is: > - a one time only thing (supposed to happen when you set the machine up >for the first time) > - a current only issue > - only affecting some machines > - a blocker for the netbsd-10 branch > Unfortunatley there is no consensus yet how to deal with it better. > Martin I believe I must apply the fix/workaround every time. meaning every booted session where I would build packages from pkgsrc. Had I known the next point, I might have tried to upgrade to releng-9 (NetBSD 9.2_STABLE) instead of HEAD, if the cvs checkout and update didn't get stuck on a broken pipe. But I don't really know if that would have helped regarding pkgsrc problems. NetBSD 9.99.82 has reduced functionality compared to 8.99.51. I can still use some old packages, but much less than with 8.99.51. Last time I looked at the releng wiki page, I noticed that there were issues that prevented the netbsd-10 branch, and no time estimate for the branch. Entropy bug was not mentioned specifically, but clearly it is a blocker. Tom
daily CVS update output
Updating src tree: P src/external/gpl3/gcc/README.gcc10 P src/external/gpl3/gcc/dist/gcc/config.gcc P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earm/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earm/symver-config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmeb/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmeb/symver-config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmhf/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmhf/symver-config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmhfeb/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmhfeb/symver-config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv4/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv4/gstdint.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv4/symver-config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv4eb/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv4eb/symver-config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv6/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv6/symver-config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv6eb/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv6eb/symver-config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv6hf/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv6hf/symver-config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv6hfeb/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv6hfeb/symver-config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv7/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv7/symver-config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv7eb/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv7eb/symver-config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv7hf/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv7hf/symver-config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv7hfeb/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv7hfeb/symver-config.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earm/configargs.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earm/defs.mk P src/external/gpl3/gcc/usr.bin/gcc/arch/earm/gtyp-input.list P src/external/gpl3/gcc/usr.bin/gcc/arch/earm/tm.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earmeb/configargs.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earmeb/defs.mk P src/external/gpl3/gcc/usr.bin/gcc/arch/earmeb/gtyp-input.list P src/external/gpl3/gcc/usr.bin/gcc/arch/earmeb/tm.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earmhf/configargs.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earmhf/defs.mk P src/external/gpl3/gcc/usr.bin/gcc/arch/earmhf/gtyp-input.list P src/external/gpl3/gcc/usr.bin/gcc/arch/earmhf/tm.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earmhfeb/configargs.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earmhfeb/defs.mk P src/external/gpl3/gcc/usr.bin/gcc/arch/earmhfeb/gtyp-input.list P src/external/gpl3/gcc/usr.bin/gcc/arch/earmhfeb/tm.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv4/configargs.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv4/defs.mk P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv4/gtyp-input.list P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv4/tm.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv4eb/configargs.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv4eb/defs.mk P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv4eb/gtyp-input.list P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv4eb/tm.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv6/configargs.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv6/defs.mk P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv6/gtyp-input.list P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv6/tm.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv6eb/configargs.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv6eb/defs.mk P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv6eb/gtyp-input.list P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv6eb/tm.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv6hf/configargs.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv6hf/defs.mk P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv6hf/gtyp-input.list P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv6hf/tm.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv6hfeb/configargs.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv6hfeb/defs.mk P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv6hfeb/gtyp-input.list P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv6hfeb/tm.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv7/configargs.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv7/defs.mk P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv7/gtyp-input.list P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv7/tm.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv7eb/configargs.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv7eb/defs.mk P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv7eb/gtyp-input.list P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv7eb/tm.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv7hf/configargs.h P
Re: Entropy error blocks lang/python38 installation
from Thomas Klausner: > On Mon, Jun 14, 2021 at 10:24:23PM +, Thomas Mueller wrote: > > Another old bug has popped up that I thought was fixed some time ago for > > NetBSD-current and releng-9: > > [ 190470.442443] wd1d: error writing fsbn 2316146760 of > > 2316146760-2316146791 (wd1 bn 2316146760; cn 2297764 tn 10 sn 18) > > [ 190480.442412] wd1d: device timeout writing fsbn 2316146792 of > > 2316146792-2316146823 (wd1 bn 2316146792; cn 2297764 tn 10 sn 50), xfer 40, > > retry 0 > These look like hardware errors to me - the disk starts failing. > Thomas This is the same error/bug that hit me in NetBSD 8.99.51 and earlier 8.99.x, but never with 7.99.1 or FreeBSD. Tom
Re: Script command under NetBSD-current
On Tuesday 15 Jun 2021 08:15:12 RVP wrote:
> On Mon, 14 Jun 2021, Dave Tyson wrote:
> > NetBSD cruncher2.anduin.org.uk 9.99.83 NetBSD 9.99.83 (GENERIC) #2: Tue
> > Jun 8 19:42:49 GMT 2021
> > r...@cruncher2.anduin.org.uk:/usr/obj/sys/arch/amd64/compile/GENERIC amd64
> >
> > If you issue a script command, run a process with takes a little while and
> > then an exit command to close the script file and return to a command
> > prompt. viz:
> >
> > cd /usr/pkgsrc
> > script /tmp/ll
> > cvs update -dP
> > exit
> >
> > what happens is you don't get a command prompt - its like the script
> > command
> > freezes and doesn't return. Issuing a ps shows the script processes:
> The small patch below fixes it for me.
>
> --- START PATCH ---
> --- libexec/ld.elf_so.orig/rtld.c 2020-09-22 00:41:27.0 +
> +++ libexec/ld.elf_so/rtld.c 2021-06-15 08:11:34.301709238 +
> @@ -1750,6 +1750,8 @@
> sigdelset(, SIGTRAP); /* Allow the debugger */
> sigprocmask(SIG_BLOCK, , mask);
>
> + membar_enter();
> +
> for (;;) {
> if (atomic_cas_uint(&_rtld_mutex, 0, locked_value) == 0) {
> membar_enter();
> --- END PATCH ---
>
> -RVP
Thanks for the fast response and fix. I can confirm the patch fixes the
problem. Please can this be committed
Cheers,
Dave
Re: ``ddump -W'' fails in /etc/daily
FWIW, the [*] tag was intended to lead to: [*] The drive had a little help on the path to failure - my new puppy pulled on the cable and the drive experienced a free-fall of approximately 20 inches (0.5 meters). It seemed to work for a short while, but then totally locked up and won't even complete the auto-conf discovery process. :-( On Tue, 15 Jun 2021, Paul Goyette wrote: I have the following entry in my /etc/fstab file: ... NAME=backups/backup ffs rw,noauto ... This is for a removable USB drive which is used to store various backups (as suggested by the label!). Most of the time, the drive is _not_connected_ - I only plug it in when I am actively doing a backup. Previously, the backup drive was labeled with disklabel(8), and the fstab entry specified ``/dev/sd0e''. Everything was fine. But that old backup device failed [*] so I had to replaced it, and I decided to use gpt(8) labels instead. Now, the daily job complains with the following message: Uptime: 3:15AM up 2 days, 7:49, 2 users, load averages: 0.00, 0.00, 0.00 DUMP: can't resolve mount point NAME=backups (no match for `backups'): Nosuch process DUMP: The ENTIRE dump is aborted. This would seem to be generated by the following: if [ -s /etc/dumpdates ] ; then dump -W > $TMP2 fi This behavior seems sub-optimal to me! Should I submit a PR? ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | || | pgoyett...@gmail.com | ++--+--+ !DSPAM:60c8a300140861428417275! ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | || | pgoyett...@gmail.com | ++--+--+
``ddump -W'' fails in /etc/daily
I have the following entry in my /etc/fstab file: ... NAME=backups/backup ffs rw,noauto ... This is for a removable USB drive which is used to store various backups (as suggested by the label!). Most of the time, the drive is _not_connected_ - I only plug it in when I am actively doing a backup. Previously, the backup drive was labeled with disklabel(8), and the fstab entry specified ``/dev/sd0e''. Everything was fine. But that old backup device failed [*] so I had to replaced it, and I decided to use gpt(8) labels instead. Now, the daily job complains with the following message: Uptime: 3:15AM up 2 days, 7:49, 2 users, load averages: 0.00, 0.00, 0.00 DUMP: can't resolve mount point NAME=backups (no match for `backups'): Nosuch process DUMP: The ENTIRE dump is aborted. This would seem to be generated by the following: if [ -s /etc/dumpdates ] ; then dump -W > $TMP2 fi This behavior seems sub-optimal to me! Should I submit a PR? ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | || | pgoyett...@gmail.com | ++--+--+
Re: Script command under NetBSD-current
On Mon, 14 Jun 2021, Dave Tyson wrote:
NetBSD cruncher2.anduin.org.uk 9.99.83 NetBSD 9.99.83 (GENERIC) #2: Tue Jun 8
19:42:49 GMT 2021
r...@cruncher2.anduin.org.uk:/usr/obj/sys/arch/amd64/compile/GENERIC amd64
If you issue a script command, run a process with takes a little while and
then an exit command to close the script file and return to a command prompt.
viz:
cd /usr/pkgsrc
script /tmp/ll
cvs update -dP
exit
what happens is you don't get a command prompt - its like the script command
freezes and doesn't return. Issuing a ps shows the script processes:
The small patch below fixes it for me.
--- START PATCH ---
--- libexec/ld.elf_so.orig/rtld.c 2020-09-22 00:41:27.0 +
+++ libexec/ld.elf_so/rtld.c2021-06-15 08:11:34.301709238 +
@@ -1750,6 +1750,8 @@
sigdelset(, SIGTRAP); /* Allow the debugger */
sigprocmask(SIG_BLOCK, , mask);
+ membar_enter();
+
for (;;) {
if (atomic_cas_uint(&_rtld_mutex, 0, locked_value) == 0) {
membar_enter();
--- END PATCH ---
-RVP
Re: Entropy error blocks lang/python38 installation
On Tue, Jun 15, 2021 at 09:24:01AM +, Thomas Mueller wrote: > This entropy thing seems crazy to me It is! But it also is: - a one time only thing (supposed to happen when you set the machine up for the first time) - a current only issue - only affecting some machines - a blocker for the netbsd-10 branch Unfortunatley there is no consensus yet how to deal with it better. Martin
Re: Entropy error blocks lang/python38 installation
> Hi, > This problem was reported/discussed several time I believe and I guess > it does not have final solution yet (you can check this thread: > http://mail-index.netbsd.org/tech-security/2021/01/11/msg001100.html). > However, there are workarounds to build python38 now. > One described here > https://mail-index.netbsd.org/current-users/2020/05/01/msg038495.html, > you can fool system into believing that it has enough entropy: > dd if=/dev/urandom of=/dev/random bs=32 count=1 > sysctl -w kern.entropy.consolidate=1 -> These two lines enabled me to build lang/python38 where otherwise it would lead to a system crash and unclean reboot. Now onto other packages. I have a file /extra/entropy.txt on the partition where I keep pkgsrc tree, so I know what to do and don't have to remember perfectly. > Another workaround which also makes python to compile was described in > pkg/55847: https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=55847 > Regards, > Andrius V > On Mon, Jun 14, 2021 at 08:15:27AM +, Thomas Mueller wrote: > > [ 386.3532035] entropy: pid 24617 (python) blocking due to lack of entropy > This means your setup is incomplete. You need to seed entropy, e.g. > by one of the methods in entropy(7) in the "Adding entropy" subsection. > Python is probably stupid, but that is a harder battle to fight. > Martin Thanks for the suggestions! I will surely try when I get the chance. -> succeeded. I want to be able to build packages besides and beyond lang/python38. This entropy thing seems crazy to me, but then having to sanitize Linux kernel headers to be usable for userspace programs also impressed me as crazy. On the other computer, I was on FreeBSD-current mass-building packages with synth. Partially successful, some sloppy bugs, packages failed to install, and graphical web browsers all were skipped because lang/rust, a dependency, failed. Tom
Re: Xen panics in autoconf
On Tue, Jun 15, 2021 at 09:17:17AM +0200, Manuel Bouyer wrote: > Hello, > some recent changes broke Xen: > [ 2.919] panic: kernel diagnostic assertion "KERNEL_LOCKED_P()" failed: > file "/usr/src/sys/kern/subr_autoconf.c", line 1039 > [ 2.919] cpu0: Begin traceback... > [ 2.919] > vpanic(c05be3c0,cd02ddb8,cd02ddd4,c0415210,c05be3c0,c05be322,c05c6cc1,c05f4284,40f,cd02de18) > at netbsd:vpanic+0x139 > [ 2.919] > kern_assert(c05be3c0,c05be322,c05c6cc1,c05f4284,40f,cd02de18,c0b84b60,0,cd02ddf4,c0415270) > at netbsd:kern_assert+0x23 > [ 2.919] > config_match(c12e6c00,c0b84b60,cd02ded8,c0b84b60,c0b84b60,c12e6c00,cd02de3c,c04155d2,cd02de18,c0428627) > at netbsd:config_match+0x90 > [ 2.0100679] > mapply(cd02de18,c0428627,0,c12e5dc0,,c0cb6524,cd02de18,0,c12e6c00,0) > at netbsd:mapply+0x50 > [ 2.0100679] > config_vsearch(c12e6c00,cd02ded8,,cd02dea0,cd02de88,c01120af,0,c1460278,cd02dee6,c05c06cd) > at netbsd:config_vsearch+0x212 > [ 2.0100679] > config_vfound(c12e6c00,cd02ded8,c0111f20,,cd02dea0,cd02df00,c0112638,c12e6c00,cd02ded8,c0111f20) > at netbsd:config_vfound+0x2f > [ 2.0100679] > config_found(c12e6c00,cd02ded8,c0111f20,,a,8,0,c12ddf54,0,c12c21f0) > at netbsd:config_found+0x2d > [ 2.0100679] > xenbus_probe_device_type(cd02df2e,1e,c05c0734,c12ddf54,cd02df24,4,c12ddf44,c12ddf44,2,6564) > at netbsd:xenbus_probe_device_type+0x498 > [ 2.0100679] > xenbus_probe_frontends.isra.0(60,2,0,c0113430,0,c05bec62,0,0,cd02df9c,c0112e65) > at netbsd:xenbus_probe_frontends.isra.0+0xbb > [ 2.0100679] > xenbus_probe(0,c05c076d,6,c1453c00,0,c0102031,c1453c00,d99000,c0b92200,0) at > netbsd:xenbus_probe+0x2d > [ 2.0100679] > xenbus_probe_init(c1453c00,d99000,c0b92200,0,c0100084,0,0,0,0,0) at > netbsd:xenbus_probe_init+0x85 > [ 2.0100679] cpu0: End traceback... > > Any idea what changed recently ? The KASSERT was added :-) xenbus_probe_init should hold the kernel lock? Martin
Xen panics in autoconf
Hello, some recent changes broke Xen: [ 2.919] panic: kernel diagnostic assertion "KERNEL_LOCKED_P()" failed: file "/usr/src/sys/kern/subr_autoconf.c", line 1039 [ 2.919] cpu0: Begin traceback... [ 2.919] vpanic(c05be3c0,cd02ddb8,cd02ddd4,c0415210,c05be3c0,c05be322,c05c6cc1,c05f4284,40f,cd02de18) at netbsd:vpanic+0x139 [ 2.919] kern_assert(c05be3c0,c05be322,c05c6cc1,c05f4284,40f,cd02de18,c0b84b60,0,cd02ddf4,c0415270) at netbsd:kern_assert+0x23 [ 2.919] config_match(c12e6c00,c0b84b60,cd02ded8,c0b84b60,c0b84b60,c12e6c00,cd02de3c,c04155d2,cd02de18,c0428627) at netbsd:config_match+0x90 [ 2.0100679] mapply(cd02de18,c0428627,0,c12e5dc0,,c0cb6524,cd02de18,0,c12e6c00,0) at netbsd:mapply+0x50 [ 2.0100679] config_vsearch(c12e6c00,cd02ded8,,cd02dea0,cd02de88,c01120af,0,c1460278,cd02dee6,c05c06cd) at netbsd:config_vsearch+0x212 [ 2.0100679] config_vfound(c12e6c00,cd02ded8,c0111f20,,cd02dea0,cd02df00,c0112638,c12e6c00,cd02ded8,c0111f20) at netbsd:config_vfound+0x2f [ 2.0100679] config_found(c12e6c00,cd02ded8,c0111f20,,a,8,0,c12ddf54,0,c12c21f0) at netbsd:config_found+0x2d [ 2.0100679] xenbus_probe_device_type(cd02df2e,1e,c05c0734,c12ddf54,cd02df24,4,c12ddf44,c12ddf44,2,6564) at netbsd:xenbus_probe_device_type+0x498 [ 2.0100679] xenbus_probe_frontends.isra.0(60,2,0,c0113430,0,c05bec62,0,0,cd02df9c,c0112e65) at netbsd:xenbus_probe_frontends.isra.0+0xbb [ 2.0100679] xenbus_probe(0,c05c076d,6,c1453c00,0,c0102031,c1453c00,d99000,c0b92200,0) at netbsd:xenbus_probe+0x2d [ 2.0100679] xenbus_probe_init(c1453c00,d99000,c0b92200,0,c0100084,0,0,0,0,0) at netbsd:xenbus_probe_init+0x85 [ 2.0100679] cpu0: End traceback... Any idea what changed recently ? -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
