Re: sysupgrade fails due to "CHECK AND RESET DATE" ?

[kasak]

18.10.2021 23:18, kasak пишет:

Hello everyone!

I have one mini router, made from gigabyte GB-SBCAP4200 barebone

It has nothing special. Just base openbsd, without any additional 
packages and modifications.


for some reason, sysupgrade does not upgrade this system.
It successfully boot new kernel, but do not process the upgrade, Just 
load 6.9 back.


This is dmesg from loading 7.0 and further:

OpenBSD 7.0 (RAMDISK_CD) #219: Thu Sep 30 14:32:42 MDT 2021
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 8415617024 (8025MB)
avail mem = 8156545024 (7778MB)
random: good seed from bootblocks
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x79db7000 (50 entries)
bios0: vendor American Megatrends Inc. version "F1" date 06/11/2018
bios0: Gigabyte Technology Co., Ltd. Default string
acpi0 at bios0: ACPI 6.0
acpi0: tables DSDT FACP FPDT FIDT MCFG DBG2 DBGP HPET LPIT APIC NPKT 
PRAM WSMT SSDT SSDT SSDT SSDT SSDT SSDT SSDT UEFI TPM2 WDAT

acpihpet0 at acpi0: 1920 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Pentium(R) CPU N4200 @ 1.10GHz, 1097.47 MHz, 06-5c-09
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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN

cpu0: 1MB 64b/line 16-way L2 cache
cpu0: apic clock running at 19MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.2.4.2.1.1, IBE
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 120 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (RP01)
acpiprt2 at acpi0: bus -1 (RP02)
acpiprt3 at acpi0: bus 1 (RP03)
acpiprt4 at acpi0: bus 2 (RP04)
acpiprt5 at acpi0: bus 3 (RP05)
acpiprt6 at acpi0: bus 4 (RP06)
acpiec0 at acpi0: not present
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
acpicmos0 at acpi0
"PNP0C0C" at acpi0 not configured
aplgpio0 at acpi0 GPO0 uid 1 addr 0xd0c5/0x76c irq 14, 78 pins
aplgpio1 at acpi0 GPO1 uid 2 addr 0xd0c4/0x764 irq 14, 77 pins
aplgpio2 at acpi0 GPO2 uid 3 addr 0xd0c7/0x674 irq 14, 47 pins
aplgpio3 at acpi0 GPO3 uid 4 addr 0xd0c0/0x654 irq 14, 43 pins
"INT33A1" at acpi0 not configured
"MSFT0101" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
acpicpu at acpi0 not configured
acpipwrres at acpi0 not configured
acpitz at acpi0 not configured
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Apollo Lake Host" rev 0x0b
"Intel HD Graphics 505" rev 0x0b at pci0 dev 2 function 0 not configured
"Intel Apollo Lake HD Audio" rev 0x0b at pci0 dev 14 function 0 not 
configured

"Intel Apollo Lake TXE" rev 0x0b at pci0 dev 15 function 0 not configured
ahci0 at pci0 dev 18 function 0 "Intel Apollo Lake AHCI" rev 0x0b: 
msi, AHCI 1.3.1

ahci0: PHY offline on port 0
ahci0: port 1: 6.0Gb/s
scsibus0 at ahci0: 32 targets
sd0 at scsibus0 targ 1 lun 0:  
naa.50026b7783a249ed

sd0: 228936MB, 512 bytes/sector, 468862128 sectors, thin
ppb0 at pci0 dev 19 function 0 "Intel Apollo Lake PCIE" rev 0xfb: msi
pci1 at ppb0 bus 1
ppb1 at pci0 dev 19 function 1 "Intel Apollo Lake PCIE" rev 0xfb: msi
pci2 at ppb1 bus 2
ppb2 at pci0 dev 19 function 2 "Intel Apollo Lake PCIE" rev 0xfb: msi
pci3 at ppb2 bus 3
re0 at pci3 dev 0 function 0 "Realtek 8168" rev 0x0c: RTL8168G/8111G 
(0x4c00), msi, address e0:d5:5e:e7:50:4f

rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0
ppb3 at pci0 dev 19 function 3 "Intel Apollo Lake PCIE" rev 0xfb: msi
pci4 at ppb3 bus 4
re1 at pci4 dev 0 function 0 "Realtek 8168" rev 0x0c: RTL8168G/8111G 
(0x4c00), msi, address e0:d5:5e:e7:50:51

rgephy1 at re1 phy 7: RTL8251 PHY, rev. 0
xhci0 at pci0 dev 21 function 0 "Intel Apollo Lake xHCI" rev 0x0b: 
msi, xHCI 1.0

usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 
3.00/1.00 addr 1

"Intel Apollo Lake LPC" rev 0x0b at pci0 dev 31 function 0 not configured
"Intel Apollo Lake SMBus" rev 0x0b at pci0 dev 31 function 1 not 
configured

isa0 at mainbus0
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
efifb at mainbus0 not configured
softraid0 at root
scsibus1 at softraid0: 256 targets
root on rd0a swap on rd0b dump on rd0b
WARNING: CHECK AND RESET THE DATE!
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 = 8415617024 (8025MB)
avail mem = 8145182720 (7767MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x79db7000 (50 entries)
bios0: vendor American Megatrends Inc. version "F1" date 06/11/2018
bios0: Gigabyte Tec

Re: DHCP leases not being renewed

[Zé Loff]

On Tue, Oct 19, 2021 at 03:26:20PM +1000, Ryan Vitelli wrote:
> Hello,
> 
> After upgrading to 7.0 I noticed DHCP leases from my ISP were
> not being renewed.
> 
> After researching I ended up modifying my /etc/hostname.em0 file
> by replacing 'dhcp' with '!dhclient \$if' and this "appears"
> to resolve the issue.
> 
> The FAQ and the dhclient/hostname.if manpages infer that this
> shouldn't be necessary and a simple 'dhcp' should be sufficient.
> Obviously I'm missing something because our application is very basic.
> 
> With the above "fix" in place, the other thing I've noticed is that
> on bootup I now get this
> em0: no linkgot link
> em0: no lease.got lease
> em0: my.wan.ip.addr lease accepted from nnn.nnn.nnn.nnn (u:v:w:x:y:z)
> This does not appear with hostname.em0 containing 'dhcp', however
> it did previously when on 6.9
> 
> Any help on this would be great. Thanks.
> 
> Notes:
> No related messages in daemon or messages logs
> OS: openbsd 7.0 /amd64
> hardware is PC Engines APU2e4 with BIOS version v4.13.0.2
> em0 at pci1 dev 0 function 0 "Intel I210" rev 0x03: msi, address a:b:c:d:e:f
> 

dhcpleased(8) is now preferred, instead of dhclient:
http://www.openbsd.org/faq/faq6.html#DHCP

Changing "dhcp" to "inet autoconf" should suffice.

(does this warrant an entry on faq/upgrade70.html ?)

You might want to also take a look at some of the new(-ish) man pages
for dhcpleased, dhcpleased.conf and maybe resolvd.

Cheers
Zé


-- 
 

Re: DHCP leases not being renewed

[Guy Godfroy]

Also, if you have some curtom DHCP options (like vendor ID) just 
translate it from /etc/dhclient.conf to /etc/dhcpleased.conf.


Guy Godfroy

Le 19/10/2021 à 10:50, Zé Loff a écrit :

On Tue, Oct 19, 2021 at 03:26:20PM +1000, Ryan Vitelli wrote:

Hello,

After upgrading to 7.0 I noticed DHCP leases from my ISP were
not being renewed.

After researching I ended up modifying my /etc/hostname.em0 file
by replacing 'dhcp' with '!dhclient \$if' and this "appears"
to resolve the issue.

The FAQ and the dhclient/hostname.if manpages infer that this
shouldn't be necessary and a simple 'dhcp' should be sufficient.
Obviously I'm missing something because our application is very basic.

With the above "fix" in place, the other thing I've noticed is that
on bootup I now get this
em0: no linkgot link
em0: no lease.got lease
em0: my.wan.ip.addr lease accepted from nnn.nnn.nnn.nnn (u:v:w:x:y:z)
This does not appear with hostname.em0 containing 'dhcp', however
it did previously when on 6.9

Any help on this would be great. Thanks.

Notes:
No related messages in daemon or messages logs
OS: openbsd 7.0 /amd64
hardware is PC Engines APU2e4 with BIOS version v4.13.0.2
em0 at pci1 dev 0 function 0 "Intel I210" rev 0x03: msi, address a:b:c:d:e:f



dhcpleased(8) is now preferred, instead of dhclient:
http://www.openbsd.org/faq/faq6.html#DHCP

Changing "dhcp" to "inet autoconf" should suffice.

(does this warrant an entry on faq/upgrade70.html ?)

You might want to also take a look at some of the new(-ish) man pages
for dhcpleased, dhcpleased.conf and maybe resolvd.

Cheers
Zé

Re: http(8) - PHP 8.0.11 - excecute shell command return code 127 (not found)

[Stuart Henderson]

On 2021-10-19, J. K.  wrote:
> Hi,
>
> I'm played around with the exec() command from
> PHP for the purpose of education. Don't use
> these feature in production, to avoid security
> issues.
>
> In the default configuration from OpenBSD, PHP
> is inside chroot, so I linked a simple
> Hello World program static and placed it in
> the root directory from the PHP script.
>
> But always get code 127, when I try to execute
> the binary within PHP. I also checked the file
> permissions, which are 755.
>
> Also tried to place the program in the
> /var/www/bin folder. But with the same result.
>
> Is this function disabled or will be blocked
> by the kernel?

You need to provide $CHROOT/bin/sh as well for php's exec() function to work.

-- 
Please keep replies on the mailing list.

Re: mpd - All audio outputs are disabled

[Stuart Henderson]

On 2021-10-18, Alexandre Ratchov  wrote:
> On Mon, Oct 18, 2021 at 03:04:20PM -0400, Mario St-Gelais wrote:
>> Hum, I had subject problem in the past following an upgrade, It happened
>> again, yet, I cannot remember what the heck I used to do to solve it.
>> 
>> I vaguely remember it was a stupid thing.  Any hint please?
>> 
>> I can do aucat -i file.wav no problem.
>> Changed ownership of audio0 to my username
>> 
>
> audio and MIDI-related files in /dev are supposed to be owned by root,
> by default only sndiod(8) uses them directly.
>
> Most probably _mpd user and you are trying to connect to sndiod
> simultaneously.
>
> If so, you can authorize _mpd to connect to your sndio session by
> copying your ~/.sndio/cookie to _mpd home directory. There's a short
> explanation in the "Authentication" section of sndio(7).
>
>

$ doas pkg_add mpd
quirks-4.54 signed on 2021-10-18T15:54:45Z
mpd-0.22.11:libaudiofile-0.3.6p6: ok
mpd-0.22.11: ok
The following new rcscripts were installed: /etc/rc.d/mpd
See rcctl(8) for details.
New and changed readme(s):
/usr/local/share/doc/pkg-readmes/mpd

$ cat /usr/local/share/doc/pkg-readmes/mpd
$OpenBSD: README,v 1.1 2020/04/28 17:16:21 jca Exp $

+---
| Running mpd on OpenBSD
+---

sndiod(8) concurrent access by mpd(1) and other users
=

sndiod(8) normally only allows access to audio by a single system user
at a time. This is done by generating a random authentication token and
storing it in $HOME/.sndio/cookie when a user first accesses audio,
providing a limited capability to share with other users by copying
the token to their home directory.  See AUTHENTICATION in sndio(7) for
more details.

If you want to share sndiod(8) access with mpd(1) running as the
default _mpd user, you may copy .sndio/cookie from your user's home
directory to /var/spool/mpd/.sndio/cookie.

[...]


-- 
Please keep replies on the mailing list.

Shirts

[archives]

Just dug out ye ol' (remember Mickey) Spy-vs-Spy shirt recently, but well, it 
looked right old. Is there anybody selling these shirts anymore or 
alternatively willing to give away the print, so people can just print them 
themselves? 

Thanks in advacne

midnight commander sftp problem after upgrade to OpenBSD 7.0

[Rudolf Sykora]

Hello list,


I used to use the 'sftp connection' with mc, it worked, seemingly, until I
upgraded OpenBSD from 6.9 to 7.0. Now it says, when I try to use it:

 The requested method(s) are not currently supported (-33)

Does anybody know what could have happened (and whether it is related to
the upgrade, or what can I do to get the functionality back)?


Thank you!
Rudolf Sykora

Re: midnight commander sftp problem after upgrade to OpenBSD 7.0

[Rudolf Sykora]

Dear list,


sorry for the noise, the sftp connection doesn't most probably work due
to a change in the server's settings, and is not OpenBSD related.
It was just a time coincidence of my upgrade and their change.


Best regards
Rudolf Sykora


Rudolf Sykora  writes:

> Hello list,
>
>
> I used to use the 'sftp connection' with mc, it worked, seemingly, until I
> upgraded OpenBSD from 6.9 to 7.0. Now it says, when I try to use it:
>
>  The requested method(s) are not currently supported (-33)
>
> Does anybody know what could have happened (and whether it is related to
> the upgrade, or what can I do to get the functionality back)?
>
>
> Thank you!
> Rudolf Sykora

Re: iked drops network connection when roadwarrior connects 6.9+

[Matthew Ernisse]

On Mon, Oct 18, 2021 at 07:40:39PM -, Stuart Henderson said:
> 
> Follow the 6.9 upgrade guide.

'to dynamic' did the trick.  Thanks.

--Matt

http(8) - PHP 8.0.11 - excecute shell command return code 127 (not found)

[J. K.]

Hi,

I'm played around with the exec() command from
PHP for the purpose of education. Don't use
these feature in production, to avoid security
issues.

In the default configuration from OpenBSD, PHP
is inside chroot, so I linked a simple
Hello World program static and placed it in
the root directory from the PHP script.

But always get code 127, when I try to execute
the binary within PHP. I also checked the file
permissions, which are 755.

Also tried to place the program in the
/var/www/bin folder. But with the same result.

Is this function disabled or will be blocked
by the kernel?

Kind regards,

J. K.

How BSD Authentication Works

[Dante Catalfamo]

Hello friends,

I just published a blog post about the BSD Authentication framework and 
I'm very excited to share it with you!


I'm not an OpenBSD developer but I tried my best to understand the 
system and how it works. Please let me know if I got anything wrong.


https://blog.lambda.cx/posts/how-bsd-authentication-works/

Best,
Dante

Re: NSD exit status 11 on 7.0

[Mischa]

On 2021-10-15 20:05, 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


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@.


Thanx Otto.

As this is my first time using gdb, I need some assistance.

root@name2:~ # ps -aux | grep nsd
_nsd 79188  0.0  1.0 101704 86400 ??  Ip  7:31PM0:00.20 nsd: 
xfrd (nsd)
_nsd 24002  0.0  0.4 37188 37388 ??  Ip  7:31PM0:00.29 nsd: 
main (nsd)
_nsd 44937  0.0  0.2 37544 18308 ??  Sp  7:45PM0:00.11 nsd: 
server 1 (nsd)


root@name2:~ # egdb --pid=44937 /usr/sbin/nsd
GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show 
copying"

and "show warranty" for details.
This GDB was configured as "x86_64-unknown-openbsd7.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/nsd...(no debugging symbols 
found)...done.

