Re: Auto-install over network using UEFI
On Tue, Nov 21, 2023 at 7:03 PM Chris Narkiewicz wrote: > > I'm experimentin with auto-install over network using linux libvirt > (qemu). > > I managed to load pxeboot in BIOS mode and I'm wondering if UEFI > is supported. > > According to this blog, I should load BOOTX64.EFI instead of pxeboot. > > https://eradman.com/posts/autoinstall-openbsd.html > > I was skeptical but tried it neverthekess and system immediately reboots after > probing disk: > > probing: p0 com0 mem[640K 2029M 9M 3M] > disk:BS->LocateHandle() returns 14 > > > Is it possible to net-boot installer in UEFI using QEMU? > > Cheers, > Chris > i had some trouble getting PXE set up with dhcpd - see my mail from april, "dhcpd user-class and vendor-class". i think there is also a bug in the EFI loader when run under OVMF as you experienced, but i never figured it out.
Re: how to play bytebeat on openbsd?
back when i used to mess with these, i frequently used `sox` to play the 8-bit samples. it can do the sample conversion for you to whatever the system needs. On Fri, Feb 2, 2024 at 11:08 AM Omar Polo wrote: > > On 2024/02/02 18:41:46 +, beecdadd...@danwin1210.de wrote: > > hello > > > > I've tried for hours to play bytebeat as everyone else > > > > I cannot find anything on the entire internet > > > > all I got is `cat a.out >> /dev/speaker)` as root.. a.out is compiled code > > , a > > loop and `putchar(t*((t>>12|t>>8)&63&t>>4));`.. this doesn't sound nearly > > the > > same as it does to other people > > it's also slow, not fast > > I don't think it makes sense to feed speaker(4) with an executable code. > > Haven't seen the code, but based on your description I guess it should > be more like > > $ ./a.out | doas tee /dev/speaker > > or at least that's my guess, my crystall ball don't always works > correctly. >
Re: [answered]Re: how to play bytebeat on openbsd?
try piping to sox -r 8000 -c 1 -t u8 - -d for example, this should work as a demo: python3 -c 'import sys; [sys.stdout.write(chr(( t & (t >> 8)) % 256)) for t in range(2**19)]' | sox -r 8000 -c 1 -t u8 - -d On Sat, Feb 3, 2024 at 6:20 AM wrote: > > thank you, stranger! > > I found so many good C formulas, some sound like they could be used within a > game, even has pauses with silence and everything! > > I had to find out how to use sox, though on another site: `sox -r 8000 -c -t > u8 test.raw output.wav` > > what is weird is that I can't get bytebeats if the `t` is int8_t or > something.. doesn't seem like that makes sense, it's like 4 bytes 32-bit, not > 1 byte. > not sure difference between signed 32, 64 and unsigned, but I tried 16-bit `t` > and it's just not it.. am I messing something up? > > does this only mimic bytebeat, and is not true 8-bit technique to get > realistic bytebeat? > > On Fri, February 2, 2024 9:15 pm, Nick Owens wrote: > > back when i used to mess with these, i frequently used `sox` to play the > > 8-bit > > samples. it can do the sample conversion for you to whatever the system > > needs. > > > > > > On Fri, Feb 2, 2024 at 11:08 AM Omar Polo wrote: > > > >> > >> On 2024/02/02 18:41:46 +, beecdadd...@danwin1210.de wrote: > >> > >>> hello > >>> > >>> I've tried for hours to play bytebeat as everyone else > >>> > >>> > >>> I cannot find anything on the entire internet > >>> > >>> > >>> all I got is `cat a.out >> /dev/speaker)` as root.. a.out is compiled > >>> code , a loop and `putchar(t*((t>>12|t>>8)&63&t>>4));`.. this doesn't > >>> sound nearly the same as it does to other people it's also slow, not fast > >> > >> I don't think it makes sense to feed speaker(4) with an executable code. > >> > >> > >> Haven't seen the code, but based on your description I guess it should > >> be more like > >> > >> $ ./a.out | doas tee /dev/speaker > >> > >> > >> or at least that's my guess, my crystall ball don't always works correctly. > >> > > > > > > >
Re: ipv6 assistance
On Sat, Apr 6, 2024 at 8:10 AM Sonic wrote: > > Running -current on my router and finally (after years) decided to move into > using ipv6. > I added "inet6 autoconf" to hostname.em0 (also has "inet autoconf") and I get > a link local address: > = > # ifconfig em0 > em0:inet6 fe80::2132:31ff:fe0b:7ea4%em0 prefixlen 64 scopeid 0x1 > inet 69.31.273.6 netmask 0xfc00 broadcast 69.31.273.255 > = > And an ipv6 default route: > = > Internet6: > Destination Gateway > Flags Refs Use Mtu Prio Iface > default fe80::301:5bcf:fe75:2646%em0 > UGS0 22 - 8 em0 > = > Which matches the default router proposal listed by slaacctl: > = > em0: > index: 1 running: yes temporary: yes > lladdr: 40:62:31:0b:7e:a4 > inet6: fe80::2132:31ff:fe0b:7ea4%em0 > Router Advertisement from fe80::201:5cff:fe75:2646%em0 > received: 2024-04-06 10:49:17; 0s ago > Cur Hop Limit: 0, M: 1, O: 1, Router Lifetime: 1800s > Default Router Preference: Medium > Reachable Time: 360ms, Retrans Timer: 1000ms > prefix: 2001:623:8016:54::/64 > On-link: 0, Autonomous address-configuration: 0 > vltime: 604800, pltime: 302400 > prefix: 2001:623:6007:a5::/64 > On-link: 0, Autonomous address-configuration: 0 > vltime: 604800, pltime: 302400 > prefix: 2001:623:500e:16::/64 > On-link: 0, Autonomous address-configuration: 0 > vltime: 604800, pltime: 302400 > prefix: 2001:623:4020:a5::/64 > On-link: 0, Autonomous address-configuration: 0 > vltime: 604800, pltime: 302400 > Default router proposals > id:1, state: PROPOSAL_CONFIGURED > router: fe80::301:5bcf:fe75:2646%em0 > router lifetime: 1800 > Preference: Medium > updated: 2024-04-06 10:49:17; 0s ago, timeout: 1788s > = > However, there's no other ipv6 address on the interface - I suspect an > address from one of those 2001: prefix groups needs to be assigned. > Should not dhcpleased handle this? > Most of the web posts I find deal with the pre-dhcpleased days. > > I'm on Comcast (Xfinity) in the US. i have comcast, and i use dhcpcd for ipv6. replace rge0 and vport0 with your wan/lan interface.. # /etc/dhcpcd.conf ipv6only duid persistent vendorclassid option rapid_commit option interface_mtu # make dhcpcd not touch nameservers. nohook resolv.conf require dhcp_server_identifier slaac private allowinterfaces rge0 interface rge0 ipv6rs iaid 1 ia_na 1 ia_pd 1/::/64 vport0/0/64 > > Thank you, > Chris > > >
Re: PC Engines APU alternative for OpenBSD - 2022h2
hardkernel makes the odroid-h3/h3+. i haven't used this new generation, but my home firewall is an odroid-h2+ (the previous generation) and i use it with their 4-port pci nic addon card for a total of 6 rge(4) interfaces. they work good so far in veb(4). there's uart on the pin header but i've never tried it. dmesg for my odroid-h2+: OpenBSD 7.2 (GENERIC.MP) #758: Tue Sep 27 11:57:54 MDT 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8367374336 (7979MB) avail mem = 8096378880 (7721MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.2 @ 0x79801000 (60 entries) bios0: vendor American Megatrends Inc. version "1.22" date 11/13/2020 bios0: HARDKERNEL ODROID-H2 acpi0 at bios0: ACPI 6.2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP FPDT FIDT MCFG SSDT DBG2 DBGP HPET LPIT APIC NPKT SSDT SSDT SSDT SSDT SSDT SSDT SSDT DMAR WDAT WSMT acpi0: wakeup devices HDAS(S3) XHC_(S4) XDCI(S4) RP01(S4) RP02(S4) RP03(S4) RP04(S4) RP05(S4) RP06(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpihpet0 at acpi0: 1920 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Celeron(R) J4115 CPU @ 1.80GHz, 1795.04 MHz, 06-7a-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu0: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 4MB 64b/line 16-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 19MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.2.4.2.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Celeron(R) J4115 CPU @ 1.80GHz, 1795.04 MHz, 06-7a-01 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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu1: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 4MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Celeron(R) J4115 CPU @ 1.80GHz, 1795.04 MHz, 06-7a-01 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu2: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 4MB 64b/line 16-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Celeron(R) J4115 CPU @ 1.80GHz, 1795.04 MHz, 06-7a-01 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu3: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 4MB 64b/line 16-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 120 pins acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 5 (RP01) acpiprt2 at acpi0: bus 6 (RP02) acpiprt3 at acpi0: bus 1 (RP03) acpiprt4 at acpi0: bus 2 (RP04) acpiprt5 at acpi0: bus 3 (RP05) acpiprt6 at acpi0: bus 4 (RP06) acpiec0 at acpi0: not present acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 com0 at acpi0 UAR1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo com1 at acpi0 UAR2 addr 0x2f8/0x8 irq 3: ns16550a, 16 byte fifo acpicmos0 at acpi0 acpibtn0 at acpi0: PWRB glkgpio0 at acpi0 GPO1 uid 1 addr 0xd0c4/0xcef irq 14, 80 pins glkgpio1 at acpi0 GPO0 uid 2 addr 0xd0c5/0xaff irq 14, 80 pins glkgpio2 at acpi0 GPO2 uid 3 addr 0xd0c9/0x7bf irq 15, 20 pins glkgpio3 at acpi0 GPO3 uid 4 addr 0xd0c8/0x82f
Re: Tor daemon is unable to connect to the Tor network
works ok here. i installed tor-0.4.7.13 on my 7.2 home gateway, no special setup. i have not done any fiddling with login.conf. maybe you can set "Log debug syslog" and see what comes out? fugu$ uname -a OpenBSD fugu.offblast.org 7.2 GENERIC.MP#6 amd64 fugu$ grep '^[A-Z]' /etc/tor/torrc Log notice syslog RunAsDaemon 1 DataDirectory /var/tor User _tor fugu$ curl --silent --socks5-hostname localhost:9050 https://check.torproject.org | grep Congratulations Congratulations. This browser is configured to use Tor. Congratulations. This browser is configured to use Tor. fugu$ grep -i tor /var/log/daemon Mar 14 00:05:12 fugu Tor[84209]: Tor 0.4.7.13 running on OpenBSD with Libevent 2.1.12-stable, OpenSSL LibreSSL 3.6.0, Zlib 1.2.12, Liblzma N/A, Libzstd N/A and Unknown N/A as libc. Mar 14 00:05:12 fugu Tor[84209]: Tor can't help you if you use it wrong! Learn how to be safe at https://support.torproject.org/faq/staying-anonymous/ Mar 14 00:05:12 fugu Tor[84209]: Read configuration file "/etc/tor/torrc". Mar 14 00:05:12 fugu Tor[84209]: Opening Socks listener on 127.0.0.1:9050 Mar 14 00:05:12 fugu Tor[84209]: Opened Socks listener connection (ready) on 127.0.0.1:9050 Mar 14 00:05:12 fugu Tor[84209]: Parsing GEOIP IPv4 file /usr/local/share/tor/geoip. Mar 14 00:05:13 fugu Tor[84209]: Parsing GEOIP IPv6 file /usr/local/share/tor/geoip6. Mar 14 00:05:13 fugu Tor[84209]: We were built to run on a 64-bit CPU, with OpenSSL 1.0.1 or later, but with a version of OpenSSL that apparently lacks accelerated support for the NIST P-224 and P-256 groups. Building openssl with such support (using the enable-ec_nistp_64_gcc_128 option when configuring it) would make ECDH much faster. Mar 14 00:05:13 fugu Tor[84209]: Bootstrapped 0% (starting): Starting Mar 14 00:05:13 fugu Tor[84209]: Starting with guard context "default" Mar 14 00:05:14 fugu Tor[84209]: Bootstrapped 5% (conn): Connecting to a relay Mar 14 00:05:14 fugu Tor[84209]: Bootstrapped 10% (conn_done): Connected to a relay Mar 14 00:05:15 fugu Tor[84209]: Bootstrapped 14% (handshake): Handshaking with a relay Mar 14 00:05:15 fugu Tor[84209]: Bootstrapped 15% (handshake_done): Handshake with a relay done Mar 14 00:05:15 fugu Tor[84209]: Bootstrapped 20% (onehop_create): Establishing an encrypted directory connection Mar 14 00:05:15 fugu Tor[84209]: Bootstrapped 25% (requesting_status): Asking for networkstatus consensus Mar 14 00:05:15 fugu Tor[84209]: Bootstrapped 30% (loading_status): Loading networkstatus consensus Mar 14 00:05:19 fugu Tor[84209]: I learned some more directory information, but not enough to build a circuit: We have no usable consensus. Mar 14 00:05:19 fugu Tor[84209]: Bootstrapped 40% (loading_keys): Loading authority key certs Mar 14 00:05:20 fugu Tor[84209]: The current consensus has no exit nodes. Tor can only build internal paths, such as paths to onion services. Mar 14 00:05:20 fugu Tor[84209]: Bootstrapped 45% (requesting_descriptors): Asking for relay descriptors Mar 14 00:05:20 fugu Tor[84209]: I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 0/6489, and can only build 0% of likely paths. (We have 0% of guards bw, 0% of midpoint bw, and 0% of end bw (no exits in consensus, using mid) = 0% of path bw.) Mar 14 00:05:21 fugu Tor[84209]: Bootstrapped 50% (loading_descriptors): Loading relay descriptors Mar 14 00:05:26 fugu Tor[84209]: The current consensus contains exit nodes. Tor can build exit and internal paths. Mar 14 00:05:34 fugu Tor[84209]: Bootstrapped 56% (loading_descriptors): Loading relay descriptors Mar 14 00:05:36 fugu Tor[84209]: Bootstrapped 63% (loading_descriptors): Loading relay descriptors Mar 14 00:05:38 fugu Tor[84209]: Bootstrapped 68% (loading_descriptors): Loading relay descriptors Mar 14 00:05:38 fugu Tor[84209]: Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits Mar 14 00:05:38 fugu Tor[84209]: Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits Mar 14 00:05:38 fugu Tor[84209]: Bootstrapped 95% (circuit_create): Establishing a Tor circuit Mar 14 00:05:39 fugu Tor[84209]: Bootstrapped 100% (done): Done On Mon, Mar 13, 2023 at 4:35 AM Matt Wehowsky wrote: > > On 2023-03-12 09:53 AM, Stuart Henderson wrote: > > I don't think the problem you're seeing is related to login.conf but a > > few comments on that, > > > > ... > > > > I suggest removing login.conf.db (it is not created by default) and not > > using cap_mkdb, to avoid any problems with the db file getting out of > > sync after other changes. You probably want to override openfiles-cur as > > well, not just -max. > > Done. Thanks for the insight, Stuart. > > > Note any daemon-specific config here will only be used automatically if > > you're running it via rcctl or the rc.d script. (If you run it "by hand" > > you can set the login class with su -c or sudo -c). > > I’m aware of that, but thank you for clarification nonethe
dhcpd user-class and vendor-class
hi,
dhcpd.conf(5) has two undocumented options i experimented with
recently for doing pxe boot on my lan.
for example, one might write the following:
# iPXE client
user-class "iPXE" {
filename "menu.ipxe";
}
to configure a iPXE script as the boot file for ipxe clients, or
# UEFI PXE Boot
vendor-class "PXEClient:Arch:7:UNDI:003001" {
filename "BOOTX64.EFI";
# avoid proxy dhcp
option vendor-encapsulated-options 06:01:0a;
}
to send the EFI bootloader to a UEFI client.
should these be documented? i can't find them in the manuals.
Re: dmesg and sensors for ODROID H3
On Tue, Apr 18, 2023 at 7:28 AM stolen data wrote: > > Everything seems to work. Only caveat noticed is that the firmware is > UEFI-only with no CSM/legacy mode, and it will only boot an OpenBSD > installation from GPT which must contain an EFI system partition holding > the bootloader. great choice. my ODROID H2+ is still holding strong with the add-in card for 4 extra NICs. it is a fine home firewall. my only complaint is sometimes having rge5: watchdog timeout rge2: watchdog timeout in dmesg and occasional link state issues, but i didn't dig into whether its from the rge driver or stuff i attached. if you can, provide an iperf3 result in both forward and reverse mode. here, i only have about 1.60 Gbit/s in both directions, but that's fine for my wan link. > > > sensors and timers: > > masheen# sysctl hw.sensors kern.timecounter.choice > hw.sensors.cpu0.temp0=25.00 degC > hw.sensors.cpu0.frequency0=8.00 Hz > hw.sensors.cpu1.frequency0=8.00 Hz > hw.sensors.cpu2.frequency0=8.00 Hz > hw.sensors.cpu3.frequency0=8.00 Hz > hw.sensors.acpitz0.temp0=27.80 degC (zone temperature) > hw.sensors.softraid0.drive0=online (sd1), OK > kern.timecounter.choice=i8254(0) tsc(2000) acpihpet0(1000) acpitimer0(1000) > > > dmesg: > > OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT 2023 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 4115353600 (3924MB) > avail mem = 3971211264 (3787MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.2 @ 0x78d74000 (138 entries) > bios0: vendor American Megatrends Inc. version "5.19" date 02/27/2023 > bios0: HARDKERNEL ODROID-H3 > efi0 at bios0: UEFI 2.7 > efi0: American Megatrends rev 0x50013 > acpi0 at bios0: ACPI 6.2 > acpi0: sleep states S0 S5 > acpi0: tables DSDT FACP MCFG FIDT SSDT SSDT SSDT HPET APIC PRAM SSDT SSDT > NHLT LPIT SSDT SSDT DBGP DBG2 SSDT DMAR SSDT TPM2 WSMT FPDT > acpi0: wakeup devices PEGP(S0) PEGP(S0) PEGP(S0) PEGP(S0) SIO1(S0) RP01(S0) > PXSX(S0) RP02(S0) PXSX(S0) RP03(S0) PXSX(S0) RP04(S0) PXSX(S0) RP05(S0) > PXSX(S0) RP06(S0) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimcfg0 at acpi0 > acpimcfg0: addr 0xc000, bus 0-255 > acpihpet0 at acpi0: 1920 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Celeron(R) N5105 @ 2.00GHz, 798.28 MHz, 06-9c-00 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,RDSEED,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB > 64b/line 12-way L2 cache, 4MB 64b/line 16-way L3 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 38MHz > cpu0: mwait min=64, max=64, C-substates=0.2.0.2.2.1.1.1, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Celeron(R) N5105 @ 2.00GHz, 798.28 MHz, 06-9c-00 > 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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,RDSEED,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB > 64b/line 12-way L2 cache, 4MB 64b/line 16-way L3 cache > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 4 (application processor) > cpu2: Intel(R) Celeron(R) N5105 @ 2.00GHz, 798.27 MHz, 06-9c-00 > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,RDSEED,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB > 64b/line 12-way L2 cache, 4MB 64b/line 16-way L3 cache > cpu2: smt 0, core 2, package 0 > cpu3 at mainbus0: apid 6 (application processor) > cpu3: Intel(R) Celeron(R) N5105 @ 2.00GHz, 798.28 MHz, 06-9c-00 > cpu3: > 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,CX
Re: pfstat is having a bad time
On Sun, May 5, 2024, 13:05 Christer Solskogen wrote: > Running pfstat -q gives: > ioctl: DIOCGETSTATUS: Permission denied > pf_query: query_counters() failed > > This is on a newly updated system (current) > OpenBSD tugs.antarctica.no 7.5 GENERIC.MP#50 amd64 > > Packages are also all up to date. > this may be related to the transaction/ticket changes in pf(4) that happened a while back. I know pftop doesn't work quite right any more, nor does my own poorly maintained go code since then. > -- > chs > >
Re: checksums to detect/correct bit-rot
On Sun, Sep 15, 2024 at 12:22 AM Jonathan Thornburg wrote: > > Does OpenBSD support any file systems with built-in checksums to > (try to) ensure metadata and/or data integrity in the face of "bit rot" > disk (or memory/cpu/USB) errors? I'm not looking for ZFS-style storage > pools or logical volume management, "just" checksums to catch silent > metadata and/or data corruption. > > Softraid 1, 5, or 1C could in theory do this, but with a large space > overhead (a factor of 2 to detect errors, or 3 to correct errors). > And, the current (7.5) man pages don't mention any option to have each > read read all the chunks and verify that they're identical. > > And a related question: I have a pool of ~10 external USB3 backup > disks (all consumer-grade WD or Seagate 2.5" spinning rust, either > 2TB or 4TB capacity each), all currently setup with FFS2 filesystems > on top of softraid crypto (/bioctl -c C/). Each backup is to a single > disk, written with (roughly speaking) > rsync -aHESvv --delete /home/ /mnt/home/ > Each disk thus has slightly different contents depending on how > recently I did a backup to that disk, but the vast majority of the > files (those that haven't changed recently) should be identical > across disks. > > [Before anyone asks: Yes, I regularly rotate some of the disks offsite. > And yes, I regularly restore files "in anger".] > > Each backup disk somewhat more than 1e13 bits, so at an unrecoverable > bit error rate of 1e-14 or 1e-15 for consumer disks there's a non-trivial > chance of a bit error somewhere in my backup pool. > > Thinking about how to detect/correct bit-rot in these backups, it > occurs to me that I could hack up some Perl to walk the filesystem > tree on a mounted backup disk, /stat()/ and read each file, and build > a database of (pathname, inode mtime, checksum) tuples. (I could either > ignore symlinks, or checksum the result of /readlink()/.) Then given > such databases for a bunch of disks, a bit more Perl could read all > the databases, find all the files with matching pathname and inode > mtime (so that the contents should be the same, given that my usage > of /rsync/ preserves /mtime/), look for differing checksums, and for > any differences, majority-vote the checksums to identify which copy > or copies is in error. > > But before I reinvent the wheel, can anyone point me to software > which already does this? Bonus points if the software is already > in ports. perhaps you would find mtree(8) helpful. > > Thanks, > -- > -- "Jonathan Thornburg [remove -color to reply]" > >on the west coast of Canada >"The programmers outside looked from Web 2.0 firm to AI company, and from > AI company to Web 2.0 firm, and from Web 2.0 firm to AI company again; > but already it was impossible to say which was which." >-- /Ars Technica/ comment by /ubercurmudgeon/, 2024-05-09 > > >
Re: Doesn't work prtsc button on Tex Shinobi keyboard
On Fri, Oct 11, 2024 at 5:48 PM Kirill A. Korinsky wrote: > > On Fri, 11 Oct 2024 19:07:03 +0200, > Pascal Stumpf wrote: > > > > On Tue, 08 Oct 2024 16:59:26 +0200, Kirill A. Korinsky wrote: > > > misc@ > > > > > > I made an assumption that I'm not the only one using Tex Shinobi's > > > keyboard, > > > and just discovered that the Prtsc button doesn't work. > > > > > > Not working means that xev doesn't register an event. When I press it, it > > > looks like I'm not pressing it. > > > > > > I was almost sure it was working a while ago, like this spring. > > > > > > Does this ring a bell for anyone? tex shinobi is a great keyboard, that replicates the old ibm 8845 ultranavs very well in a modern mechanical format. thanks for reporting this bug, and it looks like the fix will also fix special key problems other folks have run into. > > > > Yes, I can confirm this behaviour on a Keychron Q6. > > > > Here a diff which fixed Prtsc button on my keyboad. > > Index: driver/xf86-input-keyboard/src/at_scancode.c > === > RCS file: /cvs/xenocara/driver/xf86-input-keyboard/src/at_scancode.c,v > retrieving revision 1.5 > diff -u -p -r1.5 at_scancode.c > --- driver/xf86-input-keyboard/src/at_scancode.c17 Dec 2015 06:03:10 > - 1.5 > +++ driver/xf86-input-keyboard/src/at_scancode.c12 Oct 2024 00:25:40 > - > @@ -95,6 +95,7 @@ ATScancode(InputInfoPtr pInfo, int *scan > case KEY_KP_Decimal: *scanCode = KEY_Delete;break; /* curs > delete */ > case KEY_Enter: *scanCode = KEY_KP_Enter; break; /* > keypad enter */ > case KEY_LCtrl: *scanCode = KEY_RCtrl; break; /* > right ctrl */ > +case KEY_ShiftL: > case KEY_KP_Multiply: *scanCode = KEY_Print; break; /* > print */ > case KEY_Slash: *scanCode = KEY_KP_Divide; break; /* keyp > divide */ > case KEY_Alt: *scanCode = KEY_AltLang; break; /* > right alt */ > @@ -113,7 +114,6 @@ ATScancode(InputInfoPtr pInfo, int *scan > keyboards */ > case 0x01:*scanCode = KEY_R_0xF4;break; > case 0x03:*scanCode = KEY_R_0xF5;break; > -case 0x2A: > case 0x36: > return TRUE; > default: > > > -- > wbr, Kirill >
Re: multicast relay?
On Wed, Oct 16, 2024 at 3:57 PM Hannu Vuolasaho wrote: > > Hello everyone, > > I'm trying to get mDNS and other multicast protocols from IoT LAN to computer > LAN. > I did this with Linux with https://github.com/marjohn56/udpbroadcastrelay > tool. > > However I don't really like that and that tool doesn't even build out of box > on OpenBSD. > > If I understand correctly, pf doesn't care about broadcast/multicast stuff. > Please correct me if I'm wrong. > > What piece of software would relay the broadcasts and multicasts. > Also those rewrites would be nice as some devices are a little bit picky > about the packets. for mDNS, avahi-daemon allows this in some form via the `enable-reflector` option in the config file. > > Best regards, > Hannu Vuolasaho
Re: Smartcard readers for personal identification
On Thu, Feb 27, 2025 at 12:47 AM Dan wrote: > > > Here, > > Console: > > "Hamlet HUSCR-NFC" rev 2.00/1.14 addr XX at uhubX portX not configured > > usbdevs: > > addr XX: 1fc9:0102 Hamlet, HUSCR-NFC > full speed, power 500 mA, config 1, rev 1.14, iSerial 0114 security/ccid port looks promising. if it doesn't support it already, it seems like making it work would not be too far of > > > Dan > > -- > bsdload.com - Repo: https://code.5mode.com > > Please reply to the mailing-list, leveraging technical stuff. > > > > Janne Johansson wrote: > > > Den tors 27 feb. 2025 kl 02:29 skrev Fabio Martins > > : > > > You should share the card reader USB ID ( "lsusb" command in Ubuntu > > > Linux - maybe a good soul will implement support in OpenBSD ) and > > > also > > > > usbdevs(8) ? > > > > # usbdevs > > Controller /dev/usb0: > > addr 01: : Octeon, EHCI root hub > > addr 02: 152d:0579 Intenso, Portable SSD > > Controller /dev/usb1: > > addr 01: : Octeon, OHCI root hub > > > > Adding a -v or two gives more info, but the id's are always shown. > > > > > > > Dan > > -- > nuggetsman.com - Repo: https://code.5mode.com > > Please reply to the mailing-list, leveraging technical stuff. >
Re: CVS Web crippled
On Fri, Mar 14, 2025 at 3:39 PM Nick Holland
wrote:
>
> hello.
> As you may have noticed, cvsweb.openbsd.org has been having
> issues. This time, it is due to effectively a Distributed Denial of
> Service, though I don't actually believe it is /deliberately/
> malicious. Speculation is someone is trying to feed a so-called AI
> application from cvsweb. While I admire the idea of training an AI
> from the work of some of the best programmers in the world, cvsweb
> is a perl script that writes a lot of temp files. The current
> system is many times the first cvsweb HW I set up many years ago,
> and won't even notice humans using it, when hundreds of simultaneous
> automated queries are happening, things get bad quickly.
>
> FOR NOW, I've stopped the ability of cvsweb to show diffs of file
> revisions. This is where both much of the abuse was happening, and
> also much of the load on the system came from.
> YES, that's horribly annoying, but you can still download any
> individual version of a file and you can still see the annotated
> output. I'll be thinking about a longer-term solution (which may
> also be "wait until they get bored and move on").
sorry to hear about AI's latest victim. i had this problem on my gitea
instance running on openbsd, where the crawler decided to follow every
link to every revision of my mirrors of openbsd src and linux, and i
"fixed" it with robots.txt which the particular crawler ("claudebot")
respected. robots.txt:
User-agent: *
Disallow: /
>
> Sorry for the inconvenience.
>
> Nick.
>
