Re: openiked + rc.conf.local

[Matt Behrens]

On Sep 26, 2016, at 2:26 PM, Infoomatic  wrote:

>> Do you get any more output if you do "rcctl -f -d start iked"?

> the output is:
> doing _rc_parse_conf
> doing _rc_quirks
> iked_flags empty, using default ><
> doing _rc_parse_conf /var/run/rc.d/iked
> doing _rc_quirks
> doing rc_check
> iked
> doing rc_pre
> configuration OK
>
> and then the terminal is blocked again

This looks similar to a problem I filed a bug on; see
https://marc.info/?l=openbsd-bugs&m=147463700507932&w=2


My workaround for now is to edit /etc/rc.d/iked and uncomment the `return 0`.
The line with `${daemon} -n ${daemon_flags}` has iked do a config test, which
appears to not exit cleanly.

iked config test hanging on 6.0

[Matt Behrens]

I've tried this on a few different systems now, one upgraded from 5.9 to 6.0
with the install CD, one a brand-new 6.0 install. The former is running as a
hosted VM at Vultr, the latter a VMware Fusion machine.

I'm not sure if this is a problem just in a virtual machine context, but I
don't have any physical hardware available to check it on at the moment. As
such, I'm not confident I have a bug, and would appreciate comments from the
community on whether they experience the same problem.

The iked config test in /etc/rc.d/iked hangs fairly reliably. I've ktraced it
and it looks like this when hanging, stopping at the wait4:

 91211 iked CALL  write(2,0x7b37a13ec73,0x11)
 91211 iked GIO   fd 2 wrote 17 bytes
   "configuration OK
   "
 91211 iked RET   write 17/0x11
 91211 iked CALL  kbind(0x7f7ce4f8,24,0x2e9d25833eef97c0)
 91211 iked RET   kbind 0
 91211 iked CALL  kill(-91211,SIGTERM)
 91211 iked RET   kill -1 errno 3 No such process
 91211 iked CALL  kill(-84806,SIGTERM)
 91211 iked RET   kill -1 errno 3 No such process
 91211 iked CALL  kill(-90967,SIGTERM)
 91211 iked RET   kill -1 errno 3 No such process
 91211 iked CALL  kill(-50484,SIGTERM)
 91211 iked RET   kill -1 errno 3 No such process
 91211 iked CALL  kbind(0x7f7ce4f8,24,0x2e9d25833eef97c0)
 91211 iked RET   kbind 0
 91211 iked CALL  wait4(WAIT_ANY,0,0<>,0)

The kill pids are all valid pids (one is the process itself), and earlier in
the ktrace output they were fork results:

 91211 iked CALL  fork()
 91211 iked RET   fork 90967/0x16357
 91211 iked CALL  fork()
 91211 iked RET   fork 84806/0x14b46
 91211 iked CALL  fork()
 91211 iked RET   fork 50484/0xc534

On the Vultr VM, if I run with -d (e.g. rcctl -df start iked), it starts fine.
It seems like this is because iked -n is allowed to output "configuration OK"
to the console. This doesn't work on the VMware Fusion machine.

I can run iked -n just fine without any problem, though on the Vultr machine
sometimes it prints exits for the privsep processes, and not predictably:

# iked -n
configuration OK
ca exiting, pid 8933
# iked -n
configuration OK
ca exiting, pid 46440
# iked -n
configuration OK
ca exiting, pid 99924
# iked -n
configuration OK
ca exiting, pid 57315
ikev2 exiting, pid 38805

On the VMware machine, it always just prints "configuration OK".

Commenting out the config test in /etc/rc.d/iked appears to be a viable
workaround.

To reproduce this on the brand-new VMware machine, I created a basic "road
warrior" config similar to the one I run on the Vultr machine:

# ikectl ca CA create

ikectl.conf:

user username passive

ikev2 'configuration' passive esp \
from 0.0.0.0/0 to 10.0.0.0/24 local any peer any \
src vpn.local \
eap "mschap-v2" \
config address 10.0.0.1 \
config name-server 8.8.8.8

Re: 5.5 CDs arriving

[Matt Behrens]

On Apr 30, 2014, at 12:56 PM, Dave Anderson  wrote:

> Just got mine, near Boston, Mass.

Mine arrived in Grand Rapids, MI yesterday.

> My thanks to everyone involved.

And mine as well!

[demime 1.01d removed an attachment of type application/pgp-signature which had 
a name of signature.asc]

Panic with degraded softraid RAID 5 array

[Matt Behrens]

Been playing with 5.1-beta (Jan. 21 build) in the interests of seeing
what I need to get together to set up my next system.  I was hoping to
do it with three drives, booting from a softraid RAID 5 volume.

When installed and rebooted, all works OK.  What I've been running into
are panics when trying to run the softraid volume in degraded mode,
i.e. if I disconnect a drive and start the system.

I've seen similar issues with a RAID 5 volume mounted on just /home
instead of on /.  RAID 1 appears to work fine, though.

Here's one example.  Though the panic traces vary, they're all very easy
to reproduce--just set up a three-drive RAID 5 array, then bring up the
system with one drive missing.

>> OpenBSD/i386 BOOT 3.17
boot>
booting hd0a:/bsd: 8230716+1088904 [61+369072+354699]=0x9941dc
entry point at 0x200120 