Attaching to program: /usr/sbin/nsd, process 44937
Reading symbols from /usr/lib/libssl.so.50.0...done.
Reading symbols from /usr/lib/libcrypto.so.47.0...done.
Reading symbols from /usr/lib/libevent.so.4.1...done.
Reading symbols from /usr/lib/libc.so.96.1...done.
Reading symbols from /usr/libexec/ld.so...done.
[Switching to thread 563101]
kevent () at /tmp/-:3
3   /tmp/-: No such file or directory.

Anything I am missing?

Mischa

Re: NSD exit status 11 on 7.0

[Otto Moerbeek]

On Tue, Oct 19, 2021 at 07:49:15PM +0200, Mischa wrote:

> On 2021-10-15 20:05, 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
> > 
> > 
> > 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@.
> 
> Thanx Otto.
> 
> As this is my first time using gdb, I need some assistance.
> 
> root@name2:~ # ps -aux | grep nsd
> _nsd 79188  0.0  1.0 101704 86400 ??  Ip  7:31PM0:00.20 nsd:
> xfrd (nsd)
> _nsd 24002  0.0  0.4 37188 37388 ??  Ip  7:31PM0:00.29 nsd: main
> (nsd)
> _nsd 44937  0.0  0.2 37544 18308 ??  Sp  7:45PM0:00.11 nsd:
> server 1 (nsd)
> 
> root@name2:~ # egdb --pid=44937 /usr/sbin/nsd
> GNU gdb (GDB) 7.12.1
> Copyright (C) 2017 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-unknown-openbsd7.0".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /usr/sbin/nsd...(no debugging symbols found)...done.
> Attaching to program: /usr/sbin/nsd, process 44937
> Reading symbols from /usr/lib/libssl.so.50.0...done.
> Reading symbols from /usr/lib/libcrypto.so.47.0...done.
> Reading symbols from /usr/lib/libevent.so.4.1...done.
> Reading symbols from /usr/lib/libc.so.96.1...done.
> Reading symbols from /usr/libexec/ld.so...done.
> [Switching to thread 563101]
> kevent () at /tmp/-:3
> 3   /tmp/-: No such file or directory.
> 
> Anything I am missing?
> 
> Mischa
> 

