Daily insecurity email: Setuid changes: /usr/bin/ssh-agent

[Why 42? The lists account.]

I noticed this email message this morning:
> Subject: mjoelnir.fritz.box daily insecurity output
> From: "Charlie Root @ mjoelnir_aa1667" ...
> To: ...
> Date: Fri, 07 Jun 2024 01:32:17 +0200 (CEST)
> 
> 
> Running security(8):
> 
> Setuid changes:
> -r-x--s--x 1 root _sshagnt 435040 May 20 14:18:15 2024 /usr/bin/ssh-agent
> -r-x--s--x 1 root _sshagnt 435040 Jun 6  12:07:27 2024 /usr/bin/ssh-agent

It's true:
mjoelnir:2024 7.06 14:00:57 % stat -x /usr/bin/ssh-agent
  File: "/usr/bin/ssh-agent"
  Size: 435040   FileType: Regular File
  Mode: (2511/-r-x--s--x) Uid: (0/root)  Gid: (   34/_sshagnt)
Device: 4,21   Inode: 156169Links: 1
Access: Fri Jun  7 01:30:01 2024
Modify: Thu Jun  6 12:07:27 2024
Change: Thu Jun  6 12:07:27 2024

mjoelnir:2024 7.06 16:10:01 % ls -ltra /usr/bin | tail
-r-xr-xr-x   1 root  bin  191200 May 19 23:41 info*
-r-xr-xr-x   1 root  bin   24000 May 19 23:41 infokey*
-r-xr-xr-x   1 root  bin  281960 May 19 23:41 makeinfo*
-r-xr-xr-x   1 root  bin   31568 May 19 23:41 install-info*
-r-xr-xr-x   1 root  bin   30560 May 19 23:41 texindex*
-r-xr-xr-x   1 root  bin   28070 May 19 23:41 texi2dvi*
-r-xr-xr-x   1 root  bin 665 May 19 23:41 texi2pdf*
drwxr-xr-x  16 root  wheel   512 May 20 00:31 ../
-r-x--s--x   1 root  _sshagnt 435040 Jun  6 12:07 ssh-agent*
drwxr-xr-x   2 root  wheel  6144 Jun  6 12:07 ./

Is that not a bit weird? Why would ssh-agent have changed / been
"touched"? Maybe that's when I booted the system ... Does it make sense
that starting an executable would cause its mtime to be set?

Just wondering ...

Cheers,
Robb.

Re: Q: Problems forwarding traffic using pf ...

[Why 42? The lists account.]

Sorry about the delay in replying, i was travelling ...

On Fri, May 24, 2024 at 06:04:25PM +0200, Peter N. M. Hansteen wrote:
> ...
> > May 23 10:32:13.267374 rule 1/(match) pass in on em0: 192.168.178.166.56334 
> > > 192.168.178.11.54321: udp 7
> So this last one never leaves, right?
Right.

> what does the gateway's routing table say about how to reach the destination 
> network?
Good question. Does it matter what the routing table contains, when I am
explicitly specifying where to send a packet via a pf rule?

In any case, here it is:
mjoelnir:/etc 7.06 15:29:04 # netstat -rnf inet
Routing tables
Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
default192.168.178.254UGS   1112713 - 8 em0
127/8  127.0.0.1  UGRS   00 32768 8 lo0
127.0.0.1  127.0.0.1  UHhl   12 32768 1 lo0
192.168.168/24 192.168.168.1  UCn00 - 4 ure0
192.168.168.1  14:eb:b6:85:09:08  UHLl   00 - 1 ure0
192.168.168.255192.168.168.1  UHb00 - 1 ure0
192.168.178/24 192.168.178.11 UCn4 2630 - 4 em0
192.168.178.11 94:c6:91:aa:16:67  UHLl   0 8094 - 1 em0
192.168.178.12 00:d8:61:4f:0d:9a  UHLc   0 2588 - 3 em0
192.168.178.13 50:7b:9d:ee:e0:b9  UHLc   1 3077 - 3 em0
192.168.178.250fc:f5:28:ed:05:e5  UHLc   0   90 - 3 em0
192.168.178.25444:4e:6d:77:42:68  UHLch  225477 - 3 em0
192.168.178.255192.168.178.11 UHb0   15 - 1 em0

> also relevant, what is the configuration of the interfaces involved?
# ifconfig em0
em0: 
flags=a48843
 mtu 1492
lladdr 94:c6:91:aa:16:67
index 1 priority 0 llprio 3
groups: egress
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet6 fe80::96c6:91ff:feaa:1667%em0 prefixlen 64 scopeid 0x1
inet 192.168.178.11 netmask 0xff00 broadcast 192.168.178.255

# ifconfig ure0
ure0: flags=8843 mtu 1500
lladdr 14:eb:b6:85:09:08
description: Desc: Testing pf
index 5 priority 0 llprio 3
media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
status: active
inet 192.168.168.1 netmask 0xff00 broadcast 192.168.168.255

Also this was well spotted by Le Zoff:
> Why setting "flags S/SA" on a rule meant for UDP packets?
I guess pf itself added the flags, presumably because I had not
explicitly specified "udp" in my second rule. So here is the same test,
this time with "proto udp":

mjoelnir:/etc 7.06 15:29:19 # cat pf.conf_forwarding_minimal
set skip on lo0
set block-policy return
set debug warning

block log all   # Begin by blocking everything

pass in  log on em0 proto udp from 192.168.178.0/24 tag UDP
pass out log on ure0 proto udp tagged UDP

mjoelnir:/etc 7.06 15:29:27 # pfctl -nf pf.conf_forwarding_minimal
mjoelnir:/etc 7.06 15:29:38 # pfctl -f pf.conf_forwarding_minimal
mjoelnir:/etc 7.06 15:29:43 # pfctl -vvs rules | grep @
@0 block return log all
@1 pass in log on em0 inet proto udp from 192.168.178.0/24 to any tag UDP
@2 pass out log on ure0 proto udp all tagged UDP

So, no TCP flags any more, but still no packets out on ure0. Tcpdump
shows only this udp test packet coming in on em0:
tcpdump -n -e -ttt -i pflog0
...
Jun 07 15:52:36.462672 rule 1/(match) pass in on em0: 192.168.178.13.54128 > 
192.168.178.11.12345: udp 19
...

Re: Q: Problems forwarding traffic using pf ...

[Why 42? The lists account.]

Hi Guys,

Thanks for the feedback, to address your points:

1> Possibly stupid question, but did you set the sysctl(s) to enable forwarding?

Yes I tried this pf rule change with version 4 forwarding
(net.inet.ip.forwarding) both enabled and disabled.

Either way the pf "pass out tagged" rule is never matched.

I didn't reboot after changing this setting. It's not clear to me if that
is necessary. For the version 6 variable (net.inet6.ip6.forwarding) "man
2 sysctl" states: 

"... changing this variable during operation may cause serious trouble.
 Hence, this variable should only be set at bootstrap time."

Whatever that might mean. Anyway, for the version 4 variable there no
similar remark.


2> And there is also mforwarding
3> And multicast=YES rc.conf.local

In this first simple proof/test I just tried to forward some UDP. So this
is not yet relevant. But I think you are both right, if I get as far as
doing multicasting, I'll probably need those.

Out of interest I grepped in /etc and it seems that setting multicast=YES
influences the netstart script. When multicast is not "YES" then the
route for 224.0.0.0/4 is deleted and re-added to the IP loopback address
with an option "reject".

Cheers,
Robb.

Q: Problems forwarding traffic using pf ...

[Why 42? The lists account.]

Hi All,

I need to quickly create a solution for forwarding multicast traffic
between two systems, so I though perhaps I could use pf to do just that
by writing some rules along the lines of:

1. pass in on iface A proto UDP ... tag mcast
2. pass out on iface B tagged mcast

And another pair of rules for the reverse direction B -> A.

(Obviously I'd add more options to filter specific addresses, etc.)

So I tried to do a quick test / proof of concept. Here is the pf.conf:
# cat pf.conf
set skip on lo0
set block-policy return
set debug warning

# Begin by blocking everything
block log all   # Begin by blocking everything
pass  in  log on em0proto udp from 192.168.178.166 tag UDP
pass  out log on ure0   tagged UDP
###match route dup-to ure0 tagged TAG_UP

# Allow all outbound
#pass out log modulate state

The two "pass" lines are the basis of the idea. This seems to be pretty
much identical to the tagging example "INTNET" in the pf.conf man page.

pfctl reports:
# pfctl -vvs rules | grep @
@0 block return log all
@1 pass in log on em0 inet proto udp from 192.168.178.166 to any tag UDP
@2 pass out log on ure0 all flags S/SA tagged UDP

I see that rule 1 is matched, but never rule 2. E.g.
...
May 23 10:32:06.602759 rule 0/(match) block in on em0: 192.168.178.179.5353 > 
224.0.0.251.5353: 46[|domain] (DF)
May 23 10:32:06.603963 rule 0/(match) block in on em0: 
fe80::4434:8bff:fecd:b116.5353 > ff02::fb.5353: 46[|domain] [flowlabel 0xbaff9]
May 23 10:32:09.700212 rule 0/(match) block in on em0: 192.168.178.254 > 
224.0.0.1: igmp query [len 12] (DF) [tos 0xc0] [ttl 1]
May 23 10:32:13.267374 rule 1/(match) pass in on em0: 192.168.178.166.56334 > 
192.168.178.11.54321: udp 7
May 23 10:32:20.592971 rule 0/(match) block in on em0: 192.168.178.179.5353 > 
224.0.0.251.5353: 16 [3q][|domain] (DF)
May 23 10:32:21.136275 rule 0/(match) block in on em0: 192.168.178.252.5353 > 
224.0.0.251.5353: 48084+[|domain]
May 23 10:32:21.137074 rule 0/(match) block in on em0: 192.168.178.252.5353 > 
224.0.0.251.5353: 0* [0q] 3/0/3[|domain]
...
May 23 10:32:48.588466 rule 1/(match) pass in on em0: 192.168.178.166.56335 > 
192.168.178.11.54321: udp 42
May 23 10:32:49.705282 rule 0/(match) block in on em0: 192.168.178.179.5353 > 
224.0.0.251.5353: 0[|domain] (DF)
May 23 10:32:49.705839 rule 0/(match) block in on em0: 
fe80::4434:8bff:fecd:b116.5353 > ff02::fb.5353: 0[|domain] [flowlabel 0xbaff9]
...

I must be missing something, but what?

Both interfaces are up and configured with IP addresses.
I'm running the current snapshot i.e. 7.5 GENERIC.MP#77 amd64.

Thanks in advance!

Cheers,
Robb.

Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"

[Why 42? The lists account.]

On Sat, Apr 06, 2024 at 02:42:25PM +0200, Eivind Eide wrote:
> After upgrading to 7.5 amd64 -stable  (and all ports updated) I get
> these messages in /var/log/messages. This is with bash from ports
> inside tmux over SSH:
> 
> tmux: vfprintf %s NULL in "%.*s"
> bash: vfprintf %s NULL in "%.*s"
> multitail: vfprintf %s NULL in "%.*s"
> vim: vfprintf %s NULL in "%.*s"

FYI, I grepped my messages and saw something similar:
mjoelnir:~ 9.04 14:10:46 % grep printf /var/log/messages
Apr  4 18:22:26 mjoelnir tumblerd: vfprintf %s NULL in "Unable to find part 
with type='%s' for '%s'"
Apr  4 18:22:26 mjoelnir tumblerd: vfprintf %s NULL in "Unable to find part 
with type='%s' for '%s'"
Apr  8 13:57:02 mjoelnir wrapper-2.0: vfprintf %s NULL in "day=%s, sun={%s, %s, 
%s, %s}, moon={%s, %s, %s, %s, %s} "
Apr  8 13:57:02 mjoelnir wrapper-2.0: vfprintf %s NULL in "day=%s, sun={%s, %s, 
%s, %s}, moon={%s, %s, %s, %s, %s} "
Apr  9 13:57:06 mjoelnir wrapper-2.0: vfprintf %s NULL in "day=%s, sun={%s, %s, 
%s, %s}, moon={%s, %s, %s, %s, %s} "
Apr  9 13:57:06 mjoelnir wrapper-2.0: vfprintf %s NULL in "day=%s, sun={%s, %s, 
%s, %s}, moon={%s, %s, %s, %s, %s} "

The "wrapper-2.0" program is, I think, part of XFCE, I see that name in
the desktop panel configuraion. Tumbler is something to do with D-Bus and
is also a required package by/for XFCE.

Cheers,
Robb.


mjoelnir:~ 9.04 14:11:01 % uname -a
OpenBSD mjoelnir.fritz.box 7.5 GENERIC.MP#18 amd64

mjoelnir:~ 9.04 14:10:54 % echo $TERM
rxvt-unicode-256color

mjoelnir:~ 9.04 14:10:50 % locale
LANG=
LC_COLLATE=C
LC_CTYPE=en_US.UTF-8
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_MESSAGES="C"
LC_ALL=

mjoelnir:~ 9.04 14:11:04 % egrep -v '^(#|$)' .xsession
NO_AT_BRIDGE=1 ; export NO_AT_BRIDGE
LC_CTYPE="en_US.UTF-8"; export LC_CTYPE
LC_COLLATE=C; export LC_COLLATE
xrandr --dpi 109
xset +fp /usr/local/share/fonts/Hack
xset +fp /usr/local/share/fonts/terminus
xset +fp /usr/local/share/fonts/victor-mono
/usr/local/bin/startxfce4

Re: ***UNCHECKED*** Re: Post (snap) update emails: fsck errors and (in)security output

[Why 42? The lists account.]

On Thu, Dec 21, 2023 at 08:20:37AM -0300, Crystal Kolipe wrote:
> > login.conf used to allow unlimited datasize for the 'daemon' class. That was
> > changed to cap at 4G
> 
> Actually the value is an architecture dependent setting.
> 
> On amd64 it is indeed 4G, but typically 1024 Mb on the smaller archs which
> until recently, (post 7.4), included i386, which has now been increased to
> 1500 Mb.
Shouldn't it vary according to the amount of RAM available on the system?
Or is the backing store (swap) more relevant? Anyway ...

> BTW, we already had this exact same discussion with Robb on the list back in
> February:
> 
> https://marc.info/?l=openbsd-misc&m=167561903118994
> 
> So when I asked why he didn't just bump the value, it was indeed a question
> and not a suggestion to just do it.
Oh right :-) Seems like I was fat and happy in February with "-s=4194304"
in fstab and "df -h /tmp" returning 1.8G available.

I don't know why or when it stopped working in the meantime. Maybe daily
should report failed mounts? I mean, normally, something like that is
hard to miss, but with /tmp it's not so obvious. Just a thought.

I guess I tend to avoid modifying login.conf to avoid having to fix
issues reported by sysmerge after an upgrade. But in reality those don't
occur that often and I'm just being overly sensitive.

Right now login.conf contains:
> daemon:\
>:ignorenologin:\
>:datasize=4096M:\
>:maxproc=infinity:\
>:openfiles-max=1024:\
>:openfiles-cur=128:\
>:stacksize-cur=8M:\
>:tc=default:
> ...

I was just able to mfs_mount 2GB on the command line:
> mjoelnir:robb 28.12 17:13:17 # mkdir /tmptmp   
> mjoelnir:robb 28.12 17:13:25 # df -h /tmptmp   
> Filesystem SizeUsed   Avail Capacity  Mounted on
> /dev/sd1a 1005M250M704M27%/
> mjoelnir:robb 28.12 17:13:29 # mount_mfs -s 4194304 swap /tmptmp
> mjoelnir:robb 28.12 17:13:43 # df -h /tmptmp
> Filesystem SizeUsed   Avail Capacity  Mounted on
> mfs:23190  1.9G1.0K1.8G 1%/tmptmp

That was as root though, so maybe that's not such a great test. Is it
possible to do something like "doas daemon ..."?

I'll switch fstab back to use this size for /tmp and check after the next
reboot if it gets mounted as expected ...

Cheers,
Robb.

Re: Post (snap) update emails: fsck errors and (in)security output

[Why 42? The lists account.]

On Wed, Dec 20, 2023 at 10:57:41AM -0500, Nick Holland wrote:
> the ROOTBACKUP process is making an image of a live file system; fsck
> grumblings ARE expected.  It's just one of those things you aren't supposed
> to do (but I do it regularly, because normally, you can get away with it).
> 
> Why the files it is grumbling about are owned by you ... that is a puzzle.
> Is your /tmp on a separate partition?  If so, it shouldn't be being backed
> up by the ROOTBACKUP process.  Same for "home" or any other file system you
> have access write to.

Interesting ... unexpectedly /tmp _is_ part of the root filesystem.

I have an entry in fstab to mount it as a seperate mfs filesystem but
that has failed for some reason. Probably then this is the reason that
the fsck errors are now occurring, being reported, and that I noticed
them.

Previously, when /tmp was transient, the root filesystem and the altroot
fsck process were not affected by content in /tmp.

Just tried the mount of /tmp manually from the command line at got:
mount_mfs: mmap: Cannot allocate memory

When I halved the size (memory) allocated (-s=2097152) it mounts
successfully:
mjoelnir:robb 20.12 19:50:02 # df -h /tmp
Filesystem SizeUsed   Avail Capacity  Mounted on
mfs:75507  1.9G1.0K1.8G 1%/tmp

Strange that it used to work. One day (!) I'll re-partition and allocate
a partition/slice of "real" storage to /tmp instead of using mfs.


> I also see this:
> > Backing up root=/dev/rsd1a to /dev/rsd0a:
> is sd1a actually your root, and sd0a actually your altroot?
 
> > Second question: Also after an upgrade, the "daily insecurity output"
> > contains a huge amount of setuid changes e.g.
> > ...
> > What actually changed then?
> 
> The files.

Aha! - I see. I had in my head somehow understood "Setuid changes:" to
mean "changes to the setuid flags/bits of these files ...", not "these
files are suid and their content has changed". Maybe that is a better
description.

> (and yes, I have seen events where a major upgrade caused a lot of noise in
> a "something changed" file...which unfortunately hid something we needed to
> know about ALSO happened, and was dismissed as "part of the upgrade noise".
> This wasn't OpenBSD nor was it a "security event", but it did delay the
> detection and repair of a redundancy failure issue because one line was
> missed in a sea of thousands of lines of "yeah, that's expected" noise.)

It is a fair bit of noise in this case ... even more so with the
following "Block device changes" and the even longer "rpki" related
section.

Thanks!

Cheers,
Robb.

Re: XFCE Thunar filemanager core dumps ...

[Why 42? The lists account.]

On Wed, Dec 20, 2023 at 03:23:52PM -, Stuart Henderson wrote:
> > ...
> > When I started gdb (no expert) I noticed this "Dwarf error":
> > mjoelnir:/tmp 20.12 12:04:38 % gdb -e /usr/local/bin/Thunar -c thunar.core
> > GNU gdb 6.3
> 
> https://www.openbsd.org/faq/ports/ports.html#Backtrace

Thanks. What I understood from there then was to install the debug
package and run egdb + "bt". Hopefully that's what you had in mind.
Here's the resulting stack trace, the "optimized out" sounds a bit
worrying :-):

(gdb) bt
#0  0x084822eb0565 in g_node_traverse_pre_order () from 
/usr/local/lib/libglib-2.0.so.4201.11
#1  0x084822eb0577 in g_node_traverse_pre_order () from 
/usr/local/lib/libglib-2.0.so.4201.11
#2  0x084822eb0577 in g_node_traverse_pre_order () from 
/usr/local/lib/libglib-2.0.so.4201.11
#3  0x084570b35046 in thunar_tree_view_set_show_hidden (view=0x848252483c0, 
show_hidden=) at thunar-tree-view.c:1990
#4  thunar_tree_view_set_property (object=0x848252483c0, prop_id=, value=, pspec=) at thunar-tree-view.c:509
#5  0x084827e3c82a in object_set_property () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#6  0x084827e3c5a8 in g_object_setv () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#7  0x084827e3d94b in g_object_set_property () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#8  0x084827e2cf19 in on_source_notify () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#9  0x084827e3442b in g_closure_invoke () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#10 0x084827e50f4c in signal_emit_unlocked_R.123 () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#11 0x084827e4ebab in signal_emit_valist_unlocked () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#12 0x084827e4f39f in g_signal_emit () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#13 0x084827e40a53 in g_object_dispatch_properties_changed () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#14 0x084827e3ae1c in g_object_notify_by_spec_internal () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#15 0x084570b43c07 in thunar_window_action_show_hidden 
(window=0x848393b6760) at thunar-window.c:4727
#16 0x0847e652dc4e in _gtk_marshal_BOOLEAN__OBJECT_UINT_FLAGS () from 
/usr/local/lib/libgtk-3.so.2201.0
#17 0x084827e3442b in g_closure_invoke () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#18 0x084827e4ff6d in signal_emit_unlocked_R () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#19 0x084827e4ec0f in signal_emit_valist_unlocked () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#20 0x084827e4f39f in g_signal_emit () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#21 0x0847e65498d2 in gtk_accel_group_activate () from 
/usr/local/lib/libgtk-3.so.2201.0
#22 0x0847e6549a24 in gtk_accel_groups_activate () from 
/usr/local/lib/libgtk-3.so.2201.0
#23 0x0847e686e048 in gtk_window_activate_key () from 
/usr/local/lib/libgtk-3.so.2201.0
#24 0x0847e6874325 in gtk_window_key_press_event () from 
/usr/local/lib/libgtk-3.so.2201.0
#25 0x0847e652ceb0 in _gtk_marshal_BOOLEAN__BOXED () from 
/usr/local/lib/libgtk-3.so.2201.0
#26 0x084827e3442b in g_closure_invoke () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#27 0x084827e50100 in signal_emit_unlocked_R () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#28 0x084827e4ec0f in signal_emit_valist_unlocked () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#29 0x084827e4f39f in g_signal_emit () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#30 0x0847e684e22a in gtk_widget_event_internal () from 
/usr/local/lib/libgtk-3.so.2201.0
#31 0x0847e66ce1cf in gtk_propagate_event () from 
/usr/local/lib/libgtk-3.so.2201.0
#32 0x0847e66cdbe1 in gtk_main_do_event () from 
/usr/local/lib/libgtk-3.so.2201.0
#33 0x08477220a65b in _gdk_event_emit () from 
/usr/local/lib/libgdk-3.so.2201.1
#34 0x084772263c88 in gdk_event_source_dispatch () from 
/usr/local/lib/libgdk-3.so.2201.1
#35 0x084822ea320d in g_main_context_dispatch_unlocked () from 
/usr/local/lib/libglib-2.0.so.4201.11
#36 0x084822ea35ec in g_main_context_iterate_unlocked () from 
/usr/local/lib/libglib-2.0.so.4201.11
#37 0x084822ea369b in g_main_context_iteration () from 
/usr/local/lib/libglib-2.0.so.4201.11
#38 0x0847e42d987d in g_application_run () from 
/usr/local/lib/libgio-2.0.so.4200.18
#39 0x084570acf399 in main (argc=1, argv=0x7ee77838c528) at main.c:86


mjoelnir:robb 20.12 18:42:54 # pkg_info | grep thunar
debug-thunar-4.18.8 debug info for thunar
thunar-4.18.8   Xfce4 file manager
thunar-archive-0.5.2 Thunar archive plugin
thunar-media-tags-0.4.0 Thunar media tags plugin

XFCE Thunar filemanager core dumps ...

[Why 42? The lists account.]

Hi All,

I'm running XFCE on OpenBSD 7.4 GENERIC.MP#1535 amd64

I pressed Control+h in thunar thinking that it would toggle the display
of hidden files ( .dot files), but instead thunar core dumps:
-rw---   1 robb  robb   20656304 Dec 19 21:02 thunar.core

Would this be an OpenBSD (porting) issue, or something upstream?

I don't see this behaviour on an adjacent Linux system (different
versions of XFCE though). I have these versions:
xfce-4.18.1 Xfce desktop meta-package (base installation)
thunar-4.18.8   Xfce4 file manager