[ using 724248 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2012 OpenBSD. All rights reserved.  http://www.OpenBSD.org

OpenBSD 5.1-beta (GENERIC) #140: Sat Jan 21 00:40:23 MST 2012
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Pentium(R) 4 CPU 2.80GHz ("GenuineIntel" 686-class) 2.79 GHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF
LUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,CNXT-ID
real mem  = 1341124608 (1278MB)
avail mem = 1309093888 (1248MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 10/22/02, BIOS32 rev. 0 @ 0xffe90, SMBIOS
rev. 2.3 @ 0xf0450 (90 entries)
bios0: vendor Dell Computer Corporation version "A01" date 10/22/2002
bios0: Dell Computer Corporation Precision WorkStation 350
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC BOOT ASF!
acpi0: wakeup devices VBTN(S4) PCI0(S5) PCI1(S5) USB0(S3) USB1(S3) USB2(S3) USB3
(S3) KBD_(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 132MHz
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 1
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (PCI1)
acpicpu0 at acpi0
acpibtn0 at acpi0: VBTN
bios0: ROM list: 0xc/0xa800 0xca800/0x1800
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82850 Host" rev 0x04
intelagp0 at pchb0
agp0 at intelagp0: aperture at 0xf000, size 0x800
ppb0 at pci0 dev 1 function 0 "Intel 82850/82860 AGP" rev 0x04
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "NVIDIA Vanta" rev 0x15
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
ppb1 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0x04
pci2 at ppb1 bus 2
uhci0 at pci2 dev 1 function 0 "VIA VT83C572 USB" rev 0x50: apic 1 int 19
uhci1 at pci2 dev 1 function 1 "VIA VT83C572 USB" rev 0x50: apic 1 int 18
ehci0 at pci2 dev 1 function 2 "VIA VT6202 USB" rev 0x51: apic 1 int 16
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "VIA EHCI root hub" rev 2.00/1.00 addr 1
uhci2 at pci2 dev 2 function 0 "VIA VT83C572 USB" rev 0x50: apic 1 int 18
uhci3 at pci2 dev 2 function 1 "VIA VT83C572 USB" rev 0x50: apic 1 int 17
ehci1 at pci2 dev 2 function 2 "VIA VT6202 USB" rev 0x51: apic 1 int 19
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 "VIA EHCI root hub" rev 2.00/1.00 addr 1
dc0 at pci2 dev 9 function 0 "ADMtek AN983" rev 0x11: apic 1 int 18, address 
00:06:25:08:1c:04
ukphy0 at dc0 phy 1: Generic IEEE 802.3u media interface, rev. 1: OUI 0x000749, 
model 0x0001
dc1 at pci2 dev 10 function 0 "ADMtek AN983" rev 0x11: apic 1 int 19, address 
00:04:5a:7e:34:56
ukphy1 at dc1 phy 1: Generic IEEE 802.3u media interface, rev. 1: OUI 0x000749, 
model 0x0001
em0 at pci2 dev 12 function 0 "Intel PRO/1000MT (82540EM)" rev 0x02: apic 1 int 
18, address 00:07:e9:85:5d:be
usb2 at uhci0: USB revision 1.0
uhub2 at usb2 "VIA UHCI root hub" rev 1.00/1.00 addr 1
usb3 at uhci1: USB revision 1.0
uhub3 at usb3 "VIA UHCI root hub" rev 1.00/1.00 addr 1usb4 at uhci2: USB 
revision 1.0
uhub4 at usb4 "VIA UHCI root hub" rev 1.00/1.00 addr 1
usb5 at uhci3: USB revision 1.0
uhub5 at usb5 "VIA UHCI root hub" rev 1.00/1.00 addr 1
ichpcib0 at pci0 dev 31 function 0 "Intel 82801BA LPC" rev 0x04
pciide0 at pci0 dev 31 function 1 "Intel 82801BA IDE" rev 0x04: DMA, channel 0 
wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: 
wd0: 16-sector PIO, LBA, 38146MB, 78125000 sectors
wd1 at pciide0 channel 0 drive 1: 
wd1: 16-sector PIO, LBA, 58644MB, 120103200 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5
wd1(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 5
pciide0: channel 1 ignored (disabled)
ichiic0 at pci0 dev 31 function 3 "Intel 82801BA SMBus" rev 0x04: apic 1 int 17
iic0 at ichiic0
iic0: addr 0x2d 1e=00 1f=00 20=c0 21=7c 22=c3 23=c

Re: Panic with degraded softraid RAID 5 array

[Matt Behrens]

On Fri, Jan 27, 2012 at 09:30:46PM +1100, Joel Sing wrote:

> From bioctl(8):
> 
> CAVEATS
>  Use of the CRYPTO & RAID 4/5 disciplines are currently considered
>  experimental.
> 
> (I probably should remove CRYPTO from that list though, since it is now 
> pretty 
> stable :)

Yeah, I apologize.  There was this, too, on softraid(4), which I totally
failed to read:

 The RAID 4 and 5 disciplines do not initialize the parity upon
 creation.  This is due to the scrub functionality not being currently
 implemented.

Had I noted that, I doubt I would have even tried :-)

> That particular trace suggests that your file system is hosed. However, RAID 
> 5 
> is not ready for prime-time yet - as far as I know it will work correctly 
> until you lose a disk, at which point it will support read-only access (e.g. 
> you should be able to keep your data), however any attempts to write will 
> result in a panic. Also, there is no support for scrubbing or rebuilding, 
> which makes it non-ideal for production.

Ah, that does mirror an experience I had once testing.  Writing was
indeed what threw it off.  Still, yeah, that is not particularly ideal
for my situation--the important data is always going to be backed up
somewhere, but it's the system itself I'd like to preserve so I can
avoid having to rebuild.

Thanks for the reply.