Do you see a gdb prompt? If so

  continue

should it (and then wait for the crash).

If you still see the crashes, a tcpdump of the traffic to nsd might
helps as well, I can replay that locally against nsd. I would also
need your nsd config for that.

-Otto

Re: NSD exit status 11 on 7.0

[Martijn van Duren]

On Tue, 2021-10-19 at 19:56 +0200, Otto Moerbeek wrote:
> On Tue, Oct 19, 2021 at 07:49:15PM +0200, Mischa wrote:
> 
> > On 2021-10-15 20:05, 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
> > > 
> > > 
> > > 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@.
> > 
> > Thanx Otto.
> > 
> > As this is my first time using gdb, I need some assistance.
> > 
> > root@name2:~ # ps -aux | grep nsd
> > _nsd 79188  0.0  1.0 101704 86400 ??  Ip  7:31PM0:00.20 nsd:
> > xfrd (nsd)
> > _nsd 24002  0.0  0.4 37188 37388 ??  Ip  7:31PM0:00.29 nsd: main
> > (nsd)
> > _nsd 44937  0.0  0.2 37544 18308 ??  Sp  7:45PM0:00.11 nsd:
> > server 1 (nsd)
> > 
> > root@name2:~ # egdb --pid=44937 /usr/sbin/nsd
> > GNU gdb (GDB) 7.12.1
> > Copyright (C) 2017 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later
> > 
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> > and "show warranty" for details.
> > This GDB was configured as "x86_64-unknown-openbsd7.0".
> > Type "show configuration" for configuration details.
> > For bug reporting instructions, please see:
> > .
> > Find the GDB manual and other documentation resources online at:
> > .
> > For help, type "help".
> > Type "apropos word" to search for commands related to "word"...
> > Reading symbols from /usr/sbin/nsd...(no debugging symbols found)...done.
> > Attaching to program: /usr/sbin/nsd, process 44937
> > Reading symbols from /usr/lib/libssl.so.50.0...done.
> > Reading symbols from /usr/lib/libcrypto.so.47.0...done.
> > Reading symbols from /usr/lib/libevent.so.4.1...done.
> > Reading symbols from /usr/lib/libc.so.96.1...done.
> > Reading symbols from /usr/libexec/ld.so...done.
> > [Switching to thread 563101]
> > kevent () at /tmp/-:3
> > 3   /tmp/-: No such file or directory.
> > 
> > Anything I am missing?
> > 
> > Mischa
> > 
> 
> Do you see a gdb prompt? If so
> 
>   continue
> 
> should it (and then wait for the crash).
> 
> If you still see the crashes, a tcpdump of the traffic to nsd might
> helps as well, I can replay that locally against nsd. I would also
> need your nsd config for that.
> 
>   -Otto
> 
I did some debugging with Mischa.

