Re: Skylake works on Dell Latitude E5570
Il 19 lug 2017 00:36, "Mihai Popescu" ha scritto: > Hibernate (apm -Z) does not work. > I don't know if it's related to the Skylake support at all. Maybe KARL? I think I saw a message about this on list. Yes, see: http://marc.info/?l=openbsd-bugs&m=150039046614972
Re: syspatch glitch
> It seems syspatch looks at the current machine capabilities instead of > which kernel is running when it decides on if /bsd is /bsd.sp or /bsd.mp. > > I tried to install OpenBSD 6.1 to a USB connected CF card that later will > run in an alix2d13 that has got one core, but I did the installation from > a laptop with two cores. Both i386. > > Then I moved /bsd to /bsd.mp and /bsd.sp to /bsd since the installer had > detected that the install machine should run /bsd.mp. > > After that I ran syspatch, still on the laptop, and it failed on patch 002 > with as I remember tar complaining on not being able to find /bsd.sp. > > Restoring /bsd to /bsd.sp and /bsd.mp to /bsd allowed me to syspatch the > installation, and after that it seems both /bsd (.mp) and /bsd.sp are > patched, so I can hopefully change the kernels just before putting the CF > card in the Alix instead, so no harm done. > > But is it by design that syspatch looks at the running machine instead of > the running kernel? I would have expected it the other way around... Yes, it is by design. You are not following the normal pattern. When you do something strange, you own the consequences. Software often doesn't handle all the cases, and I think it is wrong to accuse it for not satisfying your specific needs in a strange usage pattern.
Re: Getting Dell RAID status via SNMP
On 2017-07-18 19:45, Stuart Henderson wrote: On 2017-07-18, Jibby Jeremiah wrote: Stuart H wrote : So for now you would need to run bioctl to fetch status for this. Thanks again Stuart. But I look at the man page and it is not clear to me how to use this: [root@myname ~]# bioctl -q sd0 sd0: , serial 0077a1dc0b3da755200084e6a0a06d86 [root@myname ~]# bioctl -i sd0 sd0: , serial 0077a1dc0b3da755200084e6a0a06d86 [root@myname ~]# bioctl -i mfii0 bioctl: Can't locate mfii0 device via /dev/bio [root@myname ~]# bioctl -i mfii bioctl: Can't locate mfii device via /dev/bio [root@myname ~]# bioctl -iv sd0 sd0: , serial 0077a1dc0b3da755200084e6a0a06d86 Oh hmm - perhaps mfii(4) doesn't support reading status at all then, that's a surprise to me. Normally "bioctl sd0" would be enough. I can confirm that mfii(4) doesn't support reading status at all. There was some work last year to improve this, but it ran into some issues. http://marc.info/?t=14773842861&r=1&w=2 .jh
Re: Openbsd 6.1 and Current Console Freezes and lockup Proxmox PVE5.0
Hi Tim, all I have submitted a bug report, just now regarding Proxmox 5.0 or earlier support im afraid im not familiar with the earlier versions and we were testing the platform to use with openBSD on top. problem, the OpenBSD VGA Console of the VM freezes when OpenBSD 6.1 release or 6.1 Current (amd64) is installed on proxmox 5.0 ve this seems to happen after about 5-10 minutes of uptime and can be brought on or exacerbated by holding down any key eg when the console freezes, proxmox reports one of the 4 cores assigned to the machine is at 100% (25% constant usage) ssh sessions that were established are terminated only a reboot recovers the situation. (until the next freeze) diagnostics it happens regardless of emulated processor type it happens regardless of emulated storage type it happes regardless of emulated network type it happens on multiple generations of Intel Processors. intel X5460 & on intel e5 2660 V2 it happens regardless of cache settings on the storage Fix or workaround use serial console only and set the Proxmox VM Display to "serial 0" (removing the vga adapter) this seems to make it stable for longer ( more details to follow) I will update the thread if there are any problems encountered Thanks Tom Smyth On 19 July 2017 at 02:14, trondd wrote: > On Tue, July 18, 2017 8:14 pm, Tom Smyth wrote: >> Apologies... >> Incomplete Mail ... was feeling Trigger happy and now im certainly >> feeling uncomfortably dumb :) >> >> proper bug report to come tomorrow, >> Its a long story... :/ >> Thanks >> > > When you do come back, mention if this is new with Proxmox 5.0 and if > you've used previous versions succesfully. > > I have been running OpenBSD on Proxmox for 2 or 3 years with no problems. > I think I am still on 4.x, though. I'll check tomorrow. > > Tim. > > -- Kindest regards, Tom Smyth Mobile: +353 87 6193172 The information contained in this E-mail is intended only for the confidential use of the named recipient. If the reader of this message is not the intended recipient or the person responsible for delivering it to the recipient, you are hereby notified that you have received this communication in error and that any review, dissemination or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately by telephone at the number above and erase the message You are requested to carry out your own virus check before opening any attachment.
Re: Openbsd 6.1 and Current Console Freezes and lockup Proxmox PVE5.0
On Tue, July 18, 2017 8:14 pm, Tom Smyth wrote: > Apologies... > Incomplete Mail ... was feeling Trigger happy and now im certainly > feeling uncomfortably dumb :) > > proper bug report to come tomorrow, > Its a long story... :/ > Thanks > When you do come back, mention if this is new with Proxmox 5.0 and if you've used previous versions succesfully. I have been running OpenBSD on Proxmox for 2 or 3 years with no problems. I think I am still on 4.x, though. I'll check tomorrow. Tim.
Re: Openbsd 6.1 and Current Console Freezes and lockup Proxmox PVE5.0
Apologies... Incomplete Mail ... was feeling Trigger happy and now im certainly feeling uncomfortably dumb :) proper bug report to come tomorrow, Its a long story... :/ Thanks On 19 July 2017 at 01:00, Tom Smyth wrote: > Hello, > > Im trying to deploy OpenBSD on Proxmox VE 5.0 (QEMU) /KVM > Hypervisor running on Debian sarge > > Im noticing the console locks up (either Serial console ) or VGA Console > locks up in the following circumstances > 1) during installation of OpenBSD (when the installer is copying files to > disk) > 2)
Openbsd 6.1 and Current Console Freezes and lockup Proxmox PVE5.0
Hello, Im trying to deploy OpenBSD on Proxmox VE 5.0 (QEMU) /KVM Hypervisor running on Debian sarge Im noticing the console locks up (either Serial console ) or VGA Console locks up in the following circumstances 1) during installation of OpenBSD (when the installer is copying files to disk) 2)
Re: Good looking fonts in Java apps
Thanks to everyone for the suggestions .. B. On Wed, Jul 19, 2017 at 11:48 AM, Stuart Henderson wrote: > On 2017-07-18, Bryan Linton wrote: > > On 2017-07-19 06:39:04, Bernard Mentink wrote: > >> Thank Bryan, > >> > >> I guess that would have to go in .kshrc? I think that is the default > shell > >> for OpenBSD right? > >> > > > > It would depend on the shell you're actually using. If you > > haven't installed or aren't using another shell, then .kshrc is > > what you would want. > > .kshrc is not read automatically, if you want to use it you must > "export ENV=$HOME/.kshrc" or similar in .profile / /etc/profile. > > >
Re: Good looking fonts in Java apps
On 2017-07-18, Bryan Linton wrote: > On 2017-07-19 06:39:04, Bernard Mentink wrote: >> Thank Bryan, >> >> I guess that would have to go in .kshrc? I think that is the default shell >> for OpenBSD right? >> > > It would depend on the shell you're actually using. If you > haven't installed or aren't using another shell, then .kshrc is > what you would want. .kshrc is not read automatically, if you want to use it you must "export ENV=$HOME/.kshrc" or similar in .profile / /etc/profile.
Re: Getting Dell RAID status via SNMP
On 2017-07-18, Jibby Jeremiah wrote: > Stuart H wrote : >> So for now you would need to run bioctl to fetch status for this. > > Thanks again Stuart. But I look at the man page and it is not clear to me > how to use this: > > [root@myname ~]# bioctl -q sd0 > sd0: , serial 0077a1dc0b3da755200084e6a0a06d86 > [root@myname ~]# bioctl -i sd0 > sd0: , serial 0077a1dc0b3da755200084e6a0a06d86 > [root@myname ~]# bioctl -i mfii0 > bioctl: Can't locate mfii0 device via /dev/bio > [root@myname ~]# bioctl -i mfii > bioctl: Can't locate mfii device via /dev/bio > [root@myname ~]# bioctl -iv sd0 > sd0: , serial 0077a1dc0b3da755200084e6a0a06d86 > Oh hmm - perhaps mfii(4) doesn't support reading status at all then, that's a surprise to me. Normally "bioctl sd0" would be enough. Volume Status Size Device mfi0 0 Online 749606010880 sd0 RAID1 WB 0 Online 750156374016 1:0.0 noencl 1 Online 750156374016 1:1.0 noencl
Re: Skylake works on Dell Latitude E5570
> Hibernate (apm -Z) does not work. > I don't know if it's related to the Skylake support at all. Maybe KARL? I think I saw a message about this on list.
Re: Good looking fonts in Java apps
On 2017-07-19 06:39:04, Bernard Mentink wrote: > Thank Bryan, > > I guess that would have to go in .kshrc? I think that is the default shell > for OpenBSD right? > It would depend on the shell you're actually using. If you haven't installed or aren't using another shell, then .kshrc is what you would want. You could also try temporarily testing this by opening an xterm (or whatever terminal program you prefer) and setting that environment variable, and then launching your browser from within the terminal so it picks up the new environment variable. If it fixes the fonts, then you can set it permanently by putting that line in .kshrc. -- Bryan
Re: Skylake works on Dell Latitude E5570
On Jul 13 15:19:12, h...@stare.cz wrote: > This is current/amd64 on Dell Latitude E5570 (full dmesg below). > Skylake started working; this is a diff to the previous dmesg: > > --- dmesg/dell-latitude-E5570.20170627Tue Jun 27 14:32:18 2017 > +++ dmesg/dell-latitude-E5570.20170713Thu Jul 13 15:11:56 2017 > @@ -1,4 +1,4 @@ > -OpenBSD 6.1-current (GENERIC.MP) #0: Tue Jun 27 14:19:42 CEST 2017 > +OpenBSD 6.1-current (GENERIC.MP) #0: Thu Jul 13 14:05:55 CEST 2017 > h...@dell.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 16810340352 (16031MB) > avail mem = 16295075840 (15540MB) > @@ -21,7 +21,7 @@ cpu0: 256KB 64b/line 8-way L2 cache > cpu0: TSC frequency 259200 Hz > 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: apic clock running at 23MHz > 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-6440HQ CPU @ 2.60GHz, 2592.00 MHz > @@ -116,9 +116,14 @@ acpivout0 at acpivideo0: LCD_ > cpu0: Enhanced SpeedStep 2592 MHz: speeds: 2601, 2600, 2400, 2300, 2200, > 2100, 2000, 1800, 1700, 1600, 1400, 1300, 1200, 1100, 900, 800 MHz > pci0 at mainbus0 bus 0 > pchb0 at pci0 dev 0 function 0 "Intel Core 6G Host" rev 0x07 > -vga1 at pci0 dev 2 function 0 "Intel HD Graphics 530" rev 0x06 > -wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) > -wsdisplay0: screen 1-5 added (80x25, vt100 emulation) > +inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 530" rev 0x06 > +drm0 at inteldrm0 > +inteldrm0: msi > +error: [drm:pid0:i915_firmware_load_error_print] *ERROR* failed to load > firmware i915/skl_dmc_ver1.bin (-22) > +error: [drm:pid0:i915_gem_init_hw] *ERROR* Failed to initialize GuC, error > -8 (ignored) > +inteldrm0: 1920x1080, 32bpp > +wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation) > +wsdisplay0: screen 1-5 added (std, vt100 emulation) > "Intel Core 6G Thermal" rev 0x07 at pci0 dev 4 function 0 not configured > xhci0 at pci0 dev 20 function 0 "Intel 100 Series xHCI" rev 0x31: msi > usb0 at xhci0: USB revision 3.0 > > So I have fullscreen and xvinfo reports XVideo Extension 2.2. > One of the problems I had before was video not resuming from suspend; > I will test and get back. Light sleep (apm -S) works, and resumes OK. Suspend (apm -z) works, and resumes OK. Hibernate (apm -Z) does not work. After powering up, instead of resuming from the hibernated image, it boots as is after a forced power-off: root fs comes up dirty etc. I don't know if it's related to the Skylake support at all. I do have a big enough swap partition. The whole system is on a crypto softraid (one big RAID partition on sd0s made into a sd1) - can that be related? Jan OpenBSD 6.1-current (GENERIC.MP) #0: Thu Jul 13 14:05:55 CEST 2017 h...@dell.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 16810340352 (16031MB) avail mem = 16295075840 (15540MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xeac10 (107 entries) bios0: vendor Dell Inc. version "1.5.0" date 04/22/2016 bios0: Dell Inc. Latitude E5570 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT LPIT SSDT SSDT SSDT DBGP DBG2 SSDT UEFI SSDT SSDT SLIC ASF! acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PXSX(S4) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) RP13(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-6440HQ CPU @ 2.60GHz, 2592.00 MHz 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,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: TSC frequency 259200 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 23MHz 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-6440HQ CPU @ 2.60GHz, 2592.00 MHz 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,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLF
Re: ntpd clock unsynced in vm
> If your clock drift is worse than that, your clock is broken. Which > alas is the case for vm. I agree with this statement. About 20 years ago, I defined the minimum system we attempt to run well on as IPL32 or I32LP64, with a MMU. Soon this was redefined as with an FPU as well, after which I observed valiant painful efforts to do softfpu on arm, causing much grief and pain and showing that FPU is needed. A while back we realized that a proper RTC is mandated. Some people still want to accept cheap hardware sold without an RTC. Those people will learn their lesson. At present, vmm is also weak in this area, not regarding the RTC, but regarding syncronous clock deliver. Mike will fix that eventually.
Re: ntpd clock unsynced in vm
On 2017-07-18, tomr wrote: > In playing with vmd, I'm unable to get the guest's ntpd to sync to its > upstream ntp (whether that's the host ntpd or poot.ntp.org). The guest > is losing about 1 second for every 2 that pass. To build a bridge between this question and Mike's reply: This problem has nothing to do with ntpd. ntpd's ability to adjust the clock is limited by adjtime(), which can correct time up to a generous maximum of 5 milliseconds for each second. If your clock drift is worse than that, your clock is broken. Which alas is the case for vm. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Getting Dell RAID status via SNMP
Stuart H wrote : > So for now you would need to run bioctl to fetch status for this. Thanks again Stuart. But I look at the man page and it is not clear to me how to use this: [root@myname ~]# bioctl -q sd0 sd0: , serial 0077a1dc0b3da755200084e6a0a06d86 [root@myname ~]# bioctl -i sd0 sd0: , serial 0077a1dc0b3da755200084e6a0a06d86 [root@myname ~]# bioctl -i mfii0 bioctl: Can't locate mfii0 device via /dev/bio [root@myname ~]# bioctl -i mfii bioctl: Can't locate mfii device via /dev/bio [root@myname ~]# bioctl -iv sd0 sd0: , serial 0077a1dc0b3da755200084e6a0a06d86
Re: AMD64 modern laptop recommendation
I only now realized that a message belonging to this thread was to me only, so the response only went to the originator of that message, not to the list. The meat of that message was -- B< -- > [ ... ] Hm. Could be their market segment isn't properly represented in .au then - the machines are apparently from .tw, not the mainland as I think I said in an earlier comment. > [ ... ] No official wiki for that purpose exists, the main info source would be the platform page for amd64 and the man pages. Then again, it's possible http://dmesgd.nycbug.org/index.cgi could turn up some useful information. I need to submit my new one there. > [ ... ] The main tip is that quite a few developers, possibly even a majority, like ThinkPads a lot. My personal recommendtation would be to stay away from late 2014 to early 2015 ThinkPad models because the units produced during roughly that period came with the mouse buttons integrated in the trackpad, so clicking with anything even approaching precision is simply not possible. Other than that, they're fine machines but I would recommend demanding a close up photograph of the trackpad. And I hear recent models can be had lightly used at attractive prices via ebay and similar. For UEFI and such, for my latest I simply did not change the BIOS defaults away from "Secure Boot" and things just worked. -- B< -- - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Good looking fonts in Java apps
Thank Bryan,
I guess that would have to go in .kshrc? I think that is the default shell
for OpenBSD right?
Cheers,
Bernie
On Tue, Jul 18, 2017 at 8:37 PM, Bryan Linton wrote:
> On 2017-07-18 13:19:27, Bernard Mentink wrote:
> > Hi Guys,
> >
> > I am running a Java app launched by javaws (IcedTea-web) and am finding
> the
> > fonts terrible, does anyone know how I can get better anti-aliased fonts?
> >
>
> I don't know about javaws, but for regular stand-alone Java
> applications I had to use the following to get fonts that were
> anywhere close to readable.
>
> export _JAVA_OPTIONS='-Dawt.useSystemAAFontSettings=on'
>
> I added it to the shell-script running the program itself. You
> may need to put this in your .${SHELL}rc file (.kshrc, .zshrc,
> .bashrc, etc.) instead if this is running inside of your browser.
>
> If it doesn't work, hopefully it will at least give you a good
> starting point to try other things.
>
> --
> Bryan
>
>
Re: OT: protonmail mail body
On 18 July 2017 at 09:29, Eric Johnson wrote: > > On Wed, 12 Jul 2017, Mihai Popescu wrote: > >> Hello, >> >> I preffer to keep it calm, but some people on the list are using >> protonmail and their mails are impossible to read directly on the >> list. I think they are destroying the list, maybe they should turn >> that feature off. Here is what I see reading on marc.info: >> >> TmV2ZXIgaGVhcmQgb2YgVk5DPwpTZW50IGZyb20gUHJvdG9uTWFpbCBNb2Jp >> bGUKCk9uIFR1ZSwgSnVsIDExLCAyMDE3IGF0IDg6MzkgUE0sIE5pZWxzIEtv >> YnNjaMOkdHpraSA8bmllbHNAa29ic2NoYWV0emtpLm5ldD4gd3JvdGU6Cgo+ >> IEhpLCBJIGFtIHBvbmRlcmluZyB0byBpbnN0YWxsIE9wZW5CU0Qgb24gbXkg >> bWFpbiBtYWNoaW5lLiBCdXQgSSBqdXN0IGZvdW5kIGEgcG9zc2libGUgc2hv >> d3N0b3BwZXI6IGZhbWlseSByZW1vdGUgc3VwcG9ydCBSaWdodCBub3cgSSBh >> bSB1c2luZyBUZWFtdmlld2VyIHRvIGNvbm5lY3QgZnJvbSBteSBMaW51eC1t >> YWNoaW5lIHRvIHRoZSBmYW1pbHktTWFjLiBOb3cgSSBhbSBzZWFyY2hpbmcg >> YSBzaW1pbGFyIGVhc3kgd2F5IHRvIGRvIHRoYXQgZnJvbSBhIHBvc3NpYmxl >> IE9wZW5CU0QtbWFjaGluZS4gSXMgdGhlcmUgYW55IHNvZnR3YXJlIHRoYXQg >> Y291bGQgZG8gdGhhdD8gQXNraW5nIHRoZW0gZm9yIHRoZWlyIElQIG9yIGlD >> bG91ZC1ob3N0bmFtZSB3b3VsZCBhbHJlYWR5IGJlIHRvbyBjb21wbGljYXRl >> ZC4gV2hhdCBhcmUgeW91IHVzaW5nIGluIHN1Y2ggY2FzZXM/IElzIGEgUUVN >> VS1WTSBwZXJmb3JtYW50IGVub3VnaCBmb3Igc3VjaCBhIHRoaW5nIChJIGhh >> dmUgYSBUaGlua3BhZCBUNDYwIHdpdGggYSBTa3lsYWtlLWk1KSBOaWVscw== > > My primary e-mail address is on protonmail. For testing purposes, I have > sent e-mail from my protonmail account to a number of other accounts and > have never had any problem reading the messages. For example, on this > account I use pine (alpine) to handle my e-mail and have never had a > problem. > Oh, I get it! You can decode base64 in your head and read messages that way. Dang, that's impressive. I know a couple people who know ASCII by memory, but never anyone who can read base64. > Eric > -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info
Re: OT: protonmail mail body
> As things stand, ProtonMail is not a suitable client for writing to this > mailing list. > > Your messages are nearly unreadable. Maybe it should be blocked. Then the users there can tell them to fix it. Would have no downside for me.
Re: OT: protonmail mail body
> On Wed, 12 Jul 2017, Mihai Popescu wrote: > > > Hello, > > > > I preffer to keep it calm, but some people on the list are using > > protonmail and their mails are impossible to read directly on the > > list. I think they are destroying the list, maybe they should turn > > that feature off. Here is what I see reading on marc.info: > > > > TmV2ZXIgaGVhcmQgb2YgVk5DPwpTZW50IGZyb20gUHJvdG9uTWFpbCBNb2Jp > > bGUKCk9uIFR1ZSwgSnVsIDExLCAyMDE3IGF0IDg6MzkgUE0sIE5pZWxzIEtv > > YnNjaMOkdHpraSA8bmllbHNAa29ic2NoYWV0emtpLm5ldD4gd3JvdGU6Cgo+ > > IEhpLCBJIGFtIHBvbmRlcmluZyB0byBpbnN0YWxsIE9wZW5CU0Qgb24gbXkg > > bWFpbiBtYWNoaW5lLiBCdXQgSSBqdXN0IGZvdW5kIGEgcG9zc2libGUgc2hv > > d3N0b3BwZXI6IGZhbWlseSByZW1vdGUgc3VwcG9ydCBSaWdodCBub3cgSSBh > > bSB1c2luZyBUZWFtdmlld2VyIHRvIGNvbm5lY3QgZnJvbSBteSBMaW51eC1t > > YWNoaW5lIHRvIHRoZSBmYW1pbHktTWFjLiBOb3cgSSBhbSBzZWFyY2hpbmcg > > YSBzaW1pbGFyIGVhc3kgd2F5IHRvIGRvIHRoYXQgZnJvbSBhIHBvc3NpYmxl > > IE9wZW5CU0QtbWFjaGluZS4gSXMgdGhlcmUgYW55IHNvZnR3YXJlIHRoYXQg > > Y291bGQgZG8gdGhhdD8gQXNraW5nIHRoZW0gZm9yIHRoZWlyIElQIG9yIGlD > > bG91ZC1ob3N0bmFtZSB3b3VsZCBhbHJlYWR5IGJlIHRvbyBjb21wbGljYXRl > > ZC4gV2hhdCBhcmUgeW91IHVzaW5nIGluIHN1Y2ggY2FzZXM/IElzIGEgUUVN > > VS1WTSBwZXJmb3JtYW50IGVub3VnaCBmb3Igc3VjaCBhIHRoaW5nIChJIGhh > > dmUgYSBUaGlua3BhZCBUNDYwIHdpdGggYSBTa3lsYWtlLWk1KSBOaWVscw== > > My primary e-mail address is on protonmail. For testing purposes, I have > sent e-mail from my protonmail account to a number of other accounts and > have never had any problem reading the messages. For example, on this > account I use pine (alpine) to handle my e-mail and have never had a > problem. If I see a mail which isn't plain text, I delete it. If that means something doesn't get handled, bummer.
Re: OT: protonmail mail body
On Wed, 12 Jul 2017, Mihai Popescu wrote: > Hello, > > I preffer to keep it calm, but some people on the list are using > protonmail and their mails are impossible to read directly on the > list. I think they are destroying the list, maybe they should turn > that feature off. Here is what I see reading on marc.info: > > TmV2ZXIgaGVhcmQgb2YgVk5DPwpTZW50IGZyb20gUHJvdG9uTWFpbCBNb2Jp > bGUKCk9uIFR1ZSwgSnVsIDExLCAyMDE3IGF0IDg6MzkgUE0sIE5pZWxzIEtv > YnNjaMOkdHpraSA8bmllbHNAa29ic2NoYWV0emtpLm5ldD4gd3JvdGU6Cgo+ > IEhpLCBJIGFtIHBvbmRlcmluZyB0byBpbnN0YWxsIE9wZW5CU0Qgb24gbXkg > bWFpbiBtYWNoaW5lLiBCdXQgSSBqdXN0IGZvdW5kIGEgcG9zc2libGUgc2hv > d3N0b3BwZXI6IGZhbWlseSByZW1vdGUgc3VwcG9ydCBSaWdodCBub3cgSSBh > bSB1c2luZyBUZWFtdmlld2VyIHRvIGNvbm5lY3QgZnJvbSBteSBMaW51eC1t > YWNoaW5lIHRvIHRoZSBmYW1pbHktTWFjLiBOb3cgSSBhbSBzZWFyY2hpbmcg > YSBzaW1pbGFyIGVhc3kgd2F5IHRvIGRvIHRoYXQgZnJvbSBhIHBvc3NpYmxl > IE9wZW5CU0QtbWFjaGluZS4gSXMgdGhlcmUgYW55IHNvZnR3YXJlIHRoYXQg > Y291bGQgZG8gdGhhdD8gQXNraW5nIHRoZW0gZm9yIHRoZWlyIElQIG9yIGlD > bG91ZC1ob3N0bmFtZSB3b3VsZCBhbHJlYWR5IGJlIHRvbyBjb21wbGljYXRl > ZC4gV2hhdCBhcmUgeW91IHVzaW5nIGluIHN1Y2ggY2FzZXM/IElzIGEgUUVN > VS1WTSBwZXJmb3JtYW50IGVub3VnaCBmb3Igc3VjaCBhIHRoaW5nIChJIGhh > dmUgYSBUaGlua3BhZCBUNDYwIHdpdGggYSBTa3lsYWtlLWk1KSBOaWVscw== My primary e-mail address is on protonmail. For testing purposes, I have sent e-mail from my protonmail account to a number of other accounts and have never had any problem reading the messages. For example, on this account I use pine (alpine) to handle my e-mail and have never had a problem. Eric
Re: Getting Dell RAID status via SNMP
On 2017-07-18, Jibby Jeremiah wrote: > Thanks for the reply Stuart. > > We are running 6.0 and here is dmesg - I x'ed out some info on this second > line - do not think it was important Thanks - so this is using mfii(4), the driver for this doesn't implement sensors yet (it's about the only one that you'll find on a newish machine that hasn't - it's supported in ami, arc, cac, ciss, ips, mfi, mpi, mpii). So for now you would need to run bioctl to fetch status for this.
Re: Verified auth tty ioctl()s implementation details
> > Now, I am running on the assumption that these ioctl()s were > > implemented as a kernel-side component of doas's "password timeout" > > functionality as observed when using the "persist" configuration > > keyword. From that, my question is whether there is any particular > > reason for recording the parent process ID in particular as part of > > the cookie stored by the persistent authentication ioctl() as opposed > > to the process group ID of the calling process's session leader, as > > with sudo. > > Yes, the difference is intentional. For pretty much exactly the reason you > noticed, although perhaps with the opposite result. A successful > authentication is not meant to be inherited by any random program or script > you run. A) because vague security concerns, but also B) because I think it's > weird that a script maybe works if it runs fast enough, but fails if it takes > five minutes to get to doas. Like "make; doas make install" works on a fast > machine but fails unexectedly on a slower machine. i'd like to point out that doas+kernel semantics are intended to be stronger than what sudo does. And if some finds a way for the kernel to become more strict (further tie-in to process groups maybe?) then we could do that easily and gain the security, as long as there is no further loss in functional use.
Re: Getting Dell RAID status via SNMP
Thanks for the reply Stuart. We are running 6.0 and here is dmesg - I x'ed out some info on this second line - do not think it was important OpenBSD 6.0-stable (GENERIC.MP) #1: Mon Feb 13 13:59:48 EST 2017 bsduser@-XXX-X-XX:/usr/src/sys/arch/amd64/compile/ GENERIC.MP RTC BIOS diagnostic error 80 real mem = 8395776000 (8006MB) avail mem = 8136851456 (7759MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x8ef68000 (46 entries) bios0: vendor Dell Inc. version "1.4.5" date 08/09/2016 bios0: Dell Inc. PowerEdge R330 acpi0 at bios0: rev 2 acpi0: sleep states S0 S5 acpi0: tables DSDT FACP BOOT SSDT SLIC HPET LPIT APIC MCFG WDAT SSDT DBGP DBG2 SSDT SSDT SSDT SSDT SSDT SSDT PRAD HEST BERT ERST EINJ DMAR FPDT acpi0: wakeup devices PEGP(S0) PEG0(S0) PEGP(S0) PEG1(S0) PEGP(S0) PEG2(S0) XHC_(S0) XDCI(S0) PXSX(S0) RP01(S0) PXSX(S0) RP02(S0) PXSX(S0) RP03(S0) PXSX(S0) RP04(S0) [...] 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) Xeon(R) CPU E3-1220 v5 @ 3.00GHz, 3293.55 MHz 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT 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, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E3-1220 v5 @ 3.00GHz, 3292.35 MHz 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT 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) Xeon(R) CPU E3-1220 v5 @ 3.00GHz, 3292.35 MHz 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT 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) Xeon(R) CPU E3-1220 v5 @ 3.00GHz, 3292.35 MHz 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,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt0: no apic found for irq 32 acpiprt0: no apic found for irq 33 acpiprt0: no apic found for irq 34 acpiprt1 at acpi0: bus 1 (PEG0) acpiprt2 at acpi0: bus 2 (PEG1) acpiprt3 at acpi0: bus 3 (PEG2) acpiprt4 at acpi0: bus -1 (RP01) acpiprt5 at acpi0: bus -1 (RP02) acpiprt6 at acpi0: bus -1 (RP03) acpiprt7 at acpi0: bus -1 (RP04) acpiprt8 at acpi0: bus -1 (RP05) acpiprt9 at acpi0: bus -1 (RP06) acpiprt10 at acpi0: bus -1 (RP07) acpiprt11 at acpi0: bus -1 (RP08) acpiprt12 at acpi0: bus 4 (RP09) acpiprt13 at acpi0: bus -1 (RP10) acpiprt14 at acpi0: bus 5 (RP11) acpiprt15 at acpi0: bus -1 (RP12) acpiprt16 at acpi0: bus -1 (RP13) acpiprt17 at acpi0: bus -1 (RP14) acpiprt18 at acpi0: bus -1 (RP15) acpiprt19 at acpi0: bus -1 (RP16) acpiprt20 at acpi0: bus -1 (RP17) acpiprt21 at acpi0: bus -1 (RP18) acpiprt22 at acpi0: bus -1 (RP19) acpiprt23 at acpi0: bus -1 (RP20) acpicpu0 at acpi0: C1(@1 halt!) acpicpu1 at acpi0: C1(@1 halt!) acpicpu2 at acpi0: C1(@1 halt!) acpicpu3 at acpi0: C1(@1 halt!) "ACPI000D" at acpi0 not configured "INT3F0D" at acpi0 not configured "PNP0501" at acpi0 not configured "PNP0501" at acpi0 not configured "IPI0001" at acpi0 not configured acpibtn0 at acpi0: SLPB "PNP0C14" at acpi0 not configured "PNP0C33" at acpi0 not
Re: IPv6 with wide-dhcpv6
On 7/17/2017 11:09 PM, David Higgs wrote: >[snip] > After a good amount of trial and error, it appears that Comcast will only > dole out a single /128 via DHCPv6. Annoying but easy enough to work around > with pf(4) nat-to and some static RFC 4193 prefixes. I have Comcast as my ISP. Comcast's IPv6 DHCP, by default, doles out a /128. If you also want a prefix delegation, you have to ask for it. Comcast will give out up to a /60 prefix delegation. I ask for and receive a /62. If you don't specify a prefix delegation length, you'll get a /64 prefix. I use the ISC-DHCP dhclient with this patch: https://archive.mgm51.com/sources/pd-pref.html It's been running reliably ever since Comcast fired up IPv6 in my area, i.e., more than three years. IPv6 is deployed nationwide on Comcast's network for at least a couple of years now.
Re: Best place for VM images
On Tue, Jul 18, 2017 at 09:15:41AM -0600, Theo de Raadt wrote: > > Sure. I don't have a really strong opinion one way or the other. When I > > mentioned I put mine in a dedicated partition, I use /data/vmm or various > > places in /home if I've already fully partitioned the machine in question. > > I don't think a seperate partition is neccessary. > > However I think this should stop saying /var/anything right away, because > that is leading people in the wrong direction. > Please go ahead, I don't have any attachment to /var, feel free to update the man page to something different. -ml
Re: ntpd clock unsynced in vm
On Tue, Jul 18, 2017 at 08:45:04PM +1000, tomr wrote: > Good time-of-day, > > In playing with vmd, I'm unable to get the guest's ntpd to sync to its > upstream ntp (whether that's the host ntpd or poot.ntp.org). The guest > is losing about 1 second for every 2 that pass. I'm using a recent > snapshot on both host and guest on a 1st gen thinkpad X1 carbon (dmesgs > below). > This is a known issue that we have been working (slowly) to resolve. There are several things contributing to this and we have been knocking them down one at a time. It's better than it has been, but worse than it should be. For now, a 1000HZ host *may* make a difference for you but it's probably still not going to keep perfect time and it's just a workaround anyway. -ml
Re: Best place for VM images
> Sure. I don't have a really strong opinion one way or the other. When I > mentioned I put mine in a dedicated partition, I use /data/vmm or various > places in /home if I've already fully partitioned the machine in question. I don't think a seperate partition is neccessary. However I think this should stop saying /var/anything right away, because that is leading people in the wrong direction.
Re: Best place for VM images
On Tue, Jul 18, 2017 at 09:08:10AM -0600, Theo de Raadt wrote: > > I've been putting mine in a dedicated partition. /var/vmm should probably > > be its own partition if used. > > > > nodev, nosuid are probably good choices there too. > > That won't work. People without an additional partition will get these > mount options. And anyways those system flags don't make any sense for > such controlled files. > > Anyways, this stuff should not be in /var at all! > > /var/ Multi-purpose log, temporary, transient, and spool files. > > Note the word transient. > > These vmm images people are creating are for their own use, and I don't > think they should be anywhere near a system directory, let alone the > system directory /var. > > I'd suggest /home/vmm as a good place to store them. > Sure. I don't have a really strong opinion one way or the other. When I mentioned I put mine in a dedicated partition, I use /data/vmm or various places in /home if I've already fully partitioned the machine in question. I think the original mentioning of /var/vmm probably was put in there based on the similar usage of /var/www, but I won't defend that choice :) -ml
Re: Verified auth tty ioctl()s implementation details
> On 2017-07-18, multiplex'd wrote: > > Thank you for explaining; I suspected the reasoning was such. Speaking > > specifically > > about ports, is there a way to start a port build as root and then drop > > priviledges > > (in a similar manner to the base system's build infrastructure)? A quick > > glance > > through bsd.port.mk(5) suggests that this isn't (yet) possible. (A possible > > workaround > > is to run "make fetch" as a normal user, "make prepare" as root and "make > > build" as > > normal user etc, however if there are dependencies which need to be built > > at the "make > > prepare" stage then they are built as root.) > > dpb(8) handles this automatically, but it's a pain when you're starting > work on a new port from scratch especially if you don't have a > particularly clean ports tree. This ran into the same problem as base system builds: it isn't terribly difficult to build a de-escalation mechanism into a large infrastructure from the top-down, but it is much harder to build it for the internal elements. cd /usr/src/bin/ls; make. No de-escalation occurs. But in some ways that matches the development process, so that is OK.
Re: Best place for VM images
> I've been putting mine in a dedicated partition. /var/vmm should probably > be its own partition if used. > > nodev, nosuid are probably good choices there too. That won't work. People without an additional partition will get these mount options. And anyways those system flags don't make any sense for such controlled files. Anyways, this stuff should not be in /var at all! /var/ Multi-purpose log, temporary, transient, and spool files. Note the word transient. These vmm images people are creating are for their own use, and I don't think they should be anywhere near a system directory, let alone the system directory /var. I'd suggest /home/vmm as a good place to store them.
Re: Best place for VM images
Hey, Hey friends, what is the best/recommended place to store the vmm images. In man 5 vm.conf is an example with/var/vmm/, is this the best location? Also if /var/vmm is its own partition, what would be the best mount options for it. I would assume nodev, nosuid are good. Any recommendations? Thanks and greetings Leo I've been putting mine in a dedicated partition. /var/vmm should probably be its own partition if used. nodev, nosuid are probably good choices there too. thank you for your answer. I am going to follow your advice here. Do you think this is something that should be put into the man page? I can imagine more people having this same question. Or do you think its to trivial and would just bloat up the man page? Thanks and greetings Leo
ntpd clock unsynced in vm
Good time-of-day,
In playing with vmd, I'm unable to get the guest's ntpd to sync to its
upstream ntp (whether that's the host ntpd or poot.ntp.org). The guest
is losing about 1 second for every 2 that pass. I'm using a recent
snapshot on both host and guest on a 1st gen thinkpad X1 carbon (dmesgs
below).
Host (192.168.1.1) ntpd.conf contains:
servers pool.ntp.org
sensor *
listen on 192.168.1.1
Guest (192.168.1.45) ntpd.conf:
servers pool.ntp.org weight 2
servers 192.168.1.1 weight 5
sensor *
After waiting a couple of minutes for peers and vmmci0 to validate
(should it take that long?), 'ntpctl -s all' returns:
2/2 peers valid, 1/1 sensors valid, clock unsynced, clock offset is
32281.993ms
peer
wt tl st next poll offset delay jitter
192.168.1.1 from pool
5 10 3 17s 30s 31664.409ms 1.342ms 1.093ms
91.148.192.49 from pool pool.ntp.org
2 10 2 24s 33s 32368.088ms 191.773ms16.310ms
sensor
wt gd st next poll offset correction
vmmci0
1 1 09s 15s 98635.552ms 0.000ms
Running 'ntpd -dvs' on the guest, I get an initial correction working
fine, but then rapid lag.
ntp engine ready
sensor vmmci0 added (weight 1, correction 0.00, refstr 1146241352,
stratum 0)
sensor vmmci0: offset 182.934150
set local clock to Tue Jul 18 20:28:00 AEST 2017 (offset 182.934150s)
reply from 192.168.1.1: offset 103.081636 delay 182.956776, next query 8s
reply from 91.148.192.49: offset 11.955610 delay 0.179250, next query 6s
sensor vmmci0: offset 14.342282
reply from 91.148.192.49: offset 16.811849 delay 0.191814, next query 6s
reply from 192.168.1.1: offset 17.636314 delay 0.000753, next query 6s
reply from 91.148.192.49: offset 21.882577 delay 0.182973, next query 6s
reply from 192.168.1.1: offset 22.651855 delay 0.000650, next query 7s
peer 91.148.192.49 now valid
reply from 91.148.192.49: offset 26.093048 delay 0.193890, next query 7s
sensor vmmci0: offset 26.774802
peer 192.168.1.1 now valid
reply from 192.168.1.1: offset 27.704139 delay 0.000945, next query 7s
reply from 91.148.192.49: offset 31.263042 delay 0.200928, next query 8s
reply from 192.168.1.1: offset 32.950914 delay 0.000978, next query 5s
reply from 192.168.1.1: offset 36.540396 delay 0.002326, next query 8s
reply from 91.148.192.49: offset 37.510453 delay 0.214019, next query 6s
reply from 192.168.1.1: offset 42.784325 delay 0.000786, next query 34s
reply from 91.148.192.49: offset 42.847706 delay 0.194050, next query 30s
sensor vmmci0: offset 39.764442
sensor vmmci0: offset 52.734895
reply from 91.148.192.49: offset 66.757008 delay 0.226063, next query 30s
reply from 192.168.1.1: offset 69.387955 delay 0.000875, next query 31s
adjusting local clock by 22.651855s
sensor vmmci0: offset 43.123480
sensor update vmmci0: offset 23.597814
sensor vmmci0: offset 56.069524
reply from 91.148.192.49: offset 67.973792 delay 0.193812, next query 33s
reply from 192.168.1.1: offset 70.602103 delay 0.001234, next query 31s
I don't know how quickly that 'adjusting local clock by XXX' should take
effect, but running 'date ; sleep 1' in a loop shows no drastic steps.
vm.conf snippet for this vm:
disk "/home/tomr/vms/fresh_snapshot"
memory 1G
interface { switch "local" }
I added the 'memory 1G' line later on - results were the same with the
default of 512M.
Starting up, ntpd initially complained about /var/db/ntpd.drift being
empty, but never wrote to it. I entered a few numbers manually, but they
were never updated.
looking forward to a clue...
tom
dmesg for host:
OpenBSD 6.1-current (GENERIC.MP) #97: Sat Jul 15 12:08:50 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8383655936 (7995MB)
avail mem = 8123781120 (7747MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9d000 (68 entries)
bios0: vendor LENOVO version "G6ET96WW (2.56 )" date 04/29/2013
bios0: LENOVO 34486T7
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT
ASF! UEFI UEFI MSDM SSDT SSDT DMAR UEFI SSDT DBG2
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3)
EHC1(S3) EHC2(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1796.21 MHz
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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: TSC frequency 1796205600 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic cloc
Re: Choice of sis(4) versus vr(4) ?
Hi Lars, On 07/18/17 11:11, Stuart Henderson wrote: > On 2017-07-17, Lars Noodén wrote: >> I'm looking to refurbish an old device and will probably add a network >> card to it. Are there any reasons based on the current drivers or the >> hardware itself to choose sis(4) or vr(4) over one or the other on >> i386 -curren? >> >> Regards, >> Lars >> >> > > Staying within these drivers, the VT6105 version of vr(4) is the better > choice. Can't you find an old intel fxp(4) instead though? I don't know where you're from, but if you're from The Netherlands, I still have two PCI fxp(4) cards you can have. Kind regards, Martijn
Re: Restoring /altroot
On Mon, Jul 17, 2017 at 08:18:25AM -0400, Nick Holland wrote: > On 07/17/17 05:50, Raimo Niskanen wrote: > > On Fri, Jul 14, 2017 at 10:46:14PM -0400, Nick Holland wrote: > >> On 07/14/17 09:00, Raimo Niskanen wrote: > >> > Hi misc@. > >> > > >> > I wonder how to restore from an /altroot backup? > >> > > >> > (I missed that pax -r happily writes absolute paths and wrote over > >> > /etc from a backup file of another machine) > >> > > >> > > >> > Is it to dd(1) back all but the first 16 blocks - the reverse of what > >> > daily(8) does? Is that all that is needed? > >> > >> don't... > >> > >> > (I missed to skip the first 16 blocks, and I used the block devices > >> > instead > >> > of the character devices. The result was a vegetable, and would like to > >> > understand which of my mistakes that were fatal.) > > probably worth answering why this failed... > 1) The first 16 blocks are where the disklabel is hiding on the first > partition (usually, 'a'). Blindly copy over a disklabel from the wrong > disk, you will blow away your current disklabel. BEST case (both disks > have the exact same layout), you just changed the DDUID of your target > disk. > > 2) writing to sd0a/wd0a instead of rsd0a/rwd0a just drops the data in > the wrong place. This error probably saved your disklabel, so it's a > good error to combine with the first. Didn't help anything, but kept > the damage from being worse. Strange. It seems I got a wiped disklabel. Anyway not worth digging into anymore. Thank you for the insight! > > >> yeah, that's why. It CAN work, but ... it is the hard way and it's > >> error prone. > >> > >> better way: let's say sd1k is your /altroot... > >> > >> # mount /dev/sd1k /altroot > >> > >> now...it's just a normal file system on a normal place. Copy out > >> whatever you want. umount it when done, please. > >> > >> Nick. > > > > Yes, thank you! That is the safe way. In this case I wanted to get rid > > of all files that my pax fumbling had put there, so I wanted to clear the > > root filesystem and copy back all from /altroot. But then I also would > > have ro run installboot on the restored root filesystem, right? > > > > Is that the right(tm) way to do it? > > If you copy files from any backup back to root, yes, you will need to > re-run installboot. This has to be done any time /boot could have moved > to a new physical spot on the disk. > > If you really want to blow things completely away, give consideration to > doing an "upgrade" (to either what you were running or most recent > release, or even -current), then restoring your /etc/ directory, and > re-running sysmerge afterwards (if you change versions). > > Nick. A maybe some day useful trick indeed. Thank you! -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: Good looking fonts in Java apps
On 2017-07-18 13:19:27, Bernard Mentink wrote:
> Hi Guys,
>
> I am running a Java app launched by javaws (IcedTea-web) and am finding the
> fonts terrible, does anyone know how I can get better anti-aliased fonts?
>
I don't know about javaws, but for regular stand-alone Java
applications I had to use the following to get fonts that were
anywhere close to readable.
export _JAVA_OPTIONS='-Dawt.useSystemAAFontSettings=on'
I added it to the shell-script running the program itself. You
may need to put this in your .${SHELL}rc file (.kshrc, .zshrc,
.bashrc, etc.) instead if this is running inside of your browser.
If it doesn't work, hopefully it will at least give you a good
starting point to try other things.
--
Bryan
Re: Verified auth tty ioctl()s implementation details
On 2017-07-18, multiplex'd wrote: > Thank you for explaining; I suspected the reasoning was such. Speaking > specifically > about ports, is there a way to start a port build as root and then drop > priviledges > (in a similar manner to the base system's build infrastructure)? A quick > glance > through bsd.port.mk(5) suggests that this isn't (yet) possible. (A possible > workaround > is to run "make fetch" as a normal user, "make prepare" as root and "make > build" as > normal user etc, however if there are dependencies which need to be built at > the "make > prepare" stage then they are built as root.) dpb(8) handles this automatically, but it's a pain when you're starting work on a new port from scratch especially if you don't have a particularly clean ports tree.
Re: Getting Dell RAID status via SNMP
On 2017-07-17, Jibby Jeremiah wrote: > Hi folks, > > On HP HW we can query the RAID status of a system remotely with snmpwalk on > > .1.3.6.1.4.1.30155.2.1.2.1.5.3 > > And you get back a status of one of the following 3 : > - online > - pfail > - rebuild > > Works great! This provides access to 'sysctl hw.sensors' information. (This is more obvious if you look at the whole table with "snmptable -v2c -c public localhost sensorTable"). > I cannot find a RAID status on a Dell though. See "include important information" on http://www.openbsd.org/mail.html
Re: Choice of sis(4) versus vr(4) ?
On 2017-07-17, Lars Noodén wrote: > I'm looking to refurbish an old device and will probably add a network > card to it. Are there any reasons based on the current drivers or the > hardware itself to choose sis(4) or vr(4) over one or the other on > i386 -curren? > > Regards, > Lars > > Staying within these drivers, the VT6105 version of vr(4) is the better choice. Can't you find an old intel fxp(4) instead though?
Re: CVS: tag exploration
On 2017-07-17, Daniil Berendeev wrote: > Hi, > > I'd like to backfill the changes in 6.1 to > https://openbsd.org/plus61.html and update > https://openbsd.org/plus.html, but I faced a little problem: how do I > find out the last revision number before the pre-release code freeze? > Those revisions must be tagged, but, apparently, cvs(1) doesn't provide > any way to get a tag list or see some info on tag. > > Do I miss something? > > The versions are shown at the top of "cvs log" - OPENBSD_x_y_BASE is the version when the release was tagged e.g. symbolic names: OPENBSD_2_3: 1.8.0.2 OPENBSD_2_3_BASE: 1.8 OPENBSD_2_4: 1.15.0.2 OPENBSD_2_4_BASE: 1.15 OPENBSD_2_5: 1.15.0.4 OPENBSD_2_5_BASE: 1.15 OPENBSD_2_6: 1.16.0.2 OPENBSD_2_6_BASE: 1.16 (...) So for this file, 2.3 had rev 1.8, 2.4 had r 1.15, etc.
Re: Compiling Linux source on OpenBSD
On 2017-07-18, Bernard Mentink wrote: > Hi all, > > This is my first time on OpenBSD and am really loving it. I had my HP > Pavilion desktop booting into a Gnome3 desktop in no time (.. had so many > issues trying to boot FreeBSD, gave up) > > My question is regarding compiling Linux code. I have some tools for > programming FPGA's which I would really like to do on BSD, i.e the likes of > IceStorm tools and Yosys ... etc > They are not in the Repo or in Ports so don't have much option but to try > and compile from linux which failed of course with lot's of errors the > first time I tried. > > Is there any guidelines for porting this stuff? Start by using the ports infrastructure as it handles some things automatically. Between the ports section of the faq, comments in ports/infrastructure/Makefile.template, and cribbing from existing ports it shouldn't be too tricky to get something that downloads and starts trying to compile - if you then run into problems, send a tar.gz of your work to ports@ with a description and build logs and see if someone can help (logs might give enough a clue to make suggestions, but having the ports bits will make it easy to replicate your work if we need to dig deeper). If the programs you're interested in are ported to FreeBSD or pkgsrc you might be able to borrow ideas or patches from there too.
Re: syspatch glitch
On Mon, Jul 17, 2017 at 02:20:00PM +0200, Antoine Jacoutot wrote: > On Mon, Jul 17, 2017 at 12:04:19PM +0200, Raimo Niskanen wrote: > > It seems syspatch looks at the current machine capabilities instead of > > which kernel is running when it decides on if /bsd is /bsd.sp or /bsd.mp. > > Hi. > > > I tried to install OpenBSD 6.1 to a USB connected CF card that later will > > run in an alix2d13 that has got one core, but I did the installation from > > a laptop with two cores. Both i386. > > > > Then I moved /bsd to /bsd.mp and /bsd.sp to /bsd since the installer had > > detected that the install machine should run /bsd.mp. > > > > After that I ran syspatch, still on the laptop, and it failed on patch 002 > > with as I remember tar complaining on not being able to find /bsd.sp. > > I you run syspatch on the laptop then what you call the running kernel is the > one that booted (i.e. the one on the laptop). That's perfectly normal and as > you saw this is what the installer does as well. > > > installation, and after that it seems both /bsd (.mp) and /bsd.sp are > > patched, so I can hopefully change the kernels just before putting the CF > > card in the Alix instead, so no harm done. > > > > But is it by design that syspatch looks at the running machine instead of > > the running kernel? I would have expected it the other way around... > > Why would you expect that? > The installation was done on an MP system. The running machine and running > kernel as the same in your setup. Well, what I tried to do was to swap kernels to run the SP kernel on my MP machine and then run openup(syspatch), assuming that the running kernel is what determines how to patch the kernels. That is what I expected most likely to work... > > What you want to do instead is run syspatch from rc.firstime on your Alix. In this case I wanted to upgrade the system much far as possible before booting it on the Alix, i.e pkg_add, and openup(syspatch). 6.1 has got a number of kernel patches by no so it would be nice to start with them applied. > Kernel handling is tricky because we need to handle 2 different kernels and > kernel is usually the thing people like to fuck with... It seems both kernels are patched, so as long as I know how it works I can live with that. > > -- > Antoine -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: Verified auth tty ioctl()s implementation details
On Mon, Jul 17, 2017 at 04:39:10PM -0400, Ted Unangst wrote: > Yes, the difference is intentional. For pretty much exactly the reason you > noticed, although perhaps with the opposite result. A successful > authentication is not meant to be inherited by any random program or script > you run. A) because vague security concerns, but also B) because I think it's > weird that a script maybe works if it runs fast enough, but fails if it takes > five minutes to get to doas. Like "make; doas make install" works on a fast > machine but fails unexectedly on a slower machine. > > A more robust approach to this problem is to invert privilege. Start as root, > then drop to another user. Thank you for explaining; I suspected the reasoning was such. Speaking specifically about ports, is there a way to start a port build as root and then drop priviledges (in a similar manner to the base system's build infrastructure)? A quick glance through bsd.port.mk(5) suggests that this isn't (yet) possible. (A possible workaround is to run "make fetch" as a normal user, "make prepare" as root and "make build" as normal user etc, however if there are dependencies which need to be built at the "make prepare" stage then they are built as root.) Regards
