Ifconfig error - SIOCSETPFLOW
HI, I am getting this error since upgrading to v7.0; pf enabled net.inet.ip.forwarding: 0 -> 1 net.inet6.ip6.forwarding: 0 -> 1 starting network ifconfig: SIOCSETPFLOW: Can't assign requested address ifconfig: SIOCSETPFLOW: Can't assign requested address reordering libraries: done. starting early daemons: syslogd pflogd unbound ntpd. starting RPC daemons:. savecore: no core dump checking quotas: done. clearing /tmp kern.securelevel: 0 -> 1 creating runtime link editor directory cache. preserving editor files. starting network daemons: sshd snmpd dhcpd rad smtpd. starting package daemons: dhcpcd. starting local daemons: cron. Sat Oct 16 08:06:39 AEDT 2021 I am assuming it is related to the interface ‘pflow0’ which was working fine in version 6.9. The /etc/hostname.pflow0 is exactly the same as the examples in the man pages only that the source and destination IP addresses are different. Many thanks Antonino Sidoti
How does bsd.upgrade work?
It's not documented in the `sysupgrade` manpage. My setup is a little bit unusual, and I'm trying to understand why `uname -a` is still reporting 6.9 after I successfully booted bsd.upgrade and saw the upgrade process scroll past.
Re: Ifconfig error - SIOCSETPFLOW
> On Oct 15, 2021, at 7:09 PM, Antonino Sidoti wrote: > > HI, > > I am getting this error since upgrading to v7.0; > > pf enabled > net.inet.ip.forwarding: 0 -> 1 > net.inet6.ip6.forwarding: 0 -> 1 > starting network > > ifconfig: SIOCSETPFLOW: Can't assign requested address > ifconfig: SIOCSETPFLOW: Can't assign requested address > > reordering libraries: done. > starting early daemons: syslogd pflogd unbound ntpd. > starting RPC daemons:. > savecore: no core dump > checking quotas: done. > clearing /tmp > kern.securelevel: 0 -> 1 > creating runtime link editor directory cache. > preserving editor files. > starting network daemons: sshd snmpd dhcpd rad smtpd. > starting package daemons: dhcpcd. > starting local daemons: cron. > Sat Oct 16 08:06:39 AEDT 2021 > > I am assuming it is related to the interface ‘pflow0’ which was working fine > in version 6.9. The /etc/hostname.pflow0 is exactly the same as the examples > in the man pages only that the source and destination IP addresses are > different. > > Many thanks > > Antonino Sidoti > > > Are you using DHCP to configure the interface the source IP is on? Provide some more details of the network setup.
Re: 7.0 upgrade dmesg confusion
On Fri, 15 Oct 2021 20:09:16 -0400, Jon Fineman wrote: > I was preparing the dmesg to send off and I noticed it looks like the > old message from 6.9. How could that occur? What did I miss? >From dmesg(8): On some systems the message buffer can survive reboot and be retained (in the hope of exposing information from a crash). FILES /var/run/dmesg.boot copy of dmesg saved by rc(8) at boot time Cheers, Daniel
7.0 upgrade dmesg confusion
I was on 6.9 release, and I did a sysupgrade, which went smooth. Did a sysmerge and pkg_add -u. uuname gives me the expected output: desktop(~/nuc)$: uname -a OpenBSD desktop.xxx.com 7.0 GENERIC.MP#232 amd64 I was preparing the dmesg to send off and I noticed it looks like the old message from 6.9. How could that occur? What did I miss? desktop(~/nuc)$: dmesg | head -10 OpenBSD 6.9 (GENERIC.MP) #4: Tue Aug 10 08:12:23 MDT 2021 r...@syspatch-69-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17047867392 (16258MB) avail mem = 16515817472 (15750MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x8b1d7000 (57 entries) bios0: vendor Intel Corp. version "SYSKLi35.86A.0042.2016.0409.1246" date 04/09/2016 desktop(~/nuc)$:
Re: How does bsd.upgrade work?
> On Oct 15, 2021, at 3:19 PM, tetrahe...@danwin1210.me wrote: > > My setup is a little bit unusual, Unfortunately you have uttered the magic words that will dissuade most people on the list from helping you. sysupgrade is only designed to work for people whose setup is not at all unusual. If you want to troubleshoot you’ll have to at least fess up about whatever unusual thing you’ve done. Evan
Re: NSD exit status 11 on 7.0
On 2021-10-15, Peter J. Philipp wrote:
> On Fri, Oct 15, 2021 at 08:05:08PM +0200, Otto Moerbeek wrote:
> [ some cut ]
>
>> > Anything else I can collect.
>>
>> You might want to compile and install nsd wit debug symbols info:
>>
>> cd /usr/src/usr.sbin/nsd
>> make -f Makefile.bsd-wrapper obj
>> make -f Makefile.bsd-wrapper clean
>> DEBUG=-g make -f Makefile.bsd-wrapper
>> make -f Makefile.bsd-wrapper install
>>
>>
>> Then: collect a gdb trace from a running process: install gdb from ports,
>> run
>> egdb --pid=pidofnsdchild /usr/sbin/nsd
>>
>> and wait for the crash.
>>
>> But I'm mostly unfamiliar with the nsd code and what has been changed
>> recently. I's say make sure sthen@ and florian@ see this: move to
>> bugs@ as I do not know if they read misc@.
>>
>> -Otto
>
> Hi Otto and Mischa,
>
> I'm watching this unfold and I'm trying to convert this packet with tr and
> sed but I'm having a hard time, getting this to 101 bytes. It would be cool
> if you could show this packet in a hex dump ie. kdump -X or kdump -x.
>
> If you feel this really is a packet of nsd-death then I'd be interested in
> seeing the hexdump privately. I know how to read some DNS formats but the
> way it is in the kdump I'm having trouble converting that.
>
> Best Regards,
> -peter
>
>> >
>> > Mischa
>> >
>> >
>> > >
>> > > -Otto
>> > >
>> > > > 91127 nsd CALL
>> > > > recvfrom(7,0xb2ac85b8000,0x20109,0,0xb2acfa96018,0xb27e485a968)
>> > > > 91127 nsd GIO fd 7 read 101 bytes
>> > > > "By\0\0\0\^A\0\0\0\0\0\^A\^A6\^A0\^A1\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A1\^A0\^A0\^A0\^A4\^A0\^A0\^A1\^A0\^A0\^A0\^A6\^A3\^A0\^Aa\^A2\^Cip6\^Darpa\0\0\f\0\
>> > > >\^A\0\0)\^E\M-,\0\0\M^@\0\0\0"
>> > > > 91127 nsd STRU struct sockaddr { AF_INET,
>> > > > 141.101.75.185:10029 }
>> > > > 91127 nsd RET recvfrom 101/0x65
>> > > > 91127 nsd PSIG SIGSEGV SIG_DFL code SEGV_MAPERR<1> addr=0x10
>> > > > trapno=6
>> > > > 36104 nsd STRU struct pollfd [2] { fd=16, events=0x1,
>> > > > revents=0<> } { fd=15, events=0x1, revents=0<> }
>> > > > 36104 nsd PSIG SIGCHLD caught handler=0xb27e47fa340 mask=0<>
>>
>
>
$ echo
'By\0\0\0\^A\0\0\0\0\0\^A\^A6\^A0\^A1\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A1\^A0\^A0\^A0\^A4\^A\^A\0\0)\^E\M-,\0\0\M^@\0\0\0'
| unvis | hexdump -C
42 79 00 00 00 01 00 00 00 00 00 01 01 36 01 30 |By...6.0|
0010 01 31 01 30 01 30 01 30 01 30 01 30 01 30 01 30 |.1.0.0.0.0.0.0.0|
0020 01 30 01 30 01 30 01 30 01 30 01 30 01 31 01 30 |.0.0.0.0.0.0.1.0|
0030 01 30 01 30 01 34 01 01 00 00 29 05 ac 00 00 80 |.0.0.4).|
0040 00 00 00 0a ||
0044
--
Please keep replies on the mailing list.
Re: NSD exit status 11 on 7.0
On 2021-10-15, Otto Moerbeek wrote:
> On Fri, Oct 15, 2021 at 07:47:22PM +0200, Mischa wrote:
>
>>
>>
>> On 2021-10-15 19:42, Otto Moerbeek wrote:
>> > On Fri, Oct 15, 2021 at 07:16:55PM +0200, Mischa wrote:
>> >
>> > > On 2021-10-15 18:27, Otto Moerbeek wrote:
>> > > >
>> > > > The actual problem (SIGSEGV) happens in the child processes: ktrace the
>> > > > children as well: ktrace -di ...
>> > > >
>> > > >-Otto
>> > >
>> > > Thanx Otto.
>> > > Below is the the kdump with ktrace -di
>> > > It's quite a lot of data but I didn't want to remove something that
>> > > could
>> > > potentially be useful.
>> > >
>> > > Mischa
>> > >
>> >
>> > The pattern below happens multiple times:
>> >
>> > A recvfrom of 101 bytes and after that a SIGSEGV.
>> >
>> > Now we do not know for sure if those two lines are related.
>> >
>> > I suspect that it is no coincidence that the 101 is one larger than
>> > 100...
>> >
>> > No other clue yet.
>>
>> Anything else I can collect.
>
> You might want to compile and install nsd wit debug symbols info:
>
> cd /usr/src/usr.sbin/nsd
> make -f Makefile.bsd-wrapper obj
> make -f Makefile.bsd-wrapper clean
> DEBUG=-g make -f Makefile.bsd-wrapper
> make -f Makefile.bsd-wrapper install
"make DEBUG=-g -f Makefile.bsd-wrapper install", otherwise the installed
object is stripped.
> Then: collect a gdb trace from a running process: install gdb from ports,
> run
> egdb --pid=pidofnsdchild /usr/sbin/nsd
>
> and wait for the crash.
Alternatively set kern.nosuidcoredump=3, mkdir /var/crash/nsd, and it should
save cores there. (Don't send the core file; egdb /usr/sbin/nsd
/var/crash/nsd/XXX.core
and "bt full").
Or "egdb /usr/sbin/nsd", "set args -d -v 3" (in case we get anything useful
from logs at the time), "run"
> But I'm mostly unfamiliar with the nsd code and what has been changed
> recently. I's say make sure sthen@ and florian@ see this: move to
> bugs@ as I do not know if they read misc@.
The only thing I spotted changing code around reads was in dnstap
(which we don't build anyway), nothing stands out so far..
>> > > 91127 nsd GIO fd 7 read 101 bytes
>> > > "By\0\0\0\^A\0\0\0\0\0\^A\^A6\^A0\^A1\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A1\^A0\^A0\^A0\^A4\^A0\^A0\^A1\^A0\^A0\^A0\^A6\^A3\^A0\^Aa\^A2\^Cip6\^Darpa\0\0\f\0\
>> > > \^A\0\0)\^E\M-,\0\0\M^@\0\0\0"
>> > > 91127 nsd STRU struct sockaddr { AF_INET,
>> > > 141.101.75.185:10029 }
>> > > 91127 nsd RET recvfrom 101/0x65
>> > > 91127 nsd PSIG SIGSEGV SIG_DFL code SEGV_MAPERR<1> addr=0x10
>> > > trapno=6
>> > > 36104 nsd STRU struct pollfd [2] { fd=16, events=0x1,
>> > > revents=0<> } { fd=15, events=0x1, revents=0<> }
>> > > 36104 nsd PSIG SIGCHLD caught handler=0xb27e47fa340 mask=0<>
>
>
--
Please keep replies on the mailing list.
Re: drmfreeze
Avon Robertson [avo...@xtra.co.nz] wrote: > Hello misc@, > > Earlier today an AMD host I have froze again. I ssh'd into the host > and retrieved the output from dmesg, /var/log/messages, and > /var/run/dmesg.boot. > > I found nothing of note in $HOME/.local/share/xorg/Xorg.0.log. > > At the time of the freeze the ksh script I use to update my local /cvs > repository was the only programme executing inside the rightmost pane > of a 3 pane tmux session. I have a log of the output produced by this > script which is probably of no use to those who have been trying to > isolate and fix this bug for many months. > > Please advise if any of the above is of use or interest to anyone, and > if so to which list should I post it. > posting the dmesg to this list would be a good start
Re: Question about cryptography software compatibility on OpenBSD
On 2021-10-15, soko.tica wrote: > Please don't add my e-mail address in replying, I am subscribed to @misc > (for more than a decade). If it annoys you that much, it is probably worth including a note in your signature or setting Mail-Followup-To, as you probably noticed in that time group-reply is very common on OpenBSD lists.
Re: pkg_add -u failure; WAS: OpenBSD 7.0 released, Oct 14
On 2021-10-15, cho...@jtan.com wrote: > Bingo. I was even told about it in the email I ignored (there's > nothing wrong with *69): :) Been there done that. (If I am anywhere near tight on space in /usr I usually try to upgrade with the "untar on running system" method with a root shell open so I have some hope of fixing it..) And I have a number of systems where I have a gap in partition letters after growfs'ing /usr into what was previously the partition after it on disk. > Time to reinstall on a bigger disc. Thanks for the pointer, that > saves me some perplexed digging around. Good files to kill if you need to quickly make some breathing space (but of course will come back after reinstalling all sets): /usr/lib/lib[a-bd-z]*.a /usr/share/man Unless you are doing installs directly under /usr (usually self built software), removing everything reported by "sysclean | grep ^/usr" should be safe. It takes care of libraries needed for installed packages so you can try cleaning, making sure you have xbase and base sets fully unpacked, update packages, then run sysclean again and it will probably allow you to free up some more shared libraries. > btw Some of the space used on /usr will be old libraries (it's at > least as old as 6.8, clearly), but for the record it looks like the > minimum sizes on amd64 are approx. 1.25GB for /usr/!(X11R6|local), > 240MB for /usr/X11R6 and <75MB for everything else if the box isn't > doing a great deal. FWIW I usually try to give /usr at least 5GB. Maybe slight overkill but it's such a pain to shuffle partitions I'd rather waste a bit of space than have to do that again. The other place I often run out is / on systems where I run current as I often have a few different kernels lying around from trying to bisect when a problem was introduced. -- Please keep replies on the mailing list.
Re: Keeping a personal ports branch
On 2021-10-15, Rubén Llorente wrote:
> Marc Espie wrote:
>> On Fri, Oct 15, 2021 at 10:25:17AM -, Rubén Llorente wrote:
>>> Hi there!
>>>
>>> I am wondering how does people around here keep local branches of the ports
>>> tree for personal use.
>>>
>>
>> Put your own ports into mystuff...
>>
>> if you think they might interest other people, see whether the WIP git repo
>> would be suitable for them, until they're mature enough.
>>
>>
>
> A bunch of this stuff is really of no interest to anybody. Or does not fit a
> port system for general use.
>
> Having a "mystuff" folder sounds fine but if I want to put it under version
> control it is going to need some engineering :-) It sounds like a workable
> solution so I will study it.
>
Just use a different VCS, for example svn or git. /usr/ports/mystuff
is listed in .cvsignore in the repository so they don't conflict, and
there is special handling in ports infrastructure. The directory
layout underneath it should be as with the main ports tree i.e.
/usr/ports/mystuff/category/portname.
See PORTSDIR_PATH in bsd.port.mk(5). By default /usr/ports takes
priority over /usr/ports/mystuff, but if you want to override things
in the main tree you can swap that around with an entry in /etc/mk.conf
like PORTSDIR_PATH=${PORTSDIR}/mystuff:${PORTSDIR}
--
Please keep replies on the mailing list.
Re: NSD exit status 11 on 7.0
On Fri, Oct 15, 2021 at 08:05:08PM +0200, Otto Moerbeek wrote:
[ some cut ]
> > Anything else I can collect.
>
> You might want to compile and install nsd wit debug symbols info:
>
> cd /usr/src/usr.sbin/nsd
> make -f Makefile.bsd-wrapper obj
> make -f Makefile.bsd-wrapper clean
> DEBUG=-g make -f Makefile.bsd-wrapper
> make -f Makefile.bsd-wrapper install
>
>
> Then: collect a gdb trace from a running process: install gdb from ports,
> run
> egdb --pid=pidofnsdchild /usr/sbin/nsd
>
> and wait for the crash.
>
> But I'm mostly unfamiliar with the nsd code and what has been changed
> recently. I's say make sure sthen@ and florian@ see this: move to
> bugs@ as I do not know if they read misc@.
>
> -Otto
Hi Otto and Mischa,
I'm watching this unfold and I'm trying to convert this packet with tr and
sed but I'm having a hard time, getting this to 101 bytes. It would be cool
if you could show this packet in a hex dump ie. kdump -X or kdump -x.
If you feel this really is a packet of nsd-death then I'd be interested in
seeing the hexdump privately. I know how to read some DNS formats but the
way it is in the kdump I'm having trouble converting that.
Best Regards,
-peter
> >
> > Mischa
> >
> >
> > >
> > > -Otto
> > >
> > > > 91127 nsd CALL
> > > > recvfrom(7,0xb2ac85b8000,0x20109,0,0xb2acfa96018,0xb27e485a968)
> > > > 91127 nsd GIO fd 7 read 101 bytes
> > > > "By\0\0\0\^A\0\0\0\0\0\^A\^A6\^A0\^A1\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A1\^A0\^A0\^A0\^A4\^A0\^A0\^A1\^A0\^A0\^A0\^A6\^A3\^A0\^Aa\^A2\^Cip6\^Darpa\0\0\f\0\
> > > > \^A\0\0)\^E\M-,\0\0\M^@\0\0\0"
> > > > 91127 nsd STRU struct sockaddr { AF_INET,
> > > > 141.101.75.185:10029 }
> > > > 91127 nsd RET recvfrom 101/0x65
> > > > 91127 nsd PSIG SIGSEGV SIG_DFL code SEGV_MAPERR<1> addr=0x10
> > > > trapno=6
> > > > 36104 nsd STRU struct pollfd [2] { fd=16, events=0x1,
> > > > revents=0<> } { fd=15, events=0x1, revents=0<> }
> > > > 36104 nsd PSIG SIGCHLD caught handler=0xb27e47fa340 mask=0<>
>
Re: NSD exit status 11 on 7.0
On Fri, Oct 15, 2021 at 07:47:22PM +0200, Mischa wrote:
>
>
> On 2021-10-15 19:42, Otto Moerbeek wrote:
> > On Fri, Oct 15, 2021 at 07:16:55PM +0200, Mischa wrote:
> >
> > > On 2021-10-15 18:27, Otto Moerbeek wrote:
> > > >
> > > > The actual problem (SIGSEGV) happens in the child processes: ktrace the
> > > > children as well: ktrace -di ...
> > > >
> > > > -Otto
> > >
> > > Thanx Otto.
> > > Below is the the kdump with ktrace -di
> > > It's quite a lot of data but I didn't want to remove something that
> > > could
> > > potentially be useful.
> > >
> > > Mischa
> > >
> >
> > The pattern below happens multiple times:
> >
> > A recvfrom of 101 bytes and after that a SIGSEGV.
> >
> > Now we do not know for sure if those two lines are related.
> >
> > I suspect that it is no coincidence that the 101 is one larger than
> > 100...
> >
> > No other clue yet.
>
> Anything else I can collect.
You might want to compile and install nsd wit debug symbols info:
cd /usr/src/usr.sbin/nsd
make -f Makefile.bsd-wrapper obj
make -f Makefile.bsd-wrapper clean
DEBUG=-g make -f Makefile.bsd-wrapper
make -f Makefile.bsd-wrapper install
Then: collect a gdb trace from a running process: install gdb from ports,
run
egdb --pid=pidofnsdchild /usr/sbin/nsd
and wait for the crash.
But I'm mostly unfamiliar with the nsd code and what has been changed
recently. I's say make sure sthen@ and florian@ see this: move to
bugs@ as I do not know if they read misc@.
-Otto
>
> Mischa
>
>
> >
> > -Otto
> >
> > > 91127 nsd CALL
> > > recvfrom(7,0xb2ac85b8000,0x20109,0,0xb2acfa96018,0xb27e485a968)
> > > 91127 nsd GIO fd 7 read 101 bytes
> > > "By\0\0\0\^A\0\0\0\0\0\^A\^A6\^A0\^A1\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A1\^A0\^A0\^A0\^A4\^A0\^A0\^A1\^A0\^A0\^A0\^A6\^A3\^A0\^Aa\^A2\^Cip6\^Darpa\0\0\f\0\
> > > \^A\0\0)\^E\M-,\0\0\M^@\0\0\0"
> > > 91127 nsd STRU struct sockaddr { AF_INET,
> > > 141.101.75.185:10029 }
> > > 91127 nsd RET recvfrom 101/0x65
> > > 91127 nsd PSIG SIGSEGV SIG_DFL code SEGV_MAPERR<1> addr=0x10
> > > trapno=6
> > > 36104 nsd STRU struct pollfd [2] { fd=16, events=0x1,
> > > revents=0<> } { fd=15, events=0x1, revents=0<> }
> > > 36104 nsd PSIG SIGCHLD caught handler=0xb27e47fa340 mask=0<>
Re: NSD exit status 11 on 7.0
On 2021-10-15 19:42, Otto Moerbeek wrote:
On Fri, Oct 15, 2021 at 07:16:55PM +0200, Mischa wrote:
On 2021-10-15 18:27, Otto Moerbeek wrote:
>
> The actual problem (SIGSEGV) happens in the child processes: ktrace the
> children as well: ktrace -di ...
>
>-Otto
Thanx Otto.
Below is the the kdump with ktrace -di
It's quite a lot of data but I didn't want to remove something that
could
potentially be useful.
Mischa
The pattern below happens multiple times:
A recvfrom of 101 bytes and after that a SIGSEGV.
Now we do not know for sure if those two lines are related.
I suspect that it is no coincidence that the 101 is one larger than
100...
No other clue yet.
Anything else I can collect.
Mischa
-Otto
91127 nsd CALL
recvfrom(7,0xb2ac85b8000,0x20109,0,0xb2acfa96018,0xb27e485a968)
91127 nsd GIO fd 7 read 101 bytes
"By\0\0\0\^A\0\0\0\0\0\^A\^A6\^A0\^A1\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A1\^A0\^A0\^A0\^A4\^A0\^A0\^A1\^A0\^A0\^A0\^A6\^A3\^A0\^Aa\^A2\^Cip6\^Darpa\0\0\f\0\
\^A\0\0)\^E\M-,\0\0\M^@\0\0\0"
91127 nsd STRU struct sockaddr { AF_INET, 141.101.75.185:10029
}
91127 nsd RET recvfrom 101/0x65
91127 nsd PSIG SIGSEGV SIG_DFL code SEGV_MAPERR<1> addr=0x10
trapno=6
36104 nsd STRU struct pollfd [2] { fd=16, events=0x1,
revents=0<> } { fd=15, events=0x1, revents=0<> }
36104 nsd PSIG SIGCHLD caught handler=0xb27e47fa340 mask=0<>
Re: NSD exit status 11 on 7.0
On Fri, Oct 15, 2021 at 07:16:55PM +0200, Mischa wrote:
> On 2021-10-15 18:27, Otto Moerbeek wrote:
> >
> > The actual problem (SIGSEGV) happens in the child processes: ktrace the
> > children as well: ktrace -di ...
> >
> > -Otto
>
> Thanx Otto.
> Below is the the kdump with ktrace -di
> It's quite a lot of data but I didn't want to remove something that could
> potentially be useful.
>
> Mischa
>
The pattern below happens multiple times:
A recvfrom of 101 bytes and after that a SIGSEGV.
Now we do not know for sure if those two lines are related.
I suspect that it is no coincidence that the 101 is one larger than 100...
No other clue yet.
-Otto
> 91127 nsd CALL
> recvfrom(7,0xb2ac85b8000,0x20109,0,0xb2acfa96018,0xb27e485a968)
> 91127 nsd GIO fd 7 read 101 bytes
> "By\0\0\0\^A\0\0\0\0\0\^A\^A6\^A0\^A1\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A1\^A0\^A0\^A0\^A4\^A0\^A0\^A1\^A0\^A0\^A0\^A6\^A3\^A0\^Aa\^A2\^Cip6\^Darpa\0\0\f\0\
> \^A\0\0)\^E\M-,\0\0\M^@\0\0\0"
> 91127 nsd STRU struct sockaddr { AF_INET, 141.101.75.185:10029 }
> 91127 nsd RET recvfrom 101/0x65
> 91127 nsd PSIG SIGSEGV SIG_DFL code SEGV_MAPERR<1> addr=0x10 trapno=6
> 36104 nsd STRU struct pollfd [2] { fd=16, events=0x1,
> revents=0<> } { fd=15, events=0x1, revents=0<> }
> 36104 nsd PSIG SIGCHLD caught handler=0xb27e47fa340 mask=0<>
Re: nvme boot
On 10/15/21 8:05 AM, Jan Stary wrote: > Does any of the OpenSBD-supported platforms boot off nvme storage? > So far, I have been able to use nvme storage as a disk, > but not boot from it; but my HW is far from recent. > > Jan > Hi Jan, NVME boot will require that your motherboard / bios support it. It sounds like you're machine does not support it. I know OpenBSD supports NVME boot as I'm writing to you on an AMD Ryzen machine with B350 motherboard/chipset booting off of a 2TB NVME drive. Most modern laptops these days also boot off of NVME etc. Regards, Jordan
Re: NSD exit status 11 on 7.0
On Fri, Oct 15, 2021 at 06:18:12PM +0200, Mischa wrote:
> Hi All,
>
> Thank you all very much for OpenBSD 7.0!
> All upgrades went as smooth as always.
>
> However when I upgraded my DNS VMs, NSD keeps exiting with status 11.
> Unfortunately even in debug mode with -V4-9 it only gives me the below
> output.
>
> [2021-10-15 18:05:10.995] nsd[32203]: warning: server 70341 died
> unexpectedly with status 11, restarting
> [2021-10-15 18:05:11.246] nsd[32203]: warning: server 96047 died
> unexpectedly with status 11, restarting
> etc.. etc..
>
> With ktrace I was able to, hopefully, capture something useful.
>
> 36104 nsd RET write 1
> 36104 nsd CALL socketpair(AF_UNIX,0x1,0,0x7f7d6a48)
> 36104 nsd STRU int [2] { 16, 17 }
> 36104 nsd RET socketpair 0
> 36104 nsd CALL fork()
> 36104 nsd RET fork 24892/0x613c
> 36104 nsd CALL close(17)
> 36104 nsd RET close 0
> 36104 nsd CALL fcntl(16,F_SETFL,0x4)
> 36104 nsd RET fcntl 0
> 36104 nsd CALL wait4(WAIT_ANY,0x7f7d74d8,0x1,0)
> 36104 nsd RET wait4 0
> 36104 nsd CALL ppoll(0xb27e4857cb0,2,0x7f7d6a30,0)
> 36104 nsd STRU struct timespec { 60 }
> 36104 nsd STRU struct pollfd [2] { fd=16, events=0x1,
> revents=0<> } { fd=15, events=0x1, revents=0<> }
> 36104 nsd PSIG SIGCHLD caught handler=0xb27e47fa340 mask=0<>
> 36104 nsd RET ppoll -1 errno 4 Interrupted system call
> 36104 nsd CALL sigreturn(0x7f7d6510)
> 36104 nsd RET sigreturn JUSTRETURN
> 36104 nsd CALL wait4(WAIT_ANY,0x7f7d74d8,0x1,0)
> 36104 nsd RET wait4 24892/0x613c
> 36104 nsd CALL close(16)
> 36104 nsd RET close 0
> 36104 nsd CALL getpid()
> 36104 nsd RET getpid 36104/0x8d08
> 36104 nsd CALL sendsyslog(0x7f7d4110,73,0<>)
> 36104 nsd GIO fd -1 wrote 73 bytes
>"<28>nsd[36104]: server 24892 died unexpectedly with status 11,
> restarting"
> 36104 nsd RET sendsyslog 0
> 36104 nsd CALL gettimeofday(0x7f7d6748,0)
> 36104 nsd STRU struct timeval { 1634313545<"Oct 15 17:59:05
> 2021">.305661 }
> 36104 nsd RET gettimeofday 0
> 36104 nsd CALL getpid()
> 36104 nsd RET getpid 36104/0x8d08
> 36104 nsd CALL write(2,0x7f7d5e20,0x68)
> 36104 nsd GIO fd 2 wrote 104 bytes
>"[2021-10-15 17:59:05.305] nsd[36104]: warning: server 24892 died
> unexpectedly with status 11, restarting"
> 36104 nsd RET write 104/0x68
> 36104 nsd CALL write(2,0xb2aa1098927,0x1)
> 36104 nsd GIO fd 2 wrote 1 bytes
>
> If someone has any ideas that would be great.
>
> Mischa
>
The actual problem (SIGSEGV) happens in the child processes: ktrace the
children as well: ktrace -di ...
-Otto
NSD exit status 11 on 7.0
Hi All,
Thank you all very much for OpenBSD 7.0!
All upgrades went as smooth as always.
However when I upgraded my DNS VMs, NSD keeps exiting with status 11.
Unfortunately even in debug mode with -V4-9 it only gives me the below
output.
[2021-10-15 18:05:10.995] nsd[32203]: warning: server 70341 died
unexpectedly with status 11, restarting
[2021-10-15 18:05:11.246] nsd[32203]: warning: server 96047 died
unexpectedly with status 11, restarting
etc.. etc..
With ktrace I was able to, hopefully, capture something useful.
36104 nsd RET write 1
36104 nsd CALL
socketpair(AF_UNIX,0x1,0,0x7f7d6a48)
36104 nsd STRU int [2] { 16, 17 }
36104 nsd RET socketpair 0
36104 nsd CALL fork()
36104 nsd RET fork 24892/0x613c
36104 nsd CALL close(17)
36104 nsd RET close 0
36104 nsd CALL fcntl(16,F_SETFL,0x4)
36104 nsd RET fcntl 0
36104 nsd CALL wait4(WAIT_ANY,0x7f7d74d8,0x1,0)
36104 nsd RET wait4 0
36104 nsd CALL ppoll(0xb27e4857cb0,2,0x7f7d6a30,0)
36104 nsd STRU struct timespec { 60 }
36104 nsd STRU struct pollfd [2] { fd=16, events=0x1,
revents=0<> } { fd=15, events=0x1, revents=0<> }
36104 nsd PSIG SIGCHLD caught handler=0xb27e47fa340 mask=0<>
36104 nsd RET ppoll -1 errno 4 Interrupted system call
36104 nsd CALL sigreturn(0x7f7d6510)
36104 nsd RET sigreturn JUSTRETURN
36104 nsd CALL wait4(WAIT_ANY,0x7f7d74d8,0x1,0)
36104 nsd RET wait4 24892/0x613c
36104 nsd CALL close(16)
36104 nsd RET close 0
36104 nsd CALL getpid()
36104 nsd RET getpid 36104/0x8d08
36104 nsd CALL sendsyslog(0x7f7d4110,73,0<>)
36104 nsd GIO fd -1 wrote 73 bytes
"<28>nsd[36104]: server 24892 died unexpectedly with status 11,
restarting"
36104 nsd RET sendsyslog 0
36104 nsd CALL gettimeofday(0x7f7d6748,0)
36104 nsd STRU struct timeval { 1634313545<"Oct 15 17:59:05
2021">.305661 }
36104 nsd RET gettimeofday 0
36104 nsd CALL getpid()
36104 nsd RET getpid 36104/0x8d08
36104 nsd CALL write(2,0x7f7d5e20,0x68)
36104 nsd GIO fd 2 wrote 104 bytes
"[2021-10-15 17:59:05.305] nsd[36104]: warning: server 24892 died
unexpectedly with status 11, restarting"
36104 nsd RET write 104/0x68
36104 nsd CALL write(2,0xb2aa1098927,0x1)
36104 nsd GIO fd 2 wrote 1 bytes
If someone has any ideas that would be great.
Mischa
Re: nvme boot
On Fri, Oct 15, 2021 at 05:05:01PM +0200, Jan Stary wrote: > Does any of the OpenSBD-supported platforms boot off nvme storage? > So far, I have been able to use nvme storage as a disk, > but not boot from it; but my HW is far from recent. The Framework laptop (https://frame.work) boots fine off an internal NVME, so I suspect other modern laptops do too. Also the SiFive HiFive boots off NVME. So, yes.
Re: Keeping a personal ports branch
Marc Espie wrote: > On Fri, Oct 15, 2021 at 10:25:17AM -, Rubén Llorente wrote: >> Hi there! >> >> I am wondering how does people around here keep local branches of the ports >> tree for personal use. >> > > Put your own ports into mystuff... > > if you think they might interest other people, see whether the WIP git repo > would be suitable for them, until they're mature enough. > > A bunch of this stuff is really of no interest to anybody. Or does not fit a port system for general use. Having a "mystuff" folder sounds fine but if I want to put it under version control it is going to need some engineering :-) It sounds like a workable solution so I will study it. -- OpenPGP Key Fingerprint: 543F EB89 7FDE 8E33 AFF7 E794 E4AB 4807 58F7 6C76
Re: nvme boot
amd64 boots from nvme (i.e. recent Thinkpads) Jan On October 15, 2021 5:05:01 PM GMT+02:00, Jan Stary wrote: >Does any of the OpenSBD-supported platforms boot off nvme storage? >So far, I have been able to use nvme storage as a disk, >but not boot from it; but my HW is far from recent. > > Jan >
Re: nvme boot
On Fri, Oct 15, 2021 at 05:05:01PM +0200, Jan Stary wrote: > Does any of the OpenSBD-supported platforms boot off nvme storage? > So far, I have been able to use nvme storage as a disk, > but not boot from it; but my HW is far from recent. > > Jan Sure, my amd64 laptop boots fine from its nvme drive. Does your bios support booting from nvme? If not, I guess you need another drive to boot from. My dmesg, for reference: OpenBSD 7.0 (GENERIC.MP) #232: Thu Sep 30 14:25:29 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 16837365760 (16057MB) avail mem = 16311046144 (1MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.2 @ 0x5e6c6000 (94 entries) bios0: vendor Dell Inc. version "1.7.0" date 10/22/2020 bios0: Dell Inc. XPS 13 7390 acpi0 at bios0: ACPI 6.1 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT SSDT HPET APIC MCFG SSDT SSDT NHLT SSDT SSDT TPM2 LPIT SSDT DBGP DBG2 BOOT SSDT DMAR SSDT BGRT FPDT acpi0: wakeup devices XHC_(S0) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 2399 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-10710U CPU @ 1.10GHz, 3890.94 MHz, 06-a6-00 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-10710U CPU @ 1.10GHz, 3890.94 MHz, 06-a6-00 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-10710U CPU @ 1.10GHz, 3890.94 MHz, 06-a6-00 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-10710U CPU @ 1.10GHz, 3890.94 MHz, 06-a6-00 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 8 (application processor) cpu4: Intel(R) Core(TM) i7-10710U CPU @ 1.10GHz, 3890.94 MHz, 06-a6-00 cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu4: 256KB 64b/line 8-way L2 cache cpu4: smt 0, core 4, package 0 cpu5 at mainbus0: apid 10 (application processor) cpu5: Intel(R) Core(TM)
Re: nvme boot
Hi Jan, On Fri, Oct 15, 2021 at 05:05:01PM +0200, Jan Stary wrote: | Does any of the OpenSBD-supported platforms boot off nvme storage? | So far, I have been able to use nvme storage as a disk, | but not boot from it; but my HW is far from recent. Sure, I boot from nvme (actually, softraid crypto on nvme) on this AMD EPYC system (see below for full dmesg): despair# df -h / Filesystem SizeUsed Avail Capacity Mounted on /dev/sd3a 989M 81.1M858M 9%/ despair# bioctl softraid0 Volume Status Size Device softraid0 0 Online 429499175424 sd3 CRYPTO 0 Online 429499175424 0:0.0 noencl despair# dmesg | grep -e ^nvme0 -e ^scsibus1 -e ^sd0 nvme0 at pci1 dev 0 function 0 "Intel NVMe" rev 0x03: msix, NVMe 1.3 nvme0: INTEL SSDPEKNW512G8, firmware 004C, serial BTNH10651Y7T512A scsibus1 at nvme0: 2 targets, initiator 0 sd0 at scsibus1 targ 1 lun 0: sd0: 488386MB, 512 bytes/sector, 1000215216 sectors Just works (tm) Cheers, Paul OpenBSD 7.0-beta (GENERIC.MP) #0: Mon Aug 30 13:21:08 CEST 2021 we...@builder.alm.weirdnet.nl:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 68587933696 (65410MB) avail mem = 66493251584 (63412MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xdab19000 (51 entries) bios0: vendor American Megatrends Inc. version "1.0c" date 06/30/2020 bios0: Supermicro Super Server acpi0 at bios0: ACPI 6.1 acpi0: sleep states S0 S5 acpi0: tables DSDT FACP APIC FPDT FIDT SSDT SPMI SSDT MCFG SSDT CRAT CDIT BERT EINJ HEST HPET SSDT UEFI IVRS SSDT WSMT acpi0: wakeup devices S0D0(S3) S0D1(S3) S0D2(S3) S0D3(S3) S1D0(S3) S1D1(S3) S1D2(S3) S1D3(S3) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD EPYC 3201 8-Core Processor, 1500.27 MHz, 17-01-02 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=1.1, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD EPYC 3201 8-Core Processor, 1500.00 MHz, 17-01-02 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu1: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD EPYC 3201 8-Core Processor, 1500.00 MHz, 17-01-02 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu2: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD EPYC 3201 8-Core Processor, 1500.00 MHz, 17-01-02 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu3: 64KB
nvme boot
Does any of the OpenSBD-supported platforms boot off nvme storage? So far, I have been able to use nvme storage as a disk, but not boot from it; but my HW is far from recent. Jan
Keeping a personal ports branch
Hi there! I am wondering how does people around here keep local branches of the ports tree for personal use. The reason I am asking is because I keep some patched ports which are suited to solve my problems, but not suited (or useful) for submission to the official ports tree. Ideally I would upgrade my personal ports tree alongisde the official one. I suppose I could cvs import every -RELEASE of the ports into my own cvs repository, but ideally I would rather have something more automated. Besides, I am curious as to how people is doing it. -- OpenPGP Key Fingerprint: 543F EB89 7FDE 8E33 AFF7 E794 E4AB 4807 58F7 6C76
Re: Question about cryptography software compatibility on OpenBSD
> > > 3) Providers of public digital signatures offer software (a > > > one-size-fits-all Java “blob”) that should add cryptography capabilities > > to > > > the operating system. > > > > This is important. Thank you. Let me rephrase my wild guess: > > 3.1) An OS (OpenBSD or other) may have cryptography capabilities included > in the kernel. Yes. > 3.2) An OS that doesn't have cryptography capabilities included in the > kernel may provide cryptography software, not being included in the kernel, > fit and apt for use on the specific OS. This is where you seem to be missing that LOTS AND LOTS of programs use crypto from external libraries. They call openssl, they use NSS/NSPR, programs link against gnutls, java code use java libs, go code use go crypto and so on. > 3.3) Forcing the blind use of proprietary > java-crypto-one_size_fits_all-blob is technically possible, but it is a bad > practice since: > 3.3.1) it may downgrade crypto functionality existing in an OS as described > under 3.1 and 3.2 > 3.3.2) it may compromise and expose to the attacks not only the digital > signature, but the operating system itself > 3.3.3) for a number of other reasons (updates, licensing issues, etc.) Those last subpoints work both ways. A brought-along crypto primitive can be controlled by the person installing the program in ways you can't with the OS, so it is, like so much else, a tradeoff. If you don't control the OS and what crypto primitives it has, bringing along your own might be "safer" than to trust some OS to have a stable interface forever and ever. -- May the most significant bit of your life be positive.
Re: Keeping a personal ports branch
On Fri, Oct 15, 2021 at 10:25:17AM -, Rubén Llorente wrote: > Hi there! > > I am wondering how does people around here keep local branches of the ports > tree for personal use. > > The reason I am asking is because I keep some patched ports which are suited > to solve my problems, but not suited (or useful) for submission to the > official ports tree. Ideally I would upgrade my personal ports tree alongisde > the official one. > > I suppose I could cvs import every -RELEASE of the ports into my own cvs > repository, but ideally I would rather have something more automated. > Besides, I am curious as to how people is doing it. You can use the conversion of the CVS ports repository to Git and manage your local branches in a private repository clone. Conversion from CVS to Git is already automated so you don't have to take care of this yourself. The repository you need is published on github: https://github.com/openbsd/ports.git Two tools from ports can work on this repository, devel/git and devel/got. If you already like Git, then use it. If you don't enjoy using Git, give Got a try: pkg_add got man got (read the EXAMPLES section first if you don't know where to start) Got doesn't support HTTP yet. You can add an SSH key to your github profile and then clone the repository over SSH instead: got clone ssh://g...@github.com/openbsd/ports.git
Re: Keeping a personal ports branch
On Fri, Oct 15, 2021 at 10:25:17AM -, Rubén Llorente wrote: > Hi there! > > I am wondering how does people around here keep local branches of the ports > tree for personal use. > > The reason I am asking is because I keep some patched ports which are suited > to solve my problems, but not suited (or useful) for submission to the > official ports tree. Ideally I would upgrade my personal ports tree alongisde > the official one. > > I suppose I could cvs import every -RELEASE of the ports into my own cvs > repository, but ideally I would rather have something more automated. > Besides, I am curious as to how people is doing it. Put your own ports into mystuff... if you think they might interest other people, see whether the WIP git repo would be suitable for them, until they're mature enough.
Re: Question about cryptography software compatibility on OpenBSD
Please don't add my e-mail address in replying, I am subscribed to @misc (for more than a decade). On Fri, Oct 15, 2021 at 11:14 AM Janne Johansson wrote: > Den fre 15 okt. 2021 kl 11:01 skrev soko.tica : > > Hello list, > > I have a question about cryptography software compatibility on OpenBSD. > > I have a wild guess about the answer, but I need it to be more reliable. > > The target audience are lawyers, since I want to launch a legal battle in > > Then you need lawyer-speak, not answers from technical people. > Those two overlap very little. > > Please let me worry about the lawyer-speak. All I need is to properly understand what I am telling to other lawyers (more precisely, to Judges of Constitutional Court of Serbia). > > My wild guess is as follows: > > 1) OpenBSD includes cryptography capabilities/software in its kernel. > > yes, some. > > > 2) Most other operating systems had not included cryptography > > capabilities/software in its kernel. > > Depends on when "had" is in time. Nowadays, they probably all do. > Thanks, but it is not of essential importance. Consider this "historical" part closed. > > 3) Providers of public digital signatures offer software (a > > one-size-fits-all Java “blob”) that should add cryptography capabilities > to > > the operating system. > > No, they don't add it to the OS, they expose crypto functionality to > other programs. Big difference. > > I know of no OS that would reach out to java in order to get crypto > inside the kernel, and if it's not in the kernel, then any other > random program would not necessarily pick up that there is a bad/evil > blob installed somewhere that gives you poor crypto unless it actively > looks for it, so just by adding java-crypto-something in a folder it > might not be used by anything else that doesn't specifically ask for > exactly this. > > This is important. Thank you. Let me rephrase my wild guess: 3.1) An OS (OpenBSD or other) may have cryptography capabilities included in the kernel. 3.2) An OS that doesn't have cryptography capabilities included in the kernel may provide cryptography software, not being included in the kernel, fit and apt for use on the specific OS. 3.3) Forcing the blind use of proprietary java-crypto-one_size_fits_all-blob is technically possible, but it is a bad practice since: 3.3.1) it may downgrade crypto functionality existing in an OS as described under 3.1 and 3.2 3.3.2) it may compromise and expose to the attacks not only the digital signature, but the operating system itself 3.3.3) for a number of other reasons (updates, licensing issues, etc.) > > 4) OpenBSD doesn’t allow such technically inferior software to meddle > with > > its superior cryptography capabilities included in kernel. > > Value added statement, and mostly irrelevant to court cases I guess. > Again, let me worry about the lawyer-speak. Please. > > > 5) The proper technical solution would be that providers of public > digital > > signatures offer digital signatures adjusted to OpenBSD technical > > solutions, including offering software not being under the minimal > > cryptography standards of OpenBSD. (A side note, hash function of all > > offered public digital signatures in Serbia are SHA-1.) > > Am I somewhere wrong in my wild guess? > > Yes, you are assuming too much in the last part. > > It is not impossible for other OSes to have > better,faster,more-formally-verified,more-legal-where-I-am-located > crypto routines in their OSes which might be a preferred solution > somewhere. > While openbsd has the crypto it requires for its needs, those needs > are not guaranteed to (always) overlap with all the other requirements > that are set in different places around the world. One example could > be russian computers wanting certain algorithms like GOST in various > forms, or US computers needing FIPS-140 validation even if that in > certain cases lowers the overall security (hard to get fixes and > patches into such a setup) > Many thanks for this. How should I define that there is a need for completely inter-operable digital signatures? The ones that comply with the applicable standards, but completely free from imposition of any particular software of any specific software-producer? > -- > May the most significant bit of your life be positive. >
Re: Question about cryptography software compatibility on OpenBSD
Thanks infoomatic, I am not trying to certify a specific platform for the use for digital signatures in Serbia. I am trying to legally challenge the restrictions existing and occurring in Serbia, effectively directly imposing the use of Adobe Software (which I cannot use on OpenBSD) and indirectly imposing the use of OSes that Adobe software supports. I want to make the legislators clearly state the standards and offer completely inter-operable solutions. I want to be able to use digital signatures/certificates/digital_seal both as an individual and as a law office on OpenBSD. I need help to properly define my petition. On Fri, Oct 15, 2021 at 12:10 PM infoomatic wrote: > I agree with Janne. Almost always it is more of a compliance topic than > a technical topic. > > I did work for where we provided crypto/digital signature > stuff to government and institutions I won't name, and e.g. the > constraint for choosing an operating system for a platform was almost > always certification, e.g. at least EAL4 ... certified hardware to > certified software, everything in a chain. So if you are ready to take a > bunch of cash approach a hardware manufacturer and a certification > authority and get your whole platform certified, then you can sell it to > big corps and govs - thats sad, but the way you have to go. > > Good luck! > > > On 15.10.21 11:14, Janne Johansson wrote: > > Den fre 15 okt. 2021 kl 11:01 skrev soko.tica : > >> Hello list, > >> I have a question about cryptography software compatibility on OpenBSD. > >> I have a wild guess about the answer, but I need it to be more reliable. > >> The target audience are lawyers, since I want to launch a legal battle > in > > Then you need lawyer-speak, not answers from technical people. > > Those two overlap very little. > > > >> My wild guess is as follows: > >> 1) OpenBSD includes cryptography capabilities/software in its kernel. > > yes, some. > > > >> 2) Most other operating systems had not included cryptography > >> capabilities/software in its kernel. > > Depends on when "had" is in time. Nowadays, they probably all do. > > > >> 3) Providers of public digital signatures offer software (a > >> one-size-fits-all Java “blob”) that should add cryptography > capabilities to > >> the operating system. > > No, they don't add it to the OS, they expose crypto functionality to > > other programs. Big difference. > > > > I know of no OS that would reach out to java in order to get crypto > > inside the kernel, and if it's not in the kernel, then any other > > random program would not necessarily pick up that there is a bad/evil > > blob installed somewhere that gives you poor crypto unless it actively > > looks for it, so just by adding java-crypto-something in a folder it > > might not be used by anything else that doesn't specifically ask for > > exactly this. > > > >> 4) OpenBSD doesn’t allow such technically inferior software to meddle > with > >> its superior cryptography capabilities included in kernel. > > Value added statement, and mostly irrelevant to court cases I guess. > > > >> 5) The proper technical solution would be that providers of public > digital > >> signatures offer digital signatures adjusted to OpenBSD technical > >> solutions, including offering software not being under the minimal > >> cryptography standards of OpenBSD. (A side note, hash function of all > >> offered public digital signatures in Serbia are SHA-1.) > >> Am I somewhere wrong in my wild guess? > > Yes, you are assuming too much in the last part. > > > > It is not impossible for other OSes to have > > better,faster,more-formally-verified,more-legal-where-I-am-located > > crypto routines in their OSes which might be a preferred solution > > somewhere. > > While openbsd has the crypto it requires for its needs, those needs > > are not guaranteed to (always) overlap with all the other requirements > > that are set in different places around the world. One example could > > be russian computers wanting certain algorithms like GOST in various > > forms, or US computers needing FIPS-140 validation even if that in > > certain cases lowers the overall security (hard to get fixes and > > patches into such a setup) > > > >
Re: Question about cryptography software compatibility on OpenBSD
I agree with Janne. Almost always it is more of a compliance topic than a technical topic. I did work for where we provided crypto/digital signature stuff to government and institutions I won't name, and e.g. the constraint for choosing an operating system for a platform was almost always certification, e.g. at least EAL4 ... certified hardware to certified software, everything in a chain. So if you are ready to take a bunch of cash approach a hardware manufacturer and a certification authority and get your whole platform certified, then you can sell it to big corps and govs - thats sad, but the way you have to go. Good luck! On 15.10.21 11:14, Janne Johansson wrote: Den fre 15 okt. 2021 kl 11:01 skrev soko.tica : Hello list, I have a question about cryptography software compatibility on OpenBSD. I have a wild guess about the answer, but I need it to be more reliable. The target audience are lawyers, since I want to launch a legal battle in Then you need lawyer-speak, not answers from technical people. Those two overlap very little. My wild guess is as follows: 1) OpenBSD includes cryptography capabilities/software in its kernel. yes, some. 2) Most other operating systems had not included cryptography capabilities/software in its kernel. Depends on when "had" is in time. Nowadays, they probably all do. 3) Providers of public digital signatures offer software (a one-size-fits-all Java “blob”) that should add cryptography capabilities to the operating system. No, they don't add it to the OS, they expose crypto functionality to other programs. Big difference. I know of no OS that would reach out to java in order to get crypto inside the kernel, and if it's not in the kernel, then any other random program would not necessarily pick up that there is a bad/evil blob installed somewhere that gives you poor crypto unless it actively looks for it, so just by adding java-crypto-something in a folder it might not be used by anything else that doesn't specifically ask for exactly this. 4) OpenBSD doesn’t allow such technically inferior software to meddle with its superior cryptography capabilities included in kernel. Value added statement, and mostly irrelevant to court cases I guess. 5) The proper technical solution would be that providers of public digital signatures offer digital signatures adjusted to OpenBSD technical solutions, including offering software not being under the minimal cryptography standards of OpenBSD. (A side note, hash function of all offered public digital signatures in Serbia are SHA-1.) Am I somewhere wrong in my wild guess? Yes, you are assuming too much in the last part. It is not impossible for other OSes to have better,faster,more-formally-verified,more-legal-where-I-am-located crypto routines in their OSes which might be a preferred solution somewhere. While openbsd has the crypto it requires for its needs, those needs are not guaranteed to (always) overlap with all the other requirements that are set in different places around the world. One example could be russian computers wanting certain algorithms like GOST in various forms, or US computers needing FIPS-140 validation even if that in certain cases lowers the overall security (hard to get fixes and patches into such a setup)
Re: Question about cryptography software compatibility on OpenBSD
Den fre 15 okt. 2021 kl 11:01 skrev soko.tica : > Hello list, > I have a question about cryptography software compatibility on OpenBSD. > I have a wild guess about the answer, but I need it to be more reliable. > The target audience are lawyers, since I want to launch a legal battle in Then you need lawyer-speak, not answers from technical people. Those two overlap very little. > My wild guess is as follows: > 1) OpenBSD includes cryptography capabilities/software in its kernel. yes, some. > 2) Most other operating systems had not included cryptography > capabilities/software in its kernel. Depends on when "had" is in time. Nowadays, they probably all do. > 3) Providers of public digital signatures offer software (a > one-size-fits-all Java “blob”) that should add cryptography capabilities to > the operating system. No, they don't add it to the OS, they expose crypto functionality to other programs. Big difference. I know of no OS that would reach out to java in order to get crypto inside the kernel, and if it's not in the kernel, then any other random program would not necessarily pick up that there is a bad/evil blob installed somewhere that gives you poor crypto unless it actively looks for it, so just by adding java-crypto-something in a folder it might not be used by anything else that doesn't specifically ask for exactly this. > 4) OpenBSD doesn’t allow such technically inferior software to meddle with > its superior cryptography capabilities included in kernel. Value added statement, and mostly irrelevant to court cases I guess. > 5) The proper technical solution would be that providers of public digital > signatures offer digital signatures adjusted to OpenBSD technical > solutions, including offering software not being under the minimal > cryptography standards of OpenBSD. (A side note, hash function of all > offered public digital signatures in Serbia are SHA-1.) > Am I somewhere wrong in my wild guess? Yes, you are assuming too much in the last part. It is not impossible for other OSes to have better,faster,more-formally-verified,more-legal-where-I-am-located crypto routines in their OSes which might be a preferred solution somewhere. While openbsd has the crypto it requires for its needs, those needs are not guaranteed to (always) overlap with all the other requirements that are set in different places around the world. One example could be russian computers wanting certain algorithms like GOST in various forms, or US computers needing FIPS-140 validation even if that in certain cases lowers the overall security (hard to get fixes and patches into such a setup) -- May the most significant bit of your life be positive.
Question about cryptography software compatibility on OpenBSD
Hello list, I have a question about cryptography software compatibility on OpenBSD. I have a wild guess about the answer, but I need it to be more reliable. The target audience are lawyers, since I want to launch a legal battle in Serbia for equal opportunities for using open source software, specifically OpenBSD, but other open source software as well (yes, including other *BSDs, OpenIndiana and Linux), for creating, administering and using public digital certificates/signatures by public authorities, against offerred proprietary solutions, all of which are not interoperable with OpenBSD. My wild guess is as follows: 1) OpenBSD includes cryptography capabilities/software in its kernel. 2) Most other operating systems had not included cryptography capabilities/software in its kernel. 3) Providers of public digital signatures offer software (a one-size-fits-all Java “blob”) that should add cryptography capabilities to the operating system. 4) OpenBSD doesn’t allow such technically inferior software to meddle with its superior cryptography capabilities included in kernel. 5) The proper technical solution would be that providers of public digital signatures offer digital signatures adjusted to OpenBSD technical solutions, including offering software not being under the minimal cryptography standards of OpenBSD. (A side note, hash function of all offered public digital signatures in Serbia are SHA-1.) Am I somewhere wrong in my wild guess? Do you have any input? Thanks in advance.
Re: pkg_add -u failure; WAS: OpenBSD 7.0 released, Oct 14
Oh and it's also worth noting that despite that massive cock-up, the box is still (now) running just fine on this frankenhybrid and serving its git repositories and running its crons, all entirely hands-off and automated: # uname -a && uptime OpenBSD smoke.datum 7.0 GENERIC#224 amd64 4:29AM up 10:49, 2 users, load averages: 0.05, 0.02, 0.01 That's how engineering works. Take that, devops. Matthew
Re: pkg_add -u failure; WAS: OpenBSD 7.0 released, Oct 14
Stuart Henderson writes: > On 2021-10-14, cho...@jtan.com wrote: > > Turns out, one of my less important boxes was still on 6.8. Whoops. > > > > After two sysupgrades, this is the result of pkg_add -u: > > > > quirks-4.53 signed on 2021-10-12T20:12:39Z > > Can't install cairo-1.16.0 because of libraries > >|library pixman-1.40.0 not found > > That file is in xserv70.tgz so you shouldn't be having that problem unless the > untar failed. Does the file exist (should be in /usr/X11R6/lib)? Are you ok > for > disk space in /usr/X11R6? Bingo. I was even told about it in the email I ignored (there's nothing wrong with *69): Installing base70.tgz91% |*** | 275 MB00:01 ETAtar: Failed write to file ./usr/share/relink/kernel.tgz: No space left on device tar: Failed write to file ./usr/share/relink/usr/lib/libc.so.96.1.a: No space left on device tar: Failed write to file ./usr/share/relink/usr/lib/libcrypto.so.47.0.a: No space left on device tar: Failed write to file ./usr/share/snmp/mibs/OPENBSD-CARP-MIB.txt: No space left on device tar: Failed write to file ./usr/share/snmp/mibs/OPENBSD-PF-MIB.txt: No space left on device Installing base70.tgz99% |* | 301 MB00:00 ETAtar: Failed write to file ./usr/share/zoneinfo/CST6CDT: No space left on device tar: Failed write to file ./usr/share/zoneinfo/Europe/Paris: No space left on device tar: Failed write to file ./usr/share/zoneinfo/Europe/Zaporozhye: No space left on device tar: Failed write to file ./usr/share/zoneinfo/Pacific/Fiji: No space left on device Installing base70.tgz 100% |**| 302 MB00:14 Installation of base70.tgz failed. Continue anyway? [no] no Time to reinstall on a bigger disc. Thanks for the pointer, that saves me some perplexed digging around. Matthew btw Some of the space used on /usr will be old libraries (it's at least as old as 6.8, clearly), but for the record it looks like the minimum sizes on amd64 are approx. 1.25GB for /usr/!(X11R6|local), 240MB for /usr/X11R6 and <75MB for everything else if the box isn't doing a great deal.