Unfortunately I misclicked and deleted the backtrace. However, the
problem was that query.c calls add_rrset (query.c:736) from
answer_delegation (query.c:917), where rrset is NULL.

When looking in the original query it was always a PTR request to
an IPv6 record. When looking through the file we tried to remove
some likely suspect entries to see if we could pinpoint the root-
cause, but after readding everything it wouldn't crash anymore.

Adding a simple comment to the zonefile of the second NS server
yielded the same result: the server won't crash anymore.

Mischa is going to monitor the situation to see if the issues
return, but my current best guess is that some weird state got
cached somewhere somehow and got flushed when saving the
zonefile.

martijn@

Re: How does bsd.upgrade work?

[Stuart Henderson]

On 2021/10/19 19:30, tetrahe...@danwin1210.me wrote:
> On Mon, Oct 18, 2021 at 07:41:57PM -, Stuart Henderson wrote:
> > > I resolved the problem. The solution was to run `sysupgrade -n` to
> > > download all the upgrade files, and leave the `bsd.upgrade` kernel in
> > > place, next to the `bsd` kernel I usually boot.
> > > 
> > > Then, at the next boot, manually boot the `bsd.upgrade` kernel by
> > > specifying its location.
> > 
> > Sounds like you aren't using the correct boot loader.
> 
> That's intentional.