When I started gdb (no expert) I noticed this "Dwarf error":
mjoelnir:/tmp 20.12 12:04:38 % gdb -e /usr/local/bin/Thunar -c thunar.core
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd7.4".
Core was generated by `thunar'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libpthread.so.27.1...done.
Loaded symbols for /usr/lib/libpthread.so.27.1
Loaded symbols for /usr/local/bin/Thunar
Reading symbols from /usr/local/lib/libthunarx-3.so.0.1...done.
Loaded symbols for /usr/local/lib/libthunarx-3.so.0.1
...
Reading symbols from /usr/libexec/ld.so...Error while reading shared library 
symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in 
module /usr/libexec/ld.so]


Here is some other output, perhaps relevant ...

Where:
(gdb) where
#0  0x0570de714565 in g_node_traverse_pre_order () from 
/usr/local/lib/libglib-2.0.so.4201.11
#1  0x0570de714577 in g_node_traverse_pre_order () from 
/usr/local/lib/libglib-2.0.so.4201.11
#2  0x0570de714577 in g_node_traverse_pre_order () from 
/usr/local/lib/libglib-2.0.so.4201.11
#3  0x056ec2b50046 in thunar_tree_view_set_property () from 
/usr/local/bin/Thunar
#4  0x05711845582a in object_set_property () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#5  0x0571184555a8 in g_object_setv () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#6  0x05711845694b in g_object_set_property () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#7  0x057118445f19 in on_source_notify () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#8  0x05711844d42b in g_closure_invoke () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#9  0x057118469f4c in signal_emit_unlocked_R.123 () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#10 0x057118467bab in signal_emit_valist_unlocked () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#11 0x05711846839f in g_signal_emit () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#12 0x057118459a53 in g_object_dispatch_properties_changed () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#13 0x057118453e1c in g_object_notify_by_spec_internal () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#14 0x056ec2b5ec07 in thunar_window_action_show_hidden () from 
/usr/local/bin/Thunar
#15 0x0571c0afdc4e in _gtk_marshal_BOOLEAN__OBJECT_UINT_FLAGS () from 
/usr/local/lib/libgtk-3.so.2201.0
#16 0x05711844d42b in g_closure_invoke () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#17 0x057118468f6d in signal_emit_unlocked_R () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#18 0x057118467c0f in signal_emit_valist_unlocked () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#19 0x05711846839f in g_signal_emit () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#20 0x0571c0b198d2 in gtk_accel_group_activate () from 
/usr/local/lib/libgtk-3.so.2201.0
#21 0x0571c0b19a24 in gtk_accel_groups_activate () from 
/usr/local/lib/libgtk-3.so.2201.0
#22 0x0571c0e3e048 in gtk_window_activate_key () from 
/usr/local/lib/libgtk-3.so.2201.0
#23 0x0571c0e44325 in gtk_window_key_press_event () from 
/usr/local/lib/libgtk-3.so.2201.0
#24 0x0571c0afceb0 in _gtk_marshal_BOOLEAN__BOXED () from 
/usr/local/lib/libgtk-3.so.2201.0
#25 0x05711844d42b in g_closure_invoke () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#26 0x057118469100 in signal_emit_unlocked_R () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#27 0x057118467c0f in signal_emit_valist_unlocked () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#28 0x05711846839f in g_signal_emit () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#29 0x0571c0e1e22a in gtk_widget_event_internal () from 
/usr/local/lib/libgtk-3.so.2201.0
#30 0x0571c0c9e1cf in gtk_propagate_event () from 
/usr/local/lib/libgtk-3.so.2201.0
#31 0x0571c0c9dbe1 in gtk_main_do_event () from 
/usr/local/lib/libgtk-3.so.2201.0
#32 0x0571359bd65b in _gdk_event_emit () from 
/usr/local/lib/libgdk-3.so.2201.1
#33 0x057135a16c88 in gdk_event_source_dispatch () from 
/usr/local/lib/libgdk-3.so.2201.1
#34 0x0570de70720d in g_main_co

Post (snap) update emails: fsck errors and (in)security output

[Why 42? The lists account.]

...
Reply-To: 

Hi All,

A couple of questions ...

I have "ROOTBACKUP=1" in /etc/daily.local to replicate my root partition
as described in the FAQ (https://www.openbsd.org/faq/faq14.html#altroot)

I noticed after an update to a new snapshot via sysupgrade that the next
daily output email contains many many fsck "UNREF FILE" errors (See the
output included below). Is this expected, or is there some problem? Most
or all of the files seem to be owned by me (robb) so I'm thinking that
these errors may be related to files in /tmp ... Not sure why this occurs
though?

Second question: Also after an upgrade, the "daily insecurity output"
contains a huge amount of setuid changes e.g.
...
-r-xr-sr-x 1 root auth   21144   Nov 30 15:36:52 2023 /usr/bin/skeyinit
-r-xr-sr-x 1 root auth   21144   Dec 19 08:35:26 2023 /usr/bin/skeyinit
-r-xr-sr-x 1 root _sshagnt   440496  Nov 30 15:36:53 2023 /usr/bin/ssh-agent
-r-xr-sr-x 1 root _sshagnt   443856  Dec 19 08:35:26 2023 /usr/bin/ssh-agent
-r-sr-xr-x 1 root bin19608   Nov 30 15:36:53 2023 /usr/bin/su
-r-sr-xr-x 1 root bin19608   Dec 19 08:35:27 2023 /usr/bin/su
-r-xr-sr-x 1 root tty17936   Nov 30 15:36:54 2023 /usr/bin/wall
-r-xr-sr-x 1 root tty17936   Dec 19 08:35:28 2023 /usr/bin/wall
-r-xr-sr-x 1 root tty14184   Nov 30 15:36:55 2023 /usr/bin/write
-r-xr-sr-x 1 root tty14184   Dec 19 08:35:28 2023 /usr/bin/write
-r-xr-sr-x 4 root _token 21248   Nov 30 15:36:44 2023 
/usr/libexec/auth/login_activ
-r-xr-sr-x 4 root _token 21248   Dec 19 08:35:18 2023 
/usr/libexec/auth/login_activ
...

What actually changed then?
Surely many or all of these files had the same permission bits before the
upgrade?
Maybe these files now have diffent inode numbers, after the upgrade?
Why is each filename reported twice? Are these "old" and "new" values?

Thanks in advance for any feedback!

Cheers,
Robb.


Subject: mjoelnir daily output
...
OpenBSD 7.4-current (GENERIC.MP) #1535: Tue Dec 19 00:55:53 MST 2023
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

 1:30AM  up  7:20, 7 users, load averages: 0.62, 0.44, 0.40

Backing up root=/dev/rsd1a to /dev/rsd0a:
131071+0 records in
131071+0 records out
1073733632 bytes transferred in 10.509 secs (102169077 bytes/sec)
** /dev/rsd0a
** Last Mounted on /
** Phase 1 - Check Blocks and Sizes
INCORRECT BLOCK COUNT I=26656 (64 should be 32)
CORRECT? yes

INCORRECT BLOCK COUNT I=26688 (4128 should be 0)
CORRECT? yes

** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
UNREF FILE I=26064  OWNER=robb MODE=100600
SIZE=4 MTIME=Dec 20 01:30 2023
CLEAR? yes

UNREF FILE I=26069  OWNER=robb MODE=10640
SIZE=0 MTIME=Dec 19 19:02 2023
CLEAR? yes

UNREF FILE I=26070  OWNER=robb MODE=10640
SIZE=0 MTIME=Dec 20 01:02 2023
CLEAR? yes

UNREF FILE I=26073  OWNER=robb MODE=100600
SIZE=28672 MTIME=Dec 20 01:30 2023
CLEAR? yes
...
** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? yes

SUMMARY INFORMATION BAD
SALVAGE? yes

BLK(S) MISSING IN BIT MAPS
SALVAGE? yes

6103 files, 101471 used, 412968 free (656 frags, 51539 blocks, 0.1% 
fragmentation)

MARK FILE SYSTEM CLEAN? yes


* FILE SYSTEM WAS MODIFIED *

Scanning (documents) no longer works: scanner not found?

[Why 42? The lists account.]

Hi All,

I just noticed that "simple-scan" no longer works, it cannot find my
scanner. This used to work just fine.

I'm running the latest (installed today) snapshot, but I don't know when
this stopped working - I try not to do much scanning :-)

The scanner is a Canon Pixma "Multi Function" device, connected via
Ethernet. (I never ever got it to print.)

Running simple-scan in debug mode doesn't show me much, I see:
> simple-scan -d
> [+0.00s] DEBUG: simple-scan.vala:2015: Starting simple-scan 44.0, PID=91216
> [+0.01s] DEBUG: unsetenv() is not thread-safe and should not be used after 
> threads are created
> [+0.04s] DEBUG: _g_io_module_get_default: Found default implementation gvfs 
> (GDaemonVfs) for ‘gio-vfs’
> [+0.18s] DEBUG: Portal not found: 
> GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
> org.freedesktop.portal.Desktop was not provided by any .service files
> [+0.18s] DEBUG: Portal not found: 
> GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
> org.freedesktop.portal.Desktop was not provided by any .service files
> [+0.18s] DEBUG: Portal not found: 
> GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
> org.freedesktop.portal.Desktop was not provided by any .service files
> [+0.18s] DEBUG: _g_io_module_get_default: Found default implementation dconf 
> (DConfSettingsBackend) for ‘gsettings-backend’
> [+0.18s] WARNING: Using GtkSettings:gtk-application-prefer-dark-theme 
> together with HdyStyleManager is unsupported. Please use 
> HdyStyleManager:color-scheme instead.
> [+0.66s] DEBUG: app-window.vala:2002: Loading state from 
> /home/robb/.config/simple-scan/state
> [+0.66s] DEBUG: app-window.vala:1981: Restoring window to 1002x1235 pixels
> [+0.72s] DEBUG: scanner.vala:1619: sane_init () -> SANE_STATUS_GOOD
> [+0.72s] DEBUG: scanner.vala:1625: SANE version 1.2.1
> [+0.72s] DEBUG: scanner.vala:1686: Requesting redetection of scan devices
> [+0.72s] DEBUG: scanner.vala:863: Processing request
> [+0.86s] DEBUG: app-window.vala:2078: Saving state to 
> /home/robb/.config/simple-scan/state
> [+2.67s] DEBUG: scanner.vala:348: sane_get_devices () -> SANE_STATUS_GOOD
> [+2.67s] DEBUG: platform does not do hotplug, using polling
> ...

I have the saned daemon running, it seems to run OK. No matter what I
tried I have been unable to trick it into logging any debug output e.g.
even with "-d 32" I just see this logged:
> mjoelnir:log 4.12 17:10:14 # grep sane *   
> messages:Dec  4 10:02:07 mjoelnir pkg_add: Added 
> sane-backends-1.2.1p0->1.2.1p0
> messages:Dec  4 16:58:31 mjoelnir pkg_add: Added xsane-0.999p7

(The second message is me adding xsane, but it also fails to find the
scanner.)

The README "sane-backends" ends with this cryptic (to me) advice, but
I don't know what a "scanner device node" is for a thing with an IP
address:
> ...
> NETWORK
> ===
> By default, the saned(8) daemon runs as _saned, so you need to allow the
> _saned user access to the scanner device node.

What am I missing? Any tips for me?

(Oh, I also tried "pfctl -d" to disable the local firewall, didn't seem
to make any difference.)

Cheers,
Robb.

mjoelnir:/etc 4.12 17:14:41 # uname -a
OpenBSD mjoelnir.fritz.box 7.4 GENERIC.MP#1471 amd64

mjoelnir:/etc 4.12 17:14:46 # pkg_info | egrep '(scan|sane)'
arp-scan-1.10.0p1   ARP scanning and fingerprinting tool
nmap-7.91p5 scan ports and fingerprint stack of network hosts
py3-ruamel.yaml.clib-0.2.8 C based reader/scanner and emitter for ruamel.yaml
sane-backends-1.2.1p0 API for accessing scanners, backends
simple-scan-44.0p0  simple scanning utility
unpaper-7.0.0   post-processing tool for scanned paper sheets
xsane-0.999p7   scanner frontend for SANE

mjoelnir:/etc 4.12 17:15:55 # ps aux | grep sane
root 55249  0.0  0.0   880  1236 ??  S   4:36PM0:00.07 
/usr/local/libexec/saned -a -d 32
root  5814  0.0  0.0  3956  2016 p1  R+/25:15PM0:00.00 grep sane 
(zsh)
robb 24135  0.0  0.0  1628  2656 p3  I+p11:52AM0:00.01 less 
sane-backends

daily insecurity output (emails) end with: mtree special: exit code 2

[Why 42? The lists account.]

Hi All,

FYI, I noticed this in the last couple of daily insecurity output emails:

> From: "Charlie Root @ mjoelnir_aa1667" 
> Date: Fri,  7 Jul 2023 01:32:09 +0200 (CEST)
> 
> Running security(8):
> 
> Checking special files and directories.
> Output format is:
> filename:
> criteria (shouldbe, reallyis)
> etc/pf.conf:
> permissions (0600, 0640)
> mtree special: exit code 2

This seems to be since I updated to a snapshot:
mjoelnir:~ 7.07 14:15:44 % uname -a
OpenBSD mjoelnir.fritz.box 7.3 GENERIC.MP#1268 amd64

Re: Question regarding pf rules: block in on em0: ...

[Why 42? The lists account.]

I have no idea how I could make my question any clearer:
> My question is not about how to disable pf, but rather why the packets
> are see as "in" when coming from my own address, and, why they are
> blocked i.e. ...

On Thu, Jul 06, 2023 at 11:09:27AM -0600, Zack Newman wrote:
> For added clarity, this tcpdump you show is with pf disabled and all
> its rules flushed. The tcpdump you showed in the initial e-mail
> clearly was with active pf rules.
Dude, it is _literally_ the same trace output.

If you feel the need to try to help people, maybe calm down a bit and
actually read the question.

I'm out.

Robb.

Re: Question regarding pf rules: block in on em0: ...

[Why 42? The lists account.]

On Tue, Jul 04, 2023 at 10:42:39AM -0600, Zack Newman wrote:
> ...
> I am guessing you didn't flush the rules after disabling pf since
> clearly pf rules are still being used. Run pfctl -F all after disabling
> pf. Run pfctl -s all to verify there are no active rules.

Hi,

I see that I was not clear enough.

My question is not about how to disable pf, but rather why the packets
are see as "in" when coming from my own address, and, why they are
blocked i.e.

I noticed these block messages being logged when I click "discover/refresh" in 
simple-scan:

Jul 04 11:23:44.601042 rule 2/(match) block in on em0: 192.168.178.11.8612 > 
192.168.178.255.8612: udp 16
Jul 04 11:23:44.601051 rule 2/(match) block in on em0: 192.168.178.11.8612 > 
192.168.178.255.8610: udp 16
Jul 04 11:23:44.615516 rule 2/(match) block in on em0: 192.168.178.11.8612 > 
192.168.178.255.8612: udp 16
Jul 04 11:23:44.615523 rule 2/(match) block in on em0: 192.168.178.11.8612 > 
192.168.178.255.8610: udp 16
Jul 04 11:23:45.147239 rule 2/(match) block in on em0: 192.168.178.11.9609 > 
255.255.255.255.3289: udp 15 [ttl 1]
Jul 04 11:23:46.155868 rule 2/(match) block in on em0: 192.168.178.11.39413 > 
255.255.255.255.1124: udp 37 [ttl 1]

192.168.178.11 is my OpenBSD desktop (where of is running).

I don't understand what I'm seeing here ...

 1. Why am I seeing traffic coming _in_ from my own address? Is that not
slightly weird? Is it because it is _to_ the .255 broadcast address?

 2. And why is it being blocked? Do I have explicitly allow broadcast
traffic e.g. with rules to handle broadcast addresses? I don't think
I ever considered doing that before ...

The more I use pf, the less I seem to understand?

Danke im Voraus!

Robb.

Question regarding pf rules: block in on em0: ...

[Why 42? The lists account.]

Hi All,

I just noticed that "simple-scan" no longer discovers my scanner.

While trying to debug the issue, it occurred to me that it could be a
network / pf problem. This doesn't seem to be the issue though, even
after I disable pf (pfctl -d), the scanner is still not seen.

However, running "tcpdump -n -e -ttt -i pflog0" I noticed these block
messages being logged when I click "discover/refresh" in simple-scan:
...
Jul 04 11:23:44.601042 rule 2/(match) block in on em0: 192.168.178.11.8612 > 
192.168.178.255.8612: udp 16
Jul 04 11:23:44.601051 rule 2/(match) block in on em0: 192.168.178.11.8612 > 
192.168.178.255.8610: udp 16
Jul 04 11:23:44.615516 rule 2/(match) block in on em0: 192.168.178.11.8612 > 
192.168.178.255.8612: udp 16
Jul 04 11:23:44.615523 rule 2/(match) block in on em0: 192.168.178.11.8612 > 
192.168.178.255.8610: udp 16
Jul 04 11:23:45.147239 rule 2/(match) block in on em0: 192.168.178.11.9609 > 
255.255.255.255.3289: udp 15 [ttl 1]
Jul 04 11:23:46.155868 rule 2/(match) block in on em0: 192.168.178.11.39413 > 
255.255.255.255.1124: udp 37 [ttl 1]
...

192.168.178.11 is my OpenBSD desktop.

I don't understand what I'm seeing here ...

why am I seeing traffic coming _in_ from my own address? Is that not
slightly weird? Is it because it is _to_ the .255 broadcast address?

And why is it being blocked? Do I have explicitly allow broadcast traffic
e.g. with rules to handle broadcast addresses? I don't think I ever
considered doing that before ...

Grateful for any advice!

Yours,
Puzzled in PF-Land


FYI:
This is with a 7.3 snapshot: 7.3 GENERIC.MP#1268 amd64

Output of ifconfig:
4.07 11:23:51 # ifconfig em0
em0: 
flags=a48843
 mtu 1492
lladdr 94:c6:91:aa:16:67
index 1 priority 0 llprio 3
groups: egress
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet6 fe80::96c6:91ff:feaa:1667%em0 prefixlen 64 scopeid 0x1
inet 192.168.178.11 netmask 0xff00 broadcast 192.168.178.255
inet6 2003:ee:1718:b100:39e3:3c67:bd3c:44f4 prefixlen 64 deprecated 
autoconf pltime 0 vltime 5213
inet6 2003:ee:1718:b100:3470:4349:f8d0:e1d2 prefixlen 64 deprecated 
autoconf temporary pltime 0 vltime 5213

Not sure what that "deprecated" means here.

Rule @2 is the "classic" block all rule ...

The contents of pf.conf:
#   $OpenBSD: pf.conf,v 1.55 2017/12/03 20:40:04 sthen Exp $
#
# See pf.conf(5) and /etc/examples/pf.conf

set skip on lo
set block-policy return
set debug warning

# By default, do not permit remote connections to X11
#block return in log on ! lo0 proto tcp to port 6000:6010
block log on ! lo0 all  # Begin by blocking everything

# Port build user does not need network
block return out log proto {tcp udp} user _pbuild

# Allow all outbound
pass out quick modulate state

# Local subnet ...
local_subnet_v4="{ 192.168.178.0/24 }"

local_subnet_v6="{ fe80::/10 }"
# TODO: Correct ???

# Local systems that I might trust ...
trusted_clients_v4="{ 192.168.178.10, 192.168.178.12, 192.168.178.13, 
192.168.178.14 }"

# Allow ssh in
pass in log inet proto tcp from $trusted_clients_v4 to (egress) port ssh 
modulate state

# Scanner discovery? Allow traffic from Canon pixma TR8550
#scanner_ports="{ 8610, 8612 }"
#passlog inet  proto udp from 192.168.178.85 port $scanner_ports
pass in log inet proto udp from 192.168.178.85 port 8610
pass in log inet proto udp from 192.168.178.85 port 8612
#
# Allow avahi? See: /usr/local/share/doc/pkg-readmes/avahi
pass in log inet  proto udp from any to 224.0.0.251 port mdns allow-opts
pass in log inet6 proto udp from any to ff02::fb port mdns allow-opts
# and for SSDP:
pass in log inet  proto udp from any to 239.255.255.250 port ssdp allow-opts
pass in log inet6 proto udp from any to { ff02::c, ff05::c, ff08::c } port ssdp 
allow-opts
#
# OK, then try allowing multicast in general ...
pass log inet  proto igmp from any allow-opts

# NFS: Allow access to local NFS server
nfs_ports="{ sunrpc, nfsd, 881 }"
#
# But is UDP really still necessary?
#pass in proto udp from $trusted_clients to (egress) port $nfs_ports keep state
#pass out proto udp from (egress) to $trusted_clients port $nfs_ports keep state
#
pass in proto tcp from $trusted_clients_v4 to (egress) port $nfs_ports modulate 
state
pass in proto tcp from (egress) to $trusted_clients_v4 port $nfs_ports modulate 
state

# ICMP: Limit ICMP to allowed types: echorep, unreach, squench, echoreq, timex:
icmp_types = "{ echoreq, echorep, unreach, squench, timex }"
# See also: "man 4 icmp"
pass in log inet proto icmp to (egress) icmp-type $icmp_types label "rule $nr: 
pass: $proto: $icmp_type"

# HTTP: Running http-file-server:
# PORT= bin/http-file-server -u ~/Public/
# 2020/07/13 16:11:35 serving local path "/space/home/robb/Public" on "/Public/"
# 2020/07/13 16:11:35 redirecting to "/Public/" from "/"
# 2020/07/13 16:11:35 http-file-server listening on ":"
fs_port="{  }"
pass in proto tcp from $trusted_clients_v4 to (egress) 

Re: error when pkg_add'ing

[lists]

> Having A LOTS of problems in pkg_check usually means something in your
> process is REALLY BAD.
> 
> As the guy who wrote (most of) pkg_add/pkg_check, I don't need pkg_check
> all that often.


Just wanted to say: thanks for writing pkg_add.

Don't know if it was by you, but also really appreciated also that semi-recent 
update to pkg_add which made package updates (pkg_add -u) significantly faster.

Re: After update, vim reports undefined symbols in libruby32.so

[Why 42? The lists account.]

On Tue, Jun 13, 2023 at 09:37:32AM +0200, Theo Buehler wrote:
> ...
> That's because libruby32 did not link explicitly against libc++abi, which
> is now needed on aarch64 and amd64 for the Rust-based YJIT compiler.
> 
> Fixed in this commit: 
> https://marc.info/?l=openbsd-ports-cvs&m=168663240314909&w=2
> 
> Once you get ruby-3.2.2p0 on your machine either by updating after it
> made it into snapshot packages or by building the latest lang/ruby/3.2
> yourself, this noise should go away.

That updated package has fixed it, thanks!

Cheers,
Robb.

After update, vim reports undefined symbols in libruby32.so

[Why 42? The lists account.]

Hi All,

FYI, After running "sysupgrade -s" + "pkg_add -u" earlier today, I now
see these messages when I exit vim:

mjoelnir:awk 11.06 18:42:45 % vi substrtest.awk
...
vim:/usr/local/lib/libruby32.so: undefined symbol '_Unwind_Backtrace'
vim:/usr/local/lib/libruby32.so: undefined symbol '_Unwind_GetIP'
vim:/usr/local/lib/libruby32.so: undefined symbol '_Unwind_GetCFA'
vim:/usr/local/lib/libruby32.so: undefined symbol 
'_Unwind_FindEnclosingFunction'
vim:/usr/local/lib/libruby32.so: undefined symbol '_Unwind_GetDataRelBase'
vim:/usr/local/lib/libruby32.so: undefined symbol '_Unwind_GetTextRelBase'
vim:/usr/local/lib/libruby32.so: undefined symbol 
'_Unwind_GetLanguageSpecificData'
vim:/usr/local/lib/libruby32.so: undefined symbol '_Unwind_GetIPInfo'
vim:/usr/local/lib/libruby32.so: undefined symbol '_Unwind_GetRegionStart'
vim:/usr/local/lib/libruby32.so: undefined symbol '_Unwind_SetGR'
vim:/usr/local/lib/libruby32.so: undefined symbol '_Unwind_SetIP'
vim:/usr/local/lib/libruby32.so: undefined symbol '_Unwind_DeleteException'
vim:/usr/local/lib/libruby32.so: undefined symbol '_Unwind_RaiseException'

% uname -a
OpenBSD mjoelnir.fritz.box 7.3 GENERIC.MP#1230 amd64

% pkg_info | grep vim
vim-9.0.1536p0-no_x11-perl-python3-ruby vi clone, many additional features
vim-spell-de-9.0German spell-check files for Vim

It looks as if I received new versions of both ruby and vim:
# grep ruby /var/log/messages
Jun 11 13:47:01 mjoelnir pkg_add: Added ruby-3.2.2
Jun 11 13:52:56 mjoelnir pkg_add: Added ruby-3.1.4->3.1.4
Jun 11 13:53:22 mjoelnir pkg_add: Added 
vim-9.0.1536-no_x11-perl-python3-ruby->9.0.1536p0-no_x11-perl-python3-ruby
Jun 11 14:06:06 mjoelnir pkg_delete: Removed ruby-3.1.4

7.2 panic and "reorder_kernel: failed" ...

[Why 42? The lists account.]

Hi All,

Our 7.2 system just paniced again in pmap_page_remove / uvm_fault:
> ddb{1}> show panic
> *cpu1: uvm_fault(0xfd818b0ca560, 0x7f817ca74cb0, 0, 2) -> e
> ddb{1}> trace
> pmap_page_remove(fd8109c56480) at pmap_page_remove+0x21d
> uvm_anfree_list(fd804a0e7e40,800022eab518) at uvm_anfree_list+0x56
> amap_wipeout(fd80553d12e0) at amap_wipeout+0x113
> uvm_unmap_detach(800022eab5d8,0) at uvm_unmap_detach+0x6d
> sys_munmap(800022720010,800022eab640,800022eab6a0) at 
> sys_munmap+0x113
> syscall(800022eab710) at syscall+0x35f
> Xsyscall() at Xsyscall+0x128
> end of kernel
> end trace frame: 0x7f7dcd10, count: -7

(See also bug report from 24.4, subject: "kernel panic in pmap_page_remove")

After running fsck manually to clean one of the filesystems I did an
additional reboot, just to be sure the system would/could come up
cleanly.

I noticed this message on the console, seemingly as the system was
shutting down:
> stopping package daemons: nginx slowcgi postfix cyrus_imapd(killed) amavisd 
> clamd sshguardreorder_kernel: failed -- see 
> /usr/share/relink/kernel/GENERIC.MP/relink.log

That relink.log file looks like this:
> root:[~]# ls -ltr /usr/share/relink/kernel/GENERIC.MP/relink.log
> -rw-r--r--  1 root  wheel  142 Apr 30 14:29 
> /usr/share/relink/kernel/GENERIC.MP/relink.log

> root:[~]# cat /usr/share/relink/kernel/GENERIC.MP/relink.log
> (SHA256) /bsd: OK
> LD="ld" sh makegap.sh 0x gapdummy.o
> ld -T ld.script -X --warn-common -nopie -o newbsd ${SYSTEM_HEAD} vers.o 
> ${OBJS}
> root:[~]# 

What might that mean? Is it significant?

This is a virtualised OpenBSD instance running on QEMU / Debian Linux.

I've included some additional info, regarding the panic, output from ddb,
below ... if that is of interest.

Cheers,
Robb.


ddb{0}> show uvm
Current UVM status:
  pagesize=4096 (0x1000), pagemask=0xfff, pageshift=121519007 VM pages: 615597 
active, 54738 inactive, 1 wired, 299836 free (77933 zero)
  min  10% (25) anon, 10% (25) vnode, 5% (12) vtext
  freemin=50633, free-target=67510, inactive-target=0, wired-max=506335
  faults=147405838, traps=149196391, intrs=4821202, ctxswitch=33921314 
fpuswitch=0
  softint=46722165, syscalls=281857273, kmapent=11
  fault counts:
noram=0, noanon=0, noamap=0, pgwait=0, pgrele=0
ok relocks(total)=238350(239289), anget(retries)=19653204(0), 
amapcopy=11109730
neighbor anon/obj pg=5361492/21511643, gets(lock/unlock)=9626010/239342
cases: anon=17935690, anoncow=1717514, obj=5849938, prcopy=3775080, 
przero=118127605
  daemon and swap counts:
woke=0, revs=0, scans=0, obscans=0, anscans=0
busy=0, freed=0, reactivate=0, deactivate=0
pageouts=0, pending=0, nswget=0
nswapdev=1
swpages=526128, swpginuse=0, swpgonly=0 paging=0
  kernel pointers:
objs(kern)=0x822e7588


ddb{0}> ps
   PID TID   PPIDUID  S   FLAGS  WAIT  COMMAND
 85463  376479  19056543  30x8a  kqreadlmtpd
 40689  333687  63656507  30x92  kqreadlmtp
 20679  171977  63656507  3   0x192  kqreadcleanup
 62580  393095  63656507  30x92  kqreadsmtpd
 94055  484524  63656507  3   0x192  kqreadtrivial-rewrite
 63319  120941  63656507  3   0x192  kqreadanvil
 18813  417198  63656507  30x92  kqreadsmtpd
 25010  114571  19056543  30x82  lockf imapd
 53158  375953  19056543  30x8a  kqreadimapd
 68381  324871  63656507  30x92  kqreadtlsproxy
 63605   58831  19056543  30x8a  kqreadimapd
 52360  292291  19056543  30x8a  kqreadimapd
 99886  433302  63656507  30x92  lockf dnsblog
 768012093  19056543  7 0x2lmtpd
 25035  175379  17871530  30x90  kqreadperl
  6203  299107  17871530  30x90  lockf perl
 71793 709  19056543  30x8a  kqreadimapd
 79965  216521  19056543  30x8a  kqreadimapd
 62342  450749  19056543  30x8a  kqreadimapd
 13176  514534  63656507  30x92  kqreaddnsblog
 27955  360632  63656507  30x92  lockf dnsblog
 69483  431512  63656507  30x92  kqreadpostscreen
 10002   58404  19056543  30x8a  kqreadimapd
 46558  211092  19056543  30x8a  kqreadimapd
 46541   45982  19056543  30x8a  kqreadimapd
 14453  401009  19056543  30x8a  kqreadimapd
 36547   92359  63656507  3   0x192  kqreadpickup
 68439  377693  17871530  30x90  lockf perl
 20312  193348  17871530  30x90  lockf perl
 29531  309738  17871530  30x90  lockf perl
 47097  134056  19056543  30x8a  kqreadimapd
 57064  215926  19056543  3  

Re: Creating a "multicast bridge"?

[Why 42? The lists account.]

On Thu, Apr 06, 2023 at 04:17:26PM +0200, Martin Schröder wrote:
> > I'd like to create a "bridge" between two IP networks which will pass
> > only multicast info. / traffic.
> 
> So it should only route FF00::/8?

I'm not exactly sure of the siginificance of that address range, but in
the current configuration/version the networks are both IPv4 with a /24
netmask. There's no intent to use IPv6 at the moment.

Actually, by way of clarification, in this system the two networks to be
bridged/connected are essentially the same:

Both networks are based on the same model of switch
Both have idential set of devices
Both use the same IP addresses

The goal is to create a single "multicast domain" between the networks
i.e. to allow multicast communication betweeen applications running in
each of the networks ...

Does that make sense?

As I mentioned, grateful for any advice!

Cheers,
Robb.

Creating a "multicast bridge"?

[Why 42? The lists account.]

Hi All,

I'd like to create a "bridge" between two IP networks which will pass
only multicast info. / traffic.

Is that something that I could do using OpenBSD and pf? I don't see
anything specific to multicasting in the pf.conf man page but I suppose
it should be possible to define a set of rules based on the standard
multicast address ranges that would pass (or forward?) traffic between
two interfaces X and Y.

In this case the traffic should be passed "bidirectionally", if that's
actually a word :-)

Or, I see that "bridge(4)" might also be a potential solution for this,
although I've never used that before. Would that be a better basis?

Are there examples of how to define pf rules for a bridge configuration?

It's not entirely clear to me, but from what I've read it may be
necessary to pass additional management / meta traffic, in addition to
the actual multicast data, i.e. so that the switches on either side can
track the multicast groups being created and their members?

The source of the multicast data will be Windows 10 based applications.

Since I'll be creating the system specifically for this purpose, I can
use any version of OpenBSD for this.

When I get it running, I'd like to track the behaviour of the traffic.
Are there any tools that would be recommended for this? I thought of
using wireshark, or more likely tshark, perhaps with its "-z" statistics
option.

Grateful for any advice - thanks in advance!

Cheers,
Robb.

Re: Q: Error: mount_mfs: mmap: Cannot allocate memory

[Why 42? The lists account.]

On Mon, Feb 13, 2023 at 01:50:13PM -, Stuart Henderson wrote:
> ...
> It maybe worth checking whether mfs is actually helping -
> it's easy to assume that because it's in RAM it must be fast,
> but I've had machines where mfs was slower than SSD
> (https://marc.info/?l=openbsd-misc&m=164942119618029&w=2),
> also it's taking memory that could otherwise be used by
> buffer cache.

Hi All,

Since you mentioned it, I thought I would retry your dd test ...

# mount | grep /tmp
mfs:15266 on /tmp type mfs (asynchronous, local, nodev, nosuid, size=16777216 
512-blocks)

% cd !$ ; for i in `jot 5`; do dd if=/dev/zero of=mfs bs=1m count=990 2>&1 | 
grep bytes; done
cd /tmp/dd_test ; for i in `jot 5`; do dd if=/dev/zero of=mfs bs=1m count=990 
2>&1 | grep bytes; done
1038090240 bytes transferred in 1.376 secs (754215208 bytes/sec)
1038090240 bytes transferred in 1.189 secs (872536649 bytes/sec)
1038090240 bytes transferred in 1.227 secs (845718432 bytes/sec)
1038090240 bytes transferred in 1.186 secs (874866632 bytes/sec)
1038090240 bytes transferred in 1.254 secs (827186370 bytes/sec)

# mount | grep /fast
/dev/sd1l on /fast type ffs (local, nodev, nosuid, softdep)
# dmesg | grep sd1
sd1 at scsibus2 targ 1 lun 0: 
...

% cd /fast/dd_test ; for i in `jot 5`; do dd if=/dev/zero of=fast bs=1m 
count=990 2>&1 | grep bytes; done 
1038090240 bytes transferred in 0.871 secs (1191076597 bytes/sec)
1038090240 bytes transferred in 0.635 secs (1633246669 bytes/sec)
1038090240 bytes transferred in 0.615 secs (1685529408 bytes/sec)
1038090240 bytes transferred in 0.605 secs (1714639562 bytes/sec)
1038090240 bytes transferred in 0.612 secs (1694489764 bytes/sec)


So it seems that the Samsung NVMe device is much faster ...

However, I also tried testing the same two filesystems using the
"Flexible IO Tester" or fio (it's available as a package). When I used it
to do random 4K reads and writes, I appear to have the opposite result:

fio --name=rand_mmap_r+w --directory=/tmp/fio_test --rw=randrw --blocksize=4k 
--size=6g --io_size=60g --runtime=600 --ioengine=psync --fsync=1 --thread 
--numjobs=1 --group_reporting
...
Run status group 0 (all jobs):
   READ: bw=130MiB/s (136MB/s), 130MiB/s-130MiB/s (136MB/s-136MB/s), io=30.0GiB 
(32.2GB), run=236394-236394msec
  WRITE: bw=130MiB/s (136MB/s), 130MiB/s-130MiB/s (136MB/s-136MB/s), io=30.0GiB 
(32.2GB), run=236394-236394msec

% fio --name=rand_mmap_r+w --directory=/fast/fio_test --rw=randrw 
--blocksize=4k --size=6g --io_size=60g --runtime=600 --ioengine=psync --fsync=1 
--thread --numjobs=1 --group_reporting
...
Run status group 0 (all jobs):
   READ: bw=34.8MiB/s (36.5MB/s), 34.8MiB/s-34.8MiB/s (36.5MB/s-36.5MB/s), 
io=20.4GiB (21.9GB), run=60-60msec
  WRITE: bw=34.8MiB/s (36.4MB/s), 34.8MiB/s-34.8MiB/s (36.4MB/s-36.4MB/s), 
io=20.4GiB (21.9GB), run=60-60msec

I wonder why that would be?

Disclaimer: I know almost nothing about fio, I've never used it before.
In particular, it isn't clear to me what the correct/best choice is for
the "ioengine" option. (I played around with a few different settings,
that's why you can see that "mmap" in the (test)name argument.)

This is on a 8th generation i5 Intel NUC running a recent snapshot: 7.2
GENERIC.MP#1049

The CPU has 4 cores, hyperthreading is off. The underlying device for
"/fast" is a Samsung M.2 NVMe "stick":
nvme0: Samsung SSD 970 EVO Plus 500GB, firmware 1B2QEXM7 ...

The full output from fio is included below for anyone who might be
interested ...

Cheers,
Robb.


fio --name=rand_mmap_r+w --directory=/tmp/fio_test --rw=randrw --blocksize=4k 
--size=6g --io_size=60g --runtime=600 --ioengine=psync --fsync=1 --thread 
--numjobs=1 --group_reporting
rand_mmap_r+w: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 
4096B-4096B, ioengine=psync, iodepth=1
fio-3.33
Starting 1 thread
rand_mmap_r+w: Laying out IO file (1 file / 6144MiB)
Jobs: 1 (f=1): [m(1)][100.0%][r=134MiB/s,w=134MiB/s][r=34.3k,w=34.2k IOPS][eta 
00m:00s]
rand_mmap_r+w: (groupid=0, jobs=1): err= 0: pid=669956672: Wed Feb 15 13:52:03 
2023
  read: IOPS=33.3k, BW=130MiB/s (136MB/s)(30.0GiB/236394msec)
clat (nsec): min=1523, max=1504.6k, avg=5387.11, stdev=1201.82
 lat (nsec): min=1580, max=1504.7k, avg=5450.15, stdev=1203.46
clat percentiles (nsec):
 |  1.00th=[ 3632],  5.00th=[ 4576], 10.00th=[ 4832], 20.00th=[ 5024],
 | 30.00th=[ 5152], 40.00th=[ 5280], 50.00th=[ 5344], 60.00th=[ 5472],
 | 70.00th=[ 5600], 80.00th=[ 5792], 90.00th=[ 5984], 95.00th=[ 6176],
 | 99.00th=[ 6496], 99.50th=[ 6688], 99.90th=[13376], 99.95th=[18048],
 | 99.99th=[26240]
   bw (  KiB/s): min=126573, max=144312, per=100.00%, avg=133298.71, 
stdev=2476.36, samples=472
   iops: min=31643, max=36078, avg=33324.48, stdev=619.06, samples=472
  write: IOPS=33.2k, BW=130MiB/s (136MB/s)(30.0GiB/236394msec); 0 zone resets
clat (usec): min=3, max=1549, avg=13.84, stdev= 2.06
 lat (usec): min=3, max=1549, avg=13.92, stdev= 2.07
clat

Re: Q: Error: mount_mfs: mmap: Cannot allocate memory

[Why 42? The lists account.]

On Sun, Feb 05, 2023 at 02:50:44PM -0300, Crystal Kolipe wrote:
> On Sun, Feb 05, 2023 at 06:05:22PM +0100, Why 42? The lists account. wrote:
> ...
> > The fstab file contains this mount entry for tmp:
> > swap /tmp mfs rw,nodev,nosuid,-s=16777216 0 0
> 
> This is 8 Gb, which exceeds the default value for datasize for the daemon
> class in /etc/login.conf.
> 
> Have you changed /etc/login.conf from the default?
> 
> > Did MFS filesystems go away, or have I screwed something up?
> 
> You've screwed something up :).

You're exactly right. With this entry in fstab:
> swap /tmp mfs rw,nodev,nosuid,-s=4194304 0 0 

I now have this /tmp space:
> mjoelnir:~ 12.02 13:15:07 % df -h
> Filesystem SizeUsed   Avail Capacity  Mounted on
> /dev/sd1a 1005M537M418M57%/
> mfs:67535  1.9G   29.0K1.8G 1%/tmp
> ...

That's right after a reboot. I'll start Chrome now and it can really chow
down on some /tmp space :-)

Thanks!

Cheers,
Robb.

XFCE screensaver strangeness ...

[Why 42? The lists account.]

Hi All,

Recently I have noticed some XFCE screensaving weirdness e.g.

The XFCE desktop seems to ignore my preference for xscreensaver, but
rather always starts the xfce4-screensaver instead.

Currently I think I have disabled both in my settings and yet the xfce
saver is still getting started e.g.

mjoelnir:pkg-readmes 5.02 18:11:40 % find ~/.config/xfce4 -type f -exec grep -H 
saver {} \;
...
/home/robb/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-session.xml:

/home/robb/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-screensaver.xml:
/home/robb/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-screensaver.xml:  

/home/robb/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-screensaver.xml:  
  
/home/robb/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-screensaver.xml:

...

mjoelnir:pkg-readmes 5.02 18:17:31 % xfce4-screensaver-command -q
The screensaver is inactive
The screensaver is not inhibited

mjoelnir:pkg-readmes 5.02 18:20:44 % pstree -ws saver
-+= 1 root /sbin/init
 \--- 87710 robb /usr/local/bin/xfce4-screensaver

Has anyone else noticed anything like this?

I can kill it and start the desired xscreensaver, but that seems to have
some problems of its own e.g.

I see some strange screen colourmap lookup issues when display
images. The last time I saw something similar was on Sun hardware
that could only display, for example, 256 colours at one time ...

Sometimes the login dialog box seems not to be displayed. I think it
is still "there", a few times I have been able to login "blind", by
simply typing my password ...

This is all running a recent snapshot on a Intel NUC 8i5 system e.g. in
dmesg I see:
inteldrm0 at pci0 dev 2 function 0 "Intel Iris Plus 655" rev 0x01
drm0 at inteldrm0
inteldrm0: msi, COFFEELAKE, gen 9

Are questions regarding XFCE better suited to the misc list, or ports?

Cheers,
Robb.

Q: Error: mount_mfs: mmap: Cannot allocate memory

[Why 42? The lists account.]

Hi All,

After an update to a recent snapshot on my desktop system, I noticed
these mount_mfs messages at boot time:

/dev/sd0h (7a1775fef773535e.h): file system is clean; not checking /dev/sd1j
(281ef747da03afe7.j): file system is clean; not checking
/dev/sd1k (281ef747da03afe7.k): file system is clean; not checking
/dev/sd1l (281ef747da03afe7.l): file system is clean; not checking
/dev/sd2c (67c92dad63883338.c): file system is clean; not checking
mount_mfs: mmap: Cannot allocate memory
kbd: keyboard mapping set to de.nodead
keyboard.encoding -> de.nodead
pf enabled
kern.maxproc: 1310 -> 4000
kern.maxthread: 2620 -> 8000
kern.maxfiles: 7030 -> 16000
ddb.panic: 1 -> 0
kern.allowdt: 0 -> 1
starting network
reordering: ld.so libc libcrypto sshd.
starting early daemons: syslogd pflogd ntpd.
starting RPC daemons: portmap mountd nfsd lockd statd.
mount_mfs: mmap: Cannot allocate memory
savecore: no core dump
checking quotas: done.
clearing /tmp
kern.securelevel: 0 -> 1
creating runtime link editor directory cache.
preserving editor files.
running rc.sysmerge
starting network daemons: sshd sndiod.
running rc.firsttime
fw_update: added none; updated none; kept intel,inteldrm,vmm
starting package daemons: messagebus postfix smartd pcscd avahi_daemon.
starting local daemons: sensorsd cron xenodm.

The fstab file contains this mount entry for tmp:
swap /tmp mfs rw,nodev,nosuid,-s=16777216 0 0

I don't know when this first occurred. I first noticed it when I was
investigating why chrome had started to log "filesystem full" messages:
e.g. "/: write failed, file system is full.".

Since the mfs mount of /tmp failed, it's now using the root fs as /tmp
space, which doesn't have much free space.

I'm currently running: OpenBSD mjoelnir.fritz.box 7.2 GENERIC.MP#1012 amd64

Did MFS filesystems go away, or have I screwed something up?

Cheers,
Robb.

Re: sysupgrade fails with "FAILED" when "verifying sets"?

[Why 42? The lists account.]

On Tue, Dec 13, 2022 at 11:12:18AM -, Stuart Henderson wrote:
> On 2022-12-12, Why 42? The lists account.  wrote:
> > Today sysupgrade failed for me, but I'm not sure why? Here's the output:
> 
> As the various mirrors get updated, this should be coming back to normal now.

Just FYI, It's working for me now. I'll see you after the reboot ...

Thanks!

Cheers,
Robb.

Re: sysupgrade fails with "FAILED" when "verifying sets"?

[Why 42? The lists account.]

On Mon, Dec 12, 2022 at 11:11:24PM -0500, Nick Holland wrote:
> On 12/12/22 07:22, Why 42? The lists account. wrote:
> > 
> > Hi All,
> > 
> > Today sysupgrade failed for me, but I'm not sure why? Here's the output:
>  [ ... ]
> 
> There is a problem with the distribution network currently.  Hopefully
> will be resolved soon.
> 
> Doing a quick check, looks like only amd64 is broke..but of course,
> that's what you probably want. (good time to upgrade your other platforms!)

Right you are, that's the one :-/ I used to be a SPARC kinda guy, but
those are all gone now.

I do have a Novena (Bunny + Xobs) ARMv7 Laptop, but I suspect installing
there would make my AMD64 issue look like a walk in the park :-)

Anyway, the sysupgrade download + verify works now. Just have to reboot
...

If I had the slightest of quibbles it would be to wonder why sysupgrade
shows "SHA256.sig" (2144 bytes) being downloaded, but it only saves
"SHA256" (1992 bytes). Just seems a bit odd is all.

Thanks!

Cheers,
Robb.

Re: sysupgrade fails with "FAILED" when "verifying sets"?

[Why 42? The lists account.]

On Mon, Dec 12, 2022 at 07:39:49AM -0600, Amit Kulkarni wrote:
> retry, and all should be ok.

What's the basis of your statement, did something change?

It still fails for me (now @16:15 CET).

I also tried a different mirror, same failure (below).

@Stuart: Although sysupgrade output says that it fetched and used
SHA256.sig, it appears only to save a file SHA256. That's why I tried
using SHA256 on the signify command line :)

Yours,
Robb.

> mjoelnir:_sysupgrade 12.12 16:13:38 # sysupgrade -s -n
> Fetching from https://ftp.halifax.rwth-aachen.de/pub/OpenBSD/snapshots/amd64/
> SHA256.sig   100% 
> |*|
>   2144   00:00
> Signature Verified
> INSTALL.amd64 100% 
> ||
>  43554   00:00
> base72.tgz   100% 
> |*|
>332 MB00:40
> bsd  100% 
> |*|
>  22470 KB00:04
> bsd.mp   100% 
> |*|
>  22578 KB00:02
> bsd.rd   100% 
> |*|
>   4546 KB00:01
> comp72.tgz   100% 
> |*|
>  75019 KB00:13
> game72.tgz   100% 
> |*|
>   2745 KB00:00
> man72.tgz100% 
> |*|
>   7610 KB00:01
> xbase72.tgz  100% 
> |*|
>  52860 KB00:06
> xfont72.tgz  100% 
> |*|
>  22967 KB00:03
> xserv72.tgz  100% 
> |*|
>  14815 KB00:03
> xshare72.tgz 100% 
> |*|
>   4573 KB00:01
> Verifying sets.
> (SHA256) base72.tgz: FAILED
> (SHA256) bsd: FAILED
> (SHA256) bsd.mp: FAILED
> (SHA256) bsd.rd: FAILED
> (SHA256) comp72.tgz: FAILED
> (SHA256) game72.tgz: FAILED
> (SHA256) man72.tgz: FAILED
> (SHA256) xbase72.tgz: FAILED
> (SHA256) xfont72.tgz: FAILED
> (SHA256) xserv72.tgz: FAILED
> (SHA256) xshare72.tgz: FAILED
> mjoelnir:_sysupgrade 12.12 16:15:17 [$?==1]# ls -l SHA256*
> -rw-r--r--  1 root  wheel  1992 Dec 12 16:13 SHA256

sysupgrade fails with "FAILED" when "verifying sets"?

[Why 42? The lists account.]

Hi All,

Today sysupgrade failed for me, but I'm not sure why? Here's the output:
> # sysupgrade -s -n 
> Fetching from http://ftp.fau.de/pub/OpenBSD/snapshots/amd64/
> SHA256.sig   100% 
> |***|
>   2144   00:00
> Signature Verified
> Verifying old sets.
> base72.tgz   100% 
> |***|
>332 MB00:28
> bsd  100% 
> |***|
>  22470 KB00:02
> bsd.mp   100% 
> |***|
>  22578 KB00:02
> bsd.rd   100% 
> |***|
>   4546 KB00:01
> comp72.tgz   100% 
> |***|
>  75019 KB00:07
> game72.tgz   100% 
> |***|
>   2745 KB00:00
> man72.tgz100% 
> |***|
>   7610 KB00:01
> xbase72.tgz  100% 
> |***|
>  52860 KB00:05
> xfont72.tgz  100% 
> |***|
>  22967 KB00:02
> xserv72.tgz  100% 
> |***|
>  14815 KB00:02
> xshare72.tgz 100% 
> |***|
>   4573 KB00:01
> Verifying sets.
> (SHA256) base72.tgz: FAILED
> (SHA256) bsd: FAILED
> (SHA256) bsd.mp: FAILED
> (SHA256) bsd.rd: FAILED
> (SHA256) comp72.tgz: FAILED
> (SHA256) game72.tgz: FAILED
> (SHA256) man72.tgz: FAILED
> (SHA256) xbase72.tgz: FAILED
> (SHA256) xfont72.tgz: FAILED
> (SHA256) xserv72.tgz: FAILED
> (SHA256) xshare72.tgz: FAILED

I see that the sha256 digests/checksums in "SHA256" differ from those of
the downloaded files:
> mjoelnir:_sysupgrade 12.12 13:02:53 [$?==1]# grep bsd.rd SHA256   
> 
> SHA256 (bsd.rd) = 
> 9065a190be5eaf047c1c0ece2517712e21964c17f39bebe3420aba2372c054ad
> mjoelnir:_sysupgrade 12.12 13:03:15 # sha256 bsd.rd   
>  
> SHA256 (bsd.rd) = 
> 84ce928ccf6d71ebe5e7673aa198e424a9fdaf409d64723ba6dc8cd9333d9388

I don't know if that's the problem though ...

I have never really used signify before, but this command from the man
page also generates an error:
> mjoelnir:_sysupgrade 12.12 13:03:30 # signify -C -p 
> /etc/signify/openbsd-73-base.pub -x SHA256
> signify: invalid comment in SHA256; must start with 'untrusted comment: '

That file starts like this:
> mjoelnir:_sysupgrade 12.12 13:05:09 # head SHA256
> SHA256 (BOOTIA32.EFI) = 
> e05572dc89a5c2c1ac53962cbf6fecda01dad0d4330d95a27e2d645a63b92d6e
> SHA256 (BOOTX64.EFI) = 
> c9cf5ec60caba47c4b4ad0dc37dc88409ff9b5adb38814de1e35496759c2eed8
> SHA256 (BUILDINFO) = 
> 4d0249887ed7db9e9f336556c33a7e66024e08aeb5643f517b98c0815917529b
> ...

Any suggestions?

Cheers,
Robb.

sysupgrade fails after reboot with: The directory '/home/_sysupgrade/' does not exist.

[Why 42? The lists account.]

Hi All,

I seem to have a sysupgrade problem ...

sysupgrade fails after reboot with an error:
The directory '/home/_sysupgrade/' does not exist.

Sometime ago I had a similar issue due to my having "/home" as a
sub-directory of a filesystem "/space". My mistake apparently. Never the
less, I had a simple and effective workaround of modifying the path
defined in /auto_upgrade.conf before rebooting.

Weirdly, that workaround no longer seems to work.

To try and avoid any trace of the previous "/home" mount issue, here is
what happens when I use the sysupgrade -b flag to set a completely
different "base-directory", located in a different filesystem ...

Can anyone see where I am going wrong?

mjoelnir:/etc 8.11 15:55:08 # sysupgrade -n -b /fast   
Fetching from http://ftp.fau.de/pub/OpenBSD/snapshots/amd64/
SHA256.sig   100% 
|*|
  2144   00:00
Signature Verified
INSTALL.amd64 100% 
||
 43554   00:00
base72.tgz   100% 
|*|
   332 MB00:33
bsd  100% 
|*|
 22463 KB00:06
bsd.mp   100% 
|*|
 22578 KB00:05
bsd.rd   100% 
|*|
  4541 KB00:02
comp72.tgz   100% 
|*|
 74968 KB00:11
game72.tgz   100% 
|*|
  2745 KB00:01
man72.tgz100% 
|*|
  7612 KB00:03
xbase72.tgz  100% 
|*|
 52850 KB00:09
xfont72.tgz  100% 
|*|
 22967 KB00:06
xserv72.tgz  100% 
|*|
 14815 KB00:04
xshare72.tgz 100% 
|*|
  4573 KB00:02
Verifying sets.
Fetching updated firmware.
fw_update: added none; updated none; kept intel,inteldrm,vmm
Will upgrade on next reboot

### The new "base-directory" has been created:
mjoelnir:/etc 8.11 15:57:15 # ls -ld /fast/_sysupgrade  
drwxr-xr-x  2 root  wheel  512 Nov  8 15:57 /fast/_sysupgrade

### It contains the newly downloaded files:
mjoelnir:/etc 8.11 15:57:26 # ls -l /fast/_sysupgrade 
total 1141408
-rw-r--r--  1 root  wheel  43554 Nov  8 00:18 INSTALL.amd64
-rw-r--r--  1 root  wheel   1992 Nov  8 15:55 SHA256
-rw-r--r--  1 root  wheel  348171346 Nov  8 00:13 base72.tgz
-rw-r--r--  1 root  wheel   23002725 Nov  8 00:12 bsd
-rw-r--r--  1 root  wheel   23120636 Nov  8 00:12 bsd.mp
-rw-r--r--  1 root  wheel4650857 Nov  8 00:18 bsd.rd
-rw-r--r--  1 root  wheel   76767540 Nov  8 00:13 comp72.tgz
-rw-r--r--  1 root  wheel2811462 Nov  8 00:13 game72.tgz
-rw-r--r--  1 root  wheel7794925 Nov  8 00:13 man72.tgz
-rw-r--r--  1 root  wheel   54119339 Nov  8 00:34 xbase72.tgz
-rw-r--r--  1 root  wheel   23518994 Nov  8 00:34 xfont72.tgz
-rw-r--r--  1 root  wheel   15170647 Nov  8 00:34 xserv72.tgz
-rw-r--r--  1 root  wheel4683158 Nov  8 00:34 xshare72.tgz

### The root directory now also has some new files:
mjoelnir:/etc 8.11 15:57:32 # ls -ltr /
total 153738
-rw-r--r--   1 root  wheel   468 Jun  2  2019 .profile
-rw-r--r--   1 root  wheel   578 Jun  2  2019 .cshrc
drwxr-xr-x   2 root  wheel   512 Sep 29  2019 space
lrwxr-xr-x   1 root  wheel 9 Jun  3  2020 opt -> /fast/opt
-rw-r--r--   1 root  wheel 90496 Jan 28  2021 boot
lrwxrwx---   1 root  wheel11 Aug 19 07:54 sys -> usr/src/sys
drwxr-xr-x   2 root  wheel   512 Aug 19 07:54 altroot
drwxr-xr-x   2 root  wheel  1024 Aug 19 07:55 bin
drwxr-xr-x   2 root  wheel  1536 Aug 19 07:55 sbin
drwxr-xr-x  31 root  wheel   512 Aug 19 08:34 var
drwxr-xr-x  16 root  wheel   512 Aug 19 08:34 usr
-rwx--   1 root  wheel  22982134 Aug 19 14:46 bsd.sp
-rw---   1 root  wheel   4638162 Aug 19 14:46 bsd.rd
drwxr-xr-x   4 root  wheel   512 Nov  8 13:43 mnt
drwxr-xr-x  20 root  wheel   512 Nov  8 13:48 home
-rwx--   1 root  wheel  23088585 Nov  8 15:02 bsd.booted
drwxr-xr-x   6 root  wheel 19968 Nov  8 15:41 dev
-rwx--   1 root  wheel  23082305 Nov  8 15:41 bsd
drwxr-xr-x   6 root  wheel   512 Nov  8 15:55 fast
-rw-r--r--   1 root  wh

guide: scanning on openbsd with sane, as non-root user

[lists]

SCANNING ON OPENBSD WITH SANE, AS NON-ROOT USER

foreword: wanted to put this guide somewhere


install sane:

# pkg_add sane 


plug in the scanner, and immediately after, run this command:

# dmesg | tail -20
ugen0 at uhub0 port 3 ""

the output should appear as above


now take a note of the number after 'ugen' and the number after
'uhub'. in this example that number is 0 for both.

now to get a bit more info on the hardware, run:

# usbdevs
Controller /dev/usb0:
addr 01: 
addr 02: : 

the output should appear as above


so say we want to scan as the user 'theo', then theo needs access to
both /dev/usb0 as well as /dev/ugen0.00

so execute the following command

# chgrp theo /dev/ugen0.* /dev/usb0
# chmod g+rwx /dev/ugen0.* /dev/usb0


now run, as theo:

$ scanimage -L
device ':libusb:000:002' is a  scanner

the output should now show the scanner, as above


to scan:

$ scanimage -d ':libusb:000:002' -f jpeg --mode Color


to get scanner-specific options:

$ scanimage -h

unwind problems e.g. validation failure ... while building chain of trust

[Why 42? The lists account.]

Hi All,

I thought I would try running unwind on my desktop at home. Reading the
manual page, it doesn't seem to require any specific configuration, so I
started it via rcctl and everything seemed to work as expected e.g. it
found the address of my router/DHCP server, resolv.conf was updated and
DNS queries worked:
> mjoelnir:/etc 19.02 18:21:02 # rcctl start unwind
> unwind(ok)

> mjoelnir:/etc 19.02 18:21:18 # unwindctl status
> 1. recursorvalidating,   N/A   3. stub resolving,   N/A
> 2. autoconfvalidating,   N/A   4. oDoT-autoconf dead,   N/A
> 
>   histograms: lifetime[ms], decaying[ms]
>  <10   <20   <40   <60   <80  <100  <200  <400  <600  <800 <1000 >
>   rec  0 0 0 0 0 0 0 0 0 0 0 0
>0 0 0 0 0 0 0 0 0 0 0 0
>  auto  0 0 0 0 0 0 0 0 0 0 0 0
>0 0 0 0 0 0 0 0 0 0 0 0
>  stub  0 0 0 0 0 0 0 0 0 0 0 0
>0 0 0 0 0 0 0 0 0 0 0 0
> auto*  0 0 0 0 0 0 0 0 0 0 0 0
>0 0 0 0 0 0 0 0 0 0 0 0

> mjoelnir:/etc 19.02 18:21:29 # unwindctl status autoconf
> autoconfiguration forwarders:
>   DHCP[em0]: 192.168.178.254

After some DNS queries ...
> mjoelnir:/etc 19.02 18:33:02 # unwindctl status
> 1. autoconfvalidating,  50ms   3. stub resolving,   Inf
> 2. recursorvalidating, 150ms   4. oDoT-autoconf dead,   N/A
> 
>   histograms: lifetime[ms], decaying[ms]
>  <10   <20   <40   <60   <80  <100  <200  <400  <600  <800 <1000 >
>  auto  9132025 9 514 3 1 1 0 0
>4 91215 6 3 8 2 0 0 0 0
>   rec  2 1 4 0 0 316 4 5 0 1 1
>1 0 2 0 0 210 3 3 0 0 0
>  stub  8 0 0 0 0 0 0 0 0 0 0 1
>3 0 0 0 0 0 0 0 0 0 0 0
> auto*  0 0 0 0 0 0 0 0 0 0 0 0
>0 0 0 0 0 0 0 0 0 0 0 0

However, some time later (in this test a few minutes) resolving of local
hostnames stops working and unwind begins logging messages like these:
> Feb 19 18:36:12 mjoelnir unwind[72749]: validation failure 
> : no DNSSEC records from 192.168.178.254 for DS 
> fritz.box. while building chain of trust
> Feb 19 18:36:12 mjoelnir unwind[72749]: validation failure : 
> no DNSSEC records from 192.168.178.254 for DS mjoelnir. while building chain 
> of trust
> Feb 19 18:36:12 mjoelnir unwind[72749]: validation failure 
> : key for validation fritz.box. is marked as 
> invalid because of a previous validation failure : 
> no DNSSEC records from 192.168.178.254 for DS fritz.box. while building chain 
> of trust
> Feb 19 18:36:12 mjoelnir unwind[72749]: validation failure : 
> key for validation mjoelnir. is marked as invalid because of a previous 
> validation failure : no DNSSEC records from 192.168.178.254 
> for DS mjoelnir. while building chain of trust
> Feb 19 18:36:30 mjoelnir unwind[72749]: validation failure 
> : key for validation fritz.box. is marked as 
> invalid because of a previous validation failure : 
> no DNSSEC records from 192.168.178.254 for DS fritz.box. while building chain 
> of trust
> Feb 19 18:39:07 mjoelnir unwind[72749]: validation failure 
> : no DNSSEC records from 192.168.178.254 for DS 
> fritz.box. while building chain of trust
> Feb 19 18:39:59 mjoelnir unwind[72749]: validation failure : 
> no DNSSEC records from 192.168.178.254 for DS mjoelnir. while building chain 
> of trust
> Feb 19 18:40:38 mjoelnir unwind[72749]: validation failure : no 
> DNSSEC records from 192.168.178.254 for DS novena. while building chain of 
> trust

mjoelnir is the local system, where unwind is running, and novena is
another (linux) system on the local network. I don't know what zimagez
is.

Further validation failure messages have what appear to be incorrectly
concatenated names for the local system e.g.
> Feb 19 18:43:47 mjoelnir unwind[72749]: validation failure 
> : key for validation fritz.box. is marked 
> as invalid because of a previous validation failure  IN>: no DNSSEC records from 192.168.178.254 for DS fritz.box. while building 
> chain of trust
> Feb 19 18:43:47 mjoelnir unwind[72749]: validation failure 
> : key for validation fritz.box. is 
> marked as invalid because of a previous validation failure 
> : no DNSSEC records from 192.168.178.254 for DS 
> fritz.box. while building chain of trust

Wh

pkg_add python errors ...

[Why 42? The lists account.]

Well, errors related to the python package ...

After updating to the latest snapshot and rebooting I ran "pkg_add -vu"
to update all my packages, which I think is the right thing to do.

I noticed some strange errors related to python scroll past i.e.
> ...
> Update candidates: p7zip-16.02p6 -> p7zip-16.02p6
> Update candidates: partial-python-3.9.7p3 -> python-3.9.9
> Unexpected symlink: /usr/local/bin/2to3
> Unexpected symlink: /usr/local/bin/pydoc3
> Unexpected symlink: /usr/local/bin/python3
> Unexpected symlink: /usr/local/bin/python3-config
> Unexpected symlink: /usr/local/lib/pkgconfig/python3-embed.pc
> Unexpected symlink: /usr/local/lib/pkgconfig/python3.pc
> Unexpected symlink: /usr/local/man/man1/python3.1
> Bad rename /usr/local/bin/2to3 to /usr/local/bin/2to3.X77AFtJWEq: No such 
> file or directory
> Bad rename /usr/local/bin/pydoc3 to /usr/local/bin/pydoc3.FLyJqqVBCV: No such 
> file or directory
> Bad rename /usr/local/bin/python3 to /usr/local/bin/python3.mct9eU2JKh: No 
> such file or directory
> Bad rename /usr/local/bin/python3-config to 
> /usr/local/bin/python3-config.LVZ4scwF2N: No such file or directory
> Bad rename /usr/local/lib/pkgconfig/python3-embed.pc to 
> /usr/local/lib/pkgconfig/python3-embed.pc.W3q0EmYVnC: No such file or 
> directory
> Bad rename /usr/local/lib/pkgconfig/python3.pc to 
> /usr/local/lib/pkgconfig/python3.pc.0svv4fWReb: No such file or directory
> Bad rename /usr/local/man/man1/python3.1 to 
> /usr/local/man/man1/python3.1.iWHWD3b3mt: No such file or directory
> [python-3.9.9]partial-python-3.9.7p3->: ok
> Update candidates: pcsc-tools-1.4.27p0 -> pcsc-tools-1.4.27p0
> Update candidates: picocom-3.1 -> picocom-3.1
> ...

I'm not sure why the "bad rename" would occur, indeed the rename does
seem to have taken place:
> mjoelnir:log 29.11 # ls -l /usr/local/bin/2to3*
> -rwxr-xr-x  1 root  bin101 Nov 26 12:37 /usr/local/bin/2to3-3.8
> -rwxr-xr-x  1 root  bin101 Nov 25 20:41 /usr/local/bin/2to3-3.9
> -rw---  1 root  wheel0 Nov 29 15:04 /usr/local/bin/2to3.H0cMphlKfH
> -rw---  1 root  wheel0 Nov 29 15:34 /usr/local/bin/2to3.X77AFtJWEq

(I ran the pkg_add a second time to capture the above error messages, so
I imagine that is why there are now two temp filenames.)

The pkg_add operation ended with:
> ...
> Update candidates: zsh-syntax-highlighting-0.7.1 -> 
> zsh-syntax-highlighting-0.7.1
> --- -partial-python-3.9.7p3 ---
> Files kept as partial-python-3.9.7p3.1 package

I now seem to have four different versions of the python package
installed:
partial-python-3.9.7p3.1
python-2.7.18p5
python-3.8.12p4
python-3.9.9

I'm not sure why python-3.9.7p3.1 has been kept around, according to
pkg_info nothing requires it:
> mjoelnir:/etc 29.11 # pkg_info -R partial-python-3.9.7p3.1
> mjoelnir:/etc 29.11 #

Running sysclean doesn't report anything obviously python related.

Has something gone wrong here? Do I need to to do any manual cleanup?

Cheers,
Robb.

mjoelnir:/etc 29.11 # sysctl kern.version
kern.version=OpenBSD 7.0-current (GENERIC.MP) #131: Mon Nov 29 00:32:40 MST 2021
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Re: Thinkpad T400 temperature sensors

[Why 42? The lists account.]

On Fri, Nov 19, 2021 at 01:58:20PM +0100, Jan Stary wrote:
> This is current/amd64 on a Thinkpad T400
> (full dmesg and sysctl hw below).
> 
> It provides various sensors reporting temperatures,
> but I don't really know what temperatures these are.
> 
> $ sysctl hw | grep temp
> 
> hw.sensors.cpu0.temp0=39.00 degC
> hw.sensors.acpithinkpad0.temp0=48.00 degC
> hw.sensors.acpithinkpad0.temp1=41.00 degC
> hw.sensors.acpithinkpad0.temp2=34.00 degC
> hw.sensors.acpithinkpad0.temp4=25.00 degC
> hw.sensors.acpithinkpad0.temp6=25.00 degC
> hw.sensors.acpitz0.temp0=48.00 degC (zone temperature)
> hw.sensors.acpitz1.temp0=44.00 degC (zone temperature)
> hw.sensors.aps0.temp0=255.00 degC
> hw.sensors.aps0.temp1=255.00 degC
> ...

Hi Jan,

There is some (emperically derived) info. about the hardware here:
https://www.thinkwiki.org/wiki/Thermal_Sensors#ThinkPad_T400
And:
https://www.sthu.org/misc/t400.html

E.g.
Index in "thermal"   Location
1CPU neighbourhood (also via ACPI THM0)
2Ultrabay
3Express card
4ATI graphics module
5Main battery (always around 50°C)
6n/a (probably ultrabay battery)
7Main Battery (fits about the value reported by smapi)
8n/a (probably ultrabay battery)
9Hard disc
10   Intel graphics module
11   Heatsink?

Those numbers are the indicies into the Linux thinkpad_acpi kernel
module, made available via '/proc/acpi/ibm/thermal' 

Maybe that helps.

Cheers,
Robb.

Re: pf and tap interfaces

[tech-lists]

On Sun, Oct 31, 2021 at 10:13:06AM -0600, Theo de Raadt wrote:


you are asking a freebsd question on an openbsd mailing list.

come on



You may have missed my response to Sebastian:

In-Reply-To: 
On Sun, Oct 31, 2021 at 03:59:40PM +, tech-lists wrote:

[...]


All I'm really asking at this stage is "is this possible". I'm asking
that because I've looked in the pf section of the manual and have not
found an example (yet) close enough to my enquiry.

I think here it'd be better to ask firstly in an entirely OpenBSD 7.0
context. Like, OpenBSD has vmm now, its equivalent to bhyve. If you
wanted to allow port 22 to the host *only* but allow all traffic to the
guest, on another IP, can it be done in OpenBSD 7.0 pf on the host?


--
J.


signature.asc
Description: PGP signature

Re: pf and tap interfaces

[tech-lists]

On Sun, Oct 31, 2021 at 09:33:54AM -0600, Theo de Raadt wrote:

tech-lists  wrote:


I'm asking this here because I'm trying to do this with FreeBSD but
their pf has diverged a lot from OpenBSD's


that is incorrect history.

It is hard to see how 'absolutely minimal maintainance' can result in
divergence.


yep. I should have said 'OpenBSD's pf has significantly evolved since ...'


At some point, pf's state table data structures were rewritten completely.

You are better off adjusting your expectations.  You can be foiled by
differences at any point.


Yes. At this stage it's more of an "is it even possible y/n"
--
J.


signature.asc
Description: PGP signature

Re: pf and tap interfaces

[tech-lists]

Hi,

On Sun, Oct 31, 2021 at 04:23:58PM +0100, Sebastian Benoit wrote:


Maybe you could describe a bit more what you are trying to do.


I'm trying to protect, with pf, a freebsd host running bhyve guests. The
guests use tap interfaces. They are in the same network as the host (but
with different IPs) and the IPs are routable. 
They're all web servers, accessible from the internet.


So for example I'd like to block all on the host and just allow port 22. 
I don't want pf to process the tap interfaces at all, as all of the

guests run their own firewalls.

So far on freebsd with their pf, I've been unable to do this. 
I was wondering if the pf on openbsd can, as it has evolved
significantly from when it was incorporated into FreeBSD. 

A way around my problem may be to have openbsd as a guest in a 
bhyve instance, as pci passthru is now available in that circumstance.

But first I need to find whether it is possible to allow traffic on say
tap0 but block all traffic apart from ssh on igb0 (for example).

I understand that bridge and tap are "special" interfaces, in that they 
are not simply clones. And yet they are like clones, in that rules 
affecting the hardware interface also seem to affect the tap interface,

from what I've so far seen.

All I'm really asking at this stage is "is this possible". I'm asking
that because I've looked in the pf section of the manual and have not
found an example (yet) close enough to my enquiry. 

I think here it'd be better to ask firstly in an entirely OpenBSD 7.0 
context. Like, OpenBSD has vmm now, its equivalent to bhyve. If you

wanted to allow port 22 to the host *only* but allow all traffic to the
guest, on another IP, can it be done in OpenBSD 7.0 pf on the host?

--
J.


signature.asc
Description: PGP signature

pf and tap interfaces

[tech-lists]

Hello misc@

Generically, can OpenBSD [7.0] apply rules to *just* the ethernet
interface, ignoring the bridge and tap interfaces? Can it do this
natively or is a VLAN required as well? Or something else?

I'm asking this here because I'm trying to do this with FreeBSD 
but their pf has diverged a lot from OpenBSD's, and what I thought 
would work does not. skip on $tap_ifs has unexpected results in that

traffic still gets blocked on the guest.

If OpenBSD's pf does work for my use case, then a way to solving my
issue may be to have an OpenBSD guest in the FreeBSD host managing the
pf for the host as bhyve has pci passthru. The other way would be to put
a firewall box in front of the freebsd host.

thanks,
--
J.


signature.asc
Description: PGP signature

Re: sysctl hw.sensors.lm1 shows only one fan

[lists]

Mon, 27 Sep 2021 17:15:28 +0200 Jan Stary 
> On Sep 26 15:35:25, a23s4a2...@yandex.ru wrote:
> > This works for me, now I see all of my fans.
> > Some of them look funny, because they are really not connected and
> > show -2560RPM, Status Critical.  
> 
> That means the fan is rotating in the opposite direction
> (and sending highly critical statuses to twitter)
> 

Hello Jan Stary,

The sensors framework can benefit from some reviews and attention at any chance.

sensor_attach(9) — sensors framework
https://man.openbsd.org/sensor_attach.9

https://man.openbsd.org/?apropos=1&query=sensor
https://man.openbsd.org/?apropos=1&query=i2c

iic(4) - Inter IC (I2C) bus
https://man.openbsd.org/iic.4

acpi(4) — Advanced Configuration and Power Interface
https://man.openbsd.org/acpi.4

ipmi(4) — Intelligent Platform Management Interface driver
https://man.openbsd.org/ipmi.4

lm(4) — National Semiconductor LM78/79/81 temperature, voltage, and fan sensor
https://man.openbsd.org/lm.4

Casual example, this driver used to work fine.  A trivial change introduced bugs
"recently" broke several at once.  Later fixes do not work correctly ever since:

aibs(4) — ASUSTeK AI Booster ACPI ATK0110 temperature, voltage, and fan sensor
https://man.openbsd.org/aibs.4

Hello Maksim Rodin,

You have to be extra careful where the fan header is and the pin layout on these
headers can be "non-standard" on some server boards.  For example SuperMicro has
the serial ports wired across instead of along the pin rows unlike other boards.

Check your motherboard user manual (also in PDF on the vendor site) then you can
disable/ignore in the BIOS/IPMI firmware the respective fans that are not wired.

It can also be a completely wrong reading due to a bug in the sensor driver too.

--
Kind regards,
Anton Lazarov
MScEng EECSIT

Re: 6.9 regression: opensmtpd complains "smtp cert-check result=\"no certificate presented\""

[naib+lists]

You wrote:
> since the upgrade to 6.9 at the weekend opensmtpd complains
> smtp cert-check result="no certificate presented"
> for incoming EMails.
Again, this is just a notification from the server, that no client 
certificates were sent in case of client tls authentication. This
has nothing to do with your second issue:
> Diagnostic-Code: X-Postfix; TLS is required, but was not offered by host
> mail.example.de
I'd say that you can safely ignore the previous message.

Instead, I'd suggest trying to debug OpenSMTPD with -dT all (or -dT
transfer) and look at the output. If there is something wrong with
your certs or config, it'll be shown there.

Re: Q: dmesg: dt: 443 probes

[Why 42? The lists account.]

On Mon, May 03, 2021 at 12:59:27AM +0200, Patrick Wildt wrote:
> > ...
> > But when I do (as root): "sysctl kern.allowdt=1" it returns this error:
> > sysctl: kern.allowdt: Operation not permitted
> 
> Similarly to kern.allowkmem, you can only set it when the securelevel is
> still 'low'.  That's for security.  You need to add kern.allowdt=1 to
> sysctl.conf, and then reboot.  Then it'll be enabled after reboot.

Thanks Patrick! After the reboot I was able to experiment with btrace.

Do you use it, do you have any examples that might help to get started?

Using the bfptrace reference guide:
https://github.com/iovisor/bpftrace/blob/master/docs/reference_guide.md
I was able to get a simple "Hello World" to run, but more than that
seemed to cause me some problems e.g.
> # btrace -e 'BEGIN{ @enq = 0 } tracepoint:sched:enqueue { @enq = @enq + 1; } 
> interval:s:10 { printf("sched_enqueue: %d\n", @enq) ; @enq = 0; }'
> btrace:1:77: syntax error:
> BEGIN{ @enq = 0 } tracepoint:sched:enqueue { @enq = @enq + 1; } interval:s:10 
> { printf("sched_enqueue: %d\n", @enq) ; @enq = 0; }
> ^
Doesn't seem to like the interval syntax?

Or this one which does run but then takes an assertion failure:
> # btrace -e 'BEGIN{ @enq = 0 } tracepoint:sched:enqueue { @enq = 
> lhist(retval, 0, 1000, 100); }'
> assertion "hist->hstep == step" failed: file 
> "/usr/src/usr.sbin/btrace/map.c", line 246, function "hist_increment"
> zsh: abort (core dumped)  btrace -e 

Thanks again in any case!

Cheers,
Robb.

Re: Typo/Oversight?: upgrade69.html

[Why 42? The lists account.]

On Sun, May 02, 2021 at 03:08:12PM -0700, cal wrote:
> > ...
> If you would click on it, you would notice that it was a link to the
> page with upgrade instructions from 6.7 to 6.8. ...

And that is what I found confusing.

Cheers,
Robb.

Q: dmesg: dt: 443 probes

[Why 42? The lists account.]

Actually I do notice one thing, having just upgraded to:
kern.version=OpenBSD 6.9-current (GENERIC.MP) #492: Sat May  1 17:37:28 MDT 2021

I checked the output from dmesg and I have a new boot time message:
dt: 443 probes

man dt tells me that dt is dynamic tracing and that I can enable it by
setting kern.allowdt.

But when I do (as root): "sysctl kern.allowdt=1" it returns this error:
sysctl: kern.allowdt: Operation not permitted

What am I missing?

Cheers,
Robb.

FYI: This is on an Intel NUC:
bios0 at mainbus0: SMBIOS rev. 3.2 @ 0x7a9a4000 (77 entries)
bios0: vendor Intel Corp. version "BECFL357.86A.0087.2020.1209.1115" date 
12/09/2020
bios0: Intel(R) Client Systems NUC8i5BEH

Typo/Oversight?: upgrade69.html

[Why 42? The lists account.]

The second item (right after the separator) on this page:

https://www.openbsd.org/faq/upgrade69.html

Reads: "[FAQ Index] | [6.7 -> 6.8]"

Probably that should be 6.8 -> 6.9 ?

Otherwise looking good, just sysupgraded from a snapshot, everything
seems to be working perfectly so far.

Thanks for all your work!

Cheers,
Robb.

Q: pkg_add fails with: TLS handshake failure: ocsp verify failed: Undefined error ...

[Why 42? The lists account.]

Hi All,

What would cause pkg_add -u to report this error?
> https://ftp.fau.de/pub/OpenBSD/snapshots/packages/amd64/: TLS handshake 
> failure: ocsp verify failed: Undefined error: 0
> https://ftp.fau.de/pub/OpenBSD/snapshots/packages/amd64/: empty
> Couldn't find updates for ... a long list of (all?) installed packages ...

Error 0?

That directory, on fau.de, is not empty.

I have just rebooted after running sysupgrade to arrive at:
> OpenBSD mjoelnir.fritz.box 6.9 GENERIC.MP#416 amd64

And as my next step I wanted to then upgrade my installed packages.

Did I miss something?

Cheers,
Robb.

Re: Quick Q: proc: table is full ?

[Why 42? The lists account.]

On Tue, Jan 19, 2021 at 05:56:16PM -, Stuart Henderson wrote:
> > What causes "proc: table is full", or better asked, what limit might I be
> > hitting?
> Perhaps kern.maxthread; check kern.nthreads.

Hi Stuart,

Aha. I think you have nailed it:
> mjoelnir:/etc 19.01 21:13:02 # sysctl kern | egrep 'max(proc|thread)'
> kern.maxproc=8192
> kern.maxthread=1950
> mjoelnir:/etc 19.01 21:13:19 # ^max^n
> sysctl kern | egrep 'n(proc|thread)'
> kern.nthreads=1736
> kern.nprocs=283

I see that, way back when, I increased kern.maxproc to 8192 in
/etc/sysctl.conf. But I didn't realise then that I might also need to
increase the maxthread value. I'll change these and see if that helps.
(Bound to!)

I find the message to be a bit misleading though: "proc: table is full"

Clearer might be something like:
"kernel: thread table full: reached limit: kern.maxthread"

Or similar. I.e. the who, the what and the why.

Thanks for the tip!

Cheers,
Robb.

Quick Q: proc: table is full ?

[Why 42? The lists account.]

Hi All,

What causes "proc: table is full", or better asked, what limit might I be
hitting?

I wrote a quick loop to check how many processes are running i.e.
> while true   
> do
> DATE=`date +'%Y.%m.%d %H:%M:%S'`
> echo -n "${DATE}: "
> ps -AHk | wc -l
> sleep 90
> done
> 2021.01.19 12:59:21: 1821
> 2021.01.19 13:00:51: 1731
> 2021.01.19 13:02:21: 1698
> 2021.01.19 13:03:52: 1696
> ... 
I have yet to see a high of more than ~2000.

Sysctl shows me these proc values:
> kern.maxproc=8192
> kern.nprocs=283

I am the only user on the machine (Xfce Desktop and too many browser
tabs). I am a member of "staff" so I think these limits apply:
> staff:\
> :datasize-cur=8192M:\
> :datasize-max=infinity:\
> :maxproc-cur=7500:\
> :maxproc-max=1:\
> :openfiles-cur=15000:\
> :openfiles-max=2:\
> :ignorenologin:\
> :requirehome@:\
> :tc=default:

Running "limit" in my shell (zsh) shows:
> cputime unlimited
> filesizeunlimited
> datasize8192MB
> stacksize   4MB
> coredumpsizeunlimited
> memoryuse   31608MB
> memorylocked10537MB
> maxproc 7500
> descriptors 15000

Also, a related question ... that message shows up in the output of dmesg
and also gets logged to the messages file, but it isn't reported in my
Xconsole window. In there I see stuff like this:
> Console log for mjoelnir
> drm:pid64450:intel_pipe_update_start *ERROR* [drm] *ERROR* Potential atomic 
> update failure on pipe A
> uvm_mapent_alloc: out of static map entries

But no corresponding proc table full messages. Is it not considered to be
important enough to also go to this console?

Thanks in advance!

Cheers,
Robb.

really pleased with openbsd68/rpi4 8GB installation/performance

[tech-lists]

Thank you to everyone who helped make openbsd work on the rpi4.

Although I won't be needing xorg/x11 on this particular machine, I tried
installing it anyway out of curiosity and was surprised how easy it was 
to get it all working. I thought firefox might bog it down but no. Very smooth.

Installation was painless once I followed the instructions exactly.

thanks,
--
J.

Re: msdos partition is too small in arm64/miniroot68.img

[tech-lists]

On Thu, Jan 07, 2021 at 09:55:28AM -0700, Theo de Raadt wrote:

tech-lists  wrote:


On Wed, Jan 06, 2021 at 09:25:01AM -0700, Theo de Raadt wrote:
>The miniroot is 33MB because it contains many install firmwares, and
>it is 97% full.
>
>I suggest you find another way of installing.
>

Is there a technical (or some other reason I'm not seeing) why miniroot68.fs
has been made as small as it is, and not some other size like 48MB, which
would allow the msdos partition to be made larger?


Why 48MB?  Why not 2GB?  Why not make miniroot68.img be 2GB for download
to satisfy some bizzare usage pattern?

All media are created to be small, no larger than they need to be.


OK I get it. The install requires an additional USB storage device. 

What I wanted to do was to write latest firmwares from 
https://github.com/pftf/RPi4 as described in OpenBSD/6.8/arm64/INSTALL.arm64

into the (mdconfig-mounted) msdos partition of miniroot68.img prior to writing
it to the sdcard, as I didn't have an additional USB storage device.

The latest firmwares (v1.22) unzip to 5.4MB but the msdos partition is only
4.0MB.

thanks,
--
J.


signature.asc
Description: PGP signature

Re: msdos partition is too small in arm64/miniroot68.img

[tech-lists]

On Thu, Jan 07, 2021 at 02:20:54PM +, a...@sdf.org wrote:

On Thu, Jan 07, 2021 at 01:01:53PM +, tech-lists wrote:

On Wed, Jan 06, 2021 at 09:01:19PM +, a...@sdf.org wrote:

[...method...]

thanks for that, I'll let you know how I get on. I think your
problem with spontaneous crashes might be down to swapfile,
sdcard is unsuitable for this. I've had good results with
arm64/freebsd-current/swapfile on usb3 spinning rust/
tmpdir on tmpfs. Very quick for what it is. This other rpi4
will hopefully be a desktop replacement. Part of the reason
I'd like openbsd for this is for binary OS upgrades on this
platform.
--
J.


So after advising the list to put tmp on mfs, you think I'm using
swap. In the sd card. Come on man!


;)

(in mitigation, I didn't want to presume). Also, I don't know what 
openbsd actually has in this context, as I've not got to the 
install stage yet.


It's just that I found similar random crashes with raspios, and that
*did* have a swapfile. I'm not sure how it's mounted or how it works
in the raspios context, other than "it is a swapfile".
--
J.


signature.asc
Description: PGP signature

Re: msdos partition is too small in arm64/miniroot68.img

[tech-lists]

On Wed, Jan 06, 2021 at 09:01:19PM +, a...@sdf.org wrote:

[...method...]

thanks for that, I'll let you know how I get on. I think your
problem with spontaneous crashes might be down to swapfile,
sdcard is unsuitable for this. I've had good results with 
arm64/freebsd-current/swapfile on usb3 spinning rust/

tmpdir on tmpfs. Very quick for what it is. This other rpi4
will hopefully be a desktop replacement. Part of the reason
I'd like openbsd for this is for binary OS upgrades on this
platform.
--
J.


signature.asc
Description: PGP signature

Re: msdos partition is too small in arm64/miniroot68.img

[tech-lists]

On Wed, Jan 06, 2021 at 09:25:01AM -0700, Theo de Raadt wrote:

The miniroot is 33MB because it contains many install firmwares, and
it is 97% full.

I suggest you find another way of installing.



Is there a technical (or some other reason I'm not seeing) why miniroot68.fs
has been made as small as it is, and not some other size like 48MB, which
would allow the msdos partition to be made larger?

thanks,
--
J.


signature.asc
Description: PGP signature

msdos partition is too small in arm64/miniroot68.img

[tech-lists]

Hi,

I'm trying to install openbsd 6.8 on a raspberry pi 4/8GB. 
The files I need to add to the msdos partition are, in total, too

large to fit (the partition is only 4MB)

Is there some method of increasing the msdos partition size
of the miniroot.fs image? I'd be doing this from either a freebsd
or linux desktop. On freebsd, I can virtualise the image with 
mdconfig. Or is there some other way round this, like re-writing 
the image.


thanks,
--
J.


signature.asc
Description: PGP signature

Re: sysupgrade with latest snapshot: The directory '/home/_sysupgrade/' does not exist.

[Why 42? The lists account.]

> ...
> >  2. Figure out how to tell sysupgrade the right answers in advance i.e.
> > via the auto_upgrade.conf mechanism
> 
> This is fairly easy:
> 
> sysupgrade -s -n
> vi /auto_upgrade.conf, edit "Pathname to the sets"
> reboot
> ...

FYI, or for the record, I just tried the above and it worked perfectly.
The sysupgrade ran automatically, found the sets, and here I am running:

kern.version=OpenBSD 6.8 (GENERIC.MP) #98: Sun Oct  4 18:13:26 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

There was just this one error towards the end, after the final reboot:
> Path to firmware: http://firmware.openbsd.org/firmware/6.8/
> Updating: intel-firmware-20200616v0 vmm-firmware-1.11.0p3 
> inteldrm-firmware-20200421
> Checking for available binary patches...
> syspatch: Error retrieving 
> https://ftp.halifax.rwth-aachen.de/pub/OpenBSD/syspatch/6.8/amd64/SHA256.sig: 
> 404 Not Found

And that is correct, there is no 6.8 directory under "syspatch".

Did I pick a bad week to give up smoking (airplane :)) and just happen
to hit the switch from Beta to Release? Or have I screwed up something
else?

A subsequent "pkg_add -vu" fails with a similar error:
"pub/OpenBSD/6.8/packages/amd64/: no such dir"

Night all & thanks again!
Robb.

Re: sysupgrade with latest snapshot: The directory '/home/_sysupgrade/' does not exist.

[Why 42? The lists account.]

On Mon, Sep 28, 2020 at 08:25:34AM -0600, Theo de Raadt wrote:
> ...
> So we are at an impasse.  The recommended solution is for people to stop
> making sysupgrade-incompatible layouts in the future, and to consider
> repairing their incompatible layouts from the past.
>
> if sysupgrade doesn't work, people have the old ways of doing things.
> doctor doctor it hurts when i layout my disk strangely...
 
Hi there,

So, I think I have a workaround for my issue with sysupgrade and, from my
side, everything is more or less hunky dory ... but as Theo wrote, now I
have in the back of my mind "consider repairing" ...

So I just have to ask ... what then would be the supported/approved disk
layout for OpenBSD 6.8 on my Intel 8i5 NUC with the following storage:

1. A 2TB Samsung SSD: Currently identified as:
sd0 at scsibus1 targ 2 lun 0:  naa.5002538e4109632a
sd0: 1953514MB, 512 bytes/sector, 4000797360 sectors, thin

2. A 512GB Samsung M.2 NVMe device: Currently identified as:
sd1 at scsibus2 targ 1 lun 0: 
sd1: 476940MB, 512 bytes/sector, 976773168 sectors

It's my main desktop system, running XFCE.

Currently df shows:
Filesystem SizeUsed   Avail Capacity  Mounted on
/dev/sd1a 1005M314M640M33%/
mfs:6361   7.7G331M7.0G 4%/tmp
/dev/sd1e 58.3G   91.3M   55.3G 0%/var
/dev/sd1f  2.0G1.2G686M64%/usr
/dev/sd1g 1005M251M703M26%/usr/X11R6
/dev/sd1h 19.7G   11.0G7.7G59%/usr/local
/dev/sd1k  5.9G2.0K5.6G 0%/usr/obj
/dev/sd1j  2.0G2.0K1.9G 0%/usr/src
/dev/sd1l  295G   10.0G271G 4%/fast
/dev/sd0h  1.8T964G758G56%/space

(Yeah, yeah, when I installed I made "/var" way too big for some reason.)

There is a swap area on sd1b of 64GB (twice the size of the RAM). At
install time I thought about not allocating any swap at all, but I wasn't
sure if that was a good idea or not.

That mount "/space" contains essentially all the non OS stuff in
subdirectories e.g. "home", "images", "videos", "music", "netapp". It
will eventually be just over 1TB (and then keep growing :). Too big to
fit on the NVMe stick.

The "/fast" mount is used for working/output data from apps e.g.
Wireshark, Influxdb, Telegraf, Grafana, NetApp.

How would 6.8 layout these drives differently. if I were to installed it,
from scratch, for example?

Output of disklabel below.

Feel free to ignore this email, since, if I am honest, I am unlikely to
start moving >1TB of data around for fun (maybe with the next hardware
refresh). But I would still be interested to hear how it would be done
differently.

Cheers,
Robb.


disklabel sd0
# /dev/rsd0c:
type: SCSI
disk: SCSI disk
label: Samsung SSD 860
duid: 7a1775fef773535e
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 249038
total sectors: 4000797360
boundstart: 64
boundend: 4000797297
drivedata: 0
16 partitions:
#size   offset  fstype [fsize bsize   cpg]
  a:  2097152 1024  4.2BSD   2048 16384 12958
  c:   40007973600  unused
  h:   3998699008  2098176  4.2BSD   8192 65536 52270 # /space

disklabel sd1
# /dev/rsd1c:
type: SCSI
disk: SCSI disk
label: Samsung SSD 970
duid: 281ef747da03afe7
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 60801
total sectors: 976773168
boundstart: 1024
boundend: 976773105
drivedata: 0
16 partitions:
#size   offset  fstype [fsize bsize   cpg]
  a:  2097152 1024  4.2BSD   2048 16384 12958 # /
  b: 67324128  2098176swap# none
  c:9767731680  unused
  d:  8388608 69422304  4.2BSD   2048 16384 12958
  e:124326848 77810912  4.2BSD   2048 16384 12958 # /var
  f:  4194304202137760  4.2BSD   2048 16384 12958 # /usr
  g:  2097152206332064  4.2BSD   2048 16384 12958 # /usr/X11R6
  h: 41943040208429216  4.2BSD   2048 16384 12958 # /usr/local
  i:  960   64   MSDOS
  j:  4194304250372256  4.2BSD   2048 16384 12958 # /usr/src
  k: 12582912254566560  4.2BSD   2048 16384 12958 # /usr/obj
  l:629145536267149504  4.2BSD   4096 32768 26062 # /fast

Re: sysupgrade with latest snapshot: The directory '/home/_sysupgrade/' does not exist.

[Why 42? The lists account.]

Theo de Raadt wrote:
> Your system is layed out strangely and sysupgrade cannot handle all
> absurd layouts.

And:
> The correct proposal is:
> 
>  Install your machines in a normal way.
> 
> It is not unreasonable.
 
Hi,

You are right, that is a reasonable requirement.

This system was installed in a normal way. Later, a second disk was added.

A smaller, faster storage device for the OS with a larger, not so fast
device for data (including home) doesn't seem that absurd to me. Maybe a
bit old school.

That the device names changed, that the disk I added later became sd0, is
(I assume) related to how OpenBSD probes/manages the hardware. That
hasn't caused me any issues at all except for, perhaps, this one problem
of confusing sysupgrade. But it looks as if I have a solution for that
now, or as you suggest, I can do upgrades manually, so all good here.

Thanks for the support.

Cheers,
Robb.

Re: sysupgrade with latest snapshot: The directory '/home/_sysupgrade/' does not exist.

[Why 42? The lists account.]

On Sun, Sep 27, 2020 at 04:25:58PM -0400, Ian Darwin wrote:
> > ...
> > after the download of the new sets and the reboot, I would have been
> > prompted as to what to do i.e. Install, Upgrade, or Shell.  Then for a
> > keyboard layout (e.g. de) and for the name of the disk containing OpenBSD
> > (i.e. the system root partition) or "/").
> 
> Something is wwrong here. That is not how sysupgrade works. Probably you
> didn't install updated boot blocks and it has been failing to "switch
> to bsd.upgrade" when rebooting after the download, and your latest
> change installed the updated boot blocks, and now it is working.
 
I am not sure about that.

IMO probably the something wrong here is/was that after installing
OpenBSD as a proof of concept (of a new desktop "daily driver" system) I
subsequently added a second disk to provide more space, for my /home.

At that time this new disk (an ssd) then became know as, or inherited,
the name sd0, and the pre-existing nvme device with the OS became sd1.

Since that time I have been able to sysupgrade many times without issue,
other than that I had to manually respond to sysupgrade e.g. to specify
which disk device held the OS.
 
> Here you describe how sysupgrade normally works.
Right, although what is new for me (I think) is to see this message:
"Performing non-interactive upgrade..."
 
> >  2. The upgrade then proceeds, however it fails to identify the
> >  location of the newly downloaded sets. The error is: "The directory
> >  '/home/_sysupgrade/' does not exist."
>
> I've never tried using a symlink to /home. Can you mount /home properly
> and see if that works?
Over many sysupgrades it has always been sufficent to manually respond
that the sets are on disk, the disk is mounted and that the path to them
is "/mnt/space/home/_sysupgrade".

Sysupgrade does a nice job presenting the information needed e.g. what is
mounted where.

I'm not sure what you mean by "Can you mount /home properly". At the
point were I am having the issue, sysupgrade is in charge, has rebooted
the system and mounted things where it wants them. Unfortunately, it
doesn't find the sets and then apparently promptly reboots the system.

What I would like would be able to do (one of):
 1. Interrupt the "non-interactive upgrade" somehow, so as to provide my
own answers.

 2. Figure out how to tell sysupgrade the right answers in advance i.e.
via the auto_upgrade.conf mechanism

 3. Have sysupgrade just do the right thing. For example, there could be
a _sysupgrade user in the systems /etc/passwd, whose $HOME would
indicate the preferred location for sets ... But best understand the
problem before designing a solution :)

I guess that is reverse order of preference :)

Cheers,
Robb.


FYI: From the normal running system:

mjoelnir% sysctl hw.disknames
hw.disknames=sd0:7a1775fef773535e,sd1:281ef747da03afe7,sd2:67c92dad63883338

mjoelnir% dmesg | grep targ
...
scsibus0 at mpath0: 256 targets
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 2 lun 0:  naa.5002538e4109632a
scsibus2 at nvme0: 2 targets, initiator 0
sd1 at scsibus2 targ 1 lun 0: 
scsibus3 at umass0: 2 targets, initiator 0
sd2 at scsibus3 targ 1 lun 0:  
serial.1058262039344E4B4E5A
scsibus4 at vscsi0: 256 targets
scsibus5 at softraid0: 256 targets

mjoelnir% df -h
Filesystem SizeUsed   Avail Capacity  Mounted on
/dev/sd1a 1005M314M640M33%/
mfs:6361   7.7G201K7.4G 0%/tmp
/dev/sd1e 58.3G   92.6M   55.3G 0%/var
/dev/sd1f  2.0G1.2G686M64%/usr
/dev/sd1g 1005M251M703M26%/usr/X11R6
/dev/sd1h 19.7G   11.0G7.7G59%/usr/local
/dev/sd1k  5.9G2.0K5.6G 0%/usr/obj
/dev/sd1j  2.0G2.0K1.9G 0%/usr/src
/dev/sd1l  295G   10.0G271G 4%/fast
/dev/sd0h  1.8T964G758G56%/space

(sd2 is just a USB attached external Western Digital hard disk for
backup.)

sysupgrade with latest snapshot: The directory '/home/_sysupgrade/' does not exist.

[Why 42? The lists account.]

Hi All,

I am running:
kern.version=OpenBSD 6.8-beta (GENERIC.MP) #69: Tue Sep 15 12:34:41 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

I just tried to use sysupgrade and I notice that its behaviour has
changed a bit since my last upgrade. Previously (last six months or so)
after the download of the new sets and the reboot, I would have been
prompted as to what to do i.e. Install, Upgrade, or Shell.  Then for a
keyboard layout (e.g. de) and for the name of the disk containing OpenBSD
(i.e. the system root partition) or "/").
 
 1. Now on the console I see (post reboot):
"Performing non-interactive upgrade..."
It automatically selects a "root" disk, and in my case it correctly
selects sd1. which is great.

 2. The upgrade then proceeds, however it fails to identify the location
of the newly downloaded sets. The error is:
"The directory '/home/_sysupgrade/' does not exist."

 3. It then seems to abort the upgrade and reboot the system. Thus
leaving me back where I started.

 4. I get an excellent log via email of sysupgrades actions (see below).

The sets are (or at least they were) present on disk, located in
/space/home/_sysupgrade. There is also a symlink from /home/_sysupgrade
to this directory.

Sysupgrade has this partition mounted as "/mnt/space".

How can I best tell sysupgrade where to find the sets?

According to the man page for autoinstall it seems as if I should be able
control it with an upgrade response file e.g. previous sysupgrade runs
sent this sample/example via email:
> Which disk is the root disk = sd1
> Force checking of clean non-root filesystems = no
> Location of sets = disk
> Is the disk partition already mounted = yes
> Pathname to the sets = /mnt/space/home/_sysupgrade
> Set name(s) = done
> Directory does not contain SHA256.sig. Continue without verification = yes
> Location of sets = done

But what I am missing is how to supply the response file to sysupgrade.
In the above man page it states "... If either /auto_install.conf or
/auto_upgrade.conf is found on bsd.rd's built-in RAM disk,"

But how do I get the file into the .rd RAM disk? Or should I put it
somewhere else entirely? This is a (snapshot) upgrade, not an complete
install.

The man page also mentions serving it up via the network, using http and
dhcp, but that would require another running system.

Or, can I somehow tell sysupgrade _not_ to automatically run, but rather
interrupt it so as to manually provide the right answers (path)?

Cheers,
Robb.


Email content:
...
Subject: mjoelnir.domain.tld upgrade log

Choose your keyboard layout ('?' or 'L' for list) [default] default
Available disks are: sd0 sd1.
Which disk is the root disk? ('?' for details) [sd0] sd1
Checking root filesystem (fsck -fp /dev/sd1a)... OK.
Mounting root filesystem (mount -o ro /dev/sd1a /mnt)... OK.
Force checking of clean non-root filesystems? [no] no
fsck -p 281ef747da03afe7.e... OK.
fsck -p 281ef747da03afe7.f... OK.
fsck -p 281ef747da03afe7.g... OK.
fsck -p 281ef747da03afe7.h... OK.
fsck -p 281ef747da03afe7.k... OK.
fsck -p 281ef747da03afe7.j... OK.
fsck -p 281ef747da03afe7.l... OK.
fsck -p 7a1775fef773535e.h... OK.
/dev/sd1a (281ef747da03afe7.a) on /mnt type ffs (rw, local)
/dev/sd1e (281ef747da03afe7.e) on /mnt/var type ffs (rw, local, nodev, nosuid)
/dev/sd1f (281ef747da03afe7.f) on /mnt/usr type ffs (rw, local, nodev)
/dev/sd1g (281ef747da03afe7.g) on /mnt/usr/X11R6 type ffs (rw, local, nodev)
/dev/sd1h (281ef747da03afe7.h) on /mnt/usr/local type ffs (rw, local, nodev, 
wxallowed)
/dev/sd1k (281ef747da03afe7.k) on /mnt/usr/obj type ffs (rw, local, nodev, 
nosuid)
/dev/sd1j (281ef747da03afe7.j) on /mnt/usr/src type ffs (rw, local, nodev, 
nosuid)
/dev/sd1l (281ef747da03afe7.l) on /mnt/fast type ffs (rw, local, nodev, nosuid)
/dev/sd0h (7a1775fef773535e.h) on /mnt/space type ffs (rw, local)

Let's upgrade the sets!
Location of sets? (disk http nfs or 'done') [http] disk
Is the disk partition already mounted? [yes] yes
Pathname to the sets? (or 'done') [6.8/amd64] /home/_sysupgrade/
The directory '/home/_sysupgrade/' does not exist.

Re: OpenDNSSEC signer engine: Bus error: How to get debug information?

[Why 42? The lists account.]

Hi All,

By the way, I just wanted to say how great this is.
I have problem, I ask for help, I get (good) help. With relative easy I
can build the necessary debugging tool and use it to find out that the OS
has helped to identify a problem in the application.

Pretty nice and not necessarily my everyday experience in IT.

Thanks again.

Cheers,
Robb.

Re: OpenDNSSEC signer engine: Bus error: How to get debug information?

[Why 42? The lists account.]

On Tue, Sep 22, 2020 at 07:12:47AM -, Stuart Henderson wrote:
> Sounds like they are trapping sigbus themselves but the handler isn't
> giving useful information.
> 
> Try just running it under gdb:
> pkg_add gdb
> egdb ods-signerd
> set args -dv
> run
> 
> and see if you can get a backtrace. You may need to build opendnssec
> with debug symbols to get a usable trace though (checkout the ports
> tree and build it with "make DEBUG=-g repackage reinstall").

Hi Stuart,

Thanks for that, concise and really helpful. The debug build process was
easier than I expected :).

For what is worth the results in egdb are:
Thread 2 received signal SIGBUS, Bus error.
[Switching to thread 478985]
0x0851fb90f5f5 in ldns_rr_clone () from /usr/local/lib/libldns.so.7.1
(gdb) bt
#0  0x0851fb90f5f5 in ldns_rr_clone () from /usr/local/lib/libldns.so.7.1
#1  0x084fca6e4e55 in ixfr_del_rr (ixfr=0x852782d0d80, 
rr=0xdfdfdfdfdfdfdfdf) at signer/ixfr.c:134
#2  0x084fca6ea0da in rrset_sign (ctx=0x8522842d800, rrset=, 
signtime=1600781131) at signer/rrset.c:758
#3  0x084fca6ddd6c in drudge (worker=0x8521a9e4000) at 
daemon/signertasks.c:196
#4  0x084fca714e0b in runthread (data=0x851d1fc6300) at janitor.c:318
#5  0x0852553ad0d1 in _rthread_start (v=) at 
/usr/src/lib/librthread/rthread.c:96
#6  0x0851f742dc38 in __tfork_thread () at 
/usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:77
#7  0x in ?? ()
(gdb) info args
No symbol table info available.
(gdb) info local
No symbol table info available.
(gdb) up
#1  0x084fca6e4e55 in ixfr_del_rr (ixfr=0x852782d0d80, 
rr=0xdfdfdfdfdfdfdfdf) at signer/ixfr.c:134
134 ldns_rr* rr_copy = ldns_rr_clone(rr);
(gdb) info args
ixfr = 0x852782d0d80
rr = 0xdfdfdfdfdfdfdfdf
(gdb) info local
rr_copy = 

I'm not a gdb expert, but I wonder why it says "No symbol table info
available" ...

In any case, I've forwarded the info. on to the opendnssec developer
list.

Thanks again.

Cheers,
Robb.

OpenDNSSEC signer engine: Bus error: How to get debug information?

[Why 42? The lists account.]

Hi All,

I am attempting to setup secure DNS on an OpenBSD 6.7 system using NSD,
Unbound and a package called Opendnssec.

I seem to have arrived at a point where one of the Opendnssec daemons,
"ods-signerd", crashes on startup i.e.
> # ods-signerd -dv
> OpenDNSSEC signer engine version 2.1.6
> Bus error in ldns_rr_clone
> Threaddump
> Threaddump
> Threaddump
> Threaddump
> Threaddump
> Threaddump
> Threaddump
> Threaddump
> Threaddump
> Threaddump
> Bus error

I'm not sure exactly what Threaddump means but, as far as I can tell, no
core file is dumped/written.

Is there something I can/should do in order to enable a core dump, or to
gather some more debug info. that I can pass on to the Opendnssec
developers?

Alternatively, if anyone has any ideas about what could be causing the
problem, or how to avoid it, that would be even better :-).

The other daemon started by Opendnssec seems to be running "as expected"
e.g.
> # ps aux | grep ods
> _opendns 67028  0.0  1.1 24140 33728 ??  I7Sep209:02.01 
> /usr/local/sbin/ods-enforcerd

Thanks in advance!

Cheers,
Robb.

Browser (Gtk?) issue after sysupgrade to latest snapshot

[Why 42? The lists account.]

Hi All,

I just used sysupgrade (followed by pkg_add -u) to update my desktop
system to:
OpenBSD 6.7-current (GENERIC.MP) #22: Tue Aug 11 21:29:51 MDT 2020

All is working quite well but I noticed some issue with the iridium
browser. When I tried to export my bookmarks, iridium crashed.

As an experiment I then tried the same thing with chrome and then
firefox, they also both crash.

The iridium crash results in this on stdout/stderr:
> Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed 
> (error == NULL): Failed to load 
> /usr/local/share/icons/Faba/16x16/status/image-missing.svg: Unable to load 
> image-loading module: 
> /usr/local/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so: Cannot 
> load specified object (gdk-pixbuf-error-quark, 5)
> Bail out! Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon: assertion 
> failed (error == NULL): Failed to load 
> /usr/local/share/icons/Faba/16x16/status/image-missing.svg: Unable to load 
> image-loading module: 
> /usr/local/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so: Cannot 
> load specified object (gdk-pixbuf-error-quark, 5)
> zsh: abort (core dumped)  iridium

There are a lot of what look like related warnings in .xsession-errors
e.g.
> (xfce4-appearance-settings:35516): Gtk-WARNING **: 21:27:57.917: Could
> not load a pixbuf from icon theme.  This may indicate that pixbuf
> loaders or the mime database could not be found.

All these errors seem to be Gtk and/or file-chooser related.

After a bit of research, I thought running "update-mime-database" might
help, but it returns this cryptic error(?):
> update-mime-database -V /usr/share  
> Updating MIME database in /usr/share...
> Directory '/usr/share/packages' does not exist!

That's correct, there is no such directory.

(Changing to using a different set/theme of icons (in Xfce) didn't help
either.)

Maybe I missed some vital post "pkg_add -u" action? A couple of days ago
I switched my video output from HDMI to DisplayPort. For X(fce) this
seems to work perfectly. However the Console screen (outside X11 e.g. at
boot time) now uses a much lower resolution, which results a lot of stuff
scrolling off the screen, including much of the package update advice.

(I ran my update without X(fce), guess I should have used
script/screen/tmux to capture the session :)).

FYI, here is the debugger output from the iridium crash:

mjoelnir:~ 12.08 22:05:24 % egdb /usr/local/iridium/iridium iridium.core
GNU gdb (GDB) 7.12.1
...
Core was generated by `iridium'.
Program terminated with signal SIGABRT, Aborted.
#0  thrkill () at /tmp/-:3
3   /tmp/-: No such file or directory.
[Current thread is 1 (process 430637)]

