OpenSMTP - Wrong user for Dovecot LMTP
Hi, I just upgraded to 6.8 and the upgrade process has been super cool and simple :) Unfortunately I seem to have hit some weird issue in OpenSMTPD where it has stopped delivering the mail using Dovecots LMTP due to sending as wrong user. osmtpd tries to send the mail as *_smtpd* even when configured to send as a different user *excision* Relevant parts of the error output from the command smtpd -dv -T stat -T lookup -T expand -T mproc -T rules debug: mda: got message fd 21 for session 27dfd8470fcf834f evpid 1140e2ecd415316b debug: mda: querying mda fd for session 27dfd8470fcf834f evpid 1140e2ecd415316b mproc: pony -> parent : 6168 IMSG_MDA_FORK debug: smtpd: forking mda for session 27dfd8470fcf834f: excision as _smtpd mproc: parent -> pony : 8 IMSG_MDA_FORK debug: mda: got mda fd 22 for session 27dfd8470fcf834f evpid 1140e2ecd415316b debug: smtpd: mda process done for session 27dfd8470fcf834f: exited abnormally debug: mda: io disconnected on session 27dfd8470fcf834f mproc: parent -> pony : 35 IMSG_MDA_DONE mproc: pony -> queue : 53 IMSG_MDA_DELIVERY_TEMPFAIL 27dfd846f9575079 mda delivery evpid=1140e2ecd415316b from= to= rcpt= use r=excision delay=2h10m40s result=TempFail stat=Error (temporary failure: "mail.lmtp: connect: Permission denied") debug: mda: session 27dfd8470fcf834f done mproc: pony -> control : 46 IMSG_STAT_DECREMENT debug: mda: user "excision" becomes runnable mproc: pony -> control : 45 IMSG_STAT_DECREMENT debug: mda: all done for user ":excision" mproc: pony -> control : 42 IMSG_STAT_DECREMENT mproc: queue -> control : 57 IMSG_STAT_INCREMENT ramstat: decrement: mda.envelope ramstat: mda.envelope (0xe29944762c1): 1 -> 0 ramstat: decrement: mda.running ramstat: mda.running (0xe29d4a91c41): 1 -> 0 ramstat: decrement: mda.user ramstat: mda.user (0xe298f729481): 1 -> 0 mproc: queue -> control : 59 IMSG_STAT_INCREMENT mproc: queue -> scheduler : 441 IMSG_QUEUE_DELIVERY_TEMPFAIL ramstat: increment: queue.evpcache.load.hit mproc: scheduler -> control : 61 IMSG_STAT_INCREMENT ramstat: queue.evpcache.load.hit (0xe2a74f72f81): 111 -> 112 mproc: scheduler -> control : 61 IMSG_STAT_DECREMENT ramstat: increment: queue.evpcache.update.hit ramstat: queue.evpcache.update.hit (0xe29d4a91c41): 52 -> 53 ramstat: increment: scheduler.delivery.tempfail ramstat: scheduler.delivery.tempfail (0xe2a74f72981): 45 -> 46 ramstat: decrement: scheduler.envelope.inflight ramstat: scheduler.envelope.inflight (0xe2a74f72281): 1 -> 0 mproc: pony -> lka : 28 IMSG_GETNAMEINFO mproc: pony -> control : 46 IMSG_STAT_INCREMENT This is happening as the lmtp socket only has minimal permissions srw-rw 1 excision excision 0B Oct 18 20:03 lmtp= Relevant parts of my smtpd.conf ... action "dovecot-lmtp" \ lmtp "/var/dovecot/lmtp" rcpt-to \ virtual ... # # accept mail from outside sent to our # BUT not those who are coming for key-submission match from any \ for domain \ !rcpt-to \ action "dovecot-lmtp" ... Relevant parts of my virtuals table ai...@aisha.cc excision ... open...@aisha.ccai...@aisha.cc ... I've also attached the full files if needed and a larger log as well. It's possible I've made some error, but then it was working until yesterday. Current workaround: chmod 666 /var/dovecot/lmtp to allow _smtpd user to also write to the socket. Very insecure, I know... Hopefully, it is just me making a stupid error in the config :x Thanks, Aisha ai...@aisha.cc excision postmas...@aisha.cc ai...@aisha.cc ab...@aisha.cc ai...@aisha.cc n...@aisha.cc ai...@aisha.cc secur...@aisha.cc ai...@aisha.cc hostmas...@aisha.cc ai...@aisha.cc use...@aisha.cc ai...@aisha.cc n...@aisha.cc ai...@aisha.cc webmas...@aisha.cc ai...@aisha.cc dmarcrepo...@aisha.cc ai...@aisha.cc tlsrepo...@aisha.cc ai...@aisha.cc ansim...@aisha.cc ai...@aisha.cc gen...@aisha.cc ai...@aisha.cc open...@aisha.ccai...@aisha.cc n...@aisha.cc ai...@aisha.cc faceb...@aisha.cc ai...@aisha.cc enigm...@aisha.cc ai...@aisha.cc testu...@aisha.cc ai...@aisha.cc e...@aisha.cc ai...@aisha.cc st...@aisha.cc ai...@aisha.cc git...@aisha.cc ai...@aisha.cc n...@aisha.cc ai...@aisha.cc m...@aisha.cc ai...@aisha.cc freen...@aisha.cc ai...@aisha.cc r...@aisha.cc ai...@aisha.cc lez...@aisha.cc
Re: OpenSMTP - Wrong user for Dovecot LMTP
On Sun, Oct 18, 2020 at 08:55:16PM -0400, Aisha Tammy wrote: > Hi, > > I just upgraded to 6.8 and the upgrade process has been super cool and > simple :) > > Unfortunately I seem to have hit some weird issue in OpenSMTPD where it has > stopped > delivering the mail using Dovecots LMTP due to sending as wrong user. > > osmtpd tries to send the mail as *_smtpd* even when configured to send as a > different user *excision* Could it be this change: https://marc.info/?t=15878902902=1=2 ?
Multiple USB NICs
If I have multiple USB Ethernet adapters of identical make and model, how does OpenBSD distinguish them over time. In other words if there's a reboot or the adapters get unplugged and moved around and plugged back in, is there a way to make sure that the adapters associated with axen0 and axen1 maintain those associations? Is there some way to pin an interface to the adapters MAC address? A related question: if the adapters never move, and always stay in the same place on their respective USB hubs, will they always be numbered the same (axen0, axen1, etc)?
Re: Sending Mail to misc
> On Oct 18, 2020, at 2:47 PM, Jeffrey Joshua Rollin > wrote: > > Hi, > > I’m able to send mail from my iPad (sorry), but not from my OpenBSD machine > (same address). Any ideas what could be causing this? > > In the meantime, thanks for 6.8 and happy anniversary. > > Jeff Hi, I sent two messages to misc yesterday from Thunderbird on Ubuntu Linux 20.04 LTS and they also did not make it to the list. Perhaps there is an issue on the mail server side ? Thanks, - J
Questions about syncookie and synproxy
Hello, I have a question about pf regarding syncookie and synproxy. On OpenBSD 6.7, man 5 pf.conf states the following under OPTIONS: set syncookie never | always | adaptive . . . When syncookies are active, pf will answer each and every incoming TCP SYN with a syncookie SYNACK, without allocating any resources. Upon reception of the client's ACK in response to the syncookie SYNACK, pf will evaluate the ruleset and create state if the ruleset permits it, complete the three way handshake with the target host, and continue the connection with synproxy in place. Does this mean that: ** Syncookies are used to prevent the state table from being exhausted, while synproxy is used to prevent the TCP/IP stack resources from being exhausted ? ** Syncookies may be used in addition to synproxy ? ** Both are used to protect against resource exhaustion in TCP SYN floods ? Thanks, - J
Re: Understanding download speed reduction by introducing an inline Ubiquity ERL device
On Mon, Oct 5, 2020 at 1:08 AM Stuart Henderson wrote: > > On 2020-10-04, Amarendra Godbole wrote: > > 1. config #1: MacBook - Linksys WRT1200AC - xfinity cable modem > > (speed: ~210 Mbits/s down, 6 Mbits/s up) > > 2. config #2: MacBook - Linksys WRT1200AC - Ubiquiti ERL - xfinity > > cable modem (speed: ~90 MBits down, 6 Mbits/s up) > > 3. config #3 (Line speed): MacBook wired to cable modem (~230 Mbits/s > > down, ~8 Mbits/s up). > > > cnmac0 1600a8:28:dc:cc:2e:6f 56088774 0 22283491 2688 > > 0 > > cnmac1 160078:8a:20:46:a8:c1 23646497 4 5656985348 > > 0 > > cnmac2 160078:8a:20:46:a8:c214823 0 226198 226198 > >0 > > bridge0 1500 23187238 0 57022219 0 > > 0 > > Since "netlivelocks" is increasing, network performance will be impacted. > > Is it any better if you don't use bridge/vether, just use the cnmac interface > directly? > > Is it any better with a snapshot? (at present these haven't gone past > 6.8 yet so you can still upgrade easily from there to release - just check > to make sure it says "6.8" not "6.8-current" in the version number) [...] Upgraded to 6.8-release today, but no go. The download speed remains at ~125 Mbits/s. On that note, someone on /r/openbsd said he was able to squeeze ERL to do 300 Mbits/s by tweaking some buffers. Unfortunately, he doesn't have immediate access to the ERL, but has promised an update in a few months when covid restrictions are lifted so he can travel. I will update this thread once I hear back from him. Also, I have presently swapped the ERL for apu2e4, which comfortably matches my line-speed. I upgraded it to 6.8-release today, and posted the dmesg to misc@ in case anyone is interested. Thanks. -Amarendra
dmesg for 6.8-release on apu2e4 4GB (amd64)
The apu2e4 acts as a home router/firewall for a Comcast Xfinity 200 Mbits/s down cable connection. Quick observations: - sysupgrade worked flawlessly. For unbound.conf it notified of a manual merge, and kept the installed file unaltered. I did not require manual sysmerge. - additional x*.tgz packages were installed by sysupgrade, though in the previous configuration I had explicitly deselected these. Maybe a bug or my incompetence, I need to figure this out. Thanks to the entire OpenBSD team for yet another awesome release! :-) -Amarendra dmesg: 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 real mem = 4259880960 (4062MB) avail mem = 4115738624 (3925MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xcfe8b040 (13 entries) bios0: vendor coreboot version "v4.12.0.5" date 09/25/2020 bios0: PC Engines apu2 acpi0 at bios0: ACPI 6.0 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP SSDT MCFG TPM2 APIC HEST SSDT SSDT DRTM HPET acpi0: wakeup devices PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PBR8(S4) UOH1(S3) UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) UOH6(S3) XHC0(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-64 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD GX-412TC SOC, 998.27 MHz, 16-30-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD GX-412TC SOC, 998.13 MHz, 16-30-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD GX-412TC SOC, 998.13 MHz, 16-30-01 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu2: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu2: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu2: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD GX-412TC SOC, 998.33 MHz, 16-30-01 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu3: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu3: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu3: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins ioapic1 at mainbus0: apid 5 pa 0xfec2, version 21, 32 pins acpihpet0 at acpi0: 14318180 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PBR4) acpiprt2 at acpi0: bus 1 (PBR5) acpiprt3 at acpi0: bus 2 (PBR6) acpiprt4 at acpi0: bus 3 (PBR7) acpiprt5 at acpi0: bus -1 (PBR8) acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 amdgpio0 at acpi0 GPIO uid 0 addr 0xfed81500/0x300 irq 7, 184 pins "PRP0001" at acpi0 not configured "PRP0001" at acpi0 not configured "PRP0001" at acpi0 not configured "PRP0001" at acpi0 not configured "PRP0001" at acpi0 not
Re: Sending Mail to misc
it can be a usr error so maybe check /usr/dev/bull/ Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Sunday, 18 October 2020 21:38, Jeff Joshua Rollin wrote: > On Sun, 2020-10-18 at 15:00 -0400, J Doe wrote: > > > > On Oct 18, 2020, at 2:47 PM, Jeffrey Joshua Rollin < > > > j...@jeffjoshua.club> wrote: > > > Hi, > > > I’m able to send mail from my iPad (sorry), but not from my OpenBSD > > > machine (same address). Any ideas what could be causing this? > > > In the meantime, thanks for 6.8 and happy anniversary. > > > Jeff > > > > Hi, > > I sent two messages to misc yesterday from Thunderbird on Ubuntu > > Linux 20.04 LTS and they also did not make it to the list. Perhaps > > there is an issue on the mail server side ? > > Thanks, > > > > - J > > Well, I can't speak for your problem yesterday but if this message > makes it then the problem was clearly on my side. Something was wrong > with my smtp server settings but when I deleted my accounts and > recreated them in Evolution, I was able to send a message to someone > else. Maybe you could check your Ubuntu settings just in case you've > done the same. > > Apologies to all as I should have checked this before sending anything. > > Jeff.
Re: dmesg for 6.8-release on Pine A64+ 1GB (Arm64)
maybe no need to ruin the 6.8 release with a mention of linux,"other unfinished broken operating systems" might be better as a reference point? :) Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Sunday, 18 October 2020 18:02, stolen data wrote: > 6.8 seems to work OK on the Arm64 Pine A64+ with 1GB RAM. > > Some observations: > > OpenBSD sees 896MB of RAM and makes only 838MB available. When running > Debian Linux on the exact same board the available RAM after boot is > 994MB, a difference of more than 150MB. Perhaps this can be improved by > tuning the DTB. > > A contrived test of network performance, using httpd(8) to serve a > large file from an mfs ramdisk over plain http, yields about 175 mbit/s > sustained transfer speed. I was not expecting to reach even 100 mbit/s > so this was a positive surprise, even if it's nowhere near the full > gigabit that other OSes can squeeze out of this board. > > = > > OpenBSD 6.8 (GENERIC.MP) #828: Sun Oct 4 20:35:47 MDT 2020 > dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP > real mem = 940503040 (896MB) > avail mem = 879267840 (838MB) > random: good seed from bootblocks > mainbus0 at root: Pine64+ > psci0 at mainbus0: PSCI 1.1, SMCCC 1.2 > cpu0 at mainbus0 mpidr 0: ARM Cortex-A53 r0p4 > cpu0: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache > cpu0: 512KB 64b/line 16-way L2 cache > cpu1 at mainbus0 mpidr 1: ARM Cortex-A53 r0p4 > cpu1: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache > cpu1: 512KB 64b/line 16-way L2 cache > cpu2 at mainbus0 mpidr 2: ARM Cortex-A53 r0p4 > cpu2: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache > cpu2: 512KB 64b/line 16-way L2 cache > cpu3 at mainbus0 mpidr 3: ARM Cortex-A53 r0p4 > cpu3: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache > cpu3: 512KB 64b/line 16-way L2 cache > efi0 at mainbus0: UEFI 2.8 > efi0: Das U-Boot rev 0x20200700 > apm0 at mainbus0 > "display-engine" at mainbus0 not configured > "osc24M_clk" at mainbus0 not configured > "osc32k_clk" at mainbus0 not configured > "internal-osc-clk" at mainbus0 not configured > simpleaudio0 at mainbus0 > "spdif-out" at mainbus0 not configured > agtimer0 at mainbus0: tick rate 24000 KHz > simplebus0 at mainbus0: "soc" > sxisyscon0 at simplebus0 > sxisid0 at simplebus0 > sxiccmu0 at simplebus0 > sxipio0 at simplebus0: 103 pins > ampintc0 at simplebus0 nirq 224, ncpu 4 ipi: 0, 1: "interrupt-controller" > sxirtc0 at simplebus0 > sxiccmu1 at simplebus0 > sxipio1 at simplebus0: 13 pins > sxirsb0 at simplebus0 > axppmic0 at sxirsb0 addr 0x3a3: AXP803 > "de2" at simplebus0 not configured > "dma-controller" at simplebus0 not configured > "lcd-controller" at simplebus0 not configured > "lcd-controller" at simplebus0 not configured > sximmc0 at simplebus0 > sdmmc0 at sximmc0: 4-bit, sd high-speed, mmc high-speed, dma > "usb" at simplebus0 not configured > "phy" at simplebus0 not configured > ehci0 at simplebus0 > usb0 at ehci0: USB revision 2.0 > uhub0 at usb0 configuration 1 interface 0 "Generic EHCI root hub" rev > 2.00/1.00 addr 1 > ohci0 at simplebus0: version 1.0 > ehci1 at simplebus0 > usb1 at ehci1: USB revision 2.0 > uhub1 at usb1 configuration 1 interface 0 "Generic EHCI root hub" rev > 2.00/1.00 addr 1 > ohci1 at simplebus0: version 1.0 > com0 at simplebus0sxiccmu_ccu_reset: 0x002e > : ns16550, no working fifo > com0: console > sxitwi0 at simplebus0 > iic0 at sxitwi0 > dwxe0 at simplebus0: address 02:ba:06:9f:01:af > rgephy0 at dwxe0 phy 1: RTL8169S/8110S/8211 PHY, rev. 5 > "hdmi" at simplebus0 not configured > "hdmi-phy" at simplebus0 not configured > "interrupt-controller" at simplebus0 not configured > sxidog0 at simplebus0 > gpio0 at sxipio0: 32 pins > gpio1 at sxipio0: 32 pins > gpio2 at sxipio0: 32 pins > gpio3 at sxipio0: 32 pins > gpio4 at sxipio0: 32 pins > gpio5 at sxipio0: 32 pins > gpio6 at sxipio0: 32 pins > gpio7 at sxipio0: 32 pins > gpio8 at sxipio1: 32 pins > usb2 at ohci0: USB revision 1.0 > uhub2 at usb2 configuration 1 interface 0 "Generic OHCI root hub" rev > 1.00/1.00 addr 1 > usb3 at ohci1: USB revision 1.0 > uhub3 at usb3 configuration 1 interface 0 "Generic OHCI root hub" rev > 1.00/1.00 addr 1 > "hdmi-connector" at mainbus0 not configured > "binman" at mainbus0 not configured > scsibus0 at sdmmc0: 2
Re: Snapshot crash on boot, "entry point at: 0x1001000" (Intel Gemini Lake)
On 2020/10/18 15:01, Michel von Behr wrote: > OK, so if I understand this correctly, in theory I should be able to go with > both kernel and > binaries from snapshot, and use installboot(8) to load primary and secondary > bootstrap files > from previous releases... right? My approach would be: - install old release - copy over the new kernel - untar the new sets - do not run installboot, do not touch the boot loader If you install directly from a newer release you will have problems booting it in the first place so you won't be able to run installboot ..
Re: Sending Mail to misc
On Sun, 2020-10-18 at 15:00 -0400, J Doe wrote: > > On Oct 18, 2020, at 2:47 PM, Jeffrey Joshua Rollin < > > j...@jeffjoshua.club> wrote: > > > > Hi, > > > > I’m able to send mail from my iPad (sorry), but not from my OpenBSD > > machine (same address). Any ideas what could be causing this? > > > > In the meantime, thanks for 6.8 and happy anniversary. > > > > Jeff > > Hi, > > I sent two messages to misc yesterday from Thunderbird on Ubuntu > Linux 20.04 LTS and they also did not make it to the list. Perhaps > there is an issue on the mail server side ? > > Thanks, > > - J Well, I can't speak for your problem yesterday but if this message makes it then the problem was clearly on my side. Something was wrong with my smtp server settings but when I deleted my accounts and recreated them in Evolution, I was able to send a message to someone else. Maybe you could check your Ubuntu settings just in case you've done the same. Apologies to all as I should have checked this before sending anything. Jeff.
Sending Mail to misc
Hi, I’m able to send mail from my iPad (sorry), but not from my OpenBSD machine (same address). Any ideas what could be causing this? In the meantime, thanks for 6.8 and happy anniversary. Jeff Sent from my iPad
Testing
Sent from my iPad
Re: OpenBSD 6.8 Relase Time
Valdrin Muja(valdrinm...@protonmail.com) on 2020.10.16 13:52:14 +: > Hi Misc, > > I'm looking forward to OpenBSD 6.8 release. > > On OpenBSD 6.8 page, `Released Oct XXX` is writing.. > > https://www.openbsd.org/68.html > > When will it be released? today.
Re: Thinkpad T14s: Sound works through headphones only
Mihai Popescu writes: > Try the volume up key, since the speakers volume might be set to minimum. Nope. mixerctl suggests that's not the case. Pressing volume up/down does nothing. I turned the volume to max with cmixer also - same thing.
dmesg for 6.8-release on Pine A64+ 1GB (Arm64)
6.8 seems to work OK on the Arm64 Pine A64+ with 1GB RAM. Some observations: OpenBSD sees 896MB of RAM and makes only 838MB available. When running Debian Linux on the exact same board the available RAM *after boot* is 994MB, a difference of more than 150MB. Perhaps this can be improved by tuning the DTB. A contrived test of network performance, using httpd(8) to serve a large file from an mfs ramdisk over plain http, yields about 175 mbit/s sustained transfer speed. I was not expecting to reach even 100 mbit/s so this was a positive surprise, even if it's nowhere near the full gigabit that other OSes can squeeze out of this board. OpenBSD 6.8 (GENERIC.MP) #828: Sun Oct 4 20:35:47 MDT 2020 dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP real mem = 940503040 (896MB) avail mem = 879267840 (838MB) random: good seed from bootblocks mainbus0 at root: Pine64+ psci0 at mainbus0: PSCI 1.1, SMCCC 1.2 cpu0 at mainbus0 mpidr 0: ARM Cortex-A53 r0p4 cpu0: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache cpu0: 512KB 64b/line 16-way L2 cache cpu1 at mainbus0 mpidr 1: ARM Cortex-A53 r0p4 cpu1: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache cpu1: 512KB 64b/line 16-way L2 cache cpu2 at mainbus0 mpidr 2: ARM Cortex-A53 r0p4 cpu2: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache cpu2: 512KB 64b/line 16-way L2 cache cpu3 at mainbus0 mpidr 3: ARM Cortex-A53 r0p4 cpu3: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache cpu3: 512KB 64b/line 16-way L2 cache efi0 at mainbus0: UEFI 2.8 efi0: Das U-Boot rev 0x20200700 apm0 at mainbus0 "display-engine" at mainbus0 not configured "osc24M_clk" at mainbus0 not configured "osc32k_clk" at mainbus0 not configured "internal-osc-clk" at mainbus0 not configured simpleaudio0 at mainbus0 "spdif-out" at mainbus0 not configured agtimer0 at mainbus0: tick rate 24000 KHz simplebus0 at mainbus0: "soc" sxisyscon0 at simplebus0 sxisid0 at simplebus0 sxiccmu0 at simplebus0 sxipio0 at simplebus0: 103 pins ampintc0 at simplebus0 nirq 224, ncpu 4 ipi: 0, 1: "interrupt-controller" sxirtc0 at simplebus0 sxiccmu1 at simplebus0 sxipio1 at simplebus0: 13 pins sxirsb0 at simplebus0 axppmic0 at sxirsb0 addr 0x3a3: AXP803 "de2" at simplebus0 not configured "dma-controller" at simplebus0 not configured "lcd-controller" at simplebus0 not configured "lcd-controller" at simplebus0 not configured sximmc0 at simplebus0 sdmmc0 at sximmc0: 4-bit, sd high-speed, mmc high-speed, dma "usb" at simplebus0 not configured "phy" at simplebus0 not configured ehci0 at simplebus0 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "Generic EHCI root hub" rev 2.00/1.00 addr 1 ohci0 at simplebus0: version 1.0 ehci1 at simplebus0 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 configuration 1 interface 0 "Generic EHCI root hub" rev 2.00/1.00 addr 1 ohci1 at simplebus0: version 1.0 com0 at simplebus0sxiccmu_ccu_reset: 0x002e : ns16550, no working fifo com0: console sxitwi0 at simplebus0 iic0 at sxitwi0 dwxe0 at simplebus0: address 02:ba:06:9f:01:af rgephy0 at dwxe0 phy 1: RTL8169S/8110S/8211 PHY, rev. 5 "hdmi" at simplebus0 not configured "hdmi-phy" at simplebus0 not configured "interrupt-controller" at simplebus0 not configured sxidog0 at simplebus0 gpio0 at sxipio0: 32 pins gpio1 at sxipio0: 32 pins gpio2 at sxipio0: 32 pins gpio3 at sxipio0: 32 pins gpio4 at sxipio0: 32 pins gpio5 at sxipio0: 32 pins gpio6 at sxipio0: 32 pins gpio7 at sxipio0: 32 pins gpio8 at sxipio1: 32 pins usb2 at ohci0: USB revision 1.0 uhub2 at usb2 configuration 1 interface 0 "Generic OHCI root hub" rev 1.00/1.00 addr 1 usb3 at ohci1: USB revision 1.0 uhub3 at usb3 configuration 1 interface 0 "Generic OHCI root hub" rev 1.00/1.00 addr 1 "hdmi-connector" at mainbus0 not configured "binman" at mainbus0 not configured scsibus0 at sdmmc0: 2 targets, initiator 0 sd0 at scsibus0 targ 1 lun 0: removable sd0: 7620MB, 512 bytes/sector, 15605760 sectors vscsi0 at root scsibus1 at vscsi0: 256 targets softraid0 at root scsibus2 at softraid0: 256 targets bootfile: sd0a:/bsd boot device: sd0 root on sd0a (e07784d42ee158ca.a) swap on sd0b dump on sd0b
OpenBSD 6.8 released, - Oct 18, 2020
- OpenBSD 6.8 RELEASED - October 18, 2020. We are pleased to announce the official release of OpenBSD 6.8. This day marks the OpenBSD project's 25th anniversary. As we celebrate our 49th release, we remain proud of OpenBSD's record of more than twenty years with only two remote holes in the default install. As in our previous releases, 6.8 provides significant improvements, including new features, in nearly all areas of the system: - New/extended platforms: o New powerpc64 platform, supporting PowerNV (non-virtualized) systems with POWER8 and POWER9 CPUs, such as Raptor Computing Systems Talos II and Blackbird systems. POWER8 support has not been tested on real hardware yet. - Improvements to time measurements, mostly in the kernel: o Added support in the kernel and libc for timecounting in userland, eliminating the need for a context switch everytime a process requests the current time, thereby improving speed and responsiveness in programs which make many gettimeofday(2) calls, especially browsers and office software. The userland timecounters are enabled on the amd64, arm64, macppc, octeon and sparc64 architectures. o Added a ktrace(1) -T option to make time-related system calls more prominent. o Added tsc_delay(), a delay(9) implementation based on the TSC, to amd64. o Used an LFENCE instruction everywhere RDTSC is used for a time measurement, reducing the jitter in TSC skew measurements. o Introduced gettime(9) and getuptime(9) and substituted these for time_second(9) and time_uptime(9) throughout the kernel to prevent split-read problems on 32-bit platforms. o Synchronized each core's CP0 cycle counter using the IO clock counter on mips64 and octeon, making the cycle counter usable as timecounter. o Improved CPU frequency scaling in automatic performance mode by removing accounting for offline CPUs. - Various kernel improvements: o Added intrmap, an interrupt to CPU mapping API that is used by hardware drivers to use multiple CPUs for interrupt handling. o Added an ioctl PCIOCGETVPD allowing userland to access read-only support information about pci devices via the vpd register. o Set ddb(4) "/t" to show a trace via TID on all architectures. o Introduced kstat(1), a subsystem to allow the kernel to expose statistics to userland. o Added kstat to cnmac(4). o Added support for remote coverage to kcov(4). o Moved sysctl(2) CTL_DEBUG from DEBUG to the new DEBUG_SYSCTL. o Prevented creation of bogus sd(4) devices for nvme(4) namespaces which are configured but have size 0. o Added READ(12)/WRITE(12) support to cd(4). o Used READ(16)/WRITE(16) commands for disks large enough to require them to access the last sectors, fixing large 512E devices plugged into USB to ATA/ATAPI bridges which mistakenly use 4K sector addresses/sizes. o Restored VGA fonts on VT switch, preventing an unusable screen when switching to a VT with a custom VGA font from X. o Ensured only pseudo-terminal devices use reprint delays. o Prevented improper disabling of the backlight in umstc(4) when brightness is adjusted to 0. o Provided an optimized implementation of ffs(3) in the kernel on arm64/powerpc/powerpc64. o Rewrote m88k mutex code as a slight variation of the MI mutex code, potentially improving stability and rendering mutex spinning time visible in top(1). o Reworked kernel loading with octboot, the OpenBSD/octeon bootloader, which now does not rely on a mounted filesystem. o Ensured scsi(4) devices do not attempt to process bogus MODE SENSE data. - Various new userland features: o Imported login_ldap(8), using ldap(1) rather than openldap. o Added support for set -o pipefail to ksh(1), potentially helping error checking. o Cleared the screen in ksh(1)'s vi mode before redrawing the line with ^L. o Implemented the gensub(), systime() and strftime() functions for awk(1). o Allowed specification of supported TLS protocols in ftp(1) "-S protocols". o Switched the default man(1) pager from "more(1) -s" to less(1). o Supported -T html -O tag in man(1) by passing a file:// URI to the pager. o Added fstat(1) support for looking up unix domain sockets by file name. o Added / as an alias for g (grep) in top(1). o Provided a naptime variable for userspace via kvm_read(3), usable by vmstat(8). o Allowed switching between alternate devices (-F) with sndioctl(1). o Added the ability to set and display video(1) control values directly on the CLI. o Allowed the combination of video(1) "-dc" options, reset and display
Re: Installation of 6.7 does not start on Lenovo ThinkPad P1 Gen 3
Hi Todd try without the USB Docking device / LAN Dongle device cable attached ... (I see something like that in the dmesg use the bios to turn off things like the camera one by one and you will find the incompatible piece of hardware (if it exists) On Sun, 18 Oct 2020 at 05:07, Todd Brewster wrote: > > Hi Tom, > > Thanks for the quick reply. > > the only other thing I can think of is to clear the partition table > > The laptop came with a pre-installed Win10, which I have overwritten with > Fedora. > > Ok just to confirm you are writing the install67.fs or install68.img > to the USB drive... the usb drive is not encrypted.. > > Correct, I wrote Install67.fs / install68.img to the USB Flash drive and then > booted from that flash. > > when you boot your laptop you get the usual OpenBSD boot prompt and you just > hit enter ? > > Well, actually I just wait for the timeout. > > > looking at the dmesg it is saying softraid0 ... (which im assuming > would only be relevant if you were loading an encrypted drive or a > raid that is strange) > I had not noticed that in a dmesg of a standard installer (I could be wrong) > > The drive is currently not encrypted. I compared the dmesg with the other > outputs > and they all have the > softraid0 at root > scsibus2 at softraid0: 256 targets > lines. > > Thanks and all the best, > > Todd -- Kindest regards, Tom Smyth.
Re: Thinkpad T14s: Sound works through headphones only
Try the volume up key, since the speakers volume might be set to minimum.
Re: Snapshot crash on boot, "entry point at: 0x1001000" (Intel Gemini Lake)
OK, so if I understand this correctly, in theory I should be able to go with both kernel and binaries from snapshot, and use installboot(8) to load primary and secondary bootstrap files from previous releases... right? Regarding the mismatched kernel and binaries, thanks, now I understand - should be temporary, no problem. On Sun, 18 Oct 2020 at 2:33 PM Stuart Henderson wrote: > On 2020-10-17, Michel von Behr wrote: > > @stuart Thank for the suggestion - unfortunately after following the > steps > > in that link the same error occurred (entry point at: 0x1001000); I > > reverted to the obsd kernel (i.e., at boot time, “b obsd”), it’s booting > > and the system seems to be working OK, but without dmesg - when I try to > > run dmesg, I get: > > > > dmesg: sysctl: KERN_MSGBUF: Cannot allocate memory > > You have mismatched kernel and binaries. > > > $ uname -a > > OpenBSD chuwi.mabvb.pro 6.7 GENERIC.MP#6 amd64 > > You were trying to run snapshots, I think, so you'll need a snapshot > kernel. The only thing you want to hold back is the boot loader. > >
Re: Snapshot crash on boot, "entry point at: 0x1001000" (Intel Gemini Lake)
On 2020-10-17, Michel von Behr wrote: > @stuart Thank for the suggestion - unfortunately after following the steps > in that link the same error occurred (entry point at: 0x1001000); I > reverted to the obsd kernel (i.e., at boot time, “b obsd”), it’s booting > and the system seems to be working OK, but without dmesg - when I try to > run dmesg, I get: > > dmesg: sysctl: KERN_MSGBUF: Cannot allocate memory You have mismatched kernel and binaries. > $ uname -a > OpenBSD chuwi.mabvb.pro 6.7 GENERIC.MP#6 amd64 You were trying to run snapshots, I think, so you'll need a snapshot kernel. The only thing you want to hold back is the boot loader.
Re: Any experience with 10Gbe?
On 2020-10-17, Aisha Tammy wrote: > On 10/15/20 5:52 AM, Stuart Henderson wrote: >> On 2020-10-14, Rafael Possamai wrote: I'm supporting a small business who needs more bandwidth due to the work-from-home >situation. They've asked me to help them do the upgrade to 10Gbe. I'd preferto keep them on an >OpenBSD router, since I love how liuttle maintenance it needs, but I can't find any accounts of >someone actually managing to get close to line speed above 1 Gbe. I don't want to just buy expensive hardware and hope that it works. Has anyone here been able >to get close to 10 Gb/s networking with OpenBSD? I don't need to be able to have more than a >few pf-rules. >>> >>> There is a talk on YouTube about using a few OpenBSD boxes with 10gb, maybe >>> this helps somewhat. https://www.youtube.com/watch?v=veqKM4bHesM >> >> 10Gb ports work fine, passing full 10Gb of traffic on those ports not so >> much, and we're nowhere near passing 10Gb of small size packets. (the >> limit is more to do with packets per second than speed). >> >> "do the upgrade to 10GbE" isn't specific enough as to what's needed to be >> able to give much usrful advice. >> >> >> > Is there anything non technical that users can help with? > I know donating hardware is one but I don't know if thats what is needed > in this case? Testing diffs, especially those related to kernel locking, and reporting back on them can help. Running -current, updating fairly often, and reporting on problems seen (with a good date window for when they were first seen, or even better bisecting to the individual commit if possible) can be useful too.
Re: firefox freezes X on AMD Ryzen running 6.8
On Sun, Oct 18, 2020 at 02:49:30PM +1100, Jonathan Gray wrote: > There are changes coming to the memory handling in drm. [...] > I've asked for the drm_mm diff to be pulled from snapshots for now. Thank you for the information and your help!