OK. Since you didn't realise this breaks sysupgrade you might also
not realise it weakens RNG initialisation, it is not recommended

Re: How does bsd.upgrade work?

[tetrahedra]

On Mon, Oct 18, 2021 at 07:41:57PM -, Stuart Henderson wrote:

I resolved the problem. The solution was to run `sysupgrade -n` to
download all the upgrade files, and leave the `bsd.upgrade` kernel in
place, next to the `bsd` kernel I usually boot.

Then, at the next boot, manually boot the `bsd.upgrade` kernel by
specifying its location.


Sounds like you aren't using the correct boot loader.


That's intentional.

Re: How does bsd.upgrade work?

[tetrahedra]

On Mon, Oct 18, 2021 at 05:41:26PM +0200, Florian Obser wrote:

I wouldn't call this "resolved". You are missing the point that
bsd.upgrade should run automatically. *shrug*


My setup is not standard, so it's normal that bsd.upgrade not run
automatically. The solution I used, as far as I know, is by far the
simplest and easiest way of resolving the problem.

Re: NSD exit status 11 on 7.0

[Otto Moerbeek]

On Tue, Oct 19, 2021 at 09:47:22PM +0200, Martijn van Duren wrote:

> On Tue, 2021-10-19 at 19:56 +0200, Otto Moerbeek wrote:
> > On Tue, Oct 19, 2021 at 07:49:15PM +0200, Mischa wrote:
> > 
> > > On 2021-10-15 20:05, 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
> > > > 
> > > > 
> > > > 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@.
> > > 
> > > Thanx Otto.
> > > 
> > > As this is my first time using gdb, I need some assistance.
> > > 
> > > root@name2:~ # ps -aux | grep nsd
> > > _nsd 79188  0.0  1.0 101704 86400 ??  Ip  7:31PM0:00.20 nsd:
> > > xfrd (nsd)
> > > _nsd 24002  0.0  0.4 37188 37388 ??  Ip  7:31PM0:00.29 nsd: 
> > > main
> > > (nsd)
> > > _nsd 44937  0.0  0.2 37544 18308 ??  Sp  7:45PM0:00.11 nsd:
> > > server 1 (nsd)
> > > 
> > > root@name2:~ # egdb --pid=44937 /usr/sbin/nsd
> > > GNU gdb (GDB) 7.12.1
> > > Copyright (C) 2017 Free Software Foundation, Inc.
> > > License GPLv3+: GNU GPL version 3 or later
> > > 
> > > This is free software: you are free to change and redistribute it.
> > > There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> > > and "show warranty" for details.
> > > This GDB was configured as "x86_64-unknown-openbsd7.0".
> > > Type "show configuration" for configuration details.
> > > For bug reporting instructions, please see:
> > > .
> > > Find the GDB manual and other documentation resources online at:
> > > .
> > > For help, type "help".
> > > Type "apropos word" to search for commands related to "word"...
> > > Reading symbols from /usr/sbin/nsd...(no debugging symbols found)...done.
> > > Attaching to program: /usr/sbin/nsd, process 44937
> > > Reading symbols from /usr/lib/libssl.so.50.0...done.
> > > Reading symbols from /usr/lib/libcrypto.so.47.0...done.
> > > Reading symbols from /usr/lib/libevent.so.4.1...done.
> > > Reading symbols from /usr/lib/libc.so.96.1...done.
> > > Reading symbols from /usr/libexec/ld.so...done.
> > > [Switching to thread 563101]
> > > kevent () at /tmp/-:3
> > > 3   /tmp/-: No such file or directory.
> > > 
> > > Anything I am missing?
> > > 
> > > Mischa
> > > 
> > 
> > Do you see a gdb prompt? If so
> > 
> >   continue
> > 
> > should it (and then wait for the crash).
> > 
> > If you still see the crashes, a tcpdump of the traffic to nsd might
> > helps as well, I can replay that locally against nsd. I would also
> > need your nsd config for that.
> > 
> > -Otto
> > 
> I did some debugging with Mischa.
> 
> Unfortunately I misclicked and deleted the backtrace. However, the
> problem was that query.c calls add_rrset (query.c:736) from
> answer_delegation (query.c:917), where rrset is NULL.
> 
> When looking in the original query it was always a PTR request to
> an IPv6 record. When looking through the file we tried to remove
> some likely suspect entries to see if we could pinpoint the root-
> cause, but after readding everything it wouldn't crash anymore.
> 
> Adding a simple comment to the zonefile of the seco

