Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
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
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=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
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 ...
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 ...
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
Post (snap) update emails: fsck errors and (in)security output
... 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?
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
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: ...
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: ...
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: ...
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: After update, vim reports undefined symbols in libruby32.so
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=168663240314909=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
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" ...
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"?
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"?
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
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=164942119618029=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
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 ...
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
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"?
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"?
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"?
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"?
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.
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
unwind problems e.g. validation failure ... while building chain of trust
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
pkg_add python errors ...
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
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: Q: dmesg: dt: 443 probes
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
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
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
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 ...
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 ?
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 ?
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.
Re: sysupgrade with latest snapshot: The directory '/home/_sysupgrade/' does not exist.
> ... > > 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.
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.
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.
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.
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?
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?
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?
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
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: iXorg / xenodm logs fill with errors: "_XSERVTransSocketUNIXAccept: accept() failed"
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=155787066627780=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"
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
Re: Suggestions re error: "USB read failed" accessing Infinite Noise TRNG?
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?
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
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?
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
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'
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
Problems with clementine music player with 6.7
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?
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 ...
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?
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?
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: [/ is full] How to delete junk in /dev ?
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: Help: System hang/Lockup using snapshots on Intel i5 NUC?
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?
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,
Re: alix 2d13 + 6.4: should it work?
On Wed, Nov 21, 2018 at 05:37:05PM -0700, Theo de Raadt wrote:
> First time you need to
>
> stty com0
> set tty com0
>
> then you can boot.
>
> The installer will remember this for next time, but our kernel does not
> know the speed so early on.
That was it! Excellent:
boot> stty com0 38400
boot> set tty com0
switching console to com0
Kernel boot now looks like this:
cannot open hd0a:/etc/random.seed: No such file or directory
booting hd0a:/6.4/i386/bsd.rd: 3111423+1360896+3362824+0+454656
[363995+98+289392+283301]=0x8ced6c
entry point at 0x2000d4
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2018 OpenBSD. All rights reserved. https://www.OpenBSD.org
OpenBSD 6.4 (RAMDISK_CD) #916: Thu Oct 11 14:00:12 MDT 2018
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD
real mem = 267976704 (255MB)
avail mem = 254033920 (242MB)
mainbus0 at root
bios0 at mainbus0: date 01/15/14, BIOS32 rev. 0 @ 0xfd0e4
pcibios0 at bios0: rev 2.1 @ 0xf/0x1
pcibios0: pcibios_get_intr_routing - function not supported
pcibios0: PCI IRQ Routing information unavailable.
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xe/0xa800
cpu0 at mainbus0: (uniprocessor)
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 499
MHz, 05-0a-02
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
...
Some time later:
CONGRATULATIONS! Your OpenBSD install has been successfully completed!
Thanks Theo for the tip and for all the work!
Cheers,
Robb.
alix 2d13 + 6.4: should it work?
Quick question, should the PC Engines ALIX 2D13 work with 6.4? Or is the hardware too old? Or (perhaps more likely :-)) did I screw up the installation process somehow? I created an install media (cf card) and boot functions but as the kernel is loading, the system reboots: PC Engines ALIX.2 v0.99m 640 KB Base Memory 261120 KB Extended Memory Waiting for HDD ... 01F0 Master 044A CF 8GB Phys C/H/S 15538/16/63 Log C/H/S 974/255/63 LBA Using drive 0, partition 3. Loading... probing: pc0 com0 com1 mem[640K 255M a20=on] disk: hd0+ >> OpenBSD/i386 BOOT 3.34 boot> cannot open hd0a:/etc/random.seed: No such file or directory booting hd0a:/6.4/i386/bsd.rd: 3111423+1360896+3362824+0+454656 [363995+98+289392+283301]=0x8ced6c entry point at 0x2000d4 PC Engines ALIX.2 v0.99m 640 KB Base Memory 261120 KB Extended Memory Waiting for HDD ... I did: fetch https://cdn.openbsd.org/pub/OpenBSD/6.4/i386/install64.fs dd if=/dev/random of=/dev/rsdd bs=512 count=256 iflag=fullblock sync ; sync ; sync dd if=/home/robb/Downloads/install64.fs of=/dev/rsdd bs=1M sync ; sync ; sync udisksctl power-off -b /dev/sdd The same hardware was previously running OpenBSD (5.6 I think) quite happily. Cheers, Robb.
Re: NAT reliability in light of recent checksum changes
FWIW, you don't have to out in the sticks (the backwoods?) to have a network problem: http://mina.naguib.ca/blog/2012/10/22/the-little-ssh-that-sometimes-couldnt.html However, as I understand it, in this case the TCP checksumming worked and protected the application from the corrupted data. Cheers, Robb.
Novena open computing platform + openbsd?
Hi All, Saw this and found it very interesting: http://www.kosagi.com/w/index.php?title=Novena_Main_Page In summary the intention is to create an open laptop computer e.g. - All the components should have a reasonably complete set of NDA-free documentation. - No binary blobs should be required to boot and operate the system for the scenarios I care about (This one is a bit tricky). - The machine must be able to build its own firmware from source. - The physical design should be accessible. - The machine must be useful as a hardware and security hacking platform. See also: http://www.bunniestudios.com/ (Bunny is Andrew Huang - one of the primary project members.) The hardware spec. lists a Freescale iMX6 CPU, the system is currently booting a Linux kernel. How feasible would it be to get OpenBSD on this platform? What would be involved it getting a (complete) OpenBSD system implemented? (Searching didn't show me any previous discussion of novena + openbsd.) Cheers, Robb.
Re: Recommended new laptop under US$800 for OpenBSD
But returning, if possible, to the original question ... On Thu Oct 4 19:23:41 2012, Tito Mari Francis Escaño wrote: I'd like to seek your advise what new laptop brand and model should I buy that is fully functional (video, LAN, Wifi, sound) with OpenBSD 5.x. ... I have also been considering exactly this issue. Currently I'm using an elderly Thinkpad R61 with Fedora (Nvidia hardware) and XFCE. Frankly I'm starting to get a bit cheesed of with the seemingly ever increasing complexity or cruft of Linux and have been wondering what to do next. Also that R61 seems to be getting heavier and heavier :-) Well I don't fancy Windows. And while Macbook hardware looks both light and attractive, I'm not convinced that I'd really be any better off ... Can it be that there is really no good current solution using OpenBSD? Some Internet searching indicated that there are people using OpenBSD on laptops (including Apple laptop hardware?) but I also see a lot of issues mentioned e.g. in the areas of suspend/resume, wireless networking and power management. At least some of this info. maybe dated or simply cargo. I know I talked to Theo once at EuroBSDcon (2011? - Karlsruhe anyway) and I got the impression that a lot of work was going on then to improve acpi support. Does that continue to be the case? I guess I'm really asking if laptop platform support is a goal for OpenBSD? Would it be possible/feasible to sponsor the development of the necessary features/fixes in some way? My day to day requirements are quite basic: a lightweight, fast system, offering the standard Unix toolset and providing solid networking support (wired + wireless) together with good battery life (e.g. 4 or 5 hours). On top I typically use mutt, curl, ssh, screen/tmux, firefox, evince, libreoffice, etc. A windowing system desktop is necessary, but XFCE is fine for me - GNOME has gone a step too far (imho). Actually what might be ideal would be the new Google/Samsung Chromebook but with the ChromeOS replaced by OpenBSD - cheap too at ~200 UK Pounds. Comments? Yours, Robb. I keep six honest serving-men (They taught me all I knew); Their names are What and Why and When And How and Where and Who. Rudyard Kipling in his Just So Stories
