Re: How to burn a bootable .iso dvd on NetBSD 9.0
Thanks Travis, I found it and making it now. Clay On Tue, Apr 21, 2020 at 11:31 PM Travis Paul wrote: > > > > On Apr 22, 2020, at 5:49 AM, Clay Daniels > wrote: > > > > I want to burn a bootable dvd with NetBSD 9.0. I tried to install > mkisofs, but it says it is not available in the repository. Any suggestions? > > Hi Clay, > > mkisofs is in pkgsrc, it is part sysutils/cdrtools > > Good luck! > Travis >
Re: How to burn a bootable .iso dvd on NetBSD 9.0
> On Apr 22, 2020, at 5:49 AM, Clay Daniels wrote: > > I want to burn a bootable dvd with NetBSD 9.0. I tried to install mkisofs, > but it says it is not available in the repository. Any suggestions? Hi Clay, mkisofs is in pkgsrc, it is part sysutils/cdrtools Good luck! Travis signature.asc Description: Message signed with OpenPGP
How to burn a bootable .iso dvd on NetBSD 9.0
I want to burn a bootable dvd with NetBSD 9.0. I tried to install mkisofs, but it says it is not available in the repository. Any suggestions?
Re: x11-links won't install full package-content
I do use a mix of pre-built binaries and pkgsrc. My SSD isn't big enough to build things like firefox with pkgsrc. Besides, there are a few packages that I want to stay AWAY from but, they are building dependencies of things I use. So, I install the binary, build my stuff and remove the binary. Honestly, if only firefox was offered as a pre-built binary for current, I'd be running current. Although, I can't afford to build firefox. Actually, I'd dump firefox if I had a simpler browser that could replace it. I used Midori as long as I could but it seems to be dead again :( /pin Skickat från ProtonMail mobile Originalmeddelande På 21 apr. 2020 21:27, Greg Troxel skrev: > Chavdar Ivanov writes: > >> x11-links depends on osabi-9.0; it should be available in the repo, >> but I don't use the released pkgin repos myself. If you have pkgsrc >> somewhere, you can build it locally and then continue with the rest >> from the repo. While mixing of packages is normally frowned upon, I >> believe in this case there won't be any trouble. > > about mixing being frowned on: > > If the packages are built with the same pkgsrc sources for the same OS > version, that's fine. > > So if you are using the official 9 builds from amd64 for 2020Q1, check > out that branch for your builds.
X-windows
I found out from the manual that I have an on-board graphics chip. Can this cause the slowness I have been experiencing? Is there a program that allows me to interrogate this board and see what the PCI address of the on-board graphics chip is; and whether this on-board graphics chip is on or off? The last time I ran 'X -configure' , I got a error in the xorg logfile: "no screens found" I recall having this problem in the past. It had something to do with /etc/wsconf.conf. Does the nouveau driver support 1660 chipset yet?
Re: x11-links won't install full package-content
Chavdar Ivanov writes: > x11-links depends on osabi-9.0; it should be available in the repo, > but I don't use the released pkgin repos myself. If you have pkgsrc > somewhere, you can build it locally and then continue with the rest > from the repo. While mixing of packages is normally frowned upon, I > believe in this case there won't be any trouble. about mixing being frowned on: If the packages are built with the same pkgsrc sources for the same OS version, that's fine. So if you are using the official 9 builds from amd64 for 2020Q1, check out that branch for your builds.
Re: x11-links won't install full package-content
x11-links depends on osabi-9.0; it should be available in the repo, but I don't use the released pkgin repos myself. If you have pkgsrc somewhere, you can build it locally and then continue with the rest from the repo. While mixing of packages is normally frowned upon, I believe in this case there won't be any trouble. I follow -current usually; after every bump in the version I run a script which forcibly uninstalls osabi-xxx and all packages depending on it, then builds the latest osabi and subsequently the rest of the packages which depend in it. On Tue, 21 Apr 2020 at 19:43, John m0t wrote: > > hello; > sudo pkgin install x11-links > > (*master+1102) 23:05:37 > calculating dependencies...done. > > 1 package to install: > x11-links-1.31 > > 0 to refresh, 0 to upgrade, 1 to install > 0B to download, 37K to install > > proceed ? [Y/n] y > installing x11-links-1.31... > pkg_install warnings: 0, errors: 2 > pkg_install error log can be found in /var/db/pkgin/pkg_install-err.log > > and building it from pkgsrc won't install full package content. > > ---Apr 20 15:19:35: installing libidn-1.34nb1... > ---Apr 20 15:19:35: installing py37-expat-3.7.5... > ---Apr 20 15:19:37: installing py37-cElementTree-3.7.5... > ---Apr 20 15:19:37: installing xmlcatmgr-2.2nb1... > ---Apr 20 15:19:38: installing icu-64.2nb1... > ---Apr 20 15:19:38: installing jpeg-9cnb1... > ---Apr 20 15:19:38: installing jbigkit-2.1... > ---Apr 20 15:19:38: installing p5-Net-SSLeay-1.85nb2... > ---Apr 20 15:19:40: installing p5-Net-LibIDN-0.12nb11... > ---Apr 20 15:19:40: installing p5-Mozilla-CA-20180117nb2... > ---Apr 20 15:19:40: installing p5-Socket6-0.29nb1... > ---Apr 20 15:19:40: installing p5-Net-IP-1.26nb7... > ---Apr 20 15:19:40: installing p5-IO-Socket-INET6-2.72nb5... > ---Apr 20 15:19:40: installing libunistring-0.9.10... > ---Apr 20 15:19:40: installing gobject-introspection-1.62.0... > Unable to open directory /usr/pkg/lib/gio/modules: Error opening directory > ?/usr/pkg/lib/gio/modules?: No such file or directory > ---Apr 20 15:19:41: installing pcre-8.43... > ---Apr 20 15:19:41: installing lzo-2.10... > ---Apr 20 15:19:41: installing libuuid-2.32.1... > ---Apr 20 15:19:41: installing tiff-4.1.0... > ---Apr 20 15:19:41: installing png-1.6.37... > ---Apr 20 15:19:41: installing python37-3.7.5... > ---Apr 20 15:19:46: installing harfbuzz-2.6.4... > ---Apr 20 15:19:46: installing graphite2-1.3.13... > ---Apr 20 15:19:46: installing fribidi-1.0.8... > ---Apr 20 15:19:46: installing cairo-gobject-1.16.0nb3... > ---Apr 20 15:19:53: installing mozilla-rootcerts-1.0.20191207... > ---Apr 20 15:19:53: installing libffi-3.2.1nb4... > ---Apr 20 15:19:53: installing libxml2-2.9.10nb1... > ---Apr 20 15:19:53: installing nghttp2-1.40.0... > ---Apr 20 15:19:53: installing libidn2-2.3.0... > ---Apr 20 15:19:53: installing p5-GSSAPI-0.28nb10... > ---Apr 20 15:19:53: installing p5-Digest-HMAC-1.03nb9... > ---Apr 20 15:19:53: installing p5-Net-Domain-TLD-1.75nb3... > ---Apr 20 15:19:53: installing p5-Net-DNS-1.21... > ---Apr 20 15:19:53: installing p5-IO-CaptureOutput-1.1105... > ---Apr 20 15:19:54: installing p5-TimeDate-2.30nb6... > ---Apr 20 15:19:54: installing p5-IO-Socket-SSL-2.060nb1... > ---Apr 20 15:19:54: installing at-spi2-core-2.33.2nb1... > useradd: Warning: home directory `/var/run/dbus' doesn't exist, and -m was > not specified > ---Apr 20 15:19:54: installing enca-1.15... > ---Apr 20 15:19:54: installing libogg-1.3.4nb1... > ---Apr 20 15:19:54: installing shared-mime-info-1.10... > ---Apr 20 15:19:55: installing python27-2.7.17... > ---Apr 20 15:19:57: installing py27-expat-2.7.17... > ---Apr 20 15:19:57: installing pango-1.44.7... > ---Apr 20 15:19:57: installing libXft-2.3.3... > ---Apr 20 15:19:58: installing gdk-pixbuf2-2.40.0... > ---Apr 20 15:19:58: installing fontconfig-2.13.1... > ---Apr 20 15:20:05: installing cairo-1.16.0... > ---Apr 20 15:20:05: installing atk-2.33.3... > ---Apr 20 15:20:05: installing libexif-0.6.21nb1... > ---Apr 20 15:20:05: installing glib2-2.62.3... > Unable to open directory /usr/pkg/lib/gio/modules: Error opening directory > ?/usr/pkg/lib/gio/modules?: No such file or directory > ---Apr 20 15:20:06: installing ncurses-6.1nb6... > ---Apr 20 15:20:07: installing perl-5.30.1... > ---Apr 20 15:20:10: installing pcre2-10.34... > ---Apr 20 15:20:10: installing p5-Net-SMTP-SSL-1.04nb3... > ---Apr 20 15:20:10: installing p5-MailTools-2.20nb2... > ---Apr 20 15:20:10: installing p5-Error-0.17028... > ---Apr 20 15:20:10: installing p5-Email-Valid-1.202nb3... > ---Apr 20 15:20:10: installing p5-Authen-SASL-2.16nb7... > ---Apr 20 15:20:10: installing curl-7.67.0... > ---Apr 20 15:20:11: installing dbus-1.12.16... > ---Apr 20 15:20:11: installing xvidcore-1.3.3nb1... > ---Apr 20 15:20:11: installing x264-devel-20190312nb1... > ---Apr 20 15:20:11: installing
x11-links won't install full package-content
hello; sudo pkgin install x11-links (*master+1102) 23:05:37 calculating dependencies...done. 1 package to install: x11-links-1.31 0 to refresh, 0 to upgrade, 1 to install 0B to download, 37K to install proceed ? [Y/n] y installing x11-links-1.31... pkg_install warnings: 0, errors: 2 pkg_install error log can be found in /var/db/pkgin/pkg_install-err.log and building it from pkgsrc won't install full package content. ---Apr 20 15:19:35: installing libidn-1.34nb1... ---Apr 20 15:19:35: installing py37-expat-3.7.5... ---Apr 20 15:19:37: installing py37-cElementTree-3.7.5... ---Apr 20 15:19:37: installing xmlcatmgr-2.2nb1... ---Apr 20 15:19:38: installing icu-64.2nb1... ---Apr 20 15:19:38: installing jpeg-9cnb1... ---Apr 20 15:19:38: installing jbigkit-2.1... ---Apr 20 15:19:38: installing p5-Net-SSLeay-1.85nb2... ---Apr 20 15:19:40: installing p5-Net-LibIDN-0.12nb11... ---Apr 20 15:19:40: installing p5-Mozilla-CA-20180117nb2... ---Apr 20 15:19:40: installing p5-Socket6-0.29nb1... ---Apr 20 15:19:40: installing p5-Net-IP-1.26nb7... ---Apr 20 15:19:40: installing p5-IO-Socket-INET6-2.72nb5... ---Apr 20 15:19:40: installing libunistring-0.9.10... ---Apr 20 15:19:40: installing gobject-introspection-1.62.0... Unable to open directory /usr/pkg/lib/gio/modules: Error opening directory ?/usr/pkg/lib/gio/modules?: No such file or directory ---Apr 20 15:19:41: installing pcre-8.43... ---Apr 20 15:19:41: installing lzo-2.10... ---Apr 20 15:19:41: installing libuuid-2.32.1... ---Apr 20 15:19:41: installing tiff-4.1.0... ---Apr 20 15:19:41: installing png-1.6.37... ---Apr 20 15:19:41: installing python37-3.7.5... ---Apr 20 15:19:46: installing harfbuzz-2.6.4... ---Apr 20 15:19:46: installing graphite2-1.3.13... ---Apr 20 15:19:46: installing fribidi-1.0.8... ---Apr 20 15:19:46: installing cairo-gobject-1.16.0nb3... ---Apr 20 15:19:53: installing mozilla-rootcerts-1.0.20191207... ---Apr 20 15:19:53: installing libffi-3.2.1nb4... ---Apr 20 15:19:53: installing libxml2-2.9.10nb1... ---Apr 20 15:19:53: installing nghttp2-1.40.0... ---Apr 20 15:19:53: installing libidn2-2.3.0... ---Apr 20 15:19:53: installing p5-GSSAPI-0.28nb10... ---Apr 20 15:19:53: installing p5-Digest-HMAC-1.03nb9... ---Apr 20 15:19:53: installing p5-Net-Domain-TLD-1.75nb3... ---Apr 20 15:19:53: installing p5-Net-DNS-1.21... ---Apr 20 15:19:53: installing p5-IO-CaptureOutput-1.1105... ---Apr 20 15:19:54: installing p5-TimeDate-2.30nb6... ---Apr 20 15:19:54: installing p5-IO-Socket-SSL-2.060nb1... ---Apr 20 15:19:54: installing at-spi2-core-2.33.2nb1... useradd: Warning: home directory `/var/run/dbus' doesn't exist, and -m was not specified ---Apr 20 15:19:54: installing enca-1.15... ---Apr 20 15:19:54: installing libogg-1.3.4nb1... ---Apr 20 15:19:54: installing shared-mime-info-1.10... ---Apr 20 15:19:55: installing python27-2.7.17... ---Apr 20 15:19:57: installing py27-expat-2.7.17... ---Apr 20 15:19:57: installing pango-1.44.7... ---Apr 20 15:19:57: installing libXft-2.3.3... ---Apr 20 15:19:58: installing gdk-pixbuf2-2.40.0... ---Apr 20 15:19:58: installing fontconfig-2.13.1... ---Apr 20 15:20:05: installing cairo-1.16.0... ---Apr 20 15:20:05: installing atk-2.33.3... ---Apr 20 15:20:05: installing libexif-0.6.21nb1... ---Apr 20 15:20:05: installing glib2-2.62.3... Unable to open directory /usr/pkg/lib/gio/modules: Error opening directory ?/usr/pkg/lib/gio/modules?: No such file or directory ---Apr 20 15:20:06: installing ncurses-6.1nb6... ---Apr 20 15:20:07: installing perl-5.30.1... ---Apr 20 15:20:10: installing pcre2-10.34... ---Apr 20 15:20:10: installing p5-Net-SMTP-SSL-1.04nb3... ---Apr 20 15:20:10: installing p5-MailTools-2.20nb2... ---Apr 20 15:20:10: installing p5-Error-0.17028... ---Apr 20 15:20:10: installing p5-Email-Valid-1.202nb3... ---Apr 20 15:20:10: installing p5-Authen-SASL-2.16nb7... ---Apr 20 15:20:10: installing curl-7.67.0... ---Apr 20 15:20:11: installing dbus-1.12.16... ---Apr 20 15:20:11: installing xvidcore-1.3.3nb1... ---Apr 20 15:20:11: installing x264-devel-20190312nb1... ---Apr 20 15:20:11: installing libvpx-1.8.1nb1... ---Apr 20 15:20:11: installing libvorbis-1.3.6nb1... ---Apr 20 15:20:11: installing libva-2.3.0... ---Apr 20 15:20:11: installing libtheora-1.1.1nb2... ---Apr 20 15:20:12: installing libbluray-1.1.2... ---Apr 20 15:20:12: installing libass-0.14.0nb2... ---Apr 20 15:20:12: installing libaom-1.0.0nb2... ---Apr 20 15:20:12: installing lame-3.100nb1... ---Apr 20 15:20:12: installing hicolor-icon-theme-0.17... ---Apr 20 15:20:12: installing at-spi2-atk-2.33.2... ---Apr 20 15:20:12: installing giflib-5.1.4... ---Apr 20 15:20:12: installing menu-cache-1.1.0... ---Apr 20 15:20:13: installing libfm-extra-1.3.0.2nb3... ---Apr 20 15:20:13: installing libfm-1.3.1nb1... The databases in [/usr/pkg/share/applications] could not be updated. ---Apr 20 15:20:13:
Re: DNSSEC vs netbsd-8/sparc?
The problem I reproduced in March (but didn't solve) was on amd64 where the DS didn't match. It used SHA384. Two different examples: https://mail-index.netbsd.org/netbsd-users/2020/03/24/msg024303.html https://mail-index.netbsd.org/netbsd-users/2020/03/20/msg024285.html
Re: DNSSEC vs netbsd-8/sparc?
On Tue, 21 Apr 2020, John D. Baker wrote: > Patch modified for netbsd-7 ( instead of ): My netbsd-7 BIND now generates the proper SHA-1 hash and resolves external domains with DNSSEC enabled. The output of 'dig ' doesn't seem to indicate that DNSSEC is in use--appears the same with it disabled or enabled, although with the broken hash it would report SERVFAIL and wouldn't resolve external domains at all when DNSSEC was enabled. I'll check my netbsd-8/sparc system soon. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: DNSSEC vs netbsd-8/sparc?
Patch modified for netbsd-7 ( instead of ): Index: include/config.h === RCS file: /cvsroot/src/external/bsd/bind/include/Attic/config.h,v retrieving revision 1.20.8.1 diff -u -r1.20.8.1 config.h --- include/config.h21 Jun 2017 18:03:51 - 1.20.8.1 +++ include/config.h21 Apr 2020 14:26:04 - @@ -594,6 +594,11 @@ /* # undef WORDS_BIGENDIAN */ # endif #endif +#else /* __NetBSD__ */ +# include +# if _BYTE_ORDER == _BIG_ENDIAN +# define WORDS_BIGENDIAN 1 +# endif #endif /* Define to empty if `const' does not conform to ANSI C. */ -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: DNSSEC vs netbsd-8/sparc?
On 21/04/2020 17:38, John D. Baker wrote:
I seem to recall the real issue there was "dnssec-lookaside auto" being
set in "named.conf" and the "dlv.isc.org." key in "bind.keys" being
expired. The canned root keys in the file are valid (at least the second
one). If one has the latest updates to netbsd-{7,8,9,current}, the
"bind.keys" file are all up-to-date and identical aside from RCS IDs.
The solution was to comment-out or remove the "dnssec-lookaside" option.
The latter has been done for netbsd-{8,9,current}.
Yes. That was certainly what blew up my DNSSEC nameservers running on
8-stable/amd64. Once I took away the lookaside option dnssec resolution
started working (and I was able to get at the protonmail domain that
triggered the change).
I have no idea if the present problem is related to that or not - just
asking if it was a "netbsd-8 on amd64 works, fails on sparc" clear case.
I have 2 DNS servers running netbsd-8/amd64 and DNSEC both wit the
following DNSSEC options setup:
options {
directory "/etc/namedb";
dnssec-enable yes;
dnssec-validation yes;
#dnssec-lookaside auto;
managed-keys-directory "keys";
bindkeys-file "bind.keys";
}
These are the primary and secondary recursive resolvers for my local
network and I don't see any problems resolving domains. So it is likely
to be a architecture specific issue.
Mike
Re: DNSSEC vs netbsd-8/sparc?
On Tue, 21 Apr 2020, Greg Troxel wrote:
> Havard Eidnes writes:
>
> >> Does anybody think that the bind bits in netbsd-8 are ok, even before we
> >> talk about compilation?
> >
> > I'm about halfway through the diff between what's in-tree in
> > netbsd-8 and what's in ISC BIND 9.10.5-P1, and all I find so far
> > are
>
> I asked because I had trouble maybe two months ago with bind failing to
> resolve protonmailch due to some DNSSEC issue, on amd64, and the same
> problem on earmv7hf-el. The consensus seemed to be that bind and the
> root keys file in 8 is old and probably shouldn't be used.
I seem to recall the real issue there was "dnssec-lookaside auto" being
set in "named.conf" and the "dlv.isc.org." key in "bind.keys" being
expired. The canned root keys in the file are valid (at least the second
one). If one has the latest updates to netbsd-{7,8,9,current}, the
"bind.keys" file are all up-to-date and identical aside from RCS IDs.
The solution was to comment-out or remove the "dnssec-lookaside" option.
The latter has been done for netbsd-{8,9,current}.
> I have no idea if the present problem is related to that or not - just
> asking if it was a "netbsd-8 on amd64 works, fails on sparc" clear case.
As per Havard's previous email, the pre-cooked "config.h" in netbsd-8
(and apparently netbsd-7) omitted a crucial macro that was harmless on
little-ending systems, but caused big-endian architectures (sparc{,64},
powerpc, and various foo-eb) to miscalculate the SHA1 hashes.
--
|/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X
|\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD
| X No HTML/proprietary data in email. BSD just sits there and works!
|/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: DNSSEC vs netbsd-8/sparc?
Havard Eidnes writes: >> Does anybody think that the bind bits in netbsd-8 are ok, even before we >> talk about compilation? > > I'm about halfway through the diff between what's in-tree in > netbsd-8 and what's in ISC BIND 9.10.5-P1, and all I find so far > are I asked because I had trouble maybe two months ago with bind failing to resolve protonmailch due to some DNSSEC issue, on amd64, and the same problem on earmv7hf-el. The consensus seemed to be that bind and the root keys file in 8 is old and probably shouldn't be used. I have no idea if the present problem is related to that or not - just asking if it was a "netbsd-8 on amd64 works, fails on sparc" clear case.
Re: DNSSEC vs netbsd-8/sparc?
On Tue, Apr 21, 2020 at 10:56 AM Havard Eidnes wrote: > > > Does anybody think that the bind bits in netbsd-8 are ok, even before we > > talk about compilation? > > I'm about halfway through the diff between what's in-tree in > netbsd-8 and what's in ISC BIND 9.10.5-P1, and all I find so far > are > ... > Hmm, wait a bit... One commonality between sparc, sparc64 and > macppc is that they're all big-endian. ... and in > external/bsd/bind/include/config.h (which is "pre-cooked" in > NetBSD, but the corresponding file is generated by configure by > the ISC build setup) we find this part: > > /* Define WORDS_BIGENDIAN to 1 if your processor stores words with the most >significant byte first (like Motorola and SPARC, unlike Intel). */ > #ifndef __NetBSD__ > /* Defined by the build process */ > #if defined AC_APPLE_UNIVERSAL_BUILD > # if defined __BIG_ENDIAN__ > # define WORDS_BIGENDIAN 1 > # endif > #else > # ifndef WORDS_BIGENDIAN > /* # undef WORDS_BIGENDIAN */ > # endif > #endif > #endif > > which on NetBSD ends up not defining WORDS_BIGENDIAN ever, which > is OK for little-endian platforms, but not quite for the others. > Let's see... > > Index: include/config.h > === > RCS file: /cvsroot/src/external/bsd/bind/include/Attic/config.h,v > retrieving revision 1.20.8.1 > diff -u -r1.20.8.1 config.h > --- include/config.h21 Jun 2017 18:03:51 - 1.20.8.1 > +++ include/config.h21 Apr 2020 14:26:04 - > @@ -594,6 +594,11 @@ > /* # undef WORDS_BIGENDIAN */ > # endif > #endif > +#else /* __NetBSD__ */ > +# include > +# if _BYTE_ORDER == _BIG_ENDIAN > +# define WORDS_BIGENDIAN 1 > +# endif > #endif > > /* Define to empty if `const' does not conform to ANSI C. */ > > fixes it! After re-building libs and reinstalling them: Yeah, it looks like the preprocessor test is not correct. To test for endianess using modern compilers, like GCC, Clang, XLC and SunCC, you have to test for __LITTLE_ENDIAN__ and __BIG_ENDIAN__. Other tests are unreliable. Jeff
Re: DNSSEC vs netbsd-8/sparc?
On Tue, 21 Apr 2020 08:25:47 -0400 Greg Troxel wrote: > Sad Clouds writes: > > > On Tue, 21 Apr 2020 09:47:45 +0200 (CEST) > > Havard Eidnes wrote: > > > >> So now I'm a bit confused where this error comes from. Its root > >> cause does not seem to be the in-tree compiler (the "standalone" > >> BIND releases I've built are built with "-g -O2"), and it's not > >> the original BIND code either by the looks of it, as this is the > >> same code which is in netbsd-8. > > > > I don't fully understand DNSSEC and how the hash is generated, but > > could it be due to bit rot, i.e. when you created install image, > > some bytes of code/data somewhere could have been corrupted. Maybe > > even source files are corrupted somewhere when you downloaded them? > > Have you tried fresh checkout and rebuilding the same code again, > > and if yes, do you reliably get the same hash mismatch? > > Does anybody think that the bind bits in netbsd-8 are ok, even before > we talk about compilation? Well the original poster mentioned he had this issue with BIND-9.10.5-P1 on NetBSD-8 sparc. He then got the same version of BIND from ISC and built it on the same machine, this time checksum was correct and the issue went away. Not sure if BIND in NetBSD differs in any way from ISC version. If no difference and different people can reproduce the issue, then something somewhere got corrupted, either source code or binary images.
Re: logout delay
Date:Tue, 21 Apr 2020 09:57:51 -0400 From:Greg Troxel Message-ID: | I have a very dim memory of somewhere between init and getty there being | a small delay, so that if getty failed, there wouldn't be a rapid loop. I doubt that is the delay that is being observed. Before getty opens the terminal it does a sleep(2) - that is to guarantee that the terminal remains closed for a detectable time, so that DTR would remain unasserted, and a connected modem would hangup. When getty was written, sleep(2) was the smallest sleep that was guaranteed to actually cause a real delay - sleep(1) simply sleeps (or did) until the clock ticked to the next second, which might be a nanosecond from now. sleep(2) guarantees a dead time of between 1 and 2 seconds. These days we probably don't often care all that much about hanging up modems, and if we did, we could use nanosleep() or usleep() and make a 100ms or so delay more reliably. But: | Is there an actual problem? Exactly. Who cares? kre
Re: DNSSEC vs netbsd-8/sparc?
> Does anybody think that the bind bits in netbsd-8 are ok, even before we
> talk about compilation?
I'm about halfway through the diff between what's in-tree in
netbsd-8 and what's in ISC BIND 9.10.5-P1, and all I find so far
are
- tweak of RCSID tags
- /*CONSTCOND*/ annotation additions
- addition of "pfilter" hooksk
- a couple of "cast via void*" additions
Oh, wait...
diff -ru /usr/pkgsrc/tmp/bind-9.10.5-P1/lib/isc/hmacsha.c
/usr/src/external/bsd/bind/dist/lib/isc/hmacsha.c
...
* This code implements the HMAC-SHA1, HMAC-SHA224, HMAC-SHA256, HMAC-SHA384
@@ -1084,6 +1086,7 @@
void
isc_hmacsha1_invalidate(isc_hmacsha1_t *ctx) {
isc_sha1_invalidate(>sha1ctx);
+ memset(ctx->key, 0, sizeof(ctx->key));
memset(ctx, 0, sizeof(*ctx));
}
...
That can't be it, can it?
...
Nope; I tried reversing this diff, and rebuilt & reinstalled the
BIND libs, and no change.
At least this problem is also evident on NetBSD/powerpc 8.0:
golden-delicious: {2} uname -a
NetBSD golden-delicious.urc.uninett.no 8.0 NetBSD 8.0 (GOLDEN-DELICIOUS) #5:
Tue Feb 26 11:52:02 CET 2019
h...@golden-delicious.urc.uninett.no:/usr/obj/sys/arch/macppc/compile/GOLDEN-DELICIOUS
macppc
golden-delicious: {3} dig . dnskey | dnssec-dsfromkey -f - .
. IN DS 20326 8 1 42CAD163F25D96B28A8413628A2EBEBC8341B1CD
. IN DS 20326 8 2
E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
golden-delicious: {4}
Hmm, wait a bit... One commonality between sparc, sparc64 and
macppc is that they're all big-endian. ... and in
external/bsd/bind/include/config.h (which is "pre-cooked" in
NetBSD, but the corresponding file is generated by configure by
the ISC build setup) we find this part:
/* Define WORDS_BIGENDIAN to 1 if your processor stores words with the most
significant byte first (like Motorola and SPARC, unlike Intel). */
#ifndef __NetBSD__
/* Defined by the build process */
#if defined AC_APPLE_UNIVERSAL_BUILD
# if defined __BIG_ENDIAN__
# define WORDS_BIGENDIAN 1
# endif
#else
# ifndef WORDS_BIGENDIAN
/* # undef WORDS_BIGENDIAN */
# endif
#endif
#endif
which on NetBSD ends up not defining WORDS_BIGENDIAN ever, which
is OK for little-endian platforms, but not quite for the others.
Let's see...
Index: include/config.h
===
RCS file: /cvsroot/src/external/bsd/bind/include/Attic/config.h,v
retrieving revision 1.20.8.1
diff -u -r1.20.8.1 config.h
--- include/config.h21 Jun 2017 18:03:51 - 1.20.8.1
+++ include/config.h21 Apr 2020 14:26:04 -
@@ -594,6 +594,11 @@
/* # undef WORDS_BIGENDIAN */
# endif
#endif
+#else /* __NetBSD__ */
+# include
+# if _BYTE_ORDER == _BIG_ENDIAN
+# define WORDS_BIGENDIAN 1
+# endif
#endif
/* Define to empty if `const' does not conform to ANSI C. */
fixes it! After re-building libs and reinstalling them:
golden-delicious# dig . dnskey | dnssec-dsfromkey -f - .
. IN DS 20326 8 1 AE1EA5B974D4C858B740BD03E3CED7EBFCBD1724
. IN DS 20326 8 2
E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
golden-delicious#
Regards,
- Håvard
Re: logout delay
Vitaly Shevtsov writes: > It seems to be a getty issue not shell itself. As I mentioned before > (but chosen incorrect responder) I type 'exit', wait ~1 second then > login prompt appears. And I tried many shells with the same result. > Actually, I stopped worried about this because it happens only on > getty logout. I log in once a day then dive into X and don't see getty > until I turn computer on the next day :) I just wonder if somebody > knows what the issue is. It's not clear that it is a bug. I have a very dim memory of somewhere between init and getty there being a small delay, so that if getty failed, there wouldn't be a rapid loop. Is there an actual problem? It seems this is simply behavior you find surprising. (This being open source, you are welcome to read the code, change it, try it out, and explain your findings. I don't see anything in need of fixing, so I won't be doing that myself.)
Re: logout delay
I just log in from physical console (/dev/constty). If I use urxvt under X11, it closes immediately. On Tue, Apr 21, 2020 at 6:35 PM Andreas Kusalananda Kähäri wrote: > > On Mon, Apr 20, 2020 at 02:06:23AM +0500, Vitaly Shevtsov wrote: > > Hello! > > > > Does anybody know why there is about 1 second delay before OS exited > > from the shell? There is no such issue on FreeBSD for example - it > > quits immediately when you type 'exit' or press ^D. > > How do you run the shell session (and what shell)? Is it in a terminal > (which one), or in a tmux pane, or a GNU screen window? > > I can see the same sort of delay on OpenBSD when exiting a shell when > that also means closing a tmux pane. > > -- > Andreas (Kusalananda) Kähäri > SciLifeLab, NBIS, ICM > Uppsala University, Sweden > > .
Re: logout delay
Greg, you're right! It seems to be a getty issue not shell itself. As I mentioned before (but chosen incorrect responder) I type 'exit', wait ~1 second then login prompt appears. And I tried many shells with the same result. Actually, I stopped worried about this because it happens only on getty logout. I log in once a day then dive into X and don't see getty until I turn computer on the next day :) I just wonder if somebody knows what the issue is. On Tue, Apr 21, 2020 at 6:26 PM Greg Troxel wrote: > > Gua Chung Lim writes: > > > * Vitaly Shevtsov wrote: > >> Does anybody know why there is about 1 second delay before OS exited > >> from the shell? There is no such issue on FreeBSD for example - it > >> quits immediately when you type 'exit' or press ^D. > > I would suggest looking into what's actually happening. I would suspect > that the shell actually exits promptly, and that the delay is between > that and getty printing a new "login:" prompt. > > If that doesn't make sense, please be much more precise about what > you're talking about.
Re: logout delay
On Mon, Apr 20, 2020 at 02:06:23AM +0500, Vitaly Shevtsov wrote: > Hello! > > Does anybody know why there is about 1 second delay before OS exited > from the shell? There is no such issue on FreeBSD for example - it > quits immediately when you type 'exit' or press ^D. How do you run the shell session (and what shell)? Is it in a terminal (which one), or in a tmux pane, or a GNU screen window? I can see the same sort of delay on OpenBSD when exiting a shell when that also means closing a tmux pane. -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: logout delay
On Tue, Apr 21, 2020 at 09:25:59AM -0400, Greg Troxel wrote: > If that doesn't make sense, please be much more precise about what > you're talking about. Yes, it is one of the sleep() calls in getty, not sure why we hit it though [for wscons based ttys]. Martin
Re: logout delay
Gua Chung Lim writes: > * Vitaly Shevtsov wrote: >> Does anybody know why there is about 1 second delay before OS exited >> from the shell? There is no such issue on FreeBSD for example - it >> quits immediately when you type 'exit' or press ^D. I would suggest looking into what's actually happening. I would suspect that the shell actually exits promptly, and that the delay is between that and getty printing a new "login:" prompt. If that doesn't make sense, please be much more precise about what you're talking about.
Re: logout delay
* Vitaly Shevtsov wrote: > Does anybody know why there is about 1 second delay before OS exited > from the shell? There is no such issue on FreeBSD for example - it > quits immediately when you type 'exit' or press ^D. Me too. Although it is not serious, but I'm very curious to know the reason. Furthermore, in my past experience on Slackware, I noticed that Slackware lagged 1 second on login and NetBSD lagged around 1 second on logout. In this perspective FreeBSD is the fastest. But I still prefer to NetBSD over everything else for the concepts of portability and clean source code. Thanks, -- Gua Chung Lim Life is a pleasant lie and death is a painful truth.
Re: DNSSEC vs netbsd-8/sparc?
>> So now I'm a bit confused where this error comes from. Its root >> cause does not seem to be the in-tree compiler (the "standalone" >> BIND releases I've built are built with "-g -O2"), and it's not >> the original BIND code either by the looks of it, as this is the >> same code which is in netbsd-8. > > I don't fully understand DNSSEC and how the hash is generated, but > could it be due to bit rot, i.e. when you created install image, some > bytes of code/data somewhere could have been corrupted. I highly doubt that. If this host had random bit rottage (the binaries I'm running are built locally), *and* the exact same bit rottage is observed by others, that would be quite strange indeed. > Maybe even source files are corrupted somewhere when you downloaded > them? Have you tried fresh checkout and rebuilding the same code > again, and if yes, do you reliably get the same hash mismatch? I'll admit that I've not tested that; I think this is unlikely to be the root cause. Regards, - Håvard
Re: setkey -- twofish-cbc unsupported algorithm
Pierre-Philipp Braun writes: > Hello, I was willing to benchmark and compare a few IPSEC settings and > I noticed twofish-cbc does not seem to be available, although it is > referenced in the manual. Seen on NetBSD/amd64 9.0. Is this a known > issue? I tried with 128 and 256 bit keys, same result. No probem > with blowfish-cbc and cast128-cbc. I am really unclear on this. Twofish was an AES finalist, and it seems not to be used so much now. I would suggest reading the sources for setkey to see if twofish appears, and for the kernel. Also the cvs logs. If it turns out that we removed twofish, or it was never there, and setkey(1) lists it, I can fix it. Also, as you test, you may want to look into whether the kernel is using AES instructions, with or without /dev/crypto offload. I have not paid attention to these details in quite a few years. As wikipedia notes, while twofish and rijndael were competitive in speed, twofihs is slower on computers with AES hardware support!
Re: DNSSEC vs netbsd-8/sparc?
Sad Clouds writes: > On Tue, 21 Apr 2020 09:47:45 +0200 (CEST) > Havard Eidnes wrote: > >> So now I'm a bit confused where this error comes from. Its root >> cause does not seem to be the in-tree compiler (the "standalone" >> BIND releases I've built are built with "-g -O2"), and it's not >> the original BIND code either by the looks of it, as this is the >> same code which is in netbsd-8. > > I don't fully understand DNSSEC and how the hash is generated, but > could it be due to bit rot, i.e. when you created install image, some > bytes of code/data somewhere could have been corrupted. Maybe even > source files are corrupted somewhere when you downloaded them? Have you > tried fresh checkout and rebuilding the same code again, and if yes, do > you reliably get the same hash mismatch? Does anybody think that the bind bits in netbsd-8 are ok, even before we talk about compilation?
Re: NetBSD-9 GPT on disks smaller than 2TB
On Tue, 21 Apr 2020 13:01:01 +0200 Martin Husemann wrote: > On Tue, Apr 21, 2020 at 11:59:38AM +0100, Sad Clouds wrote: > > Thanks guys, I'll keep this in mind. I've not used GPT that much, > > but looking at /etc/fstab entries I see > > > > NAME="XXX" / ffs rw,log 1 1 > > > > Since partitions are found by ID, does this mean swapping disks > > between different SATA/SCSI ports will still result in correct > > partitions found on boot? > > Yes. > > Martin Thanks, that's a useful feature, should fix such boot issues I had in the past.
Re: NetBSD-9 GPT on disks smaller than 2TB
On Tue, Apr 21, 2020 at 11:59:38AM +0100, Sad Clouds wrote: > > > Advantage might be portability and the availability of partition > > > names. > > > Thanks guys, I'll keep this in mind. I've not used GPT that much, but > looking at /etc/fstab entries I see > > NAME="XXX" / ffs rw,log 1 1 > > Since partitions are found by ID, does this mean swapping disks between > different SATA/SCSI ports will still result in correct partitions found > on boot? Yes. Me personally using name scheme on FC array, which have dynamic drives for VMs so drives on FC bus are renumbered literally always. -- Sincerely yours, Dima Veselov Physics R Establishment of Saint-Petersburg University
Re: NetBSD-9 GPT on disks smaller than 2TB
On Tue, Apr 21, 2020 at 11:59:38AM +0100, Sad Clouds wrote: > Thanks guys, I'll keep this in mind. I've not used GPT that much, but > looking at /etc/fstab entries I see > > NAME="XXX" / ffs rw,log 1 1 > > Since partitions are found by ID, does this mean swapping disks between > different SATA/SCSI ports will still result in correct partitions found > on boot? Yes. Martin
Re: NetBSD-9 GPT on disks smaller than 2TB
On Tue, 21 Apr 2020 11:09:07 +0100 David Brownlee wrote: > On Tue, 21 Apr 2020 at 10:58, Michael van Elst > wrote: > > > > cryintotheblue...@gmail.com (Sad Clouds) writes: > > > > >Hi, assuming I'm using a system that doesn't require UEFI and > > >disks are smaller than 2TB in size. Is there any advantage of > > >using GPT vs the old disklabel scheme? Also if I want to use a > > >partition (not whole disk) for ZFS, are there any weird > > >interaction/restrictions with GPT? > > > > Advantage might be portability and the availability of partition > > names. > > > > For ZFS it's best to use whole disks (and multiple of these). If you > > want to use a partition, it doesn't really matter if it is a slice > > (with disklabel) or wedge (with GPT). > > One issue - importing zpools from disklabel partitions does not Just > Work (wedges are OK). You have to create a new dev directory with just > the relevant device nodes). Only an issue if you need to import (eg > disks renumbered) > > David Thanks guys, I'll keep this in mind. I've not used GPT that much, but looking at /etc/fstab entries I see NAME="XXX" / ffs rw,log 1 1 Since partitions are found by ID, does this mean swapping disks between different SATA/SCSI ports will still result in correct partitions found on boot?
Re: NetBSD-9 GPT on disks smaller than 2TB
On Tue, 21 Apr 2020 at 10:58, Michael van Elst wrote: > > cryintotheblue...@gmail.com (Sad Clouds) writes: > > >Hi, assuming I'm using a system that doesn't require UEFI and disks are > >smaller than 2TB in size. Is there any advantage of using GPT vs the > >old disklabel scheme? Also if I want to use a partition (not whole > >disk) for ZFS, are there any weird interaction/restrictions with GPT? > > Advantage might be portability and the availability of partition names. > > For ZFS it's best to use whole disks (and multiple of these). If you > want to use a partition, it doesn't really matter if it is a slice > (with disklabel) or wedge (with GPT). One issue - importing zpools from disklabel partitions does not Just Work (wedges are OK). You have to create a new dev directory with just the relevant device nodes). Only an issue if you need to import (eg disks renumbered) David
Re: NetBSD-9 GPT on disks smaller than 2TB
cryintotheblue...@gmail.com (Sad Clouds) writes: >Hi, assuming I'm using a system that doesn't require UEFI and disks are >smaller than 2TB in size. Is there any advantage of using GPT vs the >old disklabel scheme? Also if I want to use a partition (not whole >disk) for ZFS, are there any weird interaction/restrictions with GPT? Advantage might be portability and the availability of partition names. For ZFS it's best to use whole disks (and multiple of these). If you want to use a partition, it doesn't really matter if it is a slice (with disklabel) or wedge (with GPT). -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
setkey -- twofish-cbc unsupported algorithm
Hello, I was willing to benchmark and compare a few IPSEC settings and I noticed twofish-cbc does not seem to be available, although it is referenced in the manual. Seen on NetBSD/amd64 9.0. Is this a known issue? I tried with 128 and 256 bit keys, same result. No probem with blowfish-cbc and cast128-cbc. # vi /etc/ipsec.conf add OFFICEPUB1 OFFICEPUB2 esp 13245 -E twofish-cbc 0x...some-pseudo-random-key...; add OFFICEPUB2 OFFICEPUB1 esp 13246 -E twofish-cbc 0x...some-other-pseudo-random-key...; spdadd SUBNET1/24 SUBNET2/24 any -P out ipsec esp/tunnel/OFFICEPUB1-OFFICEPUB2/require; spdadd SUBNET2/24 SUBNET1/24 any -P in ipsec esp/tunnel/OFFICEPUB2-OFFICEPUB1/require; # /etc/rc.d/ipsec restart Clearing ipsec manual keys/policies. Installing ipsec manual keys/policies. line 1: unsupported algorithm at [0x...some-pseudo-random-key...] parse failed, line 1. https://netbsd.gw.com/cgi-bin/man-cgi?setkey https://netbsd.gw.com/cgi-bin/man-cgi?setkey++NetBSD-current Good old KAME is much appreciated, thank you. -- Pierre-Philipp
Re: mDNS in base image
On 20/04/2020 17:23, Greg Troxel wrote: Things are occasionally removed from base if there is broad consensus that the overall NetBSD user community would be better off within them in base. So far, I see no reason to think mdnsd is one of them. In the case of mdns not having it in base would prevent base components from using it. Which might then just lead to people having to install even more stuff from pkgsrc to replace base versions just because they want mdns support in them. Mike
Re: DNSSEC vs netbsd-8/sparc?
On Tue, 21 Apr 2020 09:47:45 +0200 (CEST) Havard Eidnes wrote: > So now I'm a bit confused where this error comes from. Its root > cause does not seem to be the in-tree compiler (the "standalone" > BIND releases I've built are built with "-g -O2"), and it's not > the original BIND code either by the looks of it, as this is the > same code which is in netbsd-8. I don't fully understand DNSSEC and how the hash is generated, but could it be due to bit rot, i.e. when you created install image, some bytes of code/data somewhere could have been corrupted. Maybe even source files are corrupted somewhere when you downloaded them? Have you tried fresh checkout and rebuilding the same code again, and if yes, do you reliably get the same hash mismatch?
NetBSD-9 GPT on disks smaller than 2TB
Hi, assuming I'm using a system that doesn't require UEFI and disks are smaller than 2TB in size. Is there any advantage of using GPT vs the old disklabel scheme? Also if I want to use a partition (not whole disk) for ZFS, are there any weird interaction/restrictions with GPT? Thanks.
Re: DNSSEC vs netbsd-8/sparc?
> BIND in netbsd-8 is version 9.10.5-P1.
>
> BIND compiled from ISC, version 9.10.5-P3 also does this correctly:
>
> castor: {11} dig . dnskey | bin/dnssec/dnssec-dsfromkey -f - .
> . IN DS 20326 8 1 AE1EA5B974D4C858B740BD03E3CED7EBFCBD1724
> . IN DS 20326 8 2
> E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
> castor: {12}
>
> I'm going to do 9.10.5-P1 from ISC next.
Same, it's working as it should:
castor: {5} dig . dnskey | bin/dnssec/dnssec-dsfromkey -f - .
. IN DS 20326 8 1 AE1EA5B974D4C858B740BD03E3CED7EBFCBD1724
. IN DS 20326 8 2
E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
castor: {6}
In these builds dnssec-dsfromkey links dynamically (among others)
against
-lcrypt.1 => /lib/libcrypt.so.1
-lcrypto.12 => /usr/lib/libcrypto.so.12
So now I'm a bit confused where this error comes from. Its root
cause does not seem to be the in-tree compiler (the "standalone"
BIND releases I've built are built with "-g -O2"), and it's not
the original BIND code either by the looks of it, as this is the
same code which is in netbsd-8.
Regards,
- Håvard