(gdb) bt
#0  thrkill () at /tmp/-:3
#1  0x0b16e6d7a15e in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51
#2  0x0b1700a3f1c3 in g_assertion_message () from 
/usr/local/lib/libglib-2.0.so.4201.4
#3  0x0b1700a3f604 in g_assertion_message_error () from 
/usr/local/lib/libglib-2.0.so.4201.4
#4  0x0b1705899267 in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#5  0x0b17058994d8 in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#6  0x0b17058b5635 in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#7  0x0b17057e93de in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#8  0x0b17057eea5f in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#9  0x0b17058b5347 in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#10 0x0b1705997c95 in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#11 0x0b1705996cd7 in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#12 0x0b1705996c13 in gtk_widget_get_preferred_width () from 
/usr/local/lib/libgtk-3.so.2201.0
#13 0x0b1705789562 in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#14 0x0b17057e93de in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#15 0x0b17057eea5f in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#16 0x0b1705788a77 in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#17 0x0b1705997c95 in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#18 0x0b1705996cd7 in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#19 0x0b1705996c13 in gtk_widget_get_preferred_width () from 
/usr/local/lib/libgtk-3.so.2201.0
#20 0x0b1705997c95 in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#21 0x0b1705996cd7 in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#22 0x0b1705996c13 in gtk_widget_get_preferred_width () from 
/usr/local/lib/libgtk-3.so.2201.0
#23 0x0b1705782b46 in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#24 0x0b170596f59f in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#25 0x0b1705997c95 in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#26 0x0b1705996cd7 in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#27 0x0b1705996c13 in gtk_widget_get_preferred_width () from 
/usr/local/lib/libgtk-3.so.2201.0
#28 0x0b17057e93de in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#29 0x0b17057eea5f in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#30 0x0b17058d8c9b in ?? () 

