Re: alc0 watchdog timeout
On Fri, Jun 21, 2019 at 09:44:12PM +0200, Stephane HUC "PengouinBSD" wrote: > > HI, Hi, > To communicate on Internet, with my laptop - a Dell Alienware 13 - I > use an external LAN Adapter USB to RJ. This run correcty! > > I did not notice / understood that the physical network card was managed > . > > $ grep alc0 dmesg.txt > > alc0 at pci2 dev 0 function 0 "Attansic Technology E2200" rev 0x10: > msi, address 34:e6:d7:1b:7f:14 > atphy0 at alc0 phy 0: AR8035 10/100/1000 PHY, rev. 9 > > But, if I configure inet and inet6 on hostname.alc0 file, either dhcp > or static informations, dmesg filled with "alc0: watchdog timeout" and > /var/log/messages grow up! > > Into /var/log/messages, as: > Jun 21 16:13:26 ptb-aw13zou /bsd: alc0: watchdog timeout > Jun 21 16:14:00 ptb-aw13zou /bsd: alc0: watchdog timeout > Jun 21 16:15:56 ptb-aw13zou last message repeated 5 times > Jun 21 16:25:39 ptb-aw13zou last message repeated 20 times > Jun 21 16:35:34 ptb-aw13zou last message repeated 21 times > Jun 21 16:45:57 ptb-aw13zou last message repeated 22 times > Jun 21 16:55:56 ptb-aw13zou last message repeated 19 times > Jun 21 17:05:46 ptb-aw13zou last message repeated 22 times > Jun 21 17:15:37 ptb-aw13zou last message repeated 22 times > Jun 21 17:25:30 ptb-aw13zou last message repeated 22 times > Jun 21 17:27:54 ptb-aw13zou last message repeated 4 times > > With 'dhcp', the system reply: "no lease". > > Someone can explain-me the reason (simply), please?! > (and, perhaps, found a solution…) I think this bug has been fixed in r1.48. Please try -current, thanks.
Re: ospf point to point network
What about GRE(4) with a Cisco router on the other end? /etc/hostname.gre123: 1.1.1.1 1.1.1.2 netmask 255.255.255.252 up tunnel IP.OF.OB.SD IP.OF.I.OS Cisco IOS: ! interface Tunnel123 ip address 1.1.1.2 255.255.255.252 tunnel source GigabitEthernet0/0/1 tunnel destination IP.OF.OB.SD tunnel mode gre ! On Fri, Jun 21, 2019 at 3:37 PM Kapetanakis Giannis wrote: > > On 21/06/2019 20:30, Stuart Henderson wrote: > > On 2019-06-21, Kapetanakis Giannis wrote: > >> Hi, > >> > >> Can I get an update if point to point network support has been added in > >> ospfd? > >> > >> Thanks > >> > >> G > >> > >> > >> > >> On 19/12/2014 12:54, Kapetanakis Giannis wrote: > >>> On 18/12/14 22:38, Stuart Henderson wrote: > On 2014-12-17, Kapetanakis Giannis wrote: > > Hi, > > > > I'd like to ask if point-to-point support has been added in ospfd. > > > > I've read this > > http://marc.info/?l=openbsd-misc&m=136580208222751&w=2 > > > > but I cant seem to find relevant entries in the source tree so probably > > is still out? > > > > regards, > > > > Giannis > > > > > No, diff didn't work so it wasn't added. > > >>> Thanks for the update. > >>> > >>> G > >>> > >> > > Nothing changed in that respect. (For the benefit of the archives and > > readers unfamiliar with the situation, point to point works fine on > > a point-to-point interface, this is about ospfd pretending that an > > ethernet interface is "point to point"). > > > > That is likely something that would be added to release notes if > > it was added. > > > > > > Thanks for the reply Stuart. > > Is there any "hack" I can do with all those pseudo-interfaces available > in OB to full ospfd and do p2p? > > For instance ifconfig(8) has ptp options for bridge. > > A fellow reader of misc@ proposed gif(4), but my other end is a cisco > router. > > best, > > G >
Re: alc0 watchdog timeout
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, Brad. With -current, it seems run correctly. dhclient: ok statics inet4 and inet6 seem to good. Do you want some tests? On 6/21/19 11:24 PM, Brad Smith wrote: > Can you please try -current and let me know if it works any better? > > On > 6/21/2019 3:44 PM, Stephane HUC "PengouinBSD" wrote: >> HI, >> >> To communicate on Internet, with my laptop - a Dell Alienware 13 - I >> use an external LAN Adapter USB to RJ. This run correcty! >> >> I did not notice / understood that the physical network card was managed >> . >> >> $ grep alc0 dmesg.txt >> >> alc0 at pci2 dev 0 function 0 "Attansic Technology E2200" rev 0x10: >> msi, address 34:e6:d7:1b:7f:14 >> atphy0 at alc0 phy 0: AR8035 10/100/1000 PHY, rev. 9 >> >> But, if I configure inet and inet6 on hostname.alc0 file, either dhcp >> or static informations, dmesg filled with "alc0: watchdog timeout" and >> /var/log/messages grow up! >> >> Into /var/log/messages, as: >> Jun 21 16:13:26 ptb-aw13zou /bsd: alc0: watchdog timeout >> Jun 21 16:14:00 ptb-aw13zou /bsd: alc0: watchdog timeout >> Jun 21 16:15:56 ptb-aw13zou last message repeated 5 times >> Jun 21 16:25:39 ptb-aw13zou last message repeated 20 times >> Jun 21 16:35:34 ptb-aw13zou last message repeated 21 times >> Jun 21 16:45:57 ptb-aw13zou last message repeated 22 times >> Jun 21 16:55:56 ptb-aw13zou last message repeated 19 times >> Jun 21 17:05:46 ptb-aw13zou last message repeated 22 times >> Jun 21 17:15:37 ptb-aw13zou last message repeated 22 times >> Jun 21 17:25:30 ptb-aw13zou last message repeated 22 times >> Jun 21 17:27:54 ptb-aw13zou last message repeated 4 times >> >> With 'dhcp', the system reply: "no lease". >> >> Someone can explain-me the reason (simply), please?! >> (and, perhaps, found a solution…) >> >> >> >> My dmesg: >> OpenBSD 6.5 (GENERIC.MP) #0: Wed Apr 24 23:38:54 CEST 2019 >> >> r...@syspatch-65-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENER >> IC.MP >> real mem = 8487260160 (8094MB) >> avail mem = 8220405760 (7839MB) >> mpath0 at root >> scsibus0 at mpath0: 256 targets >> mainbus0 at root >> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xec580 (74 entries) >> bios0: vendor Alienware version "A08" date 01/25/2018 >> bios0: Alienware Alienware 13 >> acpi0 at bios0: rev 2 >> acpi0: sleep states S0 S3 S4 S5 >> acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI SSDT ASF! >> SLIC SSDT SSDT SSDT SSDT CSRT SSDT >> acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) >> PEG2(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) >> PXSX(S4) RP04(S4) RP05(S4) PEGP(S4) [...] >> acpitimer0 at acpi0: 3579545 Hz, 24 bits >> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat >> cpu0 at mainbus0: apid 0 (boot processor) >> cpu0: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz, 799.46 MHz, 06-45-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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOV >> BE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAH >> F,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIB >> P,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN >> 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 99MHz >> 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) i5-4210U CPU @ 1.70GHz, 799.31 MHz, 06-45-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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOV >> BE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAH >> F,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIB >> P,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN >> cpu1: 256KB 64b/line 8-way L2 cache >> cpu1: smt 0, core 1, package 0 >> cpu2 at mainbus0: apid 1 (application processor) >> cpu2: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz, 799.31 MHz, 06-45-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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOV >> BE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAH >> F,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIB >> P,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN >> cpu2: 256KB 64b/line 8-way L2 cache >> cpu2: smt 1, core 0, package 0 >> cpu3 at mainbus0: apid 3 (application processor) >> cpu3: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz, 799.31 MHz, 06-45-01 >> cpu3: >> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36, >> CFLUSH,DS,A
Re: Ansible install Re: Reboot and re-link
On Fri, Jun 21, 2019 at 01:20:44PM -0700, Misc User wrote: You could stick bsd.rd onto a bootable partition then point grub to it. You could also disable password login for root and just use a key pair. That way you wouldn't be sending the password encrypted (or at most only giving it a password that is useless without console access, then run 'doas passwd' the first chance you get to eliminate even that vector). That temp password could even be a long string of random junk so long as you enter it twice. You could copy bsd.rd and a copy of your pub key into /boot, or carve out a new partition using some unused disk space. Yes, the goal is a fully automated and unattended (but "stock," supported, and rage-free) install. The process of spinning up a new machine should be "add the IP address to the Ansible hosts file, run the playbook" as opposed to "dig out VNC and mess about with everything and get interrupted by someone with something urgent and come back and try to remember where I was..." This seems pretty close to doable: Ansible ought to be capable of dropping the bsd.rd into /boot and adding the relevant lines to grub, then triggering a restart. Creating partitions seems unnecessary if we can just get the sets via HTTP, yes? Resizing partitions post-install would add complexity. The autoinstall(8) man page (https://man.openbsd.org/autoinstall ) is a little unclear on whether we need to build a custom dhcpd.conf if we are using a local auto_install.conf, however I assume the answer is "no". (If "yes," then Ansible would need to get the MAC address from the server initially, build the dhcpd.conf, and put it in the bsd.rd before uploading...) Since parameters such as root password, user's username, user password, user SSH key, etc should be configured in the Ansible playbook or ancillary files, I wonder if there is a way to have Ansible build a custom autoinstall.conf (using templates) and insert it into bsd.rd immediately prior to uploading. For that matter I can't find any instructions for editing bsd.rd or adding files to it, did I miss a manpage somewhere? (It's too bad supplying the file locally requires editing the image, it would be nicer to drop the file onto /boot and then pass the filename as an argument when booting...)
Re: Ansible install Re: Reboot and re-link
On Fri, Jun 21, 2019 at 12:36:22PM -0700, Misc User wrote: I use PXE + install.conf + siteXX.tgz + siteXX-%hostname%.tgz for my installs. I also have an rc.firsttime to download and install the required packages. Thanks, but neither this nor the autoinstall suggestion seem applicable for my use case. I am dealing with virtualized servers which usually start out as Ubuntu/Debian/Fedora images, then the hosting provider supplies the IP address and root password for a first-time SSH login. In many cases it is not possible to upload an ISO to be used as server installation media, and VNC consoles (if available) are often not even encrypted. (How would you feel about installing OpenBSD and then having your root password sent in plaintext at the very beginning?) I realize installing OpenBSD under these constraints is rather like installing a ship in a bottle, but it seemed worth it to ask...
Re: Ansible install Re: Reboot and re-link
On 6/21/2019 1:08 PM, Frank Beuth wrote: On Fri, Jun 21, 2019 at 12:36:22PM -0700, Misc User wrote: I use PXE + install.conf + siteXX.tgz + siteXX-%hostname%.tgz for my installs. I also have an rc.firsttime to download and install the required packages. Thanks, but neither this nor the autoinstall suggestion seem applicable for my use case. I am dealing with virtualized servers which usually start out as Ubuntu/Debian/Fedora images, then the hosting provider supplies the IP address and root password for a first-time SSH login. In many cases it is not possible to upload an ISO to be used as server installation media, and VNC consoles (if available) are often not even encrypted. (How would you feel about installing OpenBSD and then having your root password sent in plaintext at the very beginning?) I realize installing OpenBSD under these constraints is rather like installing a ship in a bottle, but it seemed worth it to ask... You could stick bsd.rd onto a bootable partition then point grub to it. You could also disable password login for root and just use a key pair. That way you wouldn't be sending the password encrypted (or at most only giving it a password that is useless without console access, then run 'doas passwd' the first chance you get to eliminate even that vector). That temp password could even be a long string of random junk so long as you enter it twice. You could copy bsd.rd and a copy of your pub key into /boot, or carve out a new partition using some unused disk space.
tsc defect? (kern.timecounter.hardware=acpihpet0)
Hi, Always on my laptop Dell AW13, yesterday i realized a new installation on other HD with OpenBSD 6.5 (amd64) And, after log into my Xsession, I cant use correctly my keyboard since keys are repeated. (and the log X grow up). In September 2018, a solution found: change sysctl value "kern.timecounter.hardware=acpihpet0" https://marc.info/?l=openbsd-misc&m=153738193919254&w=2 it seemed to understand that a patch corrected the problem of the TSC clock, right?! https://marc.info/?l=openbsd-misc&m=153822975708782&w=2 I'm just trying to understand if this is the case, if this patch has been validated, and if it's possible than fix too my arch… because it seems that the clock is still defective, right? -- ~ " Fully Basic System Distinguish Life! " ~ " Libre as a BSD " +=<<< Stephane HUC as PengouinBSD or CIOTBSD b...@stephane-huc.net
Correct pexp variable for a shell script
I've got a shell script I'd like to run as a system service. Due to the
16 character limitation on pgrep and the -x flag that rc.subr passes to
check by default, I can't get check or stop to work correctly. The
problem is that the process name looks like "/bin/sh
/usr/local/bin/script.sh" which, even if passed to pgrep, won't match
when -x is used.
My rc.d script currently looks like this:
#!/bin/ksh
AUTHMAIL="/usr/local/bin/authmail"
daemon=${AUTHMAIL}
daemon_timeout=1
. /etc/rc.d/rc.subr
rc_reload=NO
rc_bg=YES
pexp="/bin/sh ${AUTHMAIL}"
rc_cmd $1
Do I have any other options, or do I just need to override rc_check to
remove -x?
alc0 watchdog timeout
HI, To communicate on Internet, with my laptop - a Dell Alienware 13 - I use an external LAN Adapter USB to RJ. This run correcty! I did not notice / understood that the physical network card was managed . $ grep alc0 dmesg.txt alc0 at pci2 dev 0 function 0 "Attansic Technology E2200" rev 0x10: msi, address 34:e6:d7:1b:7f:14 atphy0 at alc0 phy 0: AR8035 10/100/1000 PHY, rev. 9 But, if I configure inet and inet6 on hostname.alc0 file, either dhcp or static informations, dmesg filled with "alc0: watchdog timeout" and /var/log/messages grow up! Into /var/log/messages, as: Jun 21 16:13:26 ptb-aw13zou /bsd: alc0: watchdog timeout Jun 21 16:14:00 ptb-aw13zou /bsd: alc0: watchdog timeout Jun 21 16:15:56 ptb-aw13zou last message repeated 5 times Jun 21 16:25:39 ptb-aw13zou last message repeated 20 times Jun 21 16:35:34 ptb-aw13zou last message repeated 21 times Jun 21 16:45:57 ptb-aw13zou last message repeated 22 times Jun 21 16:55:56 ptb-aw13zou last message repeated 19 times Jun 21 17:05:46 ptb-aw13zou last message repeated 22 times Jun 21 17:15:37 ptb-aw13zou last message repeated 22 times Jun 21 17:25:30 ptb-aw13zou last message repeated 22 times Jun 21 17:27:54 ptb-aw13zou last message repeated 4 times With 'dhcp', the system reply: "no lease". Someone can explain-me the reason (simply), please?! (and, perhaps, found a solution…) My dmesg: OpenBSD 6.5 (GENERIC.MP) #0: Wed Apr 24 23:38:54 CEST 2019 r...@syspatch-65-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENER IC.MP real mem = 8487260160 (8094MB) avail mem = 8220405760 (7839MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xec580 (74 entries) bios0: vendor Alienware version "A08" date 01/25/2018 bios0: Alienware Alienware 13 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI SSDT ASF! SLIC SSDT SSDT SSDT SSDT CSRT SSDT acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) RP05(S4) PEGP(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz, 799.46 MHz, 06-45-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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOV BE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAH F,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIB P,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN 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 99MHz 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) i5-4210U CPU @ 1.70GHz, 799.31 MHz, 06-45-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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOV BE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAH F,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIB P,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz, 799.31 MHz, 06-45-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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOV BE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAH F,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIB P,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz, 799.31 MHz, 06-45-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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOV BE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAH F,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIB P,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins acpimadt0: bogus nmi for apid 0 acpimadt0: bogus nmi for apid 2 acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt
Re: Ansible install Re: Reboot and re-link
On 6/21/2019 11:02 AM, Frank Beuth wrote: On Wed, Jun 19, 2019 at 11:29:32PM +0200, Maxim Bourmistrov wrote: Installing via NOT RECOMMENDED WAY(following upgrade65.html) - scripting on steroides (ansible). I don't want to re-open the hostilities, but installing OpenBSD via Ansible is very relevant to my interests. Previously discussed on this list was a very roundabout approach using Qemu -- is there a better way now? I use PXE + install.conf + siteXX.tgz + siteXX-%hostname%.tgz for my installs. I also have an rc.firsttime to download and install the required packages. I have my machines configured to use the harddisk first and PXE second. When I go to upgrade systems, I clear the system's boot block so the boot process skips to PXE booting. Once I got the wrinkles ironed out, installs and upgrades are very much fire-and-forget. Hell, new server installs just require plugging the machine into power and network, and then walk away (The BIOS comes pre-configured with "On power restore: 'Power-on'"). Best part, this solution requires zero third party binaries or tools. Just yesterday I had to replace a failed webserver. Replaced the failed system's MAC in dhcpd.conf and then had the datacenter folks rip the old system out, install the new one, make sure it powers up, then walk away. Four hours later, I had a fully operational server up and slinging html, probably finished a lot sooner, but I didn't bother to check until then.
Re: ospf point to point network
On 21/06/2019 20:30, Stuart Henderson wrote: On 2019-06-21, Kapetanakis Giannis wrote: Hi, Can I get an update if point to point network support has been added in ospfd? Thanks G On 19/12/2014 12:54, Kapetanakis Giannis wrote: On 18/12/14 22:38, Stuart Henderson wrote: On 2014-12-17, Kapetanakis Giannis wrote: Hi, I'd like to ask if point-to-point support has been added in ospfd. I've read this http://marc.info/?l=openbsd-misc&m=136580208222751&w=2 but I cant seem to find relevant entries in the source tree so probably is still out? regards, Giannis No, diff didn't work so it wasn't added. Thanks for the update. G Nothing changed in that respect. (For the benefit of the archives and readers unfamiliar with the situation, point to point works fine on a point-to-point interface, this is about ospfd pretending that an ethernet interface is "point to point"). That is likely something that would be added to release notes if it was added. Thanks for the reply Stuart. Is there any "hack" I can do with all those pseudo-interfaces available in OB to full ospfd and do p2p? For instance ifconfig(8) has ptp options for bridge. A fellow reader of misc@ proposed gif(4), but my other end is a cisco router. best, G
Re: Ansible install Re: Reboot and re-link
On Fri, 21 Jun 2019 20:02:48 +0200, Frank Beuth wrote: > On Wed, Jun 19, 2019 at 11:29:32PM +0200, Maxim Bourmistrov wrote: > >Installing via NOT RECOMMENDED WAY(following upgrade65.html) - > >scripting on steroides (ansible). > > I don't want to re-open the hostilities, but installing OpenBSD via > Ansible is very relevant to my interests. Previously discussed on > this list was a very roundabout approach using Qemu -- is there a > better way now? > You can automate installation with autoinstall(8). You can also automate upgrades with autoinstall(8) and from 6.6 you'll be able to use sysupgrade(8) as well. Cheers, Daniel
Ansible install Re: Reboot and re-link
On Wed, Jun 19, 2019 at 11:29:32PM +0200, Maxim Bourmistrov wrote: Installing via NOT RECOMMENDED WAY(following upgrade65.html) - scripting on steroides (ansible). I don't want to re-open the hostilities, but installing OpenBSD via Ansible is very relevant to my interests. Previously discussed on this list was a very roundabout approach using Qemu -- is there a better way now?
Re: Route through different gateways depending on process
Claudio Jeker writes: > On Fri, Jun 21, 2019 at 02:11:53PM +, slackwaree wrote: >> Hello, >> >> I wonder if the following scenario can be solved with OpenBSD on 1 single >> machine or with VMM: >> >> I got 3 OpenBSD vms, all of them are exactly the same running squid except >> they use different default routers to route their traffic out. >> >> I would like to merge these to one VM if it is possible somehow to tell >> OpenBSD to use different gateway depending on the squid process. >> >> If not would the same thing be possible with VMMs? All the gateways are in >> the same IP range. >> > > A simple way to solve this is with multiple routing tables. > > Create multiple routing tables with: > route -T1 add default > route -T2 add default > route -T3 add default > > And start the 3 squid processes with route -T1 exec, route -T2 exec. > You can also use the the *_rtable variable in rc.d(8) to do that > automatically. > > This requires that the 3 squids listen on different IPs or ports. As I learned recently (investigating another issue and reading the rc.subr(8) man page), if you start these with rc scripts, you can set daemon_rtable there, as well as likely setting up the config file or port/ip address options in daemon_flags. Also be sure pexp variable is set to somthing that can differentiate the proceses or the rcctl stop/check stuff will not work. Allan
Re: dhcpd and Polycom SoundPoint IP 550 phones
>> After several days of desperation ... > > There is no need for this. Try to see the dhcpd's logs, after you put > the server to log it to the maximum extent for you. Then you can try > tcpdump to watch closely the Polycom's requests, you can see if they > are out of standard crap or if there is a problem there. Try again > with another client computer, see if it can obtain an address - this > way you can check if your dhcp server is correctly configured. > > That only helps if there's something wrong with the client's request. Possibly more likely, the client doesn't like something about the answer from dhcpd. If you'd like somebody to see if they can spot anything, send tcpdump output from one request and answer using each of dhcpd and isc-dhcp (clearly marked up). tcpdump -n -i $interface -Xvvs1500 port bootpc or bootps
Re: ospf point to point network
On 2019-06-21, Kapetanakis Giannis wrote: > Hi, > > Can I get an update if point to point network support has been added in ospfd? > > Thanks > > G > > > > On 19/12/2014 12:54, Kapetanakis Giannis wrote: >> On 18/12/14 22:38, Stuart Henderson wrote: >>> On 2014-12-17, Kapetanakis Giannis wrote: Hi, I'd like to ask if point-to-point support has been added in ospfd. I've read this http://marc.info/?l=openbsd-misc&m=136580208222751&w=2 but I cant seem to find relevant entries in the source tree so probably is still out? regards, Giannis >>> No, diff didn't work so it wasn't added. >>> >> >> Thanks for the update. >> >> G >> > > Nothing changed in that respect. (For the benefit of the archives and readers unfamiliar with the situation, point to point works fine on a point-to-point interface, this is about ospfd pretending that an ethernet interface is "point to point"). That is likely something that would be added to release notes if it was added.
Re: assembler issue - no such instruction
On 2019-06-21, Riccardo Mottola wrote: > Hi all, > > I am trying to compile ArcticFox on OpenBSD 6.5. On 6.4 I had no > issues,it compiled and worked! > I am using gcc 4.9 from ports and it dies with: > > 2:16.64 host_pathsub.o > 2:16.85 /tmp//cctgHRHn.s: Assembler messages: > 2:16.85 /tmp//cctgHRHn.s:36: Error: no such instruction: `vmovaps > %xmm0,80(%rsp)' > 2:16.85 /tmp//cctgHRHn.s:37: Error: no such instruction: `vmovaps > %xmm1,96(%rsp)' > 2:16.85 /tmp//cctgHRHn.s:38: Error: no such instruction: `vmovaps > %xmm2,112(%rsp)' > 2:16.85 /tmp//cctgHRHn.s:39: Error: no such instruction: `vmovaps > %xmm3,128(%rsp)' > 2:16.85 /tmp//cctgHRHn.s:40: Error: no such instruction: `vmovaps > %xmm4,144(%rsp)' > 2:16.85 /tmp//cctgHRHn.s:41: Error: no such instruction: `vmovaps > %xmm5,160(%rsp)' > 2:16.85 /tmp//cctgHRHn.s:42: Error: no such instruction: `vmovaps > %xmm6,176(%rsp)' > 2:16.85 /tmp//cctgHRHn.s:43: Error: no such instruction: `vmovaps > %xmm7,192(%rsp)' > 2:16.87 In the directory > /home/multix/code/Arctic-Fox/obj-amd64-unknown-openbsd6.5/config > 2:16.87 The following command failed to execute properly: > 2:16.87 egcc -o host_pathsub.o -c -DXP_UNIX -MD -MP -MF > .deps/host_pathsub.o.pp -O2 -march=sandybridge -DUNICODE -D_UNICODE > -I/home/multix/code/Arctic-Fox/config -I. -I../dist/include > -I/home/multix/code/Arctic-Fox/obj-amd64-unknown-openbsd6.5/dist/include/nspr > /home/multix/code/Arctic-Fox/config/pathsub.c > 2:16.87 gmake[5]: *** > [/home/multix/code/Arctic-Fox/config/rules.mk:889: host_pathsub.o] Error 1 > > From looking on the internet, this seems an assembler problem > > I tried to force AS to gas, but it did not change, maybe egcc is not > respecting it > > > Riccardo > > gas in base doesn't know these opcodes. You either need a newer assembler or probably easier there's a fair chance they will go away if you remove the -march=sandybridge.
Re: Reboot and re-link (fwd) Maxim Bourmistrov: Re: Reboot and re-link
On 21 June 2019 14:04:50 BST, Florian Obser wrote: >On Thu, Jun 20, 2019 at 10:47:49PM +0200, mathijs wrote: >> this makes misc@ so much more amusing > >It really doesn't. We are not here to have manure tossed at us for the >audience's amusement. Agreed. This kind of abuse happens in any FOSS project. This "Maxim" is an absolute creep, but many people are far, far worse, even. I wasted so much time and energy in the FOSS project I ran having to take countermeasures against such people.
Re: Route through different gateways depending on process
On Fri, Jun 21, 2019 at 02:11:53PM +, slackwaree wrote: > Hello, > > I wonder if the following scenario can be solved with OpenBSD on 1 single > machine or with VMM: > > I got 3 OpenBSD vms, all of them are exactly the same running squid except > they use different default routers to route their traffic out. > > I would like to merge these to one VM if it is possible somehow to tell > OpenBSD to use different gateway depending on the squid process. > > If not would the same thing be possible with VMMs? All the gateways are in > the same IP range. > A simple way to solve this is with multiple routing tables. Create multiple routing tables with: route -T1 add default route -T2 add default route -T3 add default And start the 3 squid processes with route -T1 exec, route -T2 exec. You can also use the the *_rtable variable in rc.d(8) to do that automatically. This requires that the 3 squids listen on different IPs or ports. -- :wq Claudio
Route through different gateways depending on process
Hello, I wonder if the following scenario can be solved with OpenBSD on 1 single machine or with VMM: I got 3 OpenBSD vms, all of them are exactly the same running squid except they use different default routers to route their traffic out. I would like to merge these to one VM if it is possible somehow to tell OpenBSD to use different gateway depending on the squid process. If not would the same thing be possible with VMMs? All the gateways are in the same IP range. Thanks
compiling one's own GCC - configuration considerations
Hi, ports prrovide two gcc's 4.9 and 8. I have a program which compiles fine with up to gcc 7, also the system clang is too "new". On OpenBSD 6.4 I could use the system clang. Now, a solution would be to install gcc 6.5 or 7.4, a compiler which I know works fine on NetBSD and Linux for ArcticFox. I want to make it as stock as possible, I did not apply any patches. I took inspiration from: https://raw.githubusercontent.com/openbsd/ports/master/lang/gcc/8/Makefile I installed gmake, gas, bison, libexecinfo I ended up with this command line (the rationale is not to overwrite anything of ports, put it : ./configure --prefix=/usr/local/gcc7 --program-suffix=7 --enable-languages=c,c++,objc,obj-c++ --enable-shared --enable-wchar_t --enable-threads=posix --disable-nls --with-system-zlib --disable-libmudflap --disable-libgomp --disable-libssp --with-gnu-ld --with-gnu-as --with-gmp=/usr/local --disable-libstdcxx-pch --without-isl --enable-cpp --with-arch=sandybridge --with-tune=sandybridge --enable-default-pie CC=clang CXX=clang++ AS=gas however compilation fails: checking whether the /home/multix/code/gcc-7.4.0/host-x86_64-unknown-openbsd6.5/gcc/xgcc -B/home/multix/code/gcc-7.4.0/host-x86_64-unknown-openbsd6.5/gcc/ -B/usr/local/gcc7/x86_64-unknown-openbsd6.5/bin/ -B/usr/local/gcc7/x86_64-unknown-openbsd6.5/lib/ -isystem /usr/local/gcc7/x86_64-unknown-openbsd6.5/include -isystem /usr/local/gcc7/x86_64-unknown-openbsd6.5/sys-include linker (/home/multix/code/gcc-7.4.0/host-x86_64-unknown-openbsd6.5/gcc/collect-ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... openbsd6.5 ld.so checking how to hardcode library paths into programs... immediate checking for shl_load... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. gmake[2]: *** [Makefile:13983: configure-stage1-target-libstdc++-v3] Error 1 gmake[2]: Leaving directory '/home/multix/code/gcc-7.4.0' Anyone has a useful suggestion to get gcc7 ? Thanks, Riccardo
assembler issue - no such instruction
Hi all, I am trying to compile ArcticFox on OpenBSD 6.5. On 6.4 I had no issues,it compiled and worked! I am using gcc 4.9 from ports and it dies with: 2:16.64 host_pathsub.o 2:16.85 /tmp//cctgHRHn.s: Assembler messages: 2:16.85 /tmp//cctgHRHn.s:36: Error: no such instruction: `vmovaps %xmm0,80(%rsp)' 2:16.85 /tmp//cctgHRHn.s:37: Error: no such instruction: `vmovaps %xmm1,96(%rsp)' 2:16.85 /tmp//cctgHRHn.s:38: Error: no such instruction: `vmovaps %xmm2,112(%rsp)' 2:16.85 /tmp//cctgHRHn.s:39: Error: no such instruction: `vmovaps %xmm3,128(%rsp)' 2:16.85 /tmp//cctgHRHn.s:40: Error: no such instruction: `vmovaps %xmm4,144(%rsp)' 2:16.85 /tmp//cctgHRHn.s:41: Error: no such instruction: `vmovaps %xmm5,160(%rsp)' 2:16.85 /tmp//cctgHRHn.s:42: Error: no such instruction: `vmovaps %xmm6,176(%rsp)' 2:16.85 /tmp//cctgHRHn.s:43: Error: no such instruction: `vmovaps %xmm7,192(%rsp)' 2:16.87 In the directory /home/multix/code/Arctic-Fox/obj-amd64-unknown-openbsd6.5/config 2:16.87 The following command failed to execute properly: 2:16.87 egcc -o host_pathsub.o -c -DXP_UNIX -MD -MP -MF .deps/host_pathsub.o.pp -O2 -march=sandybridge -DUNICODE -D_UNICODE -I/home/multix/code/Arctic-Fox/config -I. -I../dist/include -I/home/multix/code/Arctic-Fox/obj-amd64-unknown-openbsd6.5/dist/include/nspr /home/multix/code/Arctic-Fox/config/pathsub.c 2:16.87 gmake[5]: *** [/home/multix/code/Arctic-Fox/config/rules.mk:889: host_pathsub.o] Error 1 From looking on the internet, this seems an assembler problem I tried to force AS to gas, but it did not change, maybe egcc is not respecting it Riccardo
Re: Reboot and re-link (fwd) Maxim Bourmistrov: Re: Reboot and re-link
On Thu, Jun 20, 2019 at 10:47:49PM +0200, mathijs wrote: > this makes misc@ so much more amusing It really doesn't. We are not here to have manure tossed at us for the audience's amusement. Everytime something like this happens it takes time away from hacking on OpenBSD. It doesn't matter that it wasn't directed at me. I'm part of the project and I care about my fellow developers. -- I'm not entirely sure you are real.
Re: reinstalling boot blocks
Hi all, Riccardo Mottola wrote: I want to reinstall safely boot blocks as the installer does, how can I do it? best from the CD-ROM let me summarize the situation: - I had 6.4 not booting correctly (partition boot size issue) - I upgraded 6.5, and all works, boots fine - actually it did not work, certain things make the kernel crash (but can't report properly, I can't produce a dmesg, etc.. wifi makes a kernel panic) - after two or three panics the machine does not boot anymore, I did run fsck It looks early crashing, like reverting to the previous situation. I wonder if the filesystem may corrupt that way? I resorted in "upgrading" in place, from 6.5 to 6.5 again, this forced reinstall.. and the laptop boots again fine :) Smart installer! After all, overwriting what was just installed should not do big harm. Riccardo
Re: Newer snapshots on ALIX
Hi Claudio, others, First of, let me apologize for the severe lack of details in my previous post. I thought to quickly check if anyone else had seen what I'm seeing. I've gone to my archive of snapshots and extracted all the pxeboot's from every snapshot I have, a total 1972 snapshot over the last 4+ years. I found 91 different pxe bootloaders, so at most 7 attempts to find the breaking one :) As I only have an archive of amd64 installers, I used the amd64 pxeboot (even though ALIX is an i386 platform, the bootloader from amd64 has worked fine - and I did verify the i386 pxeboot from 6.5 and the latest snapshot have the same behaviour). My method was using the pxeboot loader to boot bsd.rd from the local storage. The only change I made between reboots was installing a different version of pxeboot on my tftp server. With a reasonable starting guess, I brought it down to 5 attempts. First to fail is the pxeboot from the snapshot dated 2019-04-10 at 18:10:42, kernel build number 817. This shows some extra information during boot though: >> OpenBSD/amd64 PXEBOOT 3.43 boot> boot hd0a:/bsd.rd booting hd0a:/bsd.rd: 3107327+1352704+3362824+0+458752 [363419+98+289008+28303]=0x8cc8a0 64 bit entry point at 0x2000d4 entry = 0x2000d4 kern_pml4 = 0 kern_pml3 = 0 kern_pml2 = 1 kern_pml1 = 0 end of bootstrap page tables = 0xa The pxeboot from the snapshot before that (kernel build time 2019-04-10 at 11:52:59, with kernel build number 816) shows: >> OpenBSD/amd64 PXEBOOT 3.42 boot> boot hd0a:/bsd.rd booting hd0a:/bsd.rd: 3107327+1352704+3362824+0+458752 [363419+98+289008+28303]=0x8cc8a0 entry point at 0x2000d4 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2018 OpenBSD. All rights reserved. https://www.OpenBSD.org The next (different) pxeboot from the snapshot with the kernel built on 2019-04-12 at 20:40:53 (kernel build number 0) gets stuck at the `entry point at 0x2000d4` again: >> OpenBSD/amd64 PXEBOOT 3.43 boot> boot hd0a:/bsd.rd booting hd0a:/bsd.rd: 3107327+1352704+3362824+0+458752 [363419+98+289008+28303]=0x8cc8a0 entry point at 0x2000d4 So, I was looking at commits to the boot code at or shortly after april 10. The only one I see is this one, where Florian brings sys/stand/boot/boot.c to version 1.48: -- Modified files: sys/stand/boot : boot.c Log message: Unbreak "boot bsd.up" line in /etc/boot.conf Found the hard way by Raf Czlonka (rczlonka AT gmail), thanks! OK deraadt -- But I don't see how Florian's change could break things this way. I'll try a revert, but it's going to take a bit of time to configure my build environment and to figure out how to make the pxe bootloader. If anyone has any suggestions in the mean time, I'm eager to hear them. Thanks, Paul On Wed, Jun 19, 2019 at 08:55:06AM +0200, Claudio Jeker wrote: | On Wed, Jun 19, 2019 at 08:37:28AM +0200, Paul de Weerd wrote: | > Morning folks, | > | > I ran into a problem after upgrading my ALIX to a more recent snapshot | > in that it won't boot anymore. It gets to "entry point 0x2d0" and | > then stops. I tried using the PXE bootloader to load the local kernel | > from disk (both bsd and bsd.rd) and to load kernels from tftp, but all | > fails in similar ways with the entry point being the last output. | > | > I grabbed another ALIX to test, but I'm afraid I screwed that one up | > and now that one doesn't boot either anymore. This is probably user | > error, but now I'd like to confirm: has anyone successfully upgraded | > their ALIX to a recent snapshot? | > | > It could be that my hardware is dying on me (I should find my piggy | > bank for some nickels), so confirmation that this still works for | > others is appreciated. | > | | There were some boot(8) changes so try some older pxeboot from 6.4, 6.5 or | the snapshot archive to see when the breakage was introduced. -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
How to specify "device" option in vm.conf to always boot PXE
Hi, I need a VM to always boot from the network. I could do it using vmctl(8): # doas vmctl start test -c -B net -b /bsd -n vswitch0 (...) PXE boot MAC address fe:e1:bb:d1:c5:d8, interface vio0 nfs_boot: using interface vio0, with revarp & bootparams But I can't find the syntax to be used in vm.conf(5). Using "boot /bsd" would not use PXE. Using "boot /pxeboot" would not boot at all. Is it possible to set the boot device as net in vm.conf ? Alternatively, is it possible to force lladdr from vmctl ? Thank you, Jo
Re: ospf point to point network
Hi, Can I get an update if point to point network support has been added in ospfd? Thanks G On 19/12/2014 12:54, Kapetanakis Giannis wrote: > On 18/12/14 22:38, Stuart Henderson wrote: >> On 2014-12-17, Kapetanakis Giannis wrote: >>> Hi, >>> >>> I'd like to ask if point-to-point support has been added in ospfd. >>> >>> I've read this >>> http://marc.info/?l=openbsd-misc&m=136580208222751&w=2 >>> >>> but I cant seem to find relevant entries in the source tree so probably >>> is still out? >>> >>> regards, >>> >>> Giannis >>> >>> >> No, diff didn't work so it wasn't added. >> > > Thanks for the update. > > G >
Re: HIPPA supported ciphers
On 6/21/19 12:43 AM, Kihaguru Gathura wrote: > OpenBSD 6.5 (GENERIC.MP) #84: Wed Apr 17 05:53:43 MDT 2019 > > Hi, > > SSL compliance tests below refers. (htbridge) > > > 2:SUPPORTED CIPHERS > TLSv1.2 > TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 Non-compliant with HIPAA guidance > TLS_RSA_WITH_CAMELL TLS_RSA_WITH_CAMELLIA_128_CBC_SHA Non-compliant > with HIPAA guidance > TLS_RSA_WITH_CAMELLIA_128_CBC_SHA Non-compliant with HIPAA guidance > > Under what circumstances could these ciphers be not considered for > HIPPA compliance? They could be things that aren't on the list that was compiled ten years ago, they could be sub-optimal options that are still in widespread use today. You are asking the wrong people. Talk to your compliance people and/or auditors. Do what they tell you to do, it's easier than reasoning with them. Remember: Security is important for ethical reasons. Compliance is important for legal reasons. The key to workplace contentment is understanding they are unrelated to each other. Both are important, but one does not lead to the other. And audits go better when the auditor finds something to complain about and get you to change. Nick.
Re: Current snapshot sets fail verification
On Thu, Jun 20, 2019 at 11:12:30PM -, Stuart Henderson wrote: > On 2019-06-20, Andreas Kusalananda Kähäri wrote: > > > > It seems to have resolved itself. Maybe I just managed to run > > sysupgrade while the mirror was updating... > > > > > > On Thu, Jun 20, 2019 at 09:45:50PM +0200, Andreas Kusalananda Kähäri wrote: > >> > >> That's for amd64, sorry, forgot to mention. > >> > >> On Thu, Jun 20, 2019 at 09:44:54PM +0200, Andreas Kusalananda Kähäri wrote: > >> > With https://cdn.openbsd.org/pub/OpenBSD in /etc/installurl, sysupgrade > >> > currently fails: > > CDN caches are fine for releases, but I strongly recommend a standard > mirror for snapshots. > Thanks for that suggestion. -- Kusalananda Sweden
