Re: Following the upgrade to 6.8, sshguard is reporting that it fails to start
On Wed, 28 Oct 2020 16:53:03 -0500, Todd wrote: > Following the upgrade to 6.8, rcctl is reporting that sshguard fails > to start. > > rcctl check sshguard > sshguard(failed) > [...] > apu$ rcctl get sshguard > > > sshguard_class=daemon > sshguard_flags=-l /var/log/authlog -a 5 -b > 10:/var/db/sshguard/blacklist.db -w xxx.xxx.xxx.xxx Yeah the pexp (from pkg/sshguard.rc) seems to be broken as it won't match as soon as you set some custom daemon_flags. The port has a maintainer so you should mail them (with or without a Cc: ports@, as you like). Or you can try to fix it yourself by playing with pgrep(1) (check what exact command it runs in /etc/rc.d/rc.subr) and looking at what pexp other ports rc scripts define. Cheers, Daniel
Re: wg(4) listen on a specific interface / address
Pierre Emeriaud wrote: > Le mar. 27 oct. 2020 à 23:46, j...@snoopy.net.nz a écrit > : > > > > > > > > Hi Pierre, > > > > The error may indicate that port 53 on 127.0.0.1 is already used by another > > service. This appears to be confirmed by your netstat example. This is > > probably a dns service. > > Thanks Joe. This is indeed a dns daemon, several in fact. But nothing > should prevent wireguard from using port 53 on any other IP address > than 127.0.0.1 here. (well, nothing but the code that has been > implemented) I believe you are running into the restriction that we don't allow an INADDR_ANY:port binding to be done after a ipaddr:port binding has been done. It must be done beforehands.
Re: wg(4) listen on a specific interface / address
> On Oct 28, 2020, at 6:21 PM, Brian Brombacher wrote: > > > >> On Oct 28, 2020, at 5:07 PM, Pierre Emeriaud >> wrote: >> >> Le mar. 27 oct. 2020 à 23:46, j...@snoopy.net.nz a >> écrit : >>> >>> >>> >>> Hi Pierre, >>> >>> The error may indicate that port 53 on 127.0.0.1 is already used by another >>> service. This appears to be confirmed by your netstat example. This is >>> probably a dns service. >> >> Thanks Joe. This is indeed a dns daemon, several in fact. But nothing >> should prevent wireguard from using port 53 on any other IP address >> than 127.0.0.1 here. (well, nothing but the code that has been >> implemented) >> > > Can you specify separate rdomains for the wg interfaces and still use port 53 > on all plus a dns daemon? > > I have not experimented with any of this guidance. > Scratch that, use the ifconfig wgrtable option to specify separate routing domains for the port 53. This lets you initiate many. You still need to deal with getting the IP pointing at the right routing domain now. https://man.openbsd.org/ifconfig#wgrtable
Re: wg(4) listen on a specific interface / address
> On Oct 28, 2020, at 5:07 PM, Pierre Emeriaud > wrote: > > Le mar. 27 oct. 2020 à 23:46, j...@snoopy.net.nz a > écrit : >> >> >> >> Hi Pierre, >> >> The error may indicate that port 53 on 127.0.0.1 is already used by another >> service. This appears to be confirmed by your netstat example. This is >> probably a dns service. > > Thanks Joe. This is indeed a dns daemon, several in fact. But nothing > should prevent wireguard from using port 53 on any other IP address > than 127.0.0.1 here. (well, nothing but the code that has been > implemented) > Can you specify separate rdomains for the wg interfaces and still use port 53 on all plus a dns daemon? I have not experimented with any of this guidance.
Following the upgrade to 6.8, sshguard is reporting that it fails to start
I have been using the sshguard package for the last several releases. Following the upgrade to 6.8, rcctl is reporting that sshguard fails to start. rcctl check sshguard sshguard(failed) Below is the relevant information I can think of to provide. Are there additional troubleshooting steps or other data that would help? I can see from the logs that sshguard is working. 2020 Oct 28 10:08:48: 192.168.10.10 (auth/notice) [sshguard] Attack from "52.187.117.17" on service SSH with danger 2. 2020 Oct 28 10:08:48: 192.168.10.10 (auth/notice) [sshguard] Attack from "52.187.117.17" on service SSH with danger 2. 2020 Oct 28 10:08:48: 192.168.10.10 (auth/notice) [sshguard] Attack from "213.32.22.189" on service SSH with danger 10. 2020 Oct 28 10:08:48: 192.168.10.10 (auth/warning) [sshguard] Blocking "213.32.22.189/32" forever (1 attacks in 0 secs, after 1 abuses over 0 secs.) And I can see the sshguard process is running apu# ps aux|grep sshguard root 76181 0.0 0.0 284 1248 p0 S+p12:44PM0:00.01 grep sshguard root 64083 0.0 0.0 732 760 00- Ip 12:22PM0:00.01 /bin/sh /usr/local/sbin/sshguard -l /var/log/authlog -a 5 -b 10:/var/db/sshguard/bla root 51935 0.0 0.0 732 652 00- Ip 12:22PM0:00.01 /bin/sh /usr/local/sbin/sshguard -l /var/log/authlog -a 5 -b 10:/var/db/sshguard/bla root 51242 0.0 0.4 11712 17876 00- Ip 12:22PM0:02.36 /usr/local/libexec/sshg-blocker -a 5 -b 10:/var/db/sshguard/blacklist.db -p 120 -s 1 The sshguard flags are (Employer's IP address redacted): apu$ rcctl get sshguard sshguard_class=daemon sshguard_flags=-l /var/log/authlog -a 5 -b 10:/var/db/sshguard/blacklist.db -w xxx.xxx.xxx.xxx sshguard_rtable=0 sshguard_timeout=30 sshguard_user=root I see on https://openports.se/security/sshguard that there was a version update from sshguard-2.3.1to sshguard-2.4.1 I've ran pkg_add -u to make sure I was not missing an update apu# pkg_info sshguard Information for inst:sshguard-2.4.1 apu# sshguard -v SSHGuard 2.4.1 /etc/sshguard.conf is unmodified from the package example apu# diff /etc/sshguard.conf /usr/local/share/examples/sshguard/sshguard.conf.sample apu# 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 = 4259885056 (4062MB) avail mem = 4115726336 (3925MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xcfe8c020 (13 entries) bios0: vendor coreboot version "v4.12.0.1" date 05/29/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 HPET acpi0: wakeup devices PWRB(S4) 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.14 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.14 MHz, 16-30-01 cpu2:
Re: wg(4) listen on a specific interface / address
Le mar. 27 oct. 2020 à 23:46, j...@snoopy.net.nz a écrit : > > > > Hi Pierre, > > The error may indicate that port 53 on 127.0.0.1 is already used by another > service. This appears to be confirmed by your netstat example. This is > probably a dns service. Thanks Joe. This is indeed a dns daemon, several in fact. But nothing should prevent wireguard from using port 53 on any other IP address than 127.0.0.1 here. (well, nothing but the code that has been implemented)
Re: wg(4) listen on a specific interface / address
Hi Brian Le mar. 27 oct. 2020 à 23:07, Brian Brombacher a écrit : > > I wonder if multiple ports, 5053, 5153 (and so on) redirected using pf rdr-to > rules may work? That way you can setup rules like first IP + port 53 > redirect to 5053, second IP + 53 redirect to 5153? > > May be worth a shot trying. Not an answer to your question, but as a > workaround for others. I just tried that, with rdr-to for inbound and nat-to for outbound. It could work indeed, but I did not manage to make it work properly. match in quick on $wan proto udp from any to $vpnip port 53 rdr-to self port 24854 rtable 1 match out quick on $wan proto udp from $vpnip to any port 24854 nat-to $vpnip port 53 rtable 1 Anyhow this is unfortunately painful. This means that any port shown on 'ifconfig wg' has to be mentally merged with pf rules, and while this could technically work, this is difficult to troubleshoot :(
Re: snapshot boot fails with error "entry point at 0x1001000"
Hi all, For the record, Mark Kettenis' patch below fixed the boot stuck problem on my Intel NUC Kit NUC7PJYH mini server, see the following email thread: https://marc.info/?l=openbsd-misc=160391516603159 Thanks a lot for this. Cheers. Fabian > Hi Mark, > > on my Lenovo V130 the patch works. Now I'm able to boot the current > kernel again, without the need to remove the radeon and amdgpu driver > (https://marc.info/?l=openbsd-misc=159276382718317=2) > > Thanks and best regards, > Sven > > On 10/27/20 1:40 PM, Mark Kettenis wrote: > > Hi Kastus, > > > > Please don't have technical discussions on misc@; some developers, > > like me, only read it sporadically. The tech@ list is a much better > > place. > > > > The problem with your approach is that you allocate memory at a fixed > > address, and we can't be sure that memory is available. We may have > > to extend the amount of memory we allocate such that larger kernels > > fit. The diff below bumps it from 32MB to 64MB. Does this work for > > you? > > > > > > Index: arch/amd64/stand/efiboot/efiboot.c > > === > > RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/efiboot.c,v > > retrieving revision 1.35 > > diff -u -p -r1.35 efiboot.c > > --- arch/amd64/stand/efiboot/efiboot.c 22 Mar 2020 14:59:11 - > > 1.35 > > +++ arch/amd64/stand/efiboot/efiboot.c 27 Oct 2020 12:36:45 - > > @@ -39,7 +39,7 @@ > > #include "eficall.h" > > #include "run_i386.h" > > > > -#defineKERN_LOADSPACE_SIZE (32 * 1024 * 1024) > > +#defineKERN_LOADSPACE_SIZE (64 * 1024 * 1024) > > > > EFI_SYSTEM_TABLE *ST; > > EFI_BOOT_SERVICES *BS;
Re: Using ports and updates to the release
Hi Marc, Thanks for your reply. I think maybe this belongs to ports more than misc. But it's a general query about releases and ports as well. My question was actually about updating the ports tree from an older release version before trying to use it rather than whether to use ports or packages. I installed 6.2 release I believe and later upgraded to 6.6 release. I pulled the release version of ports at some point and later tried to build a port which failed due to an outdated dependency. My version of the ports tree was outdated but even the newer 6.6 stable version was also outdated. When I sent my original email 6.6 was still one of the supported releases along with 6.7. I guess my question is if I run 6.x release and want to build port xyz can I expect a port to build using the ports tree that came with the 6.x release or must I always use at least the stable version of the ports tree? The following question is then if I have a problem building a port due to an outdated dependency on a supported release should I report it as an issue with the port even if a newer release of openbsd does not have the issue? Regards Ed Gray On Wed, 28 Oct 2020, 7:07 am Marc Espie, wrote: > On Sun, Oct 11, 2020 at 09:12:13PM +0200, Ingo Schwarze wrote: > > Hi Ed, > > > > Ed Gray wrote on Sun, Oct 11, 2020 at 07:21:32PM +0100: > > > > > I'm still fairly new to openbsd and the idea of using ports > > > in general rather than binary packages. > > > > You are usually better off using packages than using ports, > > especially as a new user. > > > > Even as an experienced user doing lots of development and minor > > amounts of ports development, i use packages most of the time. > > As one of the persons *responsible* for keeping the ports system > working, I do use packages all the time. > > Ports are on my development setup. > > The machine I write this mail from uses packages, > with about 3 ports that are just there because not committed yet. >
Re: OpenBSD 6.8 release boot stuck on Intel NUC NUC7PJYH
Hi Sven, misc, Thanks for your email and the effort of putting up a patched EFI boot file. Much appreciated. It took a long time to make a release in my case. I too can confirm that the patch by Marc Kettenis linked below [1] resolved the boot issue on the Intel NUC. It boots fine again now, and I could complete the post-upgrade steps for OpenBSD 6.8 release without problems. To resolve the issue, I basically did what you suggested. However, after the heads-up from Theo in the other email thread [2], I used the BOOTIA32.EFI and BOOTX64.EFI files from the latest official snapshot, and not the one that you shared earlier. Specifically, I did the following: * Boot into bsd.rd * Mount the local GPT EFI partition (mount -t msdos /dev/sd0i /mnt/efi) * Download the BOOTIA32.EFI and BOOTX64.EFI files from the latest OpenBSD snapshot from one of the mirror servers * Copy the two files into the EFI partition, replacing the files that were installed during the upgrade to OpenBSD 6.8 release * Reboot That procedure worked fine for me and was reasonably straightforward. Cheers. Fabian [1] https://marc.info/?l=openbsd-misc=160380332006125 [2] https://marc.info/?l=openbsd-misc=160390222432642 > Hi Fabian, > > the today posted patch from Marc Kettenis works on my system - > https://marc.info/?l=openbsd-tech=160383074317608=2 > > For test purposes you can download my build BOOTX64.EFI from > http://mailinglist.fusion-zone.net/BOOTX64.EFI > > Just replace it in your EFI partition. Please make a backup of your > BOOTX64.efi or download the original BOOTX64.EFI from > https://cdn.openbsd.org/pub/OpenBSD/6.7/amd64/ (in case of an error) again. > > Best regards, > Sven
Re: Chromium not starting on Thinkpad R40E with 6.8
On 2020-10-28, Ashton Fagg wrote: > Anthony Campbell writes: > >> I upgraded to the i386 version of 6.8-Release on three different >> Thinkpads R40E. On all of them, chromium fails to start, saying "Unable >> to allocate memory". >> >> I suppose these are so ancient that it's hardly surprising (can't be >> mamy still around), but I thought I'd report it anyway. Here is the >> dmesg: > > Two questions and a suggestion: > > 1. How much memory do the machines have? > > 2. Can you run chrome from the command line and post what gets put into > stdout/stderr? Both were answered in Anthony's original mail - "Unable to allocate memory" for your second q, and 2GB for the first (check the dmesg output).
Re: Chromium not starting on Thinkpad R40E with 6.8
On 2020-10-28, Anthony Campbell wrote:
> I upgraded to the i386 version of 6.8-Release on three different
> Thinkpads R40E. On all of them, chromium fails to start, saying "Unable
> to allocate memory".
How does your datasize limit look? Try bumping it as high as it will go
("infinity" in login.conf, which I think results in 3145728 in ulimit -d)
and see if that helps.
If it doesn't work at all please let me know so I can disable it on i386
and stop wasting time in the i386 bulk builds, it takes about 28 hours to
build which is a lot of time tying up the machine if the results are
useless :)
iridium may do better (at least for a while..)
Re: Chromium not starting on Thinkpad R40E with 6.8
Anthony Campbell writes: > I upgraded to the i386 version of 6.8-Release on three different > Thinkpads R40E. On all of them, chromium fails to start, saying "Unable > to allocate memory". > > I suppose these are so ancient that it's hardly surprising (can't be > mamy still around), but I thought I'd report it anyway. Here is the > dmesg: Two questions and a suggestion: 1. How much memory do the machines have? 2. Can you run chrome from the command line and post what gets put into stdout/stderr? Suggestion: See if you can get Chromium to start on a fresh profile (move the data folder in the home directory out of the way so it's like starting from fresh -- there may be a command line switch for that, not sure). That would rule out a problem with any add-ons that might be making this worse.
Re: Fwd: Re: man netstart(8) OpenBSD-6.8
aye agreed. Another option which we were also looking at it a community wiki as a separate src. So sys admins and devs can upload their own usage examples easily. With the caveat ofc that these are not official examples. If you could do something like a triple pipe ||| or even a "sudo !!!" and it would automatically upload as an example if the command worked that would be quite 21st century. But would be nice if we could alleviate the immense workload and bw from the present devs from having to add 10-20 examples for each command or even flag. My issue, even though I ran ITE, and lived on the CLI even in SunScreen was remembering all of the flags and their positioning. Examples really help on that front. Btw interesting signature Luke not that I particularly agree but nice to see another viewpoint, people seem to love the idea of the pre-universe getting flatulent and producing all of this life, biological programming, and beauty. The Big Bang is such a joke mathematically, just completely impossible, but people love to take sides. And I am NOT starting a religious conversation here! Just thought I would comment on your bravery. Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Tuesday, 27 October 2020 21:48, Luke Call wrote: > > - message from pipus pi...@protonmail.com - > > Date: Mon, 26 Oct 2020 08:29:41 + > > From: pipus pi...@protonmail.com > > To: Theo de Raadt dera...@openbsd.org > > Cc: "misc@openbsd.org" misc@openbsd.org > > Subject: Re: man netstart(8) OpenBSD-6.8 > > > > I could explain process class priority configuration until my mind is numb > > but in the end without seeing the commands that would actually be used it > > is really making your life far harder. > > I liked Theo's idea of having a "such as (possibly) x, y, and z, but see > the actual /etc/netstart script for accurate details", as striking a > good balance between being briefly informative with examples, and > more accurate over time. > > On Sunday, 25 October 2020 17:44, Theo de Raadt dera...@openbsd.org wrote: > > > Jason McIntyre j...@kerhand.co.uk wrote: > > > > > On Sun, Oct 25, 2020 at 10:16:54AM -0600, Theo de Raadt wrote: > > > > > > > Jason McIntyre j...@kerhand.co.uk wrote: > > > > > > > > > whereas /etc/netstart is actually doing: > > > > > > > > > > - configure non-physical: (1) > > > > > aggr trunk svlan vlan carp pppoe > > > > > > > > > > - routing (2) > > > > > > > > > > - rest of non-physical: (3) > > > > > tun tap gif etherip gre egre mobileip pflow wg > > > > > > > > > > > > > > > we could try to keep this list up to date, but it may be easier to > > > > > just > > > > > generally describe what netstart is doing. > > > > > > > > I think we goes wrong by trying to maintain these as lists, and part of > > > > where this goes wrong is weak definition of the reasons for the > > > > ordering. (Meaning, the developers who tweak netstart to handle the > > > > concerns I'm about to describe, don't tend to think about the manual > > > > page). > > > > The (1) list of non-physical can probably be called "link-layer control > > > > interfaces". Or let's find a name for this. These devices mutate the > > > > presentation of other devices. That's why their configuration needs to > > > > be done before the physical device. > > > > (2) The physical device is then brought up, including IP addressing. The > > > > things in (1) need to be done beforehands, or the physical device is > > > > participating in the wrong layer of network. > > > > the (3) list of non-physical devices are layer-2 or layer-3 and operate > > > > on devices which are already configured with some some sort of > > > > "addressing" configured. > > > > It would be nice to have our networking people come up with nice names > > > > for group (1) and (2); words which succinctly describe the > > > > classification like I've done above. We need to increase understanding > > > > of this order, rather than just abstractly listing names of devices with > > > > complicated behaviours. > > > > Once that is done, I still think it is problematic for us to list all > > > > devices in each catagory: > > > > a) new subsystems will be forgotten > > > > b) the order of instantiation will sometimes be listed wrong -- for some > > > > of these the order is highly significant. > > > > We can try to list as many as possible, but people who want the precise > > > > list (and order) should look in the netstart code. The lists will get > > > > long and wrong. If we find we cannot maintain the lists correctly > > > > because it is duplicated information, man page wording like "such as" > > > > could be used, also something which leads people to consider the script > > > > source as authoritative, ie. have them go read the script > > > > > > ok, here is a start. > > > i have left the description as "non-physical", because i think that is > > > clear. we could easily amend it. ifconfig.8 create
Chromium not starting on Thinkpad R40E with 6.8
I upgraded to the i386 version of 6.8-Release on three different
Thinkpads R40E. On all of them, chromium fails to start, saying "Unable
to allocate memory".
I suppose these are so ancient that it's hardly surprising (can't be
mamy still around), but I thought I'd report it anyway. Here is the
dmesg:
OpenBSD 6.8 (GENERIC.MP) #440: Sun Oct 4 18:33:20 MDT 2020
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
real mem = 2137407488 (2038MB)
avail mem = 2082074624 (1985MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 08/29/06, BIOS32 rev. 0 @ 0xfd6b0, SMBIOS rev. 2.4 @
0xe0010 (68 entries)
bios0: vendor LENOVO version "79ET67WW (1.11 )" date 08/29/2006
bios0: LENOVO 1951WAZ
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET BOOT SSDT SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4)
PCI1(S4) USB0(S3) USB1(S3) USB2(S3) USB7(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Genuine Intel(R) CPU T2400 @ 1.83GHz ("GenuineIntel" 686-class) 1.83 GHz,
06-0e-08
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,NXE,PERF,SENSOR,MELTDOWN
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 166MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Genuine Intel(R) CPU T2400 @ 1.83GHz ("GenuineIntel" 686-class) 1.83 GHz,
06-0e-08
cpu1:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,NXE,PERF,SENSOR,MELTDOWN
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped
acpimcfg0 at acpi0
acpimcfg0: addr 0xf000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (AGP_)
acpiprt2 at acpi0: bus 2 (EXP0)
acpiprt3 at acpi0: bus 3 (EXP1)
acpiprt4 at acpi0: bus 4 (EXP2)
acpiprt5 at acpi0: bus 12 (EXP3)
acpiprt6 at acpi0: bus 21 (PCI1)
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
"PNP0A08" at acpi0 not configured
acpicmos0 at acpi0
"IBM0071" at acpi0 not configured
"ATM1200" at acpi0 not configured
acpibat0 at acpi0: BAT0 model "COMPATIBLE" serial 1242 type LION oem "SANYO"
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0: version 1.0
acpicpu0 at acpi0: !C3(100@17 io@0x1015), !C2(500@1 io@0x1014), C1(1000@1
halt), PSS
acpicpu1 at acpi0: !C3(100@17 io@0x1015), !C2(500@1 io@0x1014), C1(1000@1
halt), PSS
acpipwrres0 at acpi0: PUBS, resource for USB0, USB2, USB7
acpitz0 at acpi0: critical temperature is 127 degC
acpitz1 at acpi0: critical temperature is 99 degC
acpidock0 at acpi0: GDCK not docked (0)
acpivideo0 at acpi0: VID_
acpivideo1 at acpi0: VID_
bios0: ROM list: 0xc/0xe400! 0xce800/0x1000 0xcf800/0x1000 0xdc000/0x4000!
0xe/0x1
cpu0: Enhanced SpeedStep 1829 MHz: speeds: 1833, 1333, 1000 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82945GM Host" rev 0x03
inteldrm0 at pci0 dev 2 function 0 "Intel 82945GM Video" rev 0x03
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0: apic 1 int 16, I945GM, gen 3
"Intel 82945GM Video" rev 0x03 at pci0 dev 2 function 1 not configured
azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x02: msi
azalia0: codecs: Analog Devices AD1981HD, Conexant/0x2bfa, using Analog Devices
AD1981HD
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x02: apic 1 int 20
pci1 at ppb0 bus 2
em0 at pci1 dev 0 function 0 "Intel 82573L" rev 0x00: msi, address
00:16:41:aa:de:2d
ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x02: apic 1 int 21
pci2 at ppb1 bus 3
ath0 at pci2 dev 0 function 0 "Atheros AR5212" rev 0x01: apic 1 int 17
ath0: AR5424 10.3 phy 6.1 rf5424 10.2 eeprom 5.3, WOR2W, address
00:16:cf:4b:25:b5
ppb2 at pci0 dev 28 function 2 "Intel 82801GB PCIE" rev 0x02: apic 1 int 22
pci3 at ppb2 bus 4
ppb3 at pci0 dev 28 function 3 "Intel 82801GB PCIE" rev 0x02: apic 1 int 23
pci4 at ppb3 bus 12
uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x02: apic 1 int 16
uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x02: apic 1 int 17
uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x02: apic 1 int 18
uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x02: apic 1 int 19
ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x02: apic 1 int 19
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00
addr 1
ppb4 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xe2
pci5 at ppb4 bus 21
cbb0 at pci5
Re: Internal microphone not working
Ashton Fagg wrote: > I've translated that since I'm not sure those among us speak rude, > codescending clown. And now far fewer people want to help you. Such a winner...
Re: Internal microphone not working
Mihai Popescu writes: > [ ... ] > > So, why do you trim outputs? Where is the full dmesg? Do you fear something? > > Do you realize that your and other people's problems with sound in > particular CAN BE related to other hardware present in your computer or a > specific configuration? I'm not sure who you're replying to here, but I imagine what you're trying to say is: "It'd be helpful if you posted a full, unabridged dmesg output. Thanks" I've translated that since I'm not sure those among us speak rude, codescending clown. Now that I've done that, I'm happy to oblige with my dmesg. (I'll leave the irony of the fact you've whined about someone apparently trimming something while completely trimming your own quote so as to be totally useless, alone) OpenBSD 6.8-current (GENERIC.MP) #142: Tue Oct 27 15:23:47 MDT 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 16332681216 (15576MB) avail mem = 15822307328 (15089MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.2 @ 0xbf912000 (68 entries) bios0: vendor LENOVO version "R1CET36W(1.05 )" date 06/11/2020 bios0: LENOVO 20UH000CUS acpi0 at bios0: ACPI 6.3 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT SSDT SSDT IVRS SSDT SSDT TPM2 SSDT MSDM BATB HPET APIC MCFG SBST WSMT VFCT SSDT CRAT CDIT FPDT SSDT SSDT SSDT UEFI SSDT SSDT BGRT acpi0: wakeup devices GPP0(S3) RESA(S3) GPP4(S4) GPP5(S3) L850(S3) GPP6(S3) GPP7(S3) GP17(S3) XHC0(S3) XHC1(S3) LID_(S4) SLPB(S3) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Ryzen 7 PRO 4750U with Radeon Graphics, 1697.07 MHz, 17-60-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,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 8MB 64b/line disabled L3 cache cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: DTLB 64 4KB entries fully associative, 64 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, C-substates=1.1, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Ryzen 7 PRO 4750U with Radeon Graphics, 1696.81 MHz, 17-60-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,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 8MB 64b/line disabled L3 cache cpu1: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: disabling user TSC (skew=-381968623) cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD Ryzen 7 PRO 4750U with Radeon Graphics, 1696.81 MHz, 17-60-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,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 8MB 64b/line disabled L3 cache cpu2: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: disabling user TSC (skew=-381968588) cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD Ryzen 7 PRO 4750U with Radeon Graphics, 1696.81 MHz, 17-60-01 cpu3:
Re: Snapshot crash on boot, "entry point at: 0x1001000" (Intel Gemini Lake)
This particular diff is in snapshots. That's a shortcut which will let more people try it quicker, and report back. > thanks to the fix from Mark, see > https://marc.info/?l=openbsd-tech=160383074317608=2 the problem is > solved for my machine. > > Best regards, > Sven > > On 10/10/20 11:56 AM, Sven Wolf wrote: > > Hi, > > > > on my Lenovo V130 I've to build a custom kernel without radeondrm and > > amdgpu. > > > > https://marc.info/?l=openbsd-misc=159276382718317=2 > > > > The modified efiboot.c, see > > https://marc.info/?l=openbsd-misc=159401011632149=2, doesnt work on > > this machine. > > > > Best regards, > > Sven > > > > On 10/9/20 9:32 PM, Kastus Shchuka wrote: > >> On Fri, Oct 09, 2020 at 03:37:37PM +0400, Michel von Behr wrote: > >>> Hi all, > >>> I'm trying to run snapshot on a Chuwi Lapbook laptop (Intel Gemini > >>> Lake), > >>> but I get stuck at boot time with the message "entry point at: > >>> 0x1001000". > >>> Based on previous discussions [1] it looks like the problem is with > >>> BOOTX64.EFI > >>> For now I'll be running -stable, but I would like to follow -current. Is > >>> there a way to run -current with an old version of BOOTX64.EFI for > >>> example? > >>> (i.e., the only alternatives I'm seeing is either 1) compiling a GENERIC > >>> kernel with the older version of BOOTX64.EFI src, or 2) (try to) > >>> compile a > >>> custom/smaller kernel to avoid the issue). > >>> > >>> [1] https://marc.info/?l=openbsd-misc=159147446008114=2 > >>> > >>> Any pointing to the right direction is welcome. > >> > >> I had the same problem with EFI on ASRock J4105M system, essentially > >> failing > >> to boot a kernel larger than certain size. I posted my solution here: > >> > >> https://marc.info/?l=openbsd-misc=159401011632149=2 > >> > >> I guess the patch requires more testing before asking for it to be > >> committed. > >> > >> Thanks, > >> > >> Kastus > >> >
Re: Snapshot crash on boot, "entry point at: 0x1001000" (Intel Gemini Lake)
Hi, thanks to the fix from Mark, see https://marc.info/?l=openbsd-tech=160383074317608=2 the problem is solved for my machine. Best regards, Sven On 10/10/20 11:56 AM, Sven Wolf wrote: Hi, on my Lenovo V130 I've to build a custom kernel without radeondrm and amdgpu. https://marc.info/?l=openbsd-misc=159276382718317=2 The modified efiboot.c, see https://marc.info/?l=openbsd-misc=159401011632149=2, doesnt work on this machine. Best regards, Sven On 10/9/20 9:32 PM, Kastus Shchuka wrote: On Fri, Oct 09, 2020 at 03:37:37PM +0400, Michel von Behr wrote: Hi all, I'm trying to run snapshot on a Chuwi Lapbook laptop (Intel Gemini Lake), but I get stuck at boot time with the message "entry point at: 0x1001000". Based on previous discussions [1] it looks like the problem is with BOOTX64.EFI For now I'll be running -stable, but I would like to follow -current. Is there a way to run -current with an old version of BOOTX64.EFI for example? (i.e., the only alternatives I'm seeing is either 1) compiling a GENERIC kernel with the older version of BOOTX64.EFI src, or 2) (try to) compile a custom/smaller kernel to avoid the issue). [1] https://marc.info/?l=openbsd-misc=159147446008114=2 Any pointing to the right direction is welcome. I had the same problem with EFI on ASRock J4105M system, essentially failing to boot a kernel larger than certain size. I posted my solution here: https://marc.info/?l=openbsd-misc=159401011632149=2 I guess the patch requires more testing before asking for it to be committed. Thanks, Kastus
Re: Internal microphone not working
[ ... ] So, why do you trim outputs? Where is the full dmesg? Do you fear something? Do you realize that your and other people's problems with sound in particular CAN BE related to other hardware present in your computer or a specific configuration?
Re: Internal microphone not working
Marcus MERIGHI writes: > what does > $ sysctl kern.audio.record > say? [fagg@moon][~][0] -> sysctl kern.audio.record kern.audio.record=1
Re: Authenticating Location in HTTPD
On Wed, Oct 28, 2020 at 09:40:24AM -0400, ben wrote:
> Hello, Misc;
>
> I'm attempting to configure authentication for a location in httpd...
>
> server "example.com" {
> listen on * port 80
> root "/htdocs/example.com/"
> location "/" {
> authenticate with "/passwds"
this file should have r bit to "www" group
chown root:www /var/www/passwds && chmod 0640 /var/www/passwds
> }
> }
>
> However upon navigating to the designated url and entering the password I
> receive the same prompt again and again. I generated the password using
> htpasswd(1) and am storing it in the passwds file in the root of my chroot. Am
> I missing something? Has anyone else encountered this problem? Thank you in
> advance.
>
>
> Ben Raskin.
>
Re: Authenticating Location in HTTPD
I use this config for wordpress :
authenticate "WordPress" with "/htdocs/htpasswd"
Place the htpasswd file at the root of your chroot
This file should not be served of course
Check your logs for errors if not working
Romain
-Message d'origine-
De : owner-m...@openbsd.org De la part de ben
Envoyé : mercredi 28 octobre 2020 14:40
À : misc@openbsd.org
Objet : Authenticating Location in HTTPD
Hello, Misc;
I'm attempting to configure authentication for a location in httpd...
server "example.com" {
listen on * port 80
root "/htdocs/example.com/"
location "/" {
authenticate with "/passwds"
}
}
However upon navigating to the designated url and entering the password I
receive the same prompt again and again. I generated the password using
htpasswd(1) and am storing it in the passwds file in the root of my chroot. Am
I missing something? Has anyone else encountered this problem? Thank you in
advance.
Ben Raskin.
Authenticating Location in HTTPD
Hello, Misc;
I'm attempting to configure authentication for a location in httpd...
server "example.com" {
listen on * port 80
root "/htdocs/example.com/"
location "/" {
authenticate with "/passwds"
}
}
However upon navigating to the designated url and entering the password I
receive the same prompt again and again. I generated the password using
htpasswd(1) and am storing it in the passwds file in the root of my chroot. Am
I missing something? Has anyone else encountered this problem? Thank you in
advance.
Ben Raskin.
Re: Internal microphone not working
* Ashton Fagg [2020-10-27 20:31:29 -0400]: I'm running a ThinkPad T14s. There's been some recent additions to the azalia driver to help make audio work a little better on this machine (it now works and seems to get configured correctly). However, I'm having problems getting my internal microphone to work. I compiled my kernel with AZALIA_DEBUG (output attached), and it seems as though the microphone is being picked up (also reflected in mixerctl and audioctl). If I run something like Audacity to try and record audio, it just flat-lines which makes me think it is attaching to the mic-jack, not the internal microphone itself, but mixerctl doesn't seem to offer a suggestion of what to change. Audio recording is enabled in sysctl, and the device is configured as accessible in the BIOS. Any suggestions appreciated. I also encounter this issue on a Thinkpad X1 8th gen. I set kern.audio.record=1. Recording through an external microphone through the combined headphone/mic minijack works fine, but the built-in mic does not. 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 = 16325971968 (15569MB) avail mem = 15816130560 (15083MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.2 @ 0x766ac000 (71 entries) bios0: vendor LENOVO version "N2WET19W (1.09 )" date 07/01/2020 bios0: LENOVO 20UAS5PC00 acpi0 at bios0: ACPI 6.1 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT SSDT SSDT SSDT SSDT HPET APIC MCFG ECDT SSDT SSDT SSDT NHLT BOOT SSDT LPIT WSMT SSDT DBGP DBG2 MSDM BATB DMAR UEFI FPDT acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits 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-10510U CPU @ 1.80GHz, 7087.96 MHz, 06-8e-0c cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,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-10510U CPU @ 1.80GHz, 1696.05 MHz, 06-8e-0c cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,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-10510U CPU @ 1.80GHz, 1696.05 MHz, 06-8e-0c 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,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,SRBDS_CTRL,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-10510U CPU @ 1.80GHz, 1696.05 MHz, 06-8e-0c 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,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,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Core(TM) i7-10510U CPU
Re: Internal microphone not working
Hello Ashton, ash...@fagg.id.au (Ashton Fagg), 2020.10.28 (Wed) 01:31 (CET): > However, I'm having problems getting my internal microphone to work. what does $ sysctl kern.audio.record say? Marcus
Re: Should I download 'distfiles/by_cipher ' or 'rsysnc --exlude by_chipher' ?
On 2020-10-27, Martin wrote: > Do I need 'distfiles/by_cipher' in mirrored repo? > > Or may I exclude 'rsysnc --exlude by_cipher' while mirroring repository > without negative effects possible? > > Martin > > You don't usually want to mirror distfiles at all.
Re: Using ports and updates to the release
On Sun, Oct 11, 2020 at 09:12:13PM +0200, Ingo Schwarze wrote: > Hi Ed, > > Ed Gray wrote on Sun, Oct 11, 2020 at 07:21:32PM +0100: > > > I'm still fairly new to openbsd and the idea of using ports > > in general rather than binary packages. > > You are usually better off using packages than using ports, > especially as a new user. > > Even as an experienced user doing lots of development and minor > amounts of ports development, i use packages most of the time. As one of the persons *responsible* for keeping the ports system working, I do use packages all the time. Ports are on my development setup. The machine I write this mail from uses packages, with about 3 ports that are just there because not committed yet.
Re: search contains unknown domain in resolv.conf
On Tue, Oct 27, 2020 at 11:44:21PM +0300, Andreas X wrote: > ignore domain-search; > supersede domain-name mail.myserver.tld; > supersede domain-search mail.myserver.tld; > > None of these lines have worked in dhclient.conf The domain name need to be quoted. What did you do exactly? Did you restart dhclient? Anything in logs? What are the contents of resolv.conf after re-aquiring a lease? -Otto > > Anything else I could try? > > Thank you. > > > > 27 Ekim 2020 Salı tarihinde Otto Moerbeek yazdı: > > > On Tue, Oct 27, 2020 at 02:32:46PM +0300, Andreas X wrote: > > > > > Greetings. On OpenBSD 6.8, I have unbound enabled in my server, (server > > > gets its IP via DHCP from my server provider) > > > In resolv.conf I have a "search your-server.de" line and I don't know > > what > > > hostname is that. > > > My own hostname is something different. > > > > > > That seems the older hostname during setup (I forgot to set hostname > > during > > > installation). I changed hostname, removed it from resolv.conf, rebooted, > > > it's back again (DHCP - generated by re0 dhclient) How can I > > remove/change > > > that line? > > > > > > P.S: I have unbound enabled, therefore I created dhclient.conf and added: > > > supersede domain-name-servers 127.0.0.1, my.server.provider.IP; > > > > > > openbsdl# cat /etc/resolv.conf > > > # Generated by re0 dhclient > > > search your-server.de > > > nameserver 127.0.0.1 > > > lookup file bind > > > > > > Thanks. > > > > You can tell dhclient to ignore things. > > > > something like > > > > ignore domain-search; > > > > in dhclient.conf. See dhclient.conf and dhcp-options man pages. > > > > -Otto > >
