Re: error when pkg_add'ing

[Stuart Henderson]

On 2023-06-24, Pau A.S.  wrote:
> I recently reported what I thought it was a FS corruption because the
> system (-current) was crashing when I was setting a picture or movie on
> full screen. For some reason, the fix is to use xcompmgr in .xsession.

I think you have multiple issues here.

> No pkgname in packing-list for uchardet-0.0.8
> No pkgname in packing-list for grilo-0.3.16
> No pkgname in packing-list for liboauth-1.0.3
> quirks-6.133->6.133: ok
> Can't install python-3.10.12 because of libraries
>|library util.17.0 not found
>| /usr/lib/libutil.so.16.0 (system): bad major

This is "base is too old for the packages you're trying to use".
Running -current, you need to keep on top of updates to both base
and packages, and occasionally there will be times where things
aren't working because something in base has been updated but
there's no new package set available yet (not the case here).

> 75%/usr/local/share/glib-2.0/schemas/org.gnome.totem.enums.xml:1:1  Error
> on line 1 char 1: Document must begin with an element (e.g. ).  This
> entire file has been ignored.
> /usr/local/share/glib-2.0/schemas/org.gnome.online-accounts.gschema.xml:1:1
>  Error on line 1 char 1: Document must begin with an element (e.g.
>).  This entire file has been ignored.

That file seems corrupt

> There seems to be some corruption in that file:
>
> -
> # cat /usr/local/share/applications/org.gnome.Adwaita1.Demo.desktop
> �   recode.mo�WebKitGTK-4.1.mo�eog.mo�vlc.mo
> gimp30-libgimp.mo
> xfce4-panel.mo
> �#

yes that's definitely corrupt

> I have been seeing a lot of crashes of other programs.
[...]
> OpenBSD 7.3-current (GENERIC.MP) #1246: Fri Jun 16 23:57:46 MDT 2023
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
[...]
> cpu0: 12th Gen Intel(R) Core(TM) i7-1255U, 1615.02 MHz, 06-9a-04
> 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,SMX,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,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,PKU,WAITPKG,PKS,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES

This cpu has IBT in the features line. A diff is being tested in
some snapshots to enable this (it's a control-flow protection feature
in the cpu). Some software is not yet compatible with this and the
relevant ports need to be updated to either patch them to make them
compatible, or disable enforcement of control-flow protection when the
binaries from that port are run. Typically you will see "Illegal
instruction" messages in that case.

> What I did then was to copy the contents of /local/usr somewhere else, I
> ran newfs on it by booting as a single user and restored the contents. This
> didn't fix the error, so it is not a FS problem.

err, if the filesystem is corrupt, copying the (already corrupt)
contents elsewhere, and copying them back again, isn't going
to fix things.

> acpicpu11 at acpi0: C3(200@1048 mwait.1@0x60), C2(350@127 mwait.1@0x21),
> C1(1000@1 mwait.1), PSS
> acpicpu12 at acpi0: no cpu matching ACPI ID 12
> acpicpu13 at acpi0: no cpu matching ACPI ID 13
...
> acpicpu62 at acpi0: no cpu matching ACPI ID 62
> acpicpu63 at acpi0: no cpu matching ACPI ID 63

that's "interesting" :)



-- 
Please keep replies on the mailing list.

Re: Weird pf NAT failure on apu2

[Ashlen]

On Sat, 24 Jun 2023 07:33 -0600, Zack Newman wrote:
> On 6/2l/23 9:01, Stephan Neuhaus wrote:
> > I'm not sure about the Configuring NAT section being
> > correct. I still maintain that the documentation and
> > observed behaviour are different.
> 
> I was lazy when I said that. I meant the example I quoted from that
> section in the original reply is correct. Everything else that says
> otherwise (including the two people that said that part was wrong) is
> incorrect. Explicitly the following rule _is_ correct:
> 
> match out on interface [af] \
> from src_addr to dst_addr \
> nat-to ext_addr [pool_type] [static-port]
> [...]
> pass out [log] on interface [af] [proto protocol] \
> from ext_addr [port src_port] \
> to dst_addr [port dst_port]
> 
> There is only so many ways that this can be shown. If the pass out rule
> had "src_addr" instead of "ext_addr", it would be wrong. The diff that
> "fixes" that example needs to be rejected. It is the _other_ example
> that is wrong.
> 
> If you tried using the above example to get NAT to work, you will find
> that it will work. The last e-mail I sent clearly follows the above
> example except I chose to use stateless rules to help show more
> thoroughly all the rules that are necessary. Additionally, I prefer
> "quick" rules; but the conclusion is very clear: the match out rule
> applies and "sticks" which in turn means "src_addr" is replaced with
> "ext_addr" which in turn means the pass out rule must have "ext_addr".
> 

I forgot about that diff until I read your mail today. You're right,
I just tested that and your logic is sound. This is a good reminder
to me to test before sending diffs. I'm glad it wasn't committed.
Thank you for investigating that.

Re: mp-safe tun

[Claudio Jeker]

On Mon, Jun 26, 2023 at 03:21:26PM +, Valdrin MUJA wrote:
> Hello OpenBSD,
> 
> I've been thinking about this since OpenBSD devs do a lot of mp-safe on the 
> network stack:
> Is it possible to make /dev/tun device mp-safe/Multi-queue?

It is rather complicated to do mainly because a large part of the vnode
subsystem needs to be save enough to run without the kernel lock.
I tired it and while it kind of works it may also be kind of too
optimistic.

-- 
:wq Claudio

mp-safe tun

[Valdrin MUJA]

Hello OpenBSD,

I've been thinking about this since OpenBSD devs do a lot of mp-safe on the 
network stack:
Is it possible to make /dev/tun device mp-safe/Multi-queue?
Thanks for reading.