Re: Logging in/out on console while logged in in X removes hardware acceleration

[lists]

Fri, 31 Jul 2020 17:36:53 +0200 Nils Reuße 
> Hi Theo,
> 
> thank you for your reply.  Well then, I guess I just stop switching 
> around between different login sessions ;)
> 
> Nils
> 
> 
> Am 31.07.2020 um 16:08 schrieb Theo de Raadt:
> > I'm not sure what can be done about it.
> > 
> > /etc/fbtab's first role is to give access to subsystems, but it's
> > second more important role is to *take them away* later.
> > 
> > Unfortunately there is nothing "keeping state" about previous access
> > conditions, as well it is quite unclear if reverting to previous access
> > conditions would be a safe choice.
> > 

Hi Nils,

Or use own tooling to reset desired permissions when you're in X again,
try to see if your window manager accepts bindings and use it instead..

-- 
Kind regards,
Anton Lazarov
MScEng EECSIT

Re: iXorg / xenodm logs fill with errors: "_XSERVTransSocketUNIXAccept: accept() failed"

[Why 42? The lists account.]

On Sat, Jul 11, 2020 at 07:38:58PM +0200, Caspar Schutijser wrote:
> > > [501037.408] _XSERVTransSocketUNIXAccept: accept() failed
> > > ...
> 
> This message may be of interest:
> https://marc.info/?l=openbsd-misc&m=155787066627780&w=2