Re: NSD exit status 11 on 7.0

[Mischa]

On 2021-10-20 07:30, Otto Moerbeek wrote:

On Tue, Oct 19, 2021 at 09:47:22PM +0200, Martijn van Duren wrote:

On Tue, 2021-10-19 at 19:56 +0200, Otto Moerbeek wrote:
> On Tue, Oct 19, 2021 at 07:49:15PM +0200, Mischa wrote:
> > On 2021-10-15 20:05, 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
> > >
> > >
> > > 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@.
> >
> > Thanx Otto.
> >
> > As this is my first time using gdb, I need some assistance.
> >
> > root@name2:~ # ps -aux | grep nsd
> > _nsd 79188  0.0  1.0 101704 86400 ??  Ip  7:31PM0:00.20 nsd:
> > xfrd (nsd)
> > _nsd 24002  0.0  0.4 37188 37388 ??  Ip  7:31PM0:00.29 nsd: main
> > (nsd)
> > _nsd 44937  0.0  0.2 37544 18308 ??  Sp  7:45PM0:00.11 nsd:
> > server 1 (nsd)
> >
> > root@name2:~ # egdb --pid=44937 /usr/sbin/nsd
> > GNU gdb (GDB) 7.12.1
> > Copyright (C) 2017 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later
> > 
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> > and "show warranty" for details.
> > This GDB was configured as "x86_64-unknown-openbsd7.0".
> > Type "show configuration" for configuration details.
> > For bug reporting instructions, please see:
> > .
> > Find the GDB manual and other documentation resources online at:
> > .
> > For help, type "help".
> > Type "apropos word" to search for commands related to "word"...
> > Reading symbols from /usr/sbin/nsd...(no debugging symbols found)...done.
> > Attaching to program: /usr/sbin/nsd, process 44937
> > Reading symbols from /usr/lib/libssl.so.50.0...done.
> > Reading symbols from /usr/lib/libcrypto.so.47.0...done.
> > Reading symbols from /usr/lib/libevent.so.4.1...done.
> > Reading symbols from /usr/lib/libc.so.96.1...done.
> > Reading symbols from /usr/libexec/ld.so...done.
> > [Switching to thread 563101]
> > kevent () at /tmp/-:3
> > 3   /tmp/-: No such file or directory.
> >
> > Anything I am missing?
> >
> > Mischa
> >
>
> Do you see a gdb prompt? If so
>
>   continue
>
> should it (and then wait for the crash).
>
> If you still see the crashes, a tcpdump of the traffic to nsd might
> helps as well, I can replay that locally against nsd. I would also
> need your nsd config for that.
>
>-Otto
>
I did some debugging with Mischa.

