Re: HP T430 "Thin Client": Won't sysupgrade without HDMI monitor attached.
On 5/6/22 2:30 PM, Nick Holland wrote: On 5/6/22 12:48 PM, Theo de Raadt wrote: Florian Obser wrote: So, if you end up with a /bsd.upgrade on the running system that is still mode 0700, your bootloader is on the fritz. If you have a /bsd.upgrade that's 0600 your bootloader found the kernel and tried to boot it, but the installer didn't get very far. If there is no /bsd.upgrade after a reboot and no email to root the installer got rebooted by a watchdog process, otherwise you got an email to root detailing the upgrade process. A very nice 3-way split. Brilliant, even. Then once you figure out which one of those 3 is happening, it is easy to reason about how to create further differentiations and see which is happening. I was very much guessing it was /boot, but no. -rw--- 1 root wheel 4609699 May 6 13:13 bsd.upgrade So ... it's booting bsd.upgrade and failing, which explains why copying bsd.upgrade (aka bsd.rd) to /bsd tossed it into a lala-loop. Unfortunately, this machine doesn't retain dmesg buffer between boots. so ... booted bsd.rd with a monitor attached, and grabbed the dmesg below. I'm looking at this: efifb0 at mainbus0: 1920x1080, 32bpp If the system is booted (bsd) without a monitor attached, that says: efifb at mainbus0 not configured Getting to the boot> prompt, typing "boot bsd.rd", unplugging the monitor and hitting "ENTER" resulted in a successful boot of the bsd.rd kernel (and efifb is showing the monitor as connected). I tried bsd.rd renamed "bsd" so it would only boot bsd.rd, and then firing the machine up and plugged the monitor in AFTER the boot process (probably) started hoping to see some indication on the screen of the crash. Result: no display until the kernel crashes and the system reboots. Nick. Got contacted by someone off-list who told me they "fixed" this problem on their machine by switching to a serial console, which is cool, but my machine doesn't have a serial console. (set tty com0 resulted in a hang, as it was probably waiting for the UART to say, "Sent that first character" and it never does). Is it possible that bsd.rd *must* have some kind of output device? efifb fails to configure without a monitor attached, so no console output? For giggles, I did a "gop" and a "video" at the boot> prompt, and both came back with no response, just another boot> prompt. Nick.
Re: HP T430 "Thin Client": Won't sysupgrade without HDMI monitor attached.
On 5/6/22 12:48 PM, Theo de Raadt wrote: Florian Obser wrote: So, if you end up with a /bsd.upgrade on the running system that is still mode 0700, your bootloader is on the fritz. If you have a /bsd.upgrade that's 0600 your bootloader found the kernel and tried to boot it, but the installer didn't get very far. If there is no /bsd.upgrade after a reboot and no email to root the installer got rebooted by a watchdog process, otherwise you got an email to root detailing the upgrade process. A very nice 3-way split. Brilliant, even. Then once you figure out which one of those 3 is happening, it is easy to reason about how to create further differentiations and see which is happening. I was very much guessing it was /boot, but no. -rw--- 1 root wheel 4609699 May 6 13:13 bsd.upgrade So ... it's booting bsd.upgrade and failing, which explains why copying bsd.upgrade (aka bsd.rd) to /bsd tossed it into a lala-loop. Unfortunately, this machine doesn't retain dmesg buffer between boots. so ... booted bsd.rd with a monitor attached, and grabbed the dmesg below. I'm looking at this: efifb0 at mainbus0: 1920x1080, 32bpp If the system is booted (bsd) without a monitor attached, that says: efifb at mainbus0 not configured Getting to the boot> prompt, typing "boot bsd.rd", unplugging the monitor and hitting "ENTER" resulted in a successful boot of the bsd.rd kernel (and efifb is showing the monitor as connected). I tried bsd.rd renamed "bsd" so it would only boot bsd.rd, and then firing the machine up and plugged the monitor in AFTER the boot process (probably) started hoping to see some indication on the screen of the crash. Result: no display until the kernel crashes and the system reboots. Nick. OpenBSD 7.1-current (RAMDISK_CD) #468: Tue May 3 12:18:55 MDT 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 1686781952 (1608MB) avail mem = 1631703040 (1556MB) random: good seed from bootblocks mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x6a8a7000 (23 entries) bios0: vendor AMI version "N41 v01.06" date 03/14/2019 bios0: HP HP t430 Thin Client acpi0 at bios0: ACPI 6.1 acpi0: tables DSDT FACP FPDT FIDT MCFG DBG2 DBGP HPET LPIT APIC NPKT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT UEFI DBGP SSDT WDAT NHLT WSMT 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) N4000 CPU @ 1.10GHz, 1096.97 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,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu0: 4MB 64b/line 16-way L2 cache cpu0: apic clock running at 19MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.2.4.2.1.1, IBE cpu at mainbus0: not configured ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 120 pins acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (RP01) acpiprt2 at acpi0: bus -1 (RP02) acpiprt3 at acpi0: bus 1 (RP03) acpiprt4 at acpi0: bus 2 (RP04) acpiprt5 at acpi0: bus -1 (RP05) acpiprt6 at acpi0: bus -1 (RP06) acpiec0 at acpi0: not present acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 "ALPS0001" at acpi0 not configured "WCOM508E" at acpi0 not configured "FS4304" at acpi0 not configured acpicmos0 at acpi0 "INT33A1" at acpi0 not configured "PNP0C14" at acpi0 not configured "PNP0C0C" at acpi0 not configured "USBC000" at acpi0 not configured "PNP0C14" at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpicpu at acpi0 not configured acpitz at acpi0 not configured pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Gemini Lake Host" rev 0x03 "Intel Gemini Lake GNA" rev 0x03 at pci0 dev 0 function 3 not configured "Intel UHD Graphics 600" rev 0x03 at pci0 dev 2 function 0 not configured "Intel Gemini Lake HD Audio" rev 0x03 at pci0 dev 14 function 0 not configured "Intel Gemini Lake MEI" rev 0x03 at pci0 dev 15 function 0 not configured ppb0 at pci0 dev 19 function 0 "Intel Gemini Lake PCIE" rev 0xf3: msi pci1 at ppb0 bus 1 re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x15: RTL8168H/8111H (0x5400), msi, address 04:0e:3c:12:53:85 rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0 ppb1 at pci0 dev 19 function 1 "Intel Gemini Lake PCIE" rev 0xf3: msi pci2 at ppb1 bus 2 iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless-AC 9260" rev 0x29, msix xhci0 at pci0 dev 21 function 0 "Intel Gemini Lake xHCI" rev 0x03: msi, xHCI 1.0 usb0 at xhci0:
Re: HP T430 "Thin Client": Won't sysupgrade without HDMI monitor attached.
Florian Obser wrote: > So, if you end up with a /bsd.upgrade on the running system that is > still mode 0700, your bootloader is on the fritz. > > If you have a /bsd.upgrade that's 0600 your bootloader found the kernel > and tried to boot it, but the installer didn't get very far. > > If there is no /bsd.upgrade after a reboot and no email to root the > installer got rebooted by a watchdog process, otherwise you got an email > to root detailing the upgrade process. A very nice 3-way split. Then once you figure out which one of those 3 is happening, it is easy to reason about how to create further differentiations and see which is happening.
Re: HP T430 "Thin Client": Won't sysupgrade without HDMI monitor attached.
On 2022-05-06 12:00 -04, Nick Holland wrote: > here's a weird one. > > HP T430 Thin Client, reloaded with OpenBSD. > In it's intended use, it runs Linux in BIOS boot mode. OpenBSD's > installer will boot that way, but the kernel is unable to see the > 16g storage device. In UEFI boot mode, OpenBSD works well, > including running X. This machine has ONLY HDMI and DisplayPort > video connections (one each). There's no com port on the box for > an alternative view of what is going on. > > The problem comes when I put them to work without a monitor. > > The machine will boot fine, run fine...but sysupgrade fails to upgrade > the system. It downloads the intended files, it reboots, and a few > moments later, it's back up and running -- the old kernel. Plug an > HDMI monitor in, run sysupgrade again, and it sees the upgrade marker > and does the upgrade. Textbook Heisenbug :-/ > > For giggles, I did a sysupgrade -k (keep the files), let it reboot, > in the root directory was bsd.upgrade as expected. I copied Not realy, -k keeps stuff in /home/_sysupgrade. bsd.upgrade gets deleted by the installer. My guess is bsd.rd panics when there is not monitor plugged in. You could plug in a monitor to see why it panics, oh wait... :P > bsd.upgrade to /bsd, forcing it one way or another to run > bsd.upgrade ... and the result was a hung system. Never came back > after the reboot, no idea why. When I moved it to be near an HDMI > monitor, it promptly booted, complained about permissions on > bsd.upgrade, but upgraded perfectly (but I am not sure which of > the two copies of the kernel it used). > > What can I do to help provide info to determine what is going on > here? I can't debug this, but I can tell you a bit about the interaction between sysupgrade(8), the bootloader and the installer in bsd.rd. >From there you can figure out how for you got. sysupgrade downloads the sets into /home/_sysupgrade and verifies them. Then it creates /auto_upgrade.conf and installs /home/_sysupgrade/bsd.rd as /bsd.upgrade. so bsd.upgrade is a bsd.rd, there is nothing special about it. /bsd.upgrade is installed with mode 0700. Then it execs reboot. The bootloader checks if there is an executable(!) /bsd.upgrade available, if so it does a chmod u-x /bsd.upgrade and boots it. If not it consults /etc/boot.conf and boots /bsd or whatever /etc/boot.conf says. The installer then checks if this is an unattended upgrade by checking if bsd.upgrade and auto_upgrade.conf are present. If so it runs an unattended upgrade. Very early in that process, after checking the disks and mounting all partitions, the installer delets bsd.upgrade and auto_upgrade.conf. So, if you end up with a /bsd.upgrade on the running system that is still mode 0700, your bootloader is on the fritz. If you have a /bsd.upgrade that's 0600 your bootloader found the kernel and tried to boot it, but the installer didn't get very far. If there is no /bsd.upgrade after a reboot and no email to root the installer got rebooted by a watchdog process, otherwise you got an email to root detailing the upgrade process. -- I'm not entirely sure you are real.
kernel: page fault trap, code=0
Hello,
I'm unable to boot into my OpenBSD 7.1 - CURRENT Desktop. I have been using
this desktop without issue since the release of 7.1
Today when booting I see the following message:
OpenBSD 7.1-current (GENERIC.MP) #496: Wed May 4 14:10:06 MDT 2022
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 34246377472 (32659MB)
avail mem = 33191153664 (31653MB)
kernel: page fault trap, code = 0
Stopped at SHA512Final: addb %al,0(%rax)
ddb{0}>
ddb{0}> trace
SHA512Final(8271bdf0,8271bd20,2bc11015d414a77c,4b2d3f50a8f5a93c,77ff031..more
stuff I don't want to type out...) at SHA512Final
extract_entropy(...) at extract_entropy+0x68
_rs_stir(...) at _rs_stir_0x25
random_start(...) at random_start+0x8e
main(...) at main+0x91
end trace frame: 0x0, count: -4
ddb{0}>
I had to manually type this on a different computer because I can't interact
with the crashed one. Any advice on recovering the system so I can troubleshoot?
Thanks,
Sean
Re: Howto do "a detailed cleanup with the aid of the sysclean package"?
Look, can we all just agree it is just a question of adding appropriate verbiage to the port/package, sticking a huge CAVEAT on the documentation leading to it, and go back to writing actual code ?
HP T430 "Thin Client": Won't sysupgrade without HDMI monitor attached.
here's a weird one. HP T430 Thin Client, reloaded with OpenBSD. In it's intended use, it runs Linux in BIOS boot mode. OpenBSD's installer will boot that way, but the kernel is unable to see the 16g storage device. In UEFI boot mode, OpenBSD works well, including running X. This machine has ONLY HDMI and DisplayPort video connections (one each). There's no com port on the box for an alternative view of what is going on. The problem comes when I put them to work without a monitor. The machine will boot fine, run fine...but sysupgrade fails to upgrade the system. It downloads the intended files, it reboots, and a few moments later, it's back up and running -- the old kernel. Plug an HDMI monitor in, run sysupgrade again, and it sees the upgrade marker and does the upgrade. Textbook Heisenbug :-/ For giggles, I did a sysupgrade -k (keep the files), let it reboot, in the root directory was bsd.upgrade as expected. I copied bsd.upgrade to /bsd, forcing it one way or another to run bsd.upgrade ... and the result was a hung system. Never came back after the reboot, no idea why. When I moved it to be near an HDMI monitor, it promptly booted, complained about permissions on bsd.upgrade, but upgraded perfectly (but I am not sure which of the two copies of the kernel it used). What can I do to help provide info to determine what is going on here? Nick. OpenBSD 7.1-current (GENERIC.MP) #493: Tue May 3 12:14:02 MDT 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 1686781952 (1608MB) avail mem = 1618399232 (1543MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x6a8a7000 (23 entries) bios0: vendor AMI version "N41 v01.06" date 03/14/2019 bios0: HP HP t430 Thin Client acpi0 at bios0: ACPI 6.1 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP FPDT FIDT MCFG DBG2 DBGP HPET LPIT APIC NPKT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT UEFI DBGP SSDT WDAT NHLT WSMT acpi0: wakeup devices SIO1(S3) HDAS(S3) XHC_(S4) XDCI(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(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) N4000 CPU @ 1.10GHz, 1096.97 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: 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) N4000 CPU @ 1.10GHz, 1096.97 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: 4MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 120 pins acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (RP01) acpiprt2 at acpi0: bus -1 (RP02) acpiprt3 at acpi0: bus 1 (RP03) acpiprt4 at acpi0: bus 2 (RP04) acpiprt5 at acpi0: bus -1 (RP05) acpiprt6 at acpi0: bus -1 (RP06) acpiec0 at acpi0: not present acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 "ALPS0001" at acpi0 not configured "WCOM508E" at acpi0 not configured "FS4304" at acpi0 not configured acpicmos0 at acpi0 "INT33A1" at acpi0 not configured "PNP0C14" at acpi0 not configured acpibtn0 at acpi0: PWRB "USBC000" at acpi0 not configured "PNP0C14" at acpi0 not configured acpipwrres0 at acpi0: DRST acpipwrres1 at acpi0: DRST acpipwrres2 at acpi0: DRST acpipwrres3 at acpi0: DRST acpipwrres4 at acpi0: DRST acpipwrres5 at acpi0: DRST acpipwrres6 at acpi0: WRST acpicpu0 at acpi0: C1(@1 halt!), PSS acpicpu1 at acpi0: C1(@1 halt!), PSS acpitz0 at acpi0acpitz0: TZ01: failed to read _TMP acpitz0: TZ01: failed to read _TMP acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: DD1F cpu0: Enhanced SpeedStep 1096 MHz: speeds: 1101, 1100, 1000, 900, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function
Re: Softraid on NVMe
On 5/6/22 9:03 AM, Proton wrote: Hi, I'm using softraid 1C on my remote dedicated server, built on two NVMe disks. It works really well from performance perspective and provide some data protection, but there is no way to check device health status because SMART doesn’t work. I guess bioctl will tell me only if devices are ‚online’, but nothing more? wella softraid device isn't a physical device, so, I'm not sure what you would get that you couldn't get out of bioctl. I have: bioctl softraid0 in my /etc/daily.local, and I also have a backup system that checks softraid status on all systems (hey, as long as I'm in the neighborhood and doing stuff as root...) You can look at the SMART status of the underlying physical devices in the softraid set exactly as you would non-softraid drives. So, if you put a lot of faith in SMART (I don't), what are you missing? Are there any "poor man’s” methods for checking state of devices you would suggest to perform periodically - like ‚cat /dev/rsd0c > /dev/null’ + ‚cat /dev/rsd1c > /dev/null’? Will potential I/O errors or timeouts be reported to stderr or to some system log file? doing read tests like that over the entire underlying drives seems like a good idea to me. Haven't implemented it so I can't say how it would respond to real problems, but I can think of only one good way to find out. (from experience: how things act when a drive fails are hard to predict and really hard to test. So even a dozen "this is how it behaved" results doesn't tell you what happens for the NEXT failure) I would definitely want to put some rate limiting on it so you don't kill performance overall. As last method I can reboot to linux rescue from time to time, but this would be not very convenient. Should I forget about NVMe and use other option - LSI MegaRaid HW with SSD disks attached? what would you gain there? Now you could only access what the controller thinks of the drive's state through bioctl (which you seemed to think was inadequate for softraid). In the HW vs. SW RAID argument, I'm firmly in the "either way" camp, but if I understand your query, you are LOSING info here. (I've also heard stories about SSDs and HW RAID not playing well together, but I'm not prepared to defend or refute that statement. On the other hand, I've seen SSDs work differently enough from what HW and SW expect that ... nothing would surprise me). Nick.
Re: Modern RFC3442 (Classless DHCP Static Routes)
On 2022-05-06 10:28 -04, Sonic wrote: > On Fri, May 6, 2022 at 7:18 AM Florian Obser wrote: >> Also, dhcpd(8) does not even hand out option 3 when option 121 is >> configured. > > That doesn't seem like correct behavior (the ISC version certainly > offers both). Both options should be sent if configured, it's up to > the client to properly handle this. > Clients that are rfc3442 compliant will install the option 121 routes, > clients that are not rfc3442 compliant will ignore option 121 and > install the gateway supplied by option 3. If dhcpd doesn't hand out > option 3 when option 121 is configured then clients that are not > rfc3442 compliant will not receive a gateway address. > I fully agree, I was very surprised when I discovered this behaviour. But I haven't chased it down why this is. -- I'm not entirely sure you are real.
Re: Modern RFC3442 (Classless DHCP Static Routes)
On Fri, May 6, 2022 at 7:18 AM Florian Obser wrote: > Also, dhcpd(8) does not even hand out option 3 when option 121 is > configured. That doesn't seem like correct behavior (the ISC version certainly offers both). Both options should be sent if configured, it's up to the client to properly handle this. Clients that are rfc3442 compliant will install the option 121 routes, clients that are not rfc3442 compliant will ignore option 121 and install the gateway supplied by option 3. If dhcpd doesn't hand out option 3 when option 121 is configured then clients that are not rfc3442 compliant will not receive a gateway address.
Re: QT App & CWM
This worked wonderfully - thank you! On 5/5/22 23:40, kelly wrote: I had this issue awhile back and was able to resolve it by setting xrandr --dpi 96. I added it to my xsession. Not sure if this is a great solution, but it worked for me. Best, Kelly On Thu, May 05, 2022 at 05:00:24PM -0400, David Anthony wrote: Hello, I've recently installed 7.1 on a machine and run CWM. I noticed certain QT applications appear with distorted resolution - nearly take up my entire screen. Is there a configuration change I can make or package which addresses this? The app in question is KeepassXC FWIW. Respectfully, David Anthony
Re: Modern RFC3442 (Classless DHCP Static Routes)
On 2022-05-06 08:26 UTC, Stuart Henderson wrote: > On 2022-05-04, nace...@narwhals.org wrote: >> https://marc.info/?l=openbsd-tech=162652200109398=2 I disagree. >> while its technically correct with the rfc, in practice, not many OSes >> rigidly enforces not using the router option when 121 is present that >> I've used. > > It's not just technically correct, handling this differently would be > *in*correct, it is a MUST in the RFC. > >> This is how dhcpleased works in -current: >> 1) if a client using dhcpleased gets an option 121 set of routes, it >> ignores the dhcp router option. > > right. > >> 2) dhcpleased enforces that it wont hand out a 0.0.0.0 destination route >> in option 121 > > if this is the case, it's a problem, option 121 routes must be able to set > 0.0.0.0/0. can you show your working for figuring this out as that might > give a clue what's wrong? debug logs and packet captures might help. It is not the case. This just works fine in dhcpleased(8). Also, dhcpd(8) does not even hand out option 3 when option 121 is configured. (Also dhcpleased does not "hand out" anything. I assume the OP means "configures a default route in the FIB.") -- I'm not entirely sure you are real.
Re: Howto do "a detailed cleanup with the aid of the sysclean package"?
On 2022-05-04, Theo de Raadt wrote: > I have also pointed out a couple of times now that sysclean ignores the > lessons of "find -print0" and "xargs -0", and I worry it could find a > file called > > "/somewhere/matchingpattern/\n/etc/spwd.db" Thus is easily fixed by adding a "delete" mode which removes the files internally in sysclean.
Re: Modern RFC3442 (Classless DHCP Static Routes)
On 2022-05-04, nace...@narwhals.org wrote: > https://marc.info/?l=openbsd-tech=162652200109398=2 I disagree. > while its technically correct with the rfc, in practice, not many OSes > rigidly enforces not using the router option when 121 is present that > I've used. It's not just technically correct, handling this differently would be *in*correct, it is a MUST in the RFC. > This is how dhcpleased works in -current: > 1) if a client using dhcpleased gets an option 121 set of routes, it > ignores the dhcp router option. right. > 2) dhcpleased enforces that it wont hand out a 0.0.0.0 destination route > in option 121 if this is the case, it's a problem, option 121 routes must be able to set 0.0.0.0/0. can you show your working for figuring this out as that might give a clue what's wrong? debug logs and packet captures might help. > What I've seen (and rely on with other OSes) is to honor dhcp routers and > option 121. which OS are explicitly breaking this RFC and how are they doing it? i.e. what happens if there are conflicting default routes between the two options? > if the client doesnt like the dhcp routers setting, there is > option 121. if the client doesnt like the dhcp routers setting, there is > usually a flag to ignore that (or the dhcp server can be configured to > hand out a lease without a routers option for that client) the client shouldn't do this, the whole point of DHCP is that it's a protocol where the network admin sets things up. > If there is no method to have the client ignore the routers option of the > lease, folks who for whatever reason rely on rfc3442 explicit behavior > might not like this change - but again, I suspect this is not the right > default here and that the rfc3442 has a bit of a glitch This isn't something that was just forgotten in the RFC, it was explicitly considered and the authors chose to do it this way and the reviewers agreed. > (either support > handing out the 0.0.0.0 route in option 121 or honor routers and option > 121 (and 249, fine, microsoft)... but dont do what it currently spells out > and get no default routes when option 121 is in use - thats painful.) It seems quite clear-cut that the network is misconfigured in this case... *maybe* there's a case for a "the network admin doesn't know what they're doing" option to allow getting a default route in this case but I definitely think it is wrong to change this default behaviour.
Re: OpenBSD ftp and libtls: how to use session resumption with -S
On 2022-05-06, Theo Buehler wrote: > While we could readily make libssl fall back to the legacy stack if > SSL_OP_NO_TICKET is disabled, I don't think this optimization outweighs > the overall benefit of TLSv1.3 - better protocol, cleaner code. Especially when the major beneficiary of this is pkg_add when it searches for updates; the number of connections has been *hugely* reduced with the caching added recently.
Firefox and stuttering USB audio
Hello all,
First time on the mailing list, please forgive me if I am missing any
"netiquette". I've been using OpenBSD on my desktop these last few
weeks. I have been trying to solve an issue with Only Firefox causing
stuttering issues with my audio output. Some things I have tried are:
* Setting dom.ipc.processCount to a lower number in about:config
* Muddled with sndiod -b and -z flags
* Set softdep,noatime for my different partitions in fstab (NVMe drive)
* Tried with/without SMT (Intel 10700k)
* Set some sysctl flags:
kern.shminfo.shmall=3145728
kern.shminfo.shmmax=2147483647
kern.shminfo.shmmni=2048
kern.shminfo.shmseg=2048
kern.seminfo.semmns=4096
kern.seminfo.semmni=2048
kern.maxproc=32768
kern.maxfiles=65535
kern.bufcachepercent=80
kern.maxvnodes=32
kern.somaxconn=4096
It would seem some things might work at first and pretty quickly I
would realize none of these things worked. The only solution has
been to not use Firefox. Tried chromium but it saddens me to see
that keepassxc-proxy & u2f doesn't work there.
Seems there's quite a few play errors:
# audioctl -f /dev/audioctl1 play.{bytes,errors}
play.bytes=242641680
play.errors=130560
play.errors does not go up when firefox is closed. According to the faq
it seems it could mean that the device has underrun samples. Whatever
that means, I'm unsure how to fix it. This has been a big headache for
me and I'm hoping someone could guide me to a solution here.
My DAC is a FiiO E10k
Running -current branch
$ uname -a
OpenBSD towerDefense 7.1 GENERIC.MP#492 amd64
I'm on the latest firefox (100.0)
Audio device is rsnd/1
Here is my system's dmesg below:
OpenBSD 7.1-current (GENERIC.MP) #492: Tue May 3 08:40:53 MDT 2022
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 34261110784 (32673MB)
avail mem = 33205428224 (31667MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.2 @ 0x7eb5a000 (94 entries)
bios0: vendor American Megatrends Inc. version "A.A0" date 10/22/2021
bios0: Micro-Star International Co., Ltd. MS-7C75
acpi0 at bios0: ACPI 6.2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP MCFG SSDT SSDT FIDT SSDT SSDT HPET APIC SSDT
SSDT NHLT LPIT SSDT SSDT DBGP DBG2 SSDT VFCT TPM2 WSMT FPDT BGRT
acpi0: wakeup devices PEG2(S4) PEGP(S4) PEG3(S4) PEGP(S4) PEGP(S4)
PEG1(S4) PEGP(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4)
RP04(S4) PXSX(S4) RP05(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-10700K CPU @ 3.80GHz, 4800.05 MHz, 06-a5-05
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,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-10700K CPU @ 3.80GHz, 4800.05 MHz, 06-a5-05
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,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,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7-10700K CPU @ 3.80GHz, 4800.05 MHz, 06-a5-05
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,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,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i7-10700K CPU @ 3.80GHz,