Hi,

I must have missed that message - thanks for pointing it out!

I've made the changes for daemon in login.conf and restarted. Time will
tell ...

Thanks again!

Cheers,
Robb.

iXorg / xenodm logs fill with errors: "_XSERVTransSocketUNIXAccept: accept() failed"

[Why 42? The lists account.]

Hi All,

I'm running 6.7 snapshot (6.7 GENERIC.MP#302 amd64) as my main desktop
with Xfce.

Two or three times now I've noticed that these two files in /var/log have
become unexpectedly huge:
> mjoelnir:log # du -sh xenodm.log Xorg.0.log
> 378M  xenodm.log
> 487M  Xorg.0.log

Apart from the usual startup/initialisation messages (below) Xorg.0.log
contains many many instances of this message:
> mjoelnir:log # grep -c '_XSERVTransSocketUNIXAccept: accept() failed' 
> Xorg.0.log  8800235

The same message is logged to xenodm.log i.e.
> mjoelnir:log # grep -c '_XSERVTransSocketUNIXAccept: accept() failed' 
> xenodm.log 
> 8800235

I don't know why or when this occurs, but I have the impression it occurs
when coming out of lockscreen i.e. when I return to my computer and enter
my password. The whole desktop becomes unresponsive for tens of seconds
at this point, probably busy writing those log messages ...