Unfortunately I misclicked and deleted the backtrace. However, the
problem was that query.c calls add_rrset (query.c:736) from
answer_delegation (query.c:917), where rrset is NULL.

When looking in the original query it was always a PTR request to
an IPv6 record. When looking through the file we tried to remove
some likely suspect entries to see if we could pinpoint the root-
cause, but after readding everything it wouldn't crash anymore.

Adding a simple comment to the zonefile of the second NS server
yielded the same result: the server won't crash anymore.

Mischa is going to monitor the situation to see if the issues
return, but my current best guess is that some weird state got
cached somewhere somehow and got flushed when saving the
zonefile.

martijn@



Maybe some form of corruption in the zonefile th

Re: NSD exit status 11 on 7.0

[Otto Moerbeek]

On Wed, Oct 20, 2021 at 07:47:30AM +0200, Mischa wrote:

> On 2021-10-20 07:30, Otto Moerbeek wrote:
> > On Tue, Oct 19, 2021 at 09:47:22PM +0200, Martijn van Duren wrote:
> > > On Tue, 2021-10-19 at 19:56 +0200, Otto Moerbeek wrote:
> > > > On Tue, Oct 19, 2021 at 07:49:15PM +0200, Mischa wrote:
> > > > > On 2021-10-15 20:05, 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
> > > > > >
> > > > > >
> > > > > > 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@.
> > > > >
> > > > > Thanx Otto.
> > > > >
> > > > > As this is my first time using gdb, I need some assistance.
> > > > >
> > > > > root@name2:~ # ps -aux | grep nsd
> > > > > _nsd 79188  0.0  1.0 101704 86400 ??  Ip  7:31PM0:00.20 
> > > > > nsd:
> > > > > xfrd (nsd)
> > > > > _nsd 24002  0.0  0.4 37188 37388 ??  Ip  7:31PM0:00.29 
> > > > > nsd: main
> > > > > (nsd)
> > > > > _nsd 44937  0.0  0.2 37544 18308 ??  Sp  7:45PM0:00.11 
> > > > > nsd:
> > > > > server 1 (nsd)
> > > > >
> > > > > root@name2:~ # egdb --pid=44937 /usr/sbin/nsd
> > > > > GNU gdb (GDB) 7.12.1
> > > > > Copyright (C) 2017 Free Software Foundation, Inc.
> > > > > License GPLv3+: GNU GPL version 3 or later
> > > > > 
> > > > > This is free software: you are free to change and redistribute it.
> > > > > There is NO WARRANTY, to the extent permitted by law.  Type "show 
> > > > > copying"
> > > > > and "show warranty" for details.
> > > > > This GDB was configured as "x86_64-unknown-openbsd7.0".
> > > > > Type "show configuration" for configuration details.
> > > > > For bug reporting instructions, please see:
> > > > > .
> > > > > Find the GDB manual and other documentation resources online at:
> > > > > .
> > > > > For help, type "help".
> > > > > Type "apropos word" to search for commands related to "word"...
> > > > > Reading symbols from /usr/sbin/nsd...(no debugging symbols 
> > > > > found)...done.
> > > > > Attaching to program: /usr/sbin/nsd, process 44937
> > > > > Reading symbols from /usr/lib/libssl.so.50.0...done.
> > > > > Reading symbols from /usr/lib/libcrypto.so.47.0...done.
> > > > > Reading symbols from /usr/lib/libevent.so.4.1...done.
> > > > > Reading symbols from /usr/lib/libc.so.96.1...done.
> > > > > Reading symbols from /usr/libexec/ld.so...done.
> > > > > [Switching to thread 563101]
> > > > > kevent () at /tmp/-:3
> > > > > 3   /tmp/-: No such file or directory.
> > > > >
> > > > > Anything I am missing?
> > > > >
> > > > > Mischa
> > > > >
> > > >
> > > > Do you see a gdb prompt? If so
> > > >
> > > >   continue
> > > >
> > > > should it (and then wait for the crash).
> > > >
> > > > If you still see the crashes, a tcpdump of the traffic to nsd might
> > > > helps as well, I can replay that locally against nsd. I would also
> > > > need your nsd config for that.
> > > >
> > >