I assume that there must be some an issue with xenodm or the X11
subsystem. A search on the Internet only resulted in a couple of hits,
from 2010 and 2012, at least one of which was related to the Cygwin
platform - so quite different. I ran OpenBSD 6.6 for several months on
this system (Intel NUC 8i5) and didn't notice this issue.

The only other video error I have noticed is this one in the console or
output of dmesg:
> drm:pid54673:intel_pipe_update_start *ERROR* [drm] *ERROR* Potential atomic 
> update failure on pipe A

I don't know if that is related.

Any thoughts? Anyone else experienced anything similar?


FYI: Excerpt from Xorg.0.log
> [26.343] (WW) checkDevMem: failed to open /dev/xf86 and /dev/mem
> (Operation not permitted)
> Check that you have set 'machdep.allowaperture=1'
> in /etc/sysctl.conf and reboot your machine
> refer to xf86(4) for details
> [26.343]linear framebuffer access unavailable
> [26.373] (--) Using wscons driver on /dev/ttyC4
> [26.386] 
> X.Org X Server 1.20.8
> X Protocol Version 11, Revision 0
> [26.386] Build Operating System: OpenBSD 6.7 amd64 
> [26.386] Current Operating System: OpenBSD mjoelnir.fritz.box 6.7 
> GENERIC.MP#273 amd64
> [26.386] Build Date: 15 June 2020  07:46:53PM
> [26.386]  
> [26.386] Current version of pixman: 0.38.4
> [26.386]Before reporting problems, check http://wiki.x.org
> to make sure that you have the latest version.
> [26.386] Markers: (--) probed, (**) from config file, (==) default 
> setting,
> (++) from command line, (!!) notice, (II) informational,
> (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> [26.386] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Jun 16 20:04:24 
> 2020
> [26.388] (==) Using system config directory 
> "/usr/X11R6/share/X11/xorg.conf.d"
> [26.389] (==) No Layout section.  Using the first Screen section.
> [26.389] (==) No screen section available. Using defaults.
> [26.389] (**) |-->Screen "Default Screen Section" (0)
> [26.389] (**) |   |-->Monitor ""
> [26.390] (==) No monitor specified for screen "Default Screen Section".
> Using a default monitor configuration.
> [26.390] (==) Automatically adding devices
> [26.390] (==) Automatically enabling devices
> [26.390] (==) Not automatically adding GPU devices
> [26.390] (==) Max clients allowed: 256, resource mask: 0x1f
> [26.394] (==) FontPath set to:
> /usr/X11R6/lib/X11/fonts/misc/,
> /usr/X11R6/lib/X11/fonts/TTF/,
> /usr/X11R6/lib/X11/fonts/OTF/,
> /usr/X11R6/lib/X11/fonts/Type1/,
> /usr/X11R6/lib/X11/fonts/100dpi/,
> /usr/X11R6/lib/X11/fonts/75dpi/
> [26.394] (==) ModulePath set to "/usr/X11R6/lib/modules"
> [26.394] (II) The server relies on wscons to provide the list of input 
> devices.
> If no devices become available, reconfigure wscons or disable 
> AutoAddDevices.
> [26.394] (II) Loader magic: 0xeed1a3f9000
> [26.394] (II) Module ABI versions:
> [26.394]X.Org ANSI C Emulation: 0.4
> [26.394]X.Org Video Driver: 24.1
> [26.394]X.Org XInput driver : 24.1
> [26.394]X.Org Server Extension : 10.0
> [26.395] (--) PCI:*(0@0:2:0) 8086:3ea5:8086:2074 rev 1, Mem @ 
> 0xc000/16777216, 0x8000/1073741824, I/O @ 0x4000/64
> [26.395] (II) LoadModule: "glx"
> [26.396] (II) Loading /usr/X11R6/lib/modules/extensions/libglx.so
> [26.405] (II) Module glx: vendor="X.Org Foundation"
> [26.405]compiled for 1.20.8, module version = 1.0.0
> [26.405]ABI class: X.Org Server Extension, version 10.0
> [26.405] (==) Matched modesetting as autoconfigured driver 0
> [26.405] (==) Assigned the driver to the xf86ConfigLayout
> [26.405] (II) LoadModule: "modesetting"
> [26.405] (II) Loading /usr/X11R6/lib/modules/drivers/modesetting_drv.so
> [26.406] (II) Module modesetting: vendor="X.Org Foundation"
> [26.406]compiled for 1.20.8

Re: Suggestions re error: "USB read failed" accessing Infinite Noise TRNG?

[Why 42? The lists account.]

Hi Again,

Sorry about the delay in responding. I disabled the uftdi using config as
described.

(also added it to /etc/shutdown.rc as mentioned by Chris Bennett. Seemed
like a good idea.)

It does now seem to be disabled, the boottime message has changed to show
"ugen" rather than "uftdi" i.e.
> ugen1 at uhub0 port 2 "13-37.org Infinite Noise TRNG" rev 2.00/10.00 addr 3

Unfortunately the behaviour seems unchanged:
> mjoelnir:software 1.07 17:39:16 # ./infnoise
> Error: USB read failed

FYI, "usbdevs -v" reports these two device using/being driven by ugen:
> ...
> Controller /dev/usb0:
> addr 01: 8086: Intel, xHCI root hub
>  super speed, self powered, config 1, rev 1.00
>  driver: uhub0
> addr 02: 1050:0407 Yubico, Yubikey 4 OTP+U2F+CCID
>  full speed, power 30 mA, config 1, rev 4.37
>  driver: uhidev0
>  driver: uhidev1
>  driver: ugen0
> addr 03: 0403:6015 13-37.org, Infinite Noise TRNG
>  full speed, power 10 mA, config 1, rev 10.00, iSerial 1337-ECA4E8A6
>  driver: ugen1
> ...

If it is of interest, I also uploaded the output of kdump here:
https://paste.c-net.org/HallwaysFeliz

It's the complete trace, about 2700 lines. I wasn't sure about adding a
1000 lines to my message here.

Cheers,
Robb.

Re: Suggestions re error: "USB read failed" accessing Infinite Noise TRNG?

[Why 42? The lists account.]

On Wed, Jun 24, 2020 at 09:55:05AM -, Stuart Henderson wrote:
> >
> > Disable uftdi in your kernel config (boot -c, disable uftdi, quit) and
> > see if that works. The device is attaching as a serial port, but libftdi
> > probably wants it attaching to ugen. If that helps maybe we can add a
> > quirk to knock out just this device. Send usbdevs -v output.
 
Hi Stuart,

That's most helpful, thanks for the support.

Unfortunately ... I fell at the first fence :(. After I enter 'boot -c' I
get several lines of output followed by a prompt. But the cursor is
flickering wildly and I can't enter any further input.

At this point the first line, at the top of the screen, is an error:
'kbc: cmd word write error'

(This is with boot version: BOOTX64 3.52)

A quick search on the net didn't show much, apart from a suggestion that
a USB keyboard won't work at this point because the USB subsystem hasn't
yet been discovered (that was back in 2015 though). I'm using both a USB
keyboard and mouse.

Something is definitely faffing about with the USB bus though, every time
I press a key at the flickering cursor, the LEDs in my mouse light up ...

I'll try the ktrace approach instead.

Thanks again.

Cheers,
Robb.

Re: XFCE menu does not load with keyboard shortcut

[Why 42? The lists account.]

On Tue, Jun 23, 2020 at 07:33:20PM +0100, Ed Gray wrote:
> I have an issue with XFCE on OpenBSD 6.6 and current on an amd64 system.
> XFCE works fine except for accessing the applications menu with the Alt +
> F1 keyboard shortcut. Instead of loading the menu it gets highlighted in
> grey and nothing happens. Clicking the menu loads it straight away.
> ...
> Does anyone else have this problem?

I'm running OpenBSD 6.7 (snapshot) for amd64 with XFCE as my desktop and
I don't have that problem. Alt + F1 anywhere opens the same menu that I
can get by clicking the right mouse button on the desktop background i.e.
The list of actions from "Open In New ..." through to "Applications".

Maybe check your $HOME/.xsession-errors log file?

Cheers,
Robb.

Suggestions re error: "USB read failed" accessing Infinite Noise TRNG?

[Why 42? The lists account.]

Hi All,

Has anyone ever tried the Infinite Noise TRNG hardware random number generator
with OpenBSD?

It's a USB stick that contains hardware to generate random numbers. See:
https://github.com/13-37-org/infnoise

I had a couple of these working with ArchLinux and would like to try using
them with OpenBSD.

Using either 6.6 or 6.7 the device is recognised at boot time:
> uftdi0 at uhub0 port 2 configuration 1 interface 0 "13-37.org Infinite Noise
> TRNG" rev 2.00/10.00 addr 3 ucom0 at uftdi0 portno 1

With libftdi1-1.4p2 installed I was able to compile the associated software
using the supplied "Makefile.freebsd". So a pretty easy start ...
> make -f Makefile.freebsd
> cc -Wall -Wextra -Werror -std=c99 -O3 -fPIC -I Keccak -I 
> /usr/local/include/libftdi1  -DGIT_VERSION=\"\" -DGIT_COMMIT=\"\" 
> -DGIT_DATE=\"\"  -c libinfnoise.c
> cc -Wall -Wextra -Werror -std=c99 -O3 -fPIC -I Keccak -I 
> /usr/local/include/libftdi1  -DGIT_VERSION=\"\" -DGIT_COMMIT=\"\" 
> -DGIT_DATE=\"\"   -c healthcheck.c
> cc -c -o KeccakF-1600-reference.o Keccak/KeccakF-1600-reference.c -Wall 
> -Wextra -Werror -std=c99 -O3 -fPIC -I Keccak -I /usr/local/include/libftdi1  
> -DGIT_VERSION=\"\" -DGIT_COMMIT=\"\" -DGIT_DATE=\"\" 
> ar rcs libinfnoise.a libinfnoise.o healthcheck.o KeccakF-1600-reference.o
> ranlib libinfnoise.a
> cc -Wall -Wextra -Werror -std=c99 -O3 -fPIC -I Keccak -I 
> /usr/local/include/libftdi1  -DGIT_VERSION=\"\" -DGIT_COMMIT=\"\" 
> -DGIT_DATE=\"\"  -fvisibility=hidden -o libinfnoise.so libinfnoise.o 
> healthcheck.o KeccakF-1600-reference.o  -L /usr/local/lib -Wl -lftdi1 -lm 
> -shared 
> cc -Wall -Wextra -Werror -std=c99 -O3 -fPIC -I Keccak -I 
> /usr/local/include/libftdi1  -DGIT_VERSION=\"\" -DGIT_COMMIT=\"\" 
> -DGIT_DATE=\"\"   -c infnoise.c
> cc -Wall -Wextra -Werror -std=c99 -O3 -fPIC -I Keccak -I 
> /usr/local/include/libftdi1  -DGIT_VERSION=\"\" -DGIT_COMMIT=\"\" 
> -DGIT_DATE=\"\"   -c daemon.c
> cc -Wall -Wextra -Werror -std=c99 -O3 -fPIC -I Keccak -I 
> /usr/local/include/libftdi1  -DGIT_VERSION=\"\" -DGIT_COMMIT=\"\" 
> -DGIT_DATE=\"\"  -o infnoise infnoise.o daemon.o libinfnoise.a -lftdi1 -lm 
> -L. -L /usr/local/lib
 
This creates an executable "driver" called infnoise which can be run as a
daemon e.g.
> doas ./infnoise -h
> Usage: infnoise [options]
> Options are:
> -D, --debug - turn on some debug output
> -R, --dev-random - write entropy to /dev/random instead of stdout
> -r, --raw - do not whiten the output
> -m, --multiplier  - write 256 bits * value for each 512 bits 
> written to
>   the Keccak sponge.  Default of 0 means write all the entropy.
> -n, --no-output - do not write random output data
> -p, --pidfile  - write process ID to file
> -d, --daemon - run in the background
> -s, --serial  - use specified device
> -l, --list-devices - list available devices
> -v, --version - show version information
> -h, --help - this help output
> ...

The "list-devices" mode works nicely:
> doas ./infnoise --list-devices
> ...
> ID: 0, Manufacturer: 13-37.org, Description: Infinite Noise TRNG, Serial: 
> 1337-ECA4E8A6

So far, so good ... But if I try getting actual random numbers, I get "read
failed":
> doas ./infnoise
> ...
> Error: USB read failed

Any suggestions? Where am I going wrong? Maybe I shouldn't have taken that
shortcut with the freebsd makefile? Or a security issue?

Thanks in advance.

Cheers,
Robb.

FYI: Intel 300 PCH termperature sensor now recognised

[Why 42? The lists account.]

Hi All,

Just FYI, 

I noticed that with the newest OpenBSD versions (e.g. I currently have
6.7 GENERIC.MP#273 amd64) a bit more of the Intel Platform Controller Hub
(PCH) is now recognised. At boot time the kernel logs:
> pchtemp0 at pci0 dev 18 function 0 "Intel 300 Series Thermal" rev 0x30

And an additional temperature value for "pchtemp0" is now available:
> sysctl hw.sensors
> hw.sensors.cpu0.temp0=46.00 degC
> hw.sensors.acpitz1.temp0=27.80 degC (zone temperature)
> hw.sensors.pchtemp0.temp0=52.00 degC

Apparently it's the hottest thing in the system! Maybe not surprising
given all the things that the PCH chip is capable of doing :)

This is on an Intel NUC 8i5BEH. Some of the other functionality is not
yet recognised/configured:
> "Intel 300 Series Shared SRAM" rev 0x30 at pci0 dev 20 function 2 not 
> configured
> "Intel 300 Series MEI" rev 0x30 at pci0 dev 22 function 0 not configured
> "Intel 300 Series SPI" rev 0x30 at pci0 dev 31 function 5 not configured

Certainly SPI is Serial Peripheral Interface, though I don't know what it
might be connected to. SRAM is likely Static RAM, could potentially be
used for persistent storage e.g. for crash logging "between" boots.

Cheers,
Robb.

X/xenodm logs: '_XSERVTransSocketUNIXAccept: accept() failed'

[Why 42? The lists account.]

Hi All,

I'm running 6.7 snapshot version (6.7 GENERIC.MP#273 amd64) as my main
desktop with XFCE.

A couple of time now I've noticed that these two files in /var/log have
become unexpectedly huge:
mjoelnir:log 23.06 09:44:15 # du -sh xenodm.log Xorg.0.log
378Mxenodm.log
487MXorg.0.log

Apart from the usual startup/initialisation messages (below) Xorg.0.log
contains many many instances of this message:
> mjoelnir:log 23.06 09:51:59 # grep -c '_XSERVTransSocketUNIXAccept: accept() 
> failed' Xorg.0.log  
> 8800235

The same message is logged to xenodm.log i.e.
> mjoelnir:log 23.06 09:53:14 # grep -c '_XSERVTransSocketUNIXAccept: accept() 
> failed' xenodm.log 
> 8800235

I don't know why or when this occurs, the xenodm messages aren't
timestamped, but I assume that there must be some an issue with xenodm or
the X11 subsystem. A search on the Internet only resulted in a couple of
hits, from 2010 and 2012, at least one of which was related to the Cygwin
platform - so quite different. I ran OpenBSD 6.6 for several months on
this system (Intel NUC 8i5) and don't recall ever seeing this issue.

The only other video issue/error I have noticed is this in the console or
output of dmesg:
> drm:pid54673:intel_pipe_update_start *ERROR* [drm] *ERROR* Potential atomic 
> update failure on pipe A

I don't know if that is related.

FYI: Excerpt from Xorg.0.log
> [26.343] (WW) checkDevMem: failed to open /dev/xf86 and /dev/mem
> (Operation not permitted)
> Check that you have set 'machdep.allowaperture=1'
> in /etc/sysctl.conf and reboot your machine
> refer to xf86(4) for details
> [26.343]linear framebuffer access unavailable
> [26.373] (--) Using wscons driver on /dev/ttyC4
> [26.386] 
> X.Org X Server 1.20.8
> X Protocol Version 11, Revision 0
> [26.386] Build Operating System: OpenBSD 6.7 amd64 
> [26.386] Current Operating System: OpenBSD mjoelnir.fritz.box 6.7 
> GENERIC.MP#273 amd64
> [26.386] Build Date: 15 June 2020  07:46:53PM
> [26.386]  
> [26.386] Current version of pixman: 0.38.4
> [26.386]Before reporting problems, check http://wiki.x.org
> to make sure that you have the latest version.
> [26.386] Markers: (--) probed, (**) from config file, (==) default 
> setting,
> (++) from command line, (!!) notice, (II) informational,
> (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> [26.386] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Jun 16 20:04:24 
> 2020
> [26.388] (==) Using system config directory 
> "/usr/X11R6/share/X11/xorg.conf.d"
> [26.389] (==) No Layout section.  Using the first Screen section.
> [26.389] (==) No screen section available. Using defaults.
> [26.389] (**) |-->Screen "Default Screen Section" (0)
> [26.389] (**) |   |-->Monitor ""
> [26.390] (==) No monitor specified for screen "Default Screen Section".
> Using a default monitor configuration.
> [26.390] (==) Automatically adding devices
> [26.390] (==) Automatically enabling devices
> [26.390] (==) Not automatically adding GPU devices
> [26.390] (==) Max clients allowed: 256, resource mask: 0x1f
> [26.394] (==) FontPath set to:
> /usr/X11R6/lib/X11/fonts/misc/,
> /usr/X11R6/lib/X11/fonts/TTF/,
> /usr/X11R6/lib/X11/fonts/OTF/,
> /usr/X11R6/lib/X11/fonts/Type1/,
> /usr/X11R6/lib/X11/fonts/100dpi/,
> /usr/X11R6/lib/X11/fonts/75dpi/
> [26.394] (==) ModulePath set to "/usr/X11R6/lib/modules"
> [26.394] (II) The server relies on wscons to provide the list of input 
> devices.
> If no devices become available, reconfigure wscons or disable 
> AutoAddDevices.
> [26.394] (II) Loader magic: 0xeed1a3f9000
> [26.394] (II) Module ABI versions:
> [26.394]X.Org ANSI C Emulation: 0.4
> [26.394]X.Org Video Driver: 24.1
> [26.394]X.Org XInput driver : 24.1
> [26.394]X.Org Server Extension : 10.0
> [26.395] (--) PCI:*(0@0:2:0) 8086:3ea5:8086:2074 rev 1, Mem @ 
> 0xc000/16777216, 0x8000/1073741824, I/O @ 0x4000/64
> [26.395] (II) LoadModule: "glx"
> [26.396] (II) Loading /usr/X11R6/lib/modules/extensions/libglx.so
> [26.405] (II) Module glx: vendor="X.Org Foundation"
> [26.405]compiled for 1.20.8, module version = 1.0.0
> [26.405]ABI class: X.Org Server Extension, version 10.0
> [26.405] (==) Matched modesetting as autoconfigured driver 0
> [26.405] (==) Assigned the driver to the xf86ConfigLayout
> [26.405] (II) LoadModule: "modesetting"
> [26.405] (II) Loading /usr/X11R6/lib/modules/drivers/modesetting_drv.so
> [26.406] (II) Module modesetting: vendor="X.Org Foundation"
> [26.406]compiled for 1.20.8, module version = 1.20.8
> [26.406]Module class: X.Org Video Driver
> [26.406]ABI class: X.Org Video Driver, version 24.1
> [26.406] (II) modesetting: Driver for Modesetti

Problems with clementine music player with 6.7

[Why 42? The lists account.]

Hi All,

My preferred music player application is (was) clementine. But with a 6.7
snapshot (GENERIC.MP#213 amd64) and clementine-1.4.0rc1p0 the application
seems to have problems opening files.

For example the file open dialog opens a blank dialog box and a series
of assertion failures/errors are reported (verbose mode) such as:
> (clementine:67859): Gtk-CRITICAL **: 18:23:29.544: Error building template 
> class 'GtkDialog' for an instance of type 'GtkDialog': .:2:367 Invalid object 
> type 'GtkHeaderBar'
> (clementine:67859): Gtk-CRITICAL **: 18:23:29.546: Error building template 
> class 'GtkFileChooserDialog' for an instance of type 'GtkFileChooserDialog': 
> Unknown internal child: vbox
> (clementine:67859): Gtk-CRITICAL **: 18:23:31.896: Error building template 
> class 'GtkTooltipWindow' for an instance of type 'GtkTooltipWindow': .:2:524 
> Invalid object type 'GtkImage'

Similarly, clementine cannot build up its music database. When I try to
set the location of the music files (Tools -> Preferences -> Music
Library) a similar set of errors is reported.

Dragging and dropping a music file from Thunar works fine, so there
doesn't seem to be a problem with filesystem access ...

I know next to nothing about GTK :-( ... any suggestions? I had no
issues using clementine with 6.6.

Are there alternative players that might work better?

Cheers,
Robb.

Re: rc.conf.local sorted?

[Why 42? The lists account.]

On Mon, May 25, 2020 at 04:51:51PM +0200, Antoine Jacoutot wrote:
> > ...
> > It looks as if the file has been sorted e.g.
> Did you use rcctl(8) ?

Hi Antoine,

You are correct, that does it. I checked the history and after the
upgrade I had run rcctl to enable sensorsd. Just tested it again and
running an rcctl enable or disable command causes all the lines of
/etc/rc.conf.local to be alphabetically sorted.

That seems like a defect to me, what do you think?

Thanks for the suggestion!

Cheers,
Robb.

6.7 feature: dt(4), a driver and framework for Dynamic Profiling ...

[Why 42? The lists account.]

Hi Again,

Couple of points regarding this new feature:
> Imported dt(4), a driver and framework for Dynamic Profiling, and an 
> accompanying bug tracer that speaks the dt(5) language.

What is this "bug tracer" executable called? So far I have been unable to
find it :(

Could it be that this is a reference to the DTrace project?

There is, I think, a typo in https://www.openbsd.org/plus67.html where
the same sentence refers to "bt(5)" i.e. "Bravo Tango":
> Imported dt(4), a driver and framework for Dynamic Profiling, and an 
> accompanying bug tracer that speaks the bt(5) language.

FYI, on my freshly sysupgraded 6.7 system there is a man page for "dt" in
section 4, but nothing is found for dt in 5 i.e.
> man: No entry for dt in section 5 of the manual.

(Also not for bt.)

Just FYI, in the Web page https://www.openbsd.org/67.html "dt(5)" is a
link to just "dt" which then takes the user back to the section 4 page.

Cheers,
Robb.

rc.conf.local sorted?

[Why 42? The lists account.]

Hi All,

After running sysupgrade to update from 6.6 (snapshot) to the newest
version I noticed that the comments I added to /etc/rc.conf.local no
longer made sense (if they ever did :)).

It looks as if the file has been sorted e.g.
> ...
> # Also increase the number of -b(uffer) frames so as to avoid "stutter" under 
> high CPU load. Default (7680) + 1024. See: man sndiod
> # Boot time messages:
> # For NFS
> # Prefer Postfix
> # So this should expose raw device "rsnd/1" the "Burr-Brown from TI USB Audio 
> CODEC" (aka "audio1" or "uaudio0") as subdevice: "cyrus"
> # Sound subsystem: sndiod
> # Tell syslog to write mark messages every 30 minutes
> # audio1 at uaudio0
> # uaudio0 at uhub3 port 1 configuration 1 interface 1 "Burr-Brown from TI USB 
> Audio CODEC" rev 1.10/1.00 addr 7
> # uaudio0: class v1, full-speed, sync, channels: 2 play, 2 rec, 3 ctls
> lockd_flags=
> mountd_flags=
> nfsd_flags=-n 7 -t
> pkg_scripts=messagebus postfix
> portmap_flags=
> sensorsd_flags=
> smtpd_flags=NO
> sndiod_flags="-b 8704 -f rsnd/1 -s cyrus"
> ...

Is this normal? It doesn't seem like something I would have been likely
to have done manually/accidentally.

Based on the file mtime it seems as if this happened at boot time, or
perhaps at the time of the first boot after the sysupgrade.

Strangely sysupgrade itself doesn't have much to say about what it
installed e.g. in messages log I just see:
> sysupgrade: installed new /bsd.upgrade. Old kernel version: OpenBSD 
> 6.6-current (GENERIC.MP) #55: Sun Mar 15 02:21:01 MDT 2020 
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Per uname I am currently running: 6.7 GENERIC.MP#213 amd64

Just wondering if this is the expected behaviour ...

Cheers,
Robb.

sysupgrade confused by additional disk?

[Why 42? The lists account.]

Hi All,

I use sysupgrade to update to new snapshot versions (of 6.6). Brilliant!

At some point I added a second (larger) disk to hold my user data (i.e.
home). It seems that this new disk took over the name sd0 and the OpenBSD
system disk itself became known as sd1.

The OpenBSD OS still boots and runs without issue, however this change
seems to have confused sysupgrade. After it downloads and reboots I now
get prompted to choose I)nstall, U)grade, etc. If I recall correctly,
this step used to run automatically without any intervention. Is that
right?

At this point I can choose the upgrade option and manually run through
the process, normally without issue (very helpful prompting/feedback e.g.
with the mount points!).

Still, it would be nice if this could be once again automatic ...

My first thought was I could fix the issue by using sysctl to reassign
the disk name to uuid mapping (i.e. the hw.disknames values) so that the
OS was once again on sd0. Unfortunately that didn't seem to work. Is it
the case that some of these sysctl/system variables are read-only or
cannot be set? Or maybe I did something incorrectly ... also not
impossible :)

Any other suggestions as to how to fix this?

Thinking some more about it, shouldn't sysupgrade just use those very
disk uuid values to identify its targets in the first place ... thus
avoiding the whole issue in the first place?

Thanks in advance for your feedback!

Just FYI: storage hardware configuration looks like this:
> nvme0 at pci1 dev 0 function 0 "Samsung SM981/PM981 NVMe" rev 0x00: msix, 
> NVMe 1.3
> nvme0: Samsung SSD 970 EVO Plus 500GB, firmware 1B2QEXM7, serial 
> S4EVNG0M109821X
> sd1 at scsibus2 targ 1 lun 0: 
> sd0 at scsibus1 targ 2 lun 0:  
> naa.5002538e4109632a

The NVMe device sd1 has all the OS partitions (/, /usr, etc), the SSD
device sd0 was added later to provide more space (too many photos :)).

Yours,
Robb.

Re: S3 Virge support on IBM T23 for 6.6

[lists]

Wed, 15 Apr 2020 23:26:44 +0200 Paolo Aglialoro 
> Thank you for the explanation, Otto.
> 
> Is this a hint that soon i386 architecture will be deprecated?

Hello Paolo,

Considering that it's worth reading the reply without misinterpreting anything,
it is here quoting this again:  "What other OS maintainers do is their choice".
Let's not invent reasons to claim if it does not work for you then nobody else.

Kind regards,
Anton Lazarov
MScEng EECSIT

> Considering that supported hw (at least graphics) is going more and more to
> overlap with amd64, at the very end i386 would remain only for some
> routerboards.
> 
> On Wed, Apr 15, 2020 at 8:14 PM Otto Moerbeek  wrote:
> 
> > On Wed, Apr 15, 2020 at 04:55:04PM +0200, Paolo Aglialoro wrote:
> >  
> > > Hello,
> > >
> > > I read from the 6.5 to 6.6 upgrade guide that the following files:
> > >
> > >
> > > */usr/X11R6/lib/modules/drivers/s3_drv.la 
> > > /usr/X11R6/lib/modules/drivers/s3_drv.so
> > > /usr/X11R6/lib/modules/drivers/s3virge_drv.la 
> > > /usr/X11R6/lib/modules/drivers/s3virge_drv.so/usr/X11R6/man/man4/s3.4
> > > /usr/X11R6/man/man4/s3virge.4*
> > >
> > > are being deleted as "retired". Does this mean that my IBM T23 will stop
> > > its X-life at 6.5 or is its S3 Virge video card supported in some other
> > > decent way (VESA or whatever)? I would be glad to know it *before* trying
> > > this upgrade.
> > >
> > > If the sad answer would be "no more support", could I ask why this,
> > > together with several i686 still working boxes, would be dropped while
> > > other OSs aren't doing so?
> > >
> > > Thanks  
> >
> >
> >
> > http://cvsweb.openbsd.org/xenocara/driver/Makefile?rev=1.74&content-type=text/x-cvsweb-markup
> >
> > explains it:
> >
> > "Unlink a number of old video drivers from the build.
> >
> > The corresponding hardware is out of date, barely useable
> > with modern systems and their code is not maintained.
> > ok sthen@"
> >
> > We have a very limited numnbers of volunteers. In general, code is a
> > liability, not an asset. What other OS maintainers do is their choice.
> >
> > -Otto
> >  

Re: [/ is full] How to delete junk in /dev ?

[Why 42? The lists account.]

On Sun, Apr 05, 2020 at 10:19:30AM +0200, Olivier wrote:
> 
> Please, how to identify junk to remove in /dev below :
> ...
> +---> doas find -x / -size +1 -exec du -h {} \; 
> 17.9M /bsd
> 9.8M  /bsd.rd
> 848K  /dev/sdXc
> 884M  /dev/sd3

I know you found it already, but this used to happen so often that I
learned to use "ls -l /dev | grep -v ," as a standard check whenever
someone complained about a lack of free space in the root fs.

.robb

Re: How to test for FORTIFY_SOURCE?

[lists]

Wed, 18 Mar 2020 11:55:53 -0400 Jeffrey Walton 
> On Wed, Mar 18, 2020 at 11:25 AM Andreas Kusalananda Kähäri
>  wrote:
> >
> > On Wed, Mar 18, 2020 at 10:59:21AM -0400, Jeffrey Walton wrote:  
> > > On Wed, Mar 18, 2020 at 4:26 AM Stuart Henderson  
> > > wrote:  
> > > >
> > > > On 2020-03-18, Jeffrey Walton  wrote:  
> > > > > According to 
> > > > > https://man.openbsd.org/NetBSD-8.1/security.7#FORTIFY_SOURCE
> > > > > OpenBSD implements glibc bounds checking on certain functions. I am
> > > > > trying to detect FORTIFY_SOURCE without looking up operating system
> > > > > names and versions.  
> > > >
> > > > That is a NetBSD manual page, it does not apply to OpenBSD.  
> > >
> > > Thanks.
> > >
> > > I may be splitting hairs, but the pages title clearly says it is an
> > > OpenBSD man page.  
> >
> > I have no real connection to the OpenBSD project other than being a long
> > time user, and I have an interest in documentation.
> >
> > It says, at the top of the page, it says "OpenBSD manual page server",
> > i.e. it's a manual page server hosted by the OpenBSD project.  The
> > link that you mention contains the string "NetBSD-8.1" and the name
> > of the manual that you're looking at is "security — NetBSD security
> > features".  Also, "NetBSD-8.1" is repeated in the page footer and the
> > string "NetBSD" occurs many times throughout the page while "OpenBSD"
> > really only occurs once.  
> 
> Hovering the mouse over the open tab says "security(7) - OpenBSD man
> pages". I double checked it when I saw the references to NetBSD.
> 
> Regarding the references to NetBSD, I thought your sed went sideways.
> I assumed OpenBSD and NetBSD were collaborating and shared code and
> docs in some places.
> 
> Figuring out why the sed was broken was not my task at hand. I was on
> the site to figure out why my test for FORTIFY_SOURCE was failing. The
> admins can figure that out why the document conversion is not working
> they notice it.
> 
> Jeff
> 

Hi Jeffrey,

I find the ability to check other manual pages so valuable.  People are aware
when they make a mistake, it's theirs for not checking what they are actually
looking at.  Instead of blaming the service available for confusing them like
it's so popular online these days.  The confusion is yours, just please don't
request service degradation for the rest of us because ot that.  These online
manual pages are useful, let's all keep our eyes open and honest about it ;-)

Kind regards,
Anton Lazarov
MScEng EECSIT

Re: Help: System hang/Lockup using snapshots on Intel i5 NUC?

[Why 42? The lists account.]

On Thu, Mar 05, 2020 at 11:45:30PM +0100, Why 42? wrote:
> ...
> When this happens the mouse is frozen, the capslock LED on the (USB)
> keyboard doesn't light up and the system doesn't respond to ssh. To
> recover I have to hold down the power switch to shutoff the system, then
> turn it on again, reboot and examine the resulting fsck errors.
> ...

Just to follow up, since sysupgrading to the latest snapshot (on 15.3) I
cannot reproduce this problem. (All packages were updated too.)

Also my tentative test case, which resulted in the same symptoms, also
now functions without issue (fyi: run "vblank_mode=0 glxgears" and drag
the resulting window around wildly being sure to get it to go into/out of
fullscreen by hitting the edge of the desktop).

So now  just have to decide if I continue using Firefox or revert back to
Iridium (or Chrome). Decisions, decisions ... :)

Any ideas what I can or should do about my "dubious" kernel messages?
E.g. "0:31:5: mem address conflict 0xfe01/0x1000"
What does that "0:31:5:" indicate?

Or the "not configured" messages like these for example:
> "Intel Core GMM" rev 0x00 at pci0 dev 8 function 0 not configured
> "Intel 300 Series Thermal" rev 0x30 at pci0 dev 18 function 0 not configured
> xhci0 at pci0 dev 20 function 0 "Intel 300 Series xHCI" rev 0x30: msi, xHCI 
> 1.10
> 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 300 Series Shared SRAM" rev 0x30 at pci0 dev 20 function 2 not 
> configured
> "Intel 300 Series MEI" rev 0x30 at pci0 dev 22 function 0 not configured
> ahci0 at pci0 dev 23 function 0 "Intel 300 Series AHCI" rev 0x30: msi, AHCI 
> 1.3.1
> ahci0: port 2: 6.0Gb/s
It seems as if that Intel 300 chip is only partially supported. Maybe
that's not a significant problem? Though I worry a bit about the
"Thermal" message ... suggesting some temperature sensing may not be
working correctly.

The other good news is that the new (old) keyboard is working well :-)
> uhidev0 at uhub2 port 4 configuration 1 interface 0 "Fujitsu Component Sun 
> USB Keyboard" rev 2.00/1.05 addr 4

Cheers,
Robb.

Help: System hang/Lockup using snapshots on Intel i5 NUC?

[Why 42? The lists account.]

Hi All,

We've been running OpenBSD on a server for several years now and its been
reliable with minimal issues, so I thought I would also like to try it as
a desktop system.

Thus I've been experimenting with an Intel NUC 8i5BEH running OpenBSD
current snapshots and with XFCE as the Windowing system. And it all works
very nicely. So well in fact that I've added an SSD, NFS mounted my old
Linux box and rsynced over my home directory. OpenBSD as my main desktop
system!

For the most part everything has gone well, I have only noticed one
serious issue so far: The complete system hangs intermittently. Which is
naturally a bit of a downer :(.

When this happens the mouse is frozen, the capslock LED on the (USB)
keyboard doesn't light up and the system doesn't respond to ssh. To
recover I have to hold down the power switch to shutoff the system, then
turn it on again, reboot and examine the resulting fsck errors.

I have impression this often occurs when using a Web browser. At first
when I used Iridium, then Chrome, it seemed to happen every few hours.
When I switched to trying Firefox, then the hangs seemed to occur less
often, maybe every day or two. Perhaps I'm doing less browsing because of
the hangs :).

The graphics driver being used is: inteldrm0 at pci0 dev 2 function 0
"Intel Iris Plus Graphics 655" rev 0x01

I can leave the system running, sitting at the xenodm screen, for days
without issue. I've also done a couple of complete memtest86 runs without
error. I've even upgraded to the latest BIOS/firmware version.

I've increased maxproc and maxfiles in sysctl.conf and also set
ddb.panic=0 thinking that the behaviour might change to a panic+reboot
instead of a hang, but this made no difference.

After a hang + reboot there is nothing obvious in the log files.

Any suggestions how to further debug such an issue?

The OpenBSD kernel tells me that there is a serial port / UART (com0 at
isa0 port 0x3f8/8 irq 4: ns16550 ...) but I've taken the NUC to pieces
and I cannot see anything on the board that looks like a serial port
header.

The kernel does log a few of dubious messages at boot time. There are
several instances of "not configured". And there is one occurrence of
"mem address conflict 0xfe01/0x1000". I don't know if these are
relevant, generally the system seems quite stable. Until it isn't. If you
see what I mean. (See below for a complete set of boot time messages).

I would be grateful for any support in debugging, or even better,
resolving this issue.

Cheers,
Robb.

mjoelnir:log 5.03 23:22:54 # dmesg
OpenBSD 6.6-current (GENERIC.MP) #20: Sat Feb 29 14:38:12 MST 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 34201518080 (32617MB)
avail mem = 33152389120 (31616MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.2 @ 0x7a9a4000 (77 entries)
bios0: vendor Intel Corp. version "BECFL357.86A.0077.2019.1127.1452" date 
11/27/2019
bios0: Intel(R) Client Systems NUC8i5BEH
acpi0 at bios0: ACPI 6.1
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT HPET SSDT SSDT UEFI LPIT 
SSDT SSDT DBGP DBG2 DMAR SSDT NHLT BGRT TPM2 WSMT
acpi0: wakeup devices SIO1(S3) 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) 
PXSX(S4) RP08(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz, 9182.89 MHz, 06-8e-0a
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,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
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) i5-8259U CPU @ 2.30GHz, 2194.90 MHz, 06-8e-0a
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,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, co

Re: Web documentation available offline by default?

[lists]

Fri, 28 Feb 2020 07:54:49 + Frank Beuth 
> On Fri, Feb 28, 2020 at 07:24:50AM +0100, Ingo Schwarze wrote:
> >Hi Frank,
> >
> >Frank Beuth wrote on Fri, Feb 28, 2020 at 04:22:27AM +:
> >  
> >> Is the web documentation (FAQ etc) included in the base system by
> >> default anywhere,  
> >
> >No it isn't.
> >
> >I offered some years ago to translate the FAQ from HTML to mdoc(7)
> >and to include it in /usr/share/man/faq/ such that it would become
> >available for both -current and -stable both online and offline
> >without additional maintenance effort just like any other documentation
> >and such that it would automatically be included in apropos(1)
> >searches, but the proposal was rejected because the developers who
> >actually maintain the content of the FAQ consider it easier to
> >maintain in HTML than in mdoc(7) format.
> >
> >We don't want to lose the valued contributions of those developers
> >who actually spend all the work maintaining the FAQ or make their
> >work any harder than it is now.  
> 
> Thanks. Too bad the mdoc idea failed!
> 

Hi Frank,

Maybe it just got deferred for the moment of more elegant (simplified) mandoc
markup frontend editing.  Editing HTML by hand is inconvenient + highly error
prone at the same time as shown in many iterations of missing closing tag and
other numerous errors hidden by the viewing pagers (error covering browsers).

Editing HTML by hand should be reserved for fine tuning and maintenance of an
export filter of a document specific authoring and editing convenient markup.

Using mandoc for the purpose of system and accompanying documentation is "the
best" current practice solution, it was designed for/in this specific domain.

Lightweight markup formats are an enabler for document authoring and editing,
as demonstrated by the largest online collaborative systems (encyclopaedias).

At the same time, lightweight markup can optionally contain semantic (mandoc)
markup and export cleanly to HTML, as mandoc can export to lightweight markup
and HTML and other preformated (typeset) document output formats.  An missing
at the time system has never been an impediment to outstanding, and excelling
work in the maintenance and preparation of the documentation as if it's here.

Kind regards,
Anton Lazarov
MScEng EECSIT

Re: 4GB RAM too little for Firefox?

[lists]

Fri, 5 Jul 2019 08:09:26 -0700 "Heppler, J. Scott"

> Richard Ulmer wrote:
> > Hi all,
> > after having Firefox running for some time (ca. 30min to 2h) my
> > system seems to become slow. I get frequent freezes for several
> > seconds, mpv instances start crashing and things like switching tabs
> > in Firefox become a pain.
> > 
> > I've got 4GB of RAM installed and when I look at htop after my system
> > became slow, I can see that OpenBSD started swapping. When I close
> > Firefox it takes several seconds and I can watch how my memory becomes
> > free again in htop. My system is then again responsive.
> > 
> > RAM prices seem to be low right now, but I don't want to spend money
> > uneedingly and I didn't have this problem under Linux. Has anyone had
> > similar experieces and noticed an improvement after a RAM upgrade?  
> 
> OpenBSD derives some security by confining processes and web browsing
> with firefox is notorious for memory leaks.
> 
> If you mobo supports it, more ram will also improve performance with
> firefox and other memory intensive tasks.
> 
> Other options:
> 
> Adding the Firefox "forget" widget to your panel
> https://support.mozilla.org/en-US/kb/forget-button-quickly-delete-your-browsing-history
> and using it frequently.
> 
> Under preference disable access to webcams, microphone etc.
> 
> Consider www/iridium as an alternative browser.  You can export your
> firefox bookmarks.html and import it into iridium.  Although I do not
> have solid numbers, I thought it was better in this regard than firefox.
> 

Since you did not attach a single digit, number or figure, as measures of
comparison, consider the above information opinion only and nothing more.
In fact, if you switch the names of the programs, you cannot even notice.
Try to be more specific, at least compare the memory usage: show numbers.
Such fine advice, wasted over the simplest lack of information objection.

Re: Future of X.org?

[lists]

Tue, 2 Jul 2019 10:31:21 -0700 John Brahy 
> Thanks for the Wikipedia link. I never researched sentence spacing before.

Of course, and to reward the patience of reading to the end of the noise:

Template: X Window System  https://en.wikipedia.org/wiki/Template:XWinSys

> On Tue, Jul 2, 2019 at 9:33 AM  wrote:
> 
> > Tue, 02 Jul 2019 12:09:01 +0300 cho...@jtan.com  
> > >
> > > Also you've got two spaces again.  
> >
> > Indeed..  https://en.wikipedia.org/wiki/Sentence_spacing#Computer_era
> >  

Re: Future of X.org?

[lists]

Tue, 02 Jul 2019 12:09:01 +0300 cho...@jtan.com
> li...@wrant.com writes:
> > Worthless thread, worthless comments, annoying Matthew..  STOP spamming.  
> 
> Well you're not wrong so there's no need to keep the public involved.

It's best discussed in public or not discussed at all, so list included.
Your usual intention to tease, is more useful towards instant messaging.

> Sorry I was just playing around. I've noticed your penchant for alignment and 
> felt the need to tease you a bit about it.
> 
> Also you've got two spaces again.

One novice.  https://en.wikipedia.org/wiki/Sentence_spacing#Computer_era

> 
> Matthew
> 
> ps. No ulterior motive; it was all in good fun and I'm sorry if I've been a 
> nuisance.
> 

I know, we've had enough fun already let's not waste more time and bits.
With that, I consider the thread completely exhausted beyond all points.

Re: Future of X.org?

[lists]

Tue, 02 Jul 2019 11:19:17 +0300 cho...@jtan.com
> 
> Matthew

Worthless thread, worthless comments, worthless Matthew.  STOP spamming.

Re: Future of X.org?

[lists]

Tue, 02 Jul 2019 08:40:35 +0300 cho...@jtan.com
>
> Also I don't need to fix your email system's inability to classify spam.

YOUR mail server reputation is negative, fix your setup..  STOP spamming.

> Matthew
> 

Re: Future of X.org?

[lists]

Mon, 1 Jul 2019 12:52:56 -0700 Michael Forney 
> On 2019-07-01, Roderick  wrote:
> > Namely, the only free implementation of EGL is Mesa 3D. And EGL is
> > needed by Wayland.  
> 
> I'm not an OpenBSD user, just an interested bystander, but I want to
> point out that the second part of this statement is false. Wayland
> also supports shared memory buffers. In fact, I'm writing this message
> from a Wayland desktop that has no GL whatsoever.
> 

Michael, since you are not an OpenBSD user..  please, tell us more about
this software that is not part of, and does not (yet) run on our OpenBSD
systems.  You can't really get us more interested in our graphics stack.
But please, use reddit to tell us more since we're not reading it there.

Re: Future of X.org?

[lists]

Mon, 01 Jul 2019 20:52:24 +0300 cho...@jtan.com
> li...@wrant.com writes:
> > Mon, 01 Jul 2019 07:09:41 +0300 cho...@jtan.com  
> > > 
> > > I don't think I'll be relying on software from such confused individuals 
> > > any time soo  
> > n.
> >
> > Since when?  Make a note: your long lines will never fit on a punch card.  
> 
> I haven't used a punch card since ... well ever. I have my limits but they're
> not 72.
> 
> Matthew

You're misreading something, or talking to yourself, making corrections.
Your emails ended up in the spam twice so far, do something about that..

> ps. Yes, I did that on purpose.
> 

You're not doing anything.

Re: Future of X.org?

[lists]

Mon, 1 Jul 2019 17:56:18 +0200 Juan Francisco Cantero Hurtado

> On Mon, Jul 01, 2019 at 06:39:01PM +0300, li...@wrant.com wrote:
> > Mon, 1 Jul 2019 17:13:44 +0200 Juan Francisco Cantero Hurtado
> >   
> > > On Mon, Jul 01, 2019 at 05:20:20PM +0300, li...@wrant.com wrote:  
> > > > Mon, 1 Jul 2019 00:46:33 +0200 Juan Francisco Cantero Hurtado
> > > > 
> > > > > On Sun, Jun 30, 2019 at 09:09:08PM +, Roderick wrote:
> > > > > > 
> > > > > > No. It is *you* that do not understand what X11 is and want it 
> > > > > > death.
> > > > > > A very destructive attitude.  
> > > > > 
> > > > > You're the only one with a destructive attitude here. I'm trying to 
> > > > > help
> > > > > you because usually people doesn't understand how wayland works.
> > > > 
> > > > You can't do without YOU understanding basics of X11, do something 
> > > > else..
> > > > Juan, I don't trust your lack of any qualification for even feature 
> > > > bait.
> > > 
> > > Show me where I am wrong. Enlighten us with your qualification No Name.
> > >   
> > 
> > Here you go wrong on all points..  Next time, bring 100% more experience.
> > 
> > Sat, 29 Jun 2019 20:45:14 +0200 Juan Francisco Cantero Hurtado
> >   
> > > 
> > > The missing parts are not so big but nobody is working on that.
> > > 
> > > I dont' know why people are so sad. X11 should have died long time ago.
> > >   
> > 
> > This is not exactly inspirational, neither convincing.  Try again later..
> > Juan, I still can not find one single piece of text where you were right.  
> 
> Can you show me what missing Wayland part is bigger than DRM+Mesa+LLVM?.
> 
> After the personal attack, I was hoping a more elaborated answer.
> 

All messages sent to you only through the list in public..

You can not see it:  you are wrong.  Now, cover your ears.

Re: Future of X.org?

[lists]

Mon, 1 Jul 2019 17:13:44 +0200 Juan Francisco Cantero Hurtado

> On Mon, Jul 01, 2019 at 05:20:20PM +0300, li...@wrant.com wrote:
> > Mon, 1 Jul 2019 00:46:33 +0200 Juan Francisco Cantero Hurtado
> >   
> > > On Sun, Jun 30, 2019 at 09:09:08PM +, Roderick wrote:  
> > > > 
> > > > On Sun, 30 Jun 2019, Juan Francisco Cantero Hurtado wrote:
> > > > 
> > > > > Nope, you misunderstood the text.
> > > > 
> > > > No. It is *you* that do not understand what X11 is and want it death.
> > > > A very destructive attitude.
> > > 
> > > You're the only one with a destructive attitude here. I'm trying to help
> > > you because usually people doesn't understand how wayland works.  
> > 
> > You can't do without YOU understanding basics of X11, do something else..
> > Juan, I don't trust your lack of any qualification for even feature bait.  
> 
> Show me where I am wrong. Enlighten us with your qualification No Name.
> 

Here you go wrong on all points..  Next time, bring 100% more experience.

Sat, 29 Jun 2019 20:45:14 +0200 Juan Francisco Cantero Hurtado

> 
> The missing parts are not so big but nobody is working on that.
> 
> I dont' know why people are so sad. X11 should have died long time ago.
> 

This is not exactly inspirational, neither convincing.  Try again later..
Juan, I still can not find one single piece of text where you were right.

Re: Future of X.org?

[lists]

Mon, 01 Jul 2019 07:09:41 +0300 cho...@jtan.com
> 
> I don't think I'll be relying on software from such confused individuals any 
> time soon.

Since when?  Make a note: your long lines will never fit on a punch card.

> Matthew
> 

Re: Future of X.org?

[lists]

Mon, 1 Jul 2019 02:22:02 +0300 Leonid Bobrov 
> I make a mistake by writting this mail, but:
> 
> X Window System is just a shit windowing system while Wayland is a simple,
> fast and secure display server protocol.
> (Well, almost simple, this XML dependance is overkill.)
> 
> You people protecting X make me doubt that OpenBSD aims security, I am
> agree with Linus Torvalds who called us monkeys.
> 

Yes, it's a mistake.  Normally, nothing interferes with addition of ports.
When and if this new protocol proves useful, consider switching just then.

Re: Future of X.org?

[lists]

Mon, 1 Jul 2019 00:46:33 +0200 Juan Francisco Cantero Hurtado

> On Sun, Jun 30, 2019 at 09:09:08PM +, Roderick wrote:
> > 
> > On Sun, 30 Jun 2019, Juan Francisco Cantero Hurtado wrote:
> >   
> > > Nope, you misunderstood the text.  
> > 
> > No. It is *you* that do not understand what X11 is and want it death.
> > A very destructive attitude.  
> 
> You're the only one with a destructive attitude here. I'm trying to help
> you because usually people doesn't understand how wayland works.

You can't do without YOU understanding basics of X11, do something else..
Juan, I don't trust your lack of any qualification for even feature bait.

Re: Installing OpenBSD on Supermicro A2SDi-4C-HLN4F

[lists]

Sun, 16 Jun 2019 05:23:36 +0200 ms 
> "It looks like at least the reengineering of the firmware
> 
> and the analysis of the code could increase the security, to avoid 
> security wholes"
>  ^^

Your clock is off.  Wrong time is a serious reliability & security flaw.
Before you look for the security problems in firmware, fix obvious ones.

Re: Installing OpenBSD on Supermicro A2SDi-4C-HLN4F

[lists]

Sat, 15 Jun 2019 23:52:18 +0200 ms 
> Now a day backdors are already on the silicon level (inside chips). They 
> are declared as debugging interfaces..

Must have happened around the time when school dropouts went to business.

> It looks like at least the reengineering of the frimware an it is 
> analyzing of the code could increase security wholes

Wonderful day for some misspelled general Failure statements.. is it not?

> I am curious if someone on this list had tried to do it and had achieved 
> helpfull results..

No, but if you need an English textbook, computers are not your strength.

Obviously you missed the topic of the thread and the hardware specifics..

Or at the least just try to say something OpenBSD related for any points.

Re: Security of OpenBSD

[lists]

Mon, 3 Jun 2019 22:32:16 + Josef Pospisil 
> Hey, thank you all for this mailing list.
> 
> I have a question regarding the security of OpebBSD.

See https://www.openbsd.org/security.html

Re: Good options for SAS HBA or SATA expansion cards?

[lists]

Thu, 11 Apr 2019 07:50:36 + John Long 
> [...]
> but they can be slow. They also have a card based on the Silicon Image
> SiI3114 chipset. I didn't find much info on this one except for Windows
> victims claiming it was great or sucked.

Hi John,

Don't get this.  I have a controller of this chipset on one mainboard and
found out it works very unreliable, generates errors on regular light use
and our driver for it in OpenBSD turned out to be stuck before its second
version as it is found in other operating kernels.  Skip or fix drivers..

Kind regards,
Anton Lazarov

> Can anybody recommend some good 2 or 4 port SATA (internal) expansion
> cards or a SAS HBA that works well with OpenBSD?
> 
> Thanks,
> 
> /jl
> 

Re: trackpad reversed scrolling broken on -current

[lists+misc]

On Mon, Mar 25, 2019 at 10:53:08PM +0100, Ulf Brosziewski wrote:
> You can make that permanent with an entry in wsconsctl.conf. However,
> please note that the "param" field is for debugging and development,
> there are no guarantees about its future.

Thanks yet again, Ulf.  For long term plans, please don't forget about
us backwards people ;)

You helped me a short while ago with different sensitivities between the
trackpoint/trackpad, and I've been using the specified xorg.conf with
much more enjoyment since then.

trackpad reversed scrolling broken on -current

[lists+misc]

Hello all -

On the latest snap of -current, my reversed trackpad scrolling seems to
have broken.  My xorg.conf is as follows:

Section "InputClass"
Identifier "ws pointer"
MatchIsPointer "true"
Option "AccelerationProfile" "2"
Option "AccelerationNumerator" "5"
Option "AccelerationDenominator" "2"
Option "AccelerationThreshold" "0"
EndSection

Section "InputClass"
Identifier "ws touchpad"
MatchIsTouchpad "true"
Option "AccelerationProfile" "2"
Option "AccelerationNumerator" "10"
Option "AccelerationDenominator" "9"
Option "AccelerationThreshold" "0"
Option "ZAxisMapping" "5 4"
EndSection

I saw on the "following -current" page that "Using a new kernel with
touchpads requires an updated version of ws(4). The touchpad input
driver generates new types of wscons events for scrolling.", which I
think could be related.  However, xev shows that the button events are
still 4 and 5 for Z axis scrolling.

dmesg as follows (Lenovo 5th gen X1):

OpenBSD 6.5-beta (GENERIC.MP) #830: Sun Mar 24 19:44:30 MDT 2019
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16908881920 (16125MB)
avail mem = 16386105344 (15627MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xbf0ed000 (62 entries)
bios0: vendor LENOVO version "N1MET52W(1.37)" date 02/14/2019
bios0: LENOVO 20HRCTO1WW
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP UEFI SSDT SSDT HPET APIC MCFG ECDT SSDT BOOT BATB SSDT 
SSDT SSDT WSMT SSDT SSDT DBGP DBG2 MSDM DMAR ASF! FPDT UEFI
acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) RP02(S4) 
RP04(S4) RP05(S4) RP06(S4) RP07(S4) RP08(S4) RP09(S4) RP10(S4) RP11(S4) 
RP12(S4) RP13(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-7500U CPU @ 2.70GHz, 2593.62 MHz, 06-8e-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,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,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
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-7500U CPU @ 2.70GHz, 2593.98 MHz, 06-8e-09
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,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf000, bus 0-127
acpiec0 at acpi0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (RP01)
acpiprt2 at acpi0: bus -1 (RP02)
acpiprt3 at acpi0: bus 4 (RP03)
acpiprt4 at acpi0: bus -1 (RP04)
acpiprt5 at acpi0: bus 5 (RP05)
acpiprt6 at acpi0: bus -1 (RP06)
acpiprt7 at acpi0: bus -1 (RP07)
acpiprt8 at acpi0: bus -1 (RP08)
acpiprt9 at acpi0: bus -1 (RP09)
acpiprt10 at acpi0: bus -1 (RP10)
acpiprt11 at acpi0: bus -1 (RP11)
acpiprt12 at acpi0: bus -1 (RP12)
acpiprt13 at acpi0: bus -1 (RP13)
acpiprt14 at acpi0: bus -1 (RP14)
acpiprt15 at acpi0: bus -1 (RP15)
acpiprt16 at acpi0: bus -1 (RP16)
acpiprt17 at acpi0: bus -1 (RP17)
acpiprt18 at acpi0: bus -1 (RP18)
acpiprt19 at acpi0: bus -1 (RP19)
acpiprt20 at acpi0: bus -1 (RP20)
acpiprt21 at acpi0: bus -1 (RP21)
acpiprt22 at acpi0: bus -1 (RP22)
acpiprt23 at acpi0: bus -1 (RP23)
acpiprt24 at acpi0: bus -1 (RP24)
acpicpu0 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpipwrres0 at acpi0: PUBS, resource for XHC_
acpipwrres1 at acpi0: WRST
acpipwrres2 at acpi0: WRST
acpitz0 at acpi0: critical temperature is 128 degC
acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x
acpithinkpad0 at acpi0
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT0 model "01AV494" serial  2264 type LiP oem "LGC"
acpicmos0 at acpi0
"ALPS" at acpi0 not configured
"INT0E0C" at acpi0 not configured
acpibt