Re: kernel relink segfaults on ALIX

[Patrick Dohman]

> ed...@pettijohn-web.com wrote:
> 
> One step further would be to put that in your rc.local so it survives an 
> upgrade.
> 

An even more insecure option is:
chmod 000 /usr/libexec/reorder_kernel
doas chflags schg /usr/libexec/reorder_kernel
Beware securelevel 0 is required to clear the "schg” file flag.

Mamma mia!
Patrick

Re: sshfuse: fusefs: libfuse vnode reclaim failed

[IL Ka]

First, make sure your SSH connection is stable.

Try to SSH to your server, run some commands,
download big (several megabytes) file
using SCP or SFTP.
It could be that your SSH problems.

If it works, then we can try
to investigate it:


> libfuse vnode reclaim failed

This message is from following code:
if (fb_queue(fmp->dev, fbuf))
printf("fusefs: libfuse vnode reclaim failed\n");

"fuse_lookup.c"

As we can see, "fb_queue" retruns error, but we do not know
which error.

I think we need to know this error to understand what happened.

In "fb_queue" source (fusebuf.c) we can see that error is
return code from "tsleep" or "fbuf->fb_err".


This code is part of this commit:
https://github.com/openbsd/src/commit/5e69e0b69176a7f878c899ef5828a6273ab7f0bb
Written by https://github.com/natano , while file originally written by
Sylvestre Gallon 

So, you have 2 options here:

Debug it yourself by kernel debugging (gdb)
or patch kernel and print this error value to kernel log
(printf(9)) (could be good contribution to kernel btw)

Or you can write to tech@ or bugs@
about this problem and wait for developer's attention.

I can't help you unfortunatelly because
this issue is not reproducible for me: I tried sshfs: it works like charm.

Re: NFS server down, again, and again, and again...

[Fred]

On 04/19/18 16:39, Steve Williams wrote:



On 19/04/2018 7:55 AM, Rupert Gallagher wrote:

On Thu, Apr 19, 2018 at 15:38, Zé Loff  wrote:


# mountd -d > /var/log/mountd.log 2&>1 &
It is the first thing I did this morning. Unfortunately it does not 
survive when ssh breaks out. Also, mountd -d is returning the shell 
prompt again, so I have no logs at all.


Hi,

A couple of things...  you need to read about "nohup" if you are trying 
to run programs in the background and they are getting killed when the 
ssh session ends.


Additionally, there are two programs that are very useful..

script
and
screen

"script" is on every Unix type system that I've ever been on in my last 
35+ years of working on Unix type systems.


I believe that there is an "in-tree" replacement for the functionality 
that "screen" brings, but I cannot remember what it's called. Otherwise, 
use the screen package.


"screen" allows you to run an interactive session (mountd -d) and 
"detach" (^AD) the session, log out, and at some point in the future, 
"resume" the screen session.. (screen -r).


Combined with "script", which will log all information that is appearing 
on the screen to a file, you should be able to run "mountd -d" and 
capture all information to a file, as well as resuming the session to 
see what is going on interactively.


Cheers,
Steve W.



tmux(1) is included in the base install of OpenBSD - it is a modern and 
better replacement for screen :~)


Cheers

Fred

Re: OpenBSD + 3G/4G USB modem

[Stuart Longland]

On 20/04/18 07:06, MS wrote:
> ok, I think I figured out what the problem is...OpenBSD recognizes my ZTE
> MF195 but doesn't see it as a ucom device but as a storage (sd and cd(!))

Try ejecting the "CD".

-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

Re: OpenBSD + 3G/4G USB modem

[Stuart Henderson]

On 2018/04/19 23:06, MS wrote:
> ok, I think I figured out what the problem is...OpenBSD recognizes my ZTE 
> MF195 but doesn't see
> it as a ucom device but as a storage (sd and cd(!))

Try "eject cd0". That may be enough, if that works then you have an
interim solution and we can add a DEV_UMASS4 quirk for the device.
Please send new dmesg and usbdevs -vd after the eject command has run.

If it doesn't seem to do anything useful, there are some other more
vendor-specific quirks we can try, but those will need rebuilding
a kernel to test, so give "eject" a go first.

>  port 3 addr 2: high speed, power 500 mA, config 1, MF195(0x1514), 
> ZTE(0x19d2), rev 0.01,

Re: OpenBSD + 3G/4G USB modem

[MS]

ok, I think I figured out what the problem is...OpenBSD recognizes my ZTE
MF195 but doesn't see it as a ucom device but as a storage (sd and cd(!))

here's my usbdevs:

Controller /dev/usb0:
addr 1: high speed, self powered, config 1, EHCI root hub(0x),
Intel(0x8086), rev 1.00
  uhub0
 port 1 powered
 port 2 powered
 port 3 addr 2: high speed, power 500 mA, config 1, MF195(0x1514),
ZTE(0x19d2), rev 0.01, iSerialNumber MF1950TMOD00
   umass0
 port 4 powered
 port 5 powered
 port 6 powered
Controller /dev/usb1:
addr 1: high speed, self powered, config 1, EHCI root hub(0x),
Intel(0x8086), rev 1.00
  uhub1
 port 1 powered
 port 2 powered
 port 3 powered
 port 4 addr 2: high speed, power 500 mA, config 1, Silicon Media
R/W(0x01bd), Sony(0x054c), rev 3.95, iSerialNumber 50020C59
   umass1
 port 5 powered
 port 6 powered
Controller /dev/usb2:
addr 1: full speed, self powered, config 1, UHCI root hub(0x),
Intel(0x8086), rev 1.00
  uhub2
 port 1 addr 2: low speed, power 100 mA, config 1, Dell QuietKey
Keyboard(0x2106), DELL(0x413c), rev 1.01
   uhidev0
 port 2 addr 3: low speed, power 98 mA, config 1, Usb Mouse(0x0034),
SIGMACHIP(0x1c4f), rev 1.10
   uhidev1
Controller /dev/usb3:
addr 1: full speed, self powered, config 1, UHCI root hub(0x),
Intel(0x8086), rev 1.00
  uhub3
 port 1 powered
 port 2 powered
Controller /dev/usb4:
addr 1: full speed, self powered, config 1, UHCI root hub(0x),
Intel(0x8086), rev 1.00
  uhub4
 port 1 powered
 port 2 powered
Controller /dev/usb5:
addr 1: full speed, self powered, config 1, UHCI root hub(0x),
Intel(0x8086), rev 1.00
  uhub5
 port 1 powered
 port 2 powered
Controller /dev/usb6:
addr 1: full speed, self powered, config 1, UHCI root hub(0x),
Intel(0x8086), rev 1.00
  uhub6
 port 1 powered
 port 2 powered
Controller /dev/usb7:
addr 1: full speed, self powered, config 1, UHCI root hub(0x),
Intel(0x8086), rev 1.00
  uhub7
 port 1 powered
 port 2 powered


and here's my dmesg:
OpenBSD 6.3 (GENERIC.MP ) #107: Sat Mar 24 14:21:59 MDT
2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

real mem = 4277010432 (4078MB)
avail mem = 4140306432 (3948MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (39 entries)
bios0: vendor Award Software International, Inc. version "F1" date
06/22/2007
bios0: Gigabyte Technology Co., Ltd. P35C-S3
acpi0 at bios0: rev 0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET MCFG APIC SSDT SSDT
acpi0: wakeup devices PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) PEX4(S5) PEX5(S5)
HUB0(S5) UAR1(S3) IGBE(S4) USB0(S3) USB1(S3) USB2(S3) USB3(S3) US31(S3)
USB4(S3) USB5(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimcfg0 at acpi0 addr 0xf000, bus 0-63
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz, 2667.05 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,
xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu0: 4MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 333MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz, 2666.66 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,
xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu1: 4MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
, remapped to apid 2
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (PEX0)
acpiprt2 at acpi0: bus -1 (PEX1)
acpiprt3 at acpi0: bus -1 (PEX2)
acpiprt4 at acpi0: bus 3 (PEX3)
acpiprt5 at acpi0: bus 4 (PEX4)
acpiprt6 at acpi0: bus -1 (PEX5)
acpiprt7 at acpi0: bus 5 (HUB0)
acpicpu0 at acpi0: C1(@1 halt!), FVS, 2667, 2000 MHz
acpicpu1 at acpi0: C1(@1 halt!), FVS, 2667, 2000 MHz
acpibtn0 at acpi0: PWRB
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82G33 Host" rev 0x02
ppb0 at pci0 dev 1 function 0 "Intel 82G33 PCIE" rev 0x02: msi
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "NVIDIA GeForce 8800 GTS" rev 0xa2
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x02: apic 2 int 16
uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x02: apic 2 int 21
uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x02: apic 2 int 18
ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x02: apic 2 int 18
usb0 at ehci0: USB revision 2.0
uhub0 

Re: OpenBSD + 3G/4G USB modem

[MS]

ok, I think I figured out what the problem is...OpenBSD recognizes my ZTE
MF195 but doesn't see it as a ucom device but as a storage (sd and cd(!))

here's my usbdevs:

Controller /dev/usb0:
addr 1: high speed, self powered, config 1, EHCI root hub(0x),
Intel(0x8086), rev 1.00
  uhub0
 port 1 powered
 port 2 powered
 port 3 addr 2: high speed, power 500 mA, config 1, MF195(0x1514),
ZTE(0x19d2), rev 0.01, iSerialNumber MF1950TMOD00
   umass0
 port 4 powered
 port 5 powered
 port 6 powered
Controller /dev/usb1:
addr 1: high speed, self powered, config 1, EHCI root hub(0x),
Intel(0x8086), rev 1.00
  uhub1
 port 1 powered
 port 2 powered
 port 3 powered
 port 4 addr 2: high speed, power 500 mA, config 1, Silicon Media
R/W(0x01bd), Sony(0x054c), rev 3.95, iSerialNumber 50020C59
   umass1
 port 5 powered
 port 6 powered
Controller /dev/usb2:
addr 1: full speed, self powered, config 1, UHCI root hub(0x),
Intel(0x8086), rev 1.00
  uhub2
 port 1 addr 2: low speed, power 100 mA, config 1, Dell QuietKey
Keyboard(0x2106), DELL(0x413c), rev 1.01
   uhidev0
 port 2 addr 3: low speed, power 98 mA, config 1, Usb Mouse(0x0034),
SIGMACHIP(0x1c4f), rev 1.10
   uhidev1
Controller /dev/usb3:
addr 1: full speed, self powered, config 1, UHCI root hub(0x),
Intel(0x8086), rev 1.00
  uhub3
 port 1 powered
 port 2 powered
Controller /dev/usb4:
addr 1: full speed, self powered, config 1, UHCI root hub(0x),
Intel(0x8086), rev 1.00
  uhub4
 port 1 powered
 port 2 powered
Controller /dev/usb5:
addr 1: full speed, self powered, config 1, UHCI root hub(0x),
Intel(0x8086), rev 1.00
  uhub5
 port 1 powered
 port 2 powered
Controller /dev/usb6:
addr 1: full speed, self powered, config 1, UHCI root hub(0x),
Intel(0x8086), rev 1.00
  uhub6
 port 1 powered
 port 2 powered
Controller /dev/usb7:
addr 1: full speed, self powered, config 1, UHCI root hub(0x),
Intel(0x8086), rev 1.00
  uhub7
 port 1 powered
 port 2 powered


and here's my dmesg:
OpenBSD 6.3 (GENERIC.MP) #107: Sat Mar 24 14:21:59 MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4277010432 (4078MB)
avail mem = 4140306432 (3948MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (39 entries)
bios0: vendor Award Software International, Inc. version "F1" date
06/22/2007
bios0: Gigabyte Technology Co., Ltd. P35C-S3
acpi0 at bios0: rev 0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET MCFG APIC SSDT SSDT
acpi0: wakeup devices PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) PEX4(S5) PEX5(S5)
HUB0(S5) UAR1(S3) IGBE(S4) USB0(S3) USB1(S3) USB2(S3) USB3(S3) US31(S3)
USB4(S3) USB5(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimcfg0 at acpi0 addr 0xf000, bus 0-63
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz, 2667.05 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu0: 4MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 333MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz, 2666.66 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu1: 4MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
, remapped to apid 2
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (PEX0)
acpiprt2 at acpi0: bus -1 (PEX1)
acpiprt3 at acpi0: bus -1 (PEX2)
acpiprt4 at acpi0: bus 3 (PEX3)
acpiprt5 at acpi0: bus 4 (PEX4)
acpiprt6 at acpi0: bus -1 (PEX5)
acpiprt7 at acpi0: bus 5 (HUB0)
acpicpu0 at acpi0: C1(@1 halt!), FVS, 2667, 2000 MHz
acpicpu1 at acpi0: C1(@1 halt!), FVS, 2667, 2000 MHz
acpibtn0 at acpi0: PWRB
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82G33 Host" rev 0x02
ppb0 at pci0 dev 1 function 0 "Intel 82G33 PCIE" rev 0x02: msi
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "NVIDIA GeForce 8800 GTS" rev 0xa2
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x02: apic 2 int 16
uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x02: apic 2 int 21
uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x02: apic 2 int 18
ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x02: apic 2 int 18
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI 

Re: upgrade 6.2 snapshots to 6.3 release

[Sebastian Benoit]

Kapetanakis Giannis(bil...@edu.physics.uoc.gr) on 2018.04.19 14:22:57 +0300:
> On 19/04/18 13:54, Sebastian Benoit wrote:
> > Kapetanakis Giannis(bil...@edu.physics.uoc.gr) on 2018.04.19 13:37:24 +0300:
> >> Hi,
> >>
> >> since more and more of my servers have been migrated to OpenBSD :) and I'm
> >> getting a bit lazy, I want to upgrade some of my 6.2 snapshots to 6.3
> >> release and use syspatch for upgrading them in the future.
> > 
> > sad to hear that you dont want to test snapshots in the future ;)
> 
> I will, i will :)
> but not on every machine I have. It's adding a lot of work.
> I will keep the most important machines manually updated with snapshots as I 
> also want the latest features ;)
>  
> >> What was the date of code lock/freeze so I can safely put 6.3 on top?
> > 
> > You should be able to update any system that claims its 6.2-current to
> > 6.3.
> > 
> > All instructions on http://www.openbsd.org/faq/upgrade63.html should work,
> > even when starting from a 6.2-current snapshot.
> > 
> > There is no specific data before or after that would not work, including for
> > versions claiming to be 6.3-beta and 6.3 up until "OpenBSD 6.3 (GENERIC.MP)
> > #107: Sat Mar 24 14:21:59 MDT 2018" which is the final released 6.3.
> > 
> > /Benno
> 
> So I can even update OpenBSD 6.3 (GENERIC.MP) #62: Wed Mar 14 
> ?
> 
> Eventually 6.3 is the 23-24 Mar snapshot?

Correct. And between Mar 14 and Mar 24, there is i believe nothing (like rm
commands etc) in the upgrade63.html that you need to do, just do the update
and run sysmerge and syspatch and pkg_add -u.

Re: kernel relink segfaults on ALIX

[IL Ka]

> commented out the call to
> reorder_kernel in rc.

I still believe that  ``chmod -x /usr/libexec/reorder_kernel`` is much
better and safer  than patching ``/etc/rc``,
but it is up to you)

Re: kernel relink segfaults on ALIX

[Roderick]

On Thu, 19 Apr 2018, IL Ka wrote:


We can disable  library_aslr, but there is no same option for kernel..


I disabled library_aslr and commented out the call to
reorder_kernel in rc.

I can manually reorder kernel by calling reorder_kernel
when I consider it necessary, unfortunately I cannot do
the same with library_aslr: the code is embedded in rc.

BTW. By changing /var/db/kernel.SHA256 you disable kernel 
reordering, but then calling reorder_kernel has no effect.


Rodrigo.

Re: kernel relink segfaults on ALIX

[IL Ka]

I am sorry, I skipped your last line:
> Just comment in rc -_- for kernel

You are right. But it is safer to "chmod -x" reorder_kernel (touching rc is
not good)

On Thu, Apr 19, 2018 at 9:58 PM, sven falempin 
wrote:

> On Thu, Apr 19, 2018 at 1:01 PM, IL Ka  wrote:
>
> > Upgrade may affect kernel, so you need to reorder it at least once after
> > upgrade!
> >
> > I am not sure which policy do OpenBSD use, but generally if something is
> > not documented it is subject to be changed in minor upgrade.
> >
> > The only reference to this script is ``/etc/rc`` (line 620) without of
> any
> > variable, and since "reorder_kernel" is
> > not documented it would be absolutelly legal to rename it and update
> > /etc/rc accordingly.
> >
> > So, this little hack may be broken after upgrade anyway.
> >
> > I wish there were ``man reorder_kernel(8)`` and ``reorder_kernel=NO``
> > documented in ``rc.conf(8)``
> > But if I understood everything correct, developers say we should not
> > disable this script,
> > that is why they do not document it nor create an option in rc.conf.
> >
> >
> > On Thu, Apr 19, 2018 at 7:42 PM,  wrote:
> >
> > > One step further would be to put that in your rc.local so it survives
> an
> > > upgrade.
> > > On Apr 19, 2018 9:44 AM, IL Ka  wrote:
> > > >
> > > > Ancient UNIX way to disable anything: ``doas chmod -x
> > > > /usr/libexec/reorder_kernel`` ;)
> > > >
> > > > Although ``reorder_kernel`` is very simple ksh script, I agree it
> > should
> > > be
> > > > documented.
> > > >
> > >
> >
>
> grep aslr /etc/rc.conf  >> /etc/rc.conf.local
>
> When you reboot often on crap drive, or if you are not exposed (test
> device), relinking is waste of time
> IF you are online , keep it .
>
> Just comment in rc -_- for kernel
>
> --
> --
> 
> -
> Knowing is not enough; we must apply. Willing is not enough; we must do
>

Re: kernel relink segfaults on ALIX

[IL Ka]

You are speaking about ``library_aslr`` which is documented by ``man
rc.conf``.
But it is not the same thing as kernel reordering: it reorders libs, so
they'll
be loaded at different memory address next time.
And kernel relink does same for kernel itself (relinks kernel from its
objects in random manner).

We can disable  library_aslr, but there is no same option for kernel..


On Thu, Apr 19, 2018 at 9:58 PM, sven falempin 
wrote:

> On Thu, Apr 19, 2018 at 1:01 PM, IL Ka  wrote:
>
> > Upgrade may affect kernel, so you need to reorder it at least once after
> > upgrade!
> >
> > I am not sure which policy do OpenBSD use, but generally if something is
> > not documented it is subject to be changed in minor upgrade.
> >
> > The only reference to this script is ``/etc/rc`` (line 620) without of
> any
> > variable, and since "reorder_kernel" is
> > not documented it would be absolutelly legal to rename it and update
> > /etc/rc accordingly.
> >
> > So, this little hack may be broken after upgrade anyway.
> >
> > I wish there were ``man reorder_kernel(8)`` and ``reorder_kernel=NO``
> > documented in ``rc.conf(8)``
> > But if I understood everything correct, developers say we should not
> > disable this script,
> > that is why they do not document it nor create an option in rc.conf.
> >
> >
> > On Thu, Apr 19, 2018 at 7:42 PM,  wrote:
> >
> > > One step further would be to put that in your rc.local so it survives
> an
> > > upgrade.
> > > On Apr 19, 2018 9:44 AM, IL Ka  wrote:
> > > >
> > > > Ancient UNIX way to disable anything: ``doas chmod -x
> > > > /usr/libexec/reorder_kernel`` ;)
> > > >
> > > > Although ``reorder_kernel`` is very simple ksh script, I agree it
> > should
> > > be
> > > > documented.
> > > >
> > >
> >
>
> grep aslr /etc/rc.conf  >> /etc/rc.conf.local
>
> When you reboot often on crap drive, or if you are not exposed (test
> device), relinking is waste of time
> IF you are online , keep it .
>
> Just comment in rc -_- for kernel
>
> --
> --
> 
> -
> Knowing is not enough; we must apply. Willing is not enough; we must do
>

Re: kernel relink segfaults on ALIX

[sven falempin]

On Thu, Apr 19, 2018 at 1:01 PM, IL Ka  wrote:

> Upgrade may affect kernel, so you need to reorder it at least once after
> upgrade!
>
> I am not sure which policy do OpenBSD use, but generally if something is
> not documented it is subject to be changed in minor upgrade.
>
> The only reference to this script is ``/etc/rc`` (line 620) without of any
> variable, and since "reorder_kernel" is
> not documented it would be absolutelly legal to rename it and update
> /etc/rc accordingly.
>
> So, this little hack may be broken after upgrade anyway.
>
> I wish there were ``man reorder_kernel(8)`` and ``reorder_kernel=NO``
> documented in ``rc.conf(8)``
> But if I understood everything correct, developers say we should not
> disable this script,
> that is why they do not document it nor create an option in rc.conf.
>
>
> On Thu, Apr 19, 2018 at 7:42 PM,  wrote:
>
> > One step further would be to put that in your rc.local so it survives an
> > upgrade.
> > On Apr 19, 2018 9:44 AM, IL Ka  wrote:
> > >
> > > Ancient UNIX way to disable anything: ``doas chmod -x
> > > /usr/libexec/reorder_kernel`` ;)
> > >
> > > Although ``reorder_kernel`` is very simple ksh script, I agree it
> should
> > be
> > > documented.
> > >
> >
>

grep aslr /etc/rc.conf  >> /etc/rc.conf.local

When you reboot often on crap drive, or if you are not exposed (test
device), relinking is waste of time
IF you are online , keep it .

Just comment in rc -_- for kernel

-- 
--

-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: thank you for 6.3

[Alfred Morgan]

Yes, thank you. Let's each of us give a pizza to show our appreciation.
http://www.openbsd.org/donations.html

-- 
-alfred

Re: kernel relink segfaults on ALIX

[IL Ka]

Upgrade may affect kernel, so you need to reorder it at least once after
upgrade!

I am not sure which policy do OpenBSD use, but generally if something is
not documented it is subject to be changed in minor upgrade.

The only reference to this script is ``/etc/rc`` (line 620) without of any
variable, and since "reorder_kernel" is
not documented it would be absolutelly legal to rename it and update
/etc/rc accordingly.

So, this little hack may be broken after upgrade anyway.

I wish there were ``man reorder_kernel(8)`` and ``reorder_kernel=NO``
documented in ``rc.conf(8)``
But if I understood everything correct, developers say we should not
disable this script,
that is why they do not document it nor create an option in rc.conf.


On Thu, Apr 19, 2018 at 7:42 PM,  wrote:

> One step further would be to put that in your rc.local so it survives an
> upgrade.
> On Apr 19, 2018 9:44 AM, IL Ka  wrote:
> >
> > Ancient UNIX way to disable anything: ``doas chmod -x
> > /usr/libexec/reorder_kernel`` ;)
> >
> > Although ``reorder_kernel`` is very simple ksh script, I agree it should
> be
> > documented.
> >
>

Re: NFS server down, again, and again, and again...

[Steve Williams]

On 19/04/2018 7:55 AM, Rupert Gallagher wrote:

On Thu, Apr 19, 2018 at 15:38, Zé Loff  wrote:


# mountd -d > /var/log/mountd.log 2&>1 &

It is the first thing I did this morning. Unfortunately it does not survive 
when ssh breaks out. Also, mountd -d is returning the shell prompt again, so I 
have no logs at all.


Hi,

A couple of things...  you need to read about "nohup" if you are trying 
to run programs in the background and they are getting killed when the 
ssh session ends.


Additionally, there are two programs that are very useful..

script
and
screen

"script" is on every Unix type system that I've ever been on in my last 
35+ years of working on Unix type systems.


I believe that there is an "in-tree" replacement for the functionality 
that "screen" brings, but I cannot remember what it's called.  
Otherwise, use the screen package.


"screen" allows you to run an interactive session (mountd -d) and 
"detach" (^AD) the session, log out, and at some point in the future, 
"resume" the screen session.. (screen -r).


Combined with "script", which will log all information that is appearing 
on the screen to a file, you should be able to run "mountd -d" and 
capture all information to a file, as well as resuming the session to 
see what is going on interactively.


Cheers,
Steve W.

Re: kernel relink segfaults on ALIX

[edgar]

One step further would be to put that in your rc.local so it survives an 
upgrade.
On Apr 19, 2018 9:44 AM, IL Ka  wrote:
>
> Ancient UNIX way to disable anything: ``doas chmod -x
> /usr/libexec/reorder_kernel`` ;)
>
> Although ``reorder_kernel`` is very simple ksh script, I agree it should be
> documented.
>
>
>
> On Thu, Apr 19, 2018 at 12:15 PM, Z Ero  wrote:
>
> > Coincidently I just logged in to write the misc  list about relinking
> > on boot. Is it possible to disable it? What about just relinking on
> > the first boot after install? So then every kernel image is different
> > but not re-randomized each boot! There are some low memory / slow CPU
> > embedded systems like Alix / Soekris where the benefit, in my opinion,
> > of re-linking every single boot is not worth the cost. That said
> > granted these systems should not be rebooted frequently anyway once in
> > production during normal use. I had a soekris recently that performed
> > well for the task I needed it for but that I chose to install OpenBSD
> > version 5.8 on...because I did not want to put up with the
> > relinking...I would have rather used 6.2...would it be possible to
> > give users a "switch" to turn off relinking if they want without
> > recompiling the kernel...please forgive my ignorance (or flame
> > away...) if this already exists.
> >
> > Thanks.
> >
> > On Thu, Apr 19, 2018 at 2:16 AM, Darren Tucker 
> > wrote:
> > > On 19 April 2018 at 16:52, Jan Stary  wrote:
> > >> This is a fresh upgrade of current/i386 on an ALIX 2D3.
> > >> Upon start, kernel relinking fails, with relink.log saying:
> > >
> > > Do you have any swap configured?  Relinking takes a reasonable amount
> > > of ram and the ALIX doesn't have a lot.
> > >
> > > --
> > > Darren Tucker (dtucker at dtucker.net)
> > > GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA
> > (new)
> > > Good judgement comes with experience. Unfortunately, the experience
> > > usually comes from bad judgement.
> > >
> >
> >

Re: 6.3/amd64 Thinkpad T530 touchpad problem (was ok in 6.2/amd64)

[IL Ka]

I forgot to mention that you can disable extended input devices.
Ie.
$ xinput --list
Then look at list of "Virtual core XTEST pointer" children
And ``xinput --disable [id]`` everything but the first one. It _may_ help.

On Thu, Apr 19, 2018 at 2:38 PM, Jonathan Thornburg <
jth...@astro.indiana.edu> wrote:

> I have a Lenovo Thinkpad T530.  Everything (including the builtin
> touchpad) was fine under 6.2/amd64, but under 6.3/amd64 there is a
> severe problem with the builtin touchpad when running X (autoconfigured
> with no xorg.conf; all other aspects of X operation are fine).
>
> The problem is this: when I first start X the touchpad operates normally.
> But a minute or so of use the X cursor starts jumping to the left and/or
> top side of the screen each time I start a new finger-movement.
>
> That is, a normal sequence of touchpad operation is
> 1. touch finger to touchpad
> 2. drag finger to move X cursor to desired location
> 3. remove finger from touchpad
> but once this problem starts, step 2 causes the X cursor to jump to the
> left side of the screen (if the finger-drag is in a horizontal direction),
> the top side of the screen (if the finger-drag is in a vertical direction),
> or the top-left corner of the screen (if the finger-drag is in a diagonal
> direction).
>
> I see the same symptoms if ...
> * ... I boot GENERIC instead of usual GENERIC.MP
> * ... I comment out the line 'xset m 1/4' (which is the only 'xset m' line)
>   from my $HOME/.xinitrc.
> * ... I change from my usual window manager (twm, started from
> $HOME/.xinitrc),
>   to the OpenBSD default fvwm (started if there is no $HOME/.xinitrc).
> * ... I plug in a USB (optical) mouse, but continue to use the builtin
>   touchpad,
> * ... I plug in a USB (optical) mouse, and use that as a pointer device
>   instead of the builtin touchpad.  In this case mouse movements trigger
>   the X-cursor-jumping behavior: the X cursor jumps to the left side of
>   the screen (if the mouse movement is in a horizontal direction), the top
>   side of the screen (if the mouse movement is in a vertical direction),
>   or the top-left corner of the screen (if the mouse movement is in a
>   diagonal direction).
>
> Once this problem starts, the only "cure" I have found is to kill the
> X server (either 'pkill X' or Ctrl-Shift-Backspace -- the window-manager
> menu is inaccessable due to the X cursor jumping) and start a new X
> session.
> This gets me a minute or so of normal operation before the problem
> reoccurs.
>
> I am not running xenodm -- I login on the console and start (or restart)
> X via 'startx'.
>
> Below I give my dmesg (6.3/amd64), a dmesg from 6.2/amd64 on this same
> machine for comparison, and /var/log/Xorg.0.log (6.3/amd64).
>
> Have other Thinkpad users encountered this behavior?  Is there a known
> workaround?  Is there additional information I could supply to help
> diagnose the problem?  (I could run with a debugging kernel or X server
> for a while if that would help.)
>
> Thanks, ciao,
> -- "Jonathan Thornburg [remove -animal to reply]" <
> jth...@astro.indiana-zebra.edu>
>currently visiting Max-Plack-Institute fuer Gravitationsphysik
>   (Albert-Einstein-Institut), Potsdam-Golm, Germany
>
> --- begin 6.3/amd64 /var/run/dmesg.boot ---
> OpenBSD 6.3 (GENERIC.MP) #107: Sat Mar 24 14:21:59 MDT 2018
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 16845565952 (16065MB)
> avail mem = 16327950336 (15571MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9c000 (69 entries)
> bios0: vendor LENOVO version "G4ETA7WW (2.67 )" date 08/24/2016
> bios0: LENOVO 24292A9
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT
> ASF! UEFI UEFI POAT SSDT SSDT UEFI DBG2
> acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(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) i7-3520M CPU @ 2.90GHz, 2893.80 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,
> 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,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
> cpu0: 256KB 64b/line 8-way L2 cache
> acpihpet0: recalibrated TSC frequency 2893437769 Hz
> 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.1.2, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz, 2893.43 MHz

Re: 6.3/amd64 Thinkpad T530 touchpad problem (was ok in 6.2/amd64)

[IL Ka]

Try to start ``wsmoused(8)`` and check if mouse works in console.
``/etc/rc.d/wsmoused start`` and move mouse around for minute or two.
Does it work?

It will help us to understand if it is a X problem or wmouse(4) problem

Re: NFS server down, again, and again, and again...

[Rupert Gallagher]

On Thu, Apr 19, 2018 at 15:38, Zé Loff  wrote:

> # mountd -d > /var/log/mountd.log 2&>1 &

It is the first thing I did this morning. Unfortunately it does not survive 
when ssh breaks out. Also, mountd -d is returning the shell prompt again, so I 
have no logs at all.

Re: kernel relink segfaults on ALIX

[IL Ka]

Ancient UNIX way to disable anything: ``doas chmod -x
/usr/libexec/reorder_kernel`` ;)

Although ``reorder_kernel`` is very simple ksh script, I agree it should be
documented.



On Thu, Apr 19, 2018 at 12:15 PM, Z Ero  wrote:

> Coincidently I just logged in to write the misc  list about relinking
> on boot. Is it possible to disable it? What about just relinking on
> the first boot after install? So then every kernel image is different
> but not re-randomized each boot! There are some low memory / slow CPU
> embedded systems like Alix / Soekris where the benefit, in my opinion,
> of re-linking every single boot is not worth the cost. That said
> granted these systems should not be rebooted frequently anyway once in
> production during normal use. I had a soekris recently that performed
> well for the task I needed it for but that I chose to install OpenBSD
> version 5.8 on...because I did not want to put up with the
> relinking...I would have rather used 6.2...would it be possible to
> give users a "switch" to turn off relinking if they want without
> recompiling the kernel...please forgive my ignorance (or flame
> away...) if this already exists.
>
> Thanks.
>
> On Thu, Apr 19, 2018 at 2:16 AM, Darren Tucker 
> wrote:
> > On 19 April 2018 at 16:52, Jan Stary  wrote:
> >> This is a fresh upgrade of current/i386 on an ALIX 2D3.
> >> Upon start, kernel relinking fails, with relink.log saying:
> >
> > Do you have any swap configured?  Relinking takes a reasonable amount
> > of ram and the ALIX doesn't have a lot.
> >
> > --
> > Darren Tucker (dtucker at dtucker.net)
> > GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA
> (new)
> > Good judgement comes with experience. Unfortunately, the experience
> > usually comes from bad judgement.
> >
>
>

Re: kernel relink segfaults on ALIX

[Theo de Raadt]

The great thing about OpenBSD is that it comes with all these debugging
tools that let you figure out what happened, right there on your own
system, without having to engage tech support who speaks a foreign
language.  If only you spend a few minutes to learn before sending
email.

Into enhle nge-OpenBSD yukuthi ifika nazo zonke lezi zinkinga
amathuluzi akuvumela ukuba uhlole ukuthi kwenzekani, khona-ke lapho uqobo
uhlelo, ngaphandle kokubandakanya ukwesekwa kwe-tech okhuluma ngaphandle
ulimi. Uma nje uchitha imizuzu embalwa ukuze ufunde ngaphambi kokuthumela
imeyili.

Jan Stary  wrote:
> This is a fresh upgrade of current/i386 on an ALIX 2D3.
> Upon start, kernel relinking fails, with relink.log saying:
> 
> (SHA256) /bsd: OK
> LD="ld" LDFLAGS="-g" sh makegap.sh 0x
> ld -T ld.script -X --warn-common -nopie -o newbsd ${SYSTEM_HEAD} vers.o 
> ${OBJS}
> Segmentation fault (core dumped) 
> *** Error 139 in /usr/share/relink/kernel/GENERIC (Makefile:1045 'newbsd': 
> @echo ld -T ld.script -X --warn-common -nopie -o newbsd '${SYSTEM...)
> 
> /usr/share/relink is empty, with
> /dev/wd0d 1001M801M150M84%/usr
> 
> Am I missing something obvious?
> 
>   Jan
> 

Re: thank you for 6.3

[Bogdan Kulbida]

I use block storage device with encryption just to keep my /home encrypted
and mount it manually everytime I boot...

On Thu, Apr 19, 2018 at 04:50 flipchan  wrote:

> Running 6.3 on x200 here aswell but with libreboot, except for libreboot
> not allowing me to have full disk encryption  it works like a charm
>
> On April 18, 2018 5:10:26 PM UTC, Scott Bonds  wrote:
> >Under 6.2 my laptop would hang a few hours after waking from sleep, and
> >
> >it was my own damn fault for running an unsupported config (Lenovo x200
> >
> >+ coreboot + SeaBIOS). But after upgrading to 6.3 I haven't been able
> >to
> >get it to hang and I find myself back in 'it just works' land which is
> >so, so nice. So nice.
> >
> >I don't know who to thank, and maybe the dev that fixed my issue
> >wouldn't know *they* fixed it, but...thank you.
>
> --
> Take Care Sincerely flipchan layerprox dev
>
-- 

---
Best regards,
Bogdan Kulbida
CEO/CTO, Konstankino LLC 
+1.802.793.8295

6.3/amd64 Thinkpad T530 touchpad problem (was ok in 6.2/amd64)

[Jonathan Thornburg]

I have a Lenovo Thinkpad T530.  Everything (including the builtin
touchpad) was fine under 6.2/amd64, but under 6.3/amd64 there is a
severe problem with the builtin touchpad when running X (autoconfigured
with no xorg.conf; all other aspects of X operation are fine).

The problem is this: when I first start X the touchpad operates normally.
But a minute or so of use the X cursor starts jumping to the left and/or
top side of the screen each time I start a new finger-movement.

That is, a normal sequence of touchpad operation is
1. touch finger to touchpad
2. drag finger to move X cursor to desired location
3. remove finger from touchpad
but once this problem starts, step 2 causes the X cursor to jump to the
left side of the screen (if the finger-drag is in a horizontal direction),
the top side of the screen (if the finger-drag is in a vertical direction),
or the top-left corner of the screen (if the finger-drag is in a diagonal
direction).

I see the same symptoms if ...
* ... I boot GENERIC instead of usual GENERIC.MP
* ... I comment out the line 'xset m 1/4' (which is the only 'xset m' line)
  from my $HOME/.xinitrc.
* ... I change from my usual window manager (twm, started from $HOME/.xinitrc),
  to the OpenBSD default fvwm (started if there is no $HOME/.xinitrc).
* ... I plug in a USB (optical) mouse, but continue to use the builtin
  touchpad,
* ... I plug in a USB (optical) mouse, and use that as a pointer device
  instead of the builtin touchpad.  In this case mouse movements trigger
  the X-cursor-jumping behavior: the X cursor jumps to the left side of
  the screen (if the mouse movement is in a horizontal direction), the top
  side of the screen (if the mouse movement is in a vertical direction),
  or the top-left corner of the screen (if the mouse movement is in a
  diagonal direction).

Once this problem starts, the only "cure" I have found is to kill the
X server (either 'pkill X' or Ctrl-Shift-Backspace -- the window-manager
menu is inaccessable due to the X cursor jumping) and start a new X session.
This gets me a minute or so of normal operation before the problem reoccurs.

I am not running xenodm -- I login on the console and start (or restart)
X via 'startx'.

Below I give my dmesg (6.3/amd64), a dmesg from 6.2/amd64 on this same
machine for comparison, and /var/log/Xorg.0.log (6.3/amd64).

Have other Thinkpad users encountered this behavior?  Is there a known
workaround?  Is there additional information I could supply to help
diagnose the problem?  (I could run with a debugging kernel or X server
for a while if that would help.)

Thanks, ciao,
-- "Jonathan Thornburg [remove -animal to reply]" 

   currently visiting Max-Plack-Institute fuer Gravitationsphysik
  (Albert-Einstein-Institut), Potsdam-Golm, Germany

--- begin 6.3/amd64 /var/run/dmesg.boot ---
OpenBSD 6.3 (GENERIC.MP) #107: Sat Mar 24 14:21:59 MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16845565952 (16065MB)
avail mem = 16327950336 (15571MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9c000 (69 entries)
bios0: vendor LENOVO version "G4ETA7WW (2.67 )" date 08/24/2016
bios0: LENOVO 24292A9
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT ASF! 
UEFI UEFI POAT SSDT SSDT UEFI DBG2
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(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) i7-3520M CPU @ 2.90GHz, 2893.80 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,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,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
acpihpet0: recalibrated TSC frequency 2893437769 Hz
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.1.2, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz, 2893.43 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,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,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at 

[no subject]

[Muhammad Zohaib]

I meant 6-9 June 2017 instead of 2018

Little error found in website's event page. Date for future bsdcan event shows 6-9 April 2017 instead of 2018.

[Muhammad Zohaib]

Re: Message arrived but could not be stored

[Axel Rau]

Hi,

could you please fix your MUA?
The argument of the header „Content-Language“ in your mails violates RFC 1766.
My IMAP server http://aox.org/  can’t store your mails.


> Am 19.04.2018 um 12:37 schrieb Kapetanakis Giannis 
> :
> 
> The appended message was received, but could not be stored in the mail 
> database on imap.lrau.net.
> 
> The error detected was: Content-Language: Unparseable value: "English & Greek"
> 
> Here are a few header fields from the message (possibly corrupted due to 
> syntax errors):
> 
> From: Kapetanakis Giannis 
> Subject: upgrade 6.2 snapshots to 6.3 release
> To: "misc@openbsd.org" 
> 
> The complete message as received is appended.
> <1524134256-7446-4192_4_2526>



Thanks, Axel
---
PGP-Key:29E99DD6  ☀  computing @ chaos claudius

Re: kernel relink segfaults on ALIX

[Z Ero]

Did you see my reply...i had the epiphany that no incantation is
necessary. I have seen the light.

On Thu, Apr 19, 2018 at 6:58 AM, Paul de Weerd  wrote:
> On Thu, Apr 19, 2018 at 06:53:26AM -0500, Z Ero wrote:
> | Is the feature documented in the manual pages...thanks...if this really 
> works.
>
> OpenBSD doesn't normally document how to disable security features.
> Generally, security features cannot be disabled.  In this case you
> can because of the way it's implemented.
>
> Please make sure you write "make_me_less_secure_please" to the file
> though and chant the same phrase every day at noon (in your
> /etc/localtime timezone) for each day you run in this state; this is
> an important part of stopping the kernel relinking...
>
> Paul 'WEiRD' de Weerd
>
> | On Thu, Apr 19, 2018 at 4:29 AM, Paul de Weerd  wrote:
> | > On Thu, Apr 19, 2018 at 04:15:50AM -0500, Z Ero wrote:
> | > | Coincidently I just logged in to write the misc  list about relinking
> | > | on boot. Is it possible to disable it? What about just relinking on
> | > | the first boot after install? So then every kernel image is different
> | > | but not re-randomized each boot! There are some low memory / slow CPU
> | > | embedded systems like Alix / Soekris where the benefit, in my opinion,
> | > | of re-linking every single boot is not worth the cost. That said
> | > | granted these systems should not be rebooted frequently anyway once in
> | > | production during normal use. I had a soekris recently that performed
> | > | well for the task I needed it for but that I chose to install OpenBSD
> | > | version 5.8 on...because I did not want to put up with the
> | > | relinking...I would have rather used 6.2...would it be possible to
> | > | give users a "switch" to turn off relinking if they want without
> | > | recompiling the kernel...please forgive my ignorance (or flame
> | > | away...) if this already exists.
> | >
> | > echo make_me_less_secure_please | doas tee /var/db/kernel.SHA256
> | >
> | > Going back to an older release to *avoid* security features in newer
> | > versions... wow.  You do realise that this kernel relinking thing is
> | > not the only improvement that's made in the more than two years since
> | > 5.8, right?
> | >
> | > Paul 'WEiRD' de Weerd
> | >
> | > --
> | >>[<++>-]<+++.>+++[<-->-]<.>+++[<+
> | > +++>-]<.>++[<>-]<+.--.[-]
> | >  http://www.weirdnet.nl/
>
> --
>>[<++>-]<+++.>+++[<-->-]<.>+++[<+
> +++>-]<.>++[<>-]<+.--.[-]
>  http://www.weirdnet.nl/

Re: kernel relink segfaults on ALIX

[Paul de Weerd]

On Thu, Apr 19, 2018 at 06:53:26AM -0500, Z Ero wrote:
| Is the feature documented in the manual pages...thanks...if this really works.

OpenBSD doesn't normally document how to disable security features.
Generally, security features cannot be disabled.  In this case you
can because of the way it's implemented.

Please make sure you write "make_me_less_secure_please" to the file
though and chant the same phrase every day at noon (in your
/etc/localtime timezone) for each day you run in this state; this is
an important part of stopping the kernel relinking...

Paul 'WEiRD' de Weerd

| On Thu, Apr 19, 2018 at 4:29 AM, Paul de Weerd  wrote:
| > On Thu, Apr 19, 2018 at 04:15:50AM -0500, Z Ero wrote:
| > | Coincidently I just logged in to write the misc  list about relinking
| > | on boot. Is it possible to disable it? What about just relinking on
| > | the first boot after install? So then every kernel image is different
| > | but not re-randomized each boot! There are some low memory / slow CPU
| > | embedded systems like Alix / Soekris where the benefit, in my opinion,
| > | of re-linking every single boot is not worth the cost. That said
| > | granted these systems should not be rebooted frequently anyway once in
| > | production during normal use. I had a soekris recently that performed
| > | well for the task I needed it for but that I chose to install OpenBSD
| > | version 5.8 on...because I did not want to put up with the
| > | relinking...I would have rather used 6.2...would it be possible to
| > | give users a "switch" to turn off relinking if they want without
| > | recompiling the kernel...please forgive my ignorance (or flame
| > | away...) if this already exists.
| >
| > echo make_me_less_secure_please | doas tee /var/db/kernel.SHA256
| >
| > Going back to an older release to *avoid* security features in newer
| > versions... wow.  You do realise that this kernel relinking thing is
| > not the only improvement that's made in the more than two years since
| > 5.8, right?
| >
| > Paul 'WEiRD' de Weerd
| >
| > --
| >>[<++>-]<+++.>+++[<-->-]<.>+++[<+
| > +++>-]<.>++[<>-]<+.--.[-]
| >  http://www.weirdnet.nl/

-- 
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
 http://www.weirdnet.nl/ 

Re: thank you for 6.3

[flipchan]

Running 6.3 on x200 here aswell but with libreboot, except for libreboot not 
allowing me to have full disk encryption  it works like a charm

On April 18, 2018 5:10:26 PM UTC, Scott Bonds  wrote:
>Under 6.2 my laptop would hang a few hours after waking from sleep, and
>
>it was my own damn fault for running an unsupported config (Lenovo x200
>
>+ coreboot + SeaBIOS). But after upgrading to 6.3 I haven't been able
>to 
>get it to hang and I find myself back in 'it just works' land which is 
>so, so nice. So nice.
>
>I don't know who to thank, and maybe the dev that fixed my issue 
>wouldn't know *they* fixed it, but...thank you.

-- 
Take Care Sincerely flipchan layerprox dev

Re: NFS server down, again, and again, and again...

[Rupert Gallagher]

On 18 April 2018 8:04 PM, Ryan Freeman  wrote:
> This is how it works when your system is normal:

Unfortunately my system was not "normal", because mountd -d returned the shell 
prompt, as I said. 

I also said that mountd_flags=-d prevents the OS from restarting. 
I had to restart from the serial cable, enter single user mode and clear 
mountd_flags. 
This required a field trip, because the server was on a remote location. 

Now the OS boots again, and mountd -d works as you said. 
However, this neither solves nor helps with the original problem. 
I cannot babysit mountd all day, through an ssh link, awaiting for a crash. 
I need portmap, mountd and nfsd to log into a file, just like other 
well-behaved servers do. 
Unfortunately they do not offer server flags to enable debug logs and specify a 
log file. 
They just use syslog, but then again, they do not say anything useful when they 
crash. 

R

Re: NFS server down, again, and again, and again...

[Rupert Gallagher]

On 18 April 2018 8:04 PM, Ryan Freeman  wrote:

>> On this point, ``rcctl restart mountd'' works fine.  Restarting mountd
>> will not harm things already mounted, they will already be handled
>> by one of the running nfsd processes.

It does not work fine at all. This is what I get:

>doas rcctl restart mountd
/etc/rc.d/mountd: restart is not supported

Re: upgrade 6.2 snapshots to 6.3 release

[Kapetanakis Giannis]

On 19/04/18 13:54, Sebastian Benoit wrote:
> Kapetanakis Giannis(bil...@edu.physics.uoc.gr) on 2018.04.19 13:37:24 +0300:
>> Hi,
>>
>> since more and more of my servers have been migrated to OpenBSD :) and I'm
>> getting a bit lazy, I want to upgrade some of my 6.2 snapshots to 6.3
>> release and use syspatch for upgrading them in the future.
> 
> sad to hear that you dont want to test snapshots in the future ;)

I will, i will :)
but not on every machine I have. It's adding a lot of work.
I will keep the most important machines manually updated with snapshots as I 
also want the latest features ;)
 
>> What was the date of code lock/freeze so I can safely put 6.3 on top?
> 
> You should be able to update any system that claims its 6.2-current to
> 6.3.
> 
> All instructions on http://www.openbsd.org/faq/upgrade63.html should work,
> even when starting from a 6.2-current snapshot.
> 
> There is no specific data before or after that would not work, including for
> versions claiming to be 6.3-beta and 6.3 up until "OpenBSD 6.3 (GENERIC.MP)
> #107: Sat Mar 24 14:21:59 MDT 2018" which is the final released 6.3.
> 
> /Benno

So I can even update OpenBSD 6.3 (GENERIC.MP) #62: Wed Mar 14 
?

Eventually 6.3 is the 23-24 Mar snapshot?

thanks,

G

Re: upgrade 6.2 snapshots to 6.3 release

[Sebastian Benoit]

Kapetanakis Giannis(bil...@edu.physics.uoc.gr) on 2018.04.19 13:37:24 +0300:
> Hi,
> 
> since more and more of my servers have been migrated to OpenBSD :) and I'm
> getting a bit lazy, I want to upgrade some of my 6.2 snapshots to 6.3
> release and use syspatch for upgrading them in the future.

sad to hear that you dont want to test snapshots in the future ;)

> What was the date of code lock/freeze so I can safely put 6.3 on top?

You should be able to update any system that claims its 6.2-current to
6.3.

All instructions on http://www.openbsd.org/faq/upgrade63.html should work,
even when starting from a 6.2-current snapshot.

There is no specific data before or after that would not work, including for
versions claiming to be 6.3-beta and 6.3 up until "OpenBSD 6.3 (GENERIC.MP)
#107: Sat Mar 24 14:21:59 MDT 2018" which is the final released 6.3.

/Benno

upgrade 6.2 snapshots to 6.3 release

[Kapetanakis Giannis]

Hi,

since more and more of my servers have been migrated to OpenBSD :) and I'm 
getting a bit lazy,
I want to upgrade some of my 6.2 snapshots to 6.3 release and use syspatch for 
upgrading them in the future.

What was the date of code lock/freeze so I can safely put 6.3 on top?

Thanks,

G

dmesg for ThinkPad T480s

[joe di castro]

This is the dmesg for my new ThinkPad T480s.

Detailed specs:

Intel Core i5-8250U
LG 14.0" WQHD (2560 x 1440) IPS
16 GB DDR4 2400MHz
Integrated Intel® UHD Graphics 620
IR 720p HD Camera with microphone
NO Fingerprint Reader
NO NFC
Smartcard reader
512 GB SSD Samsung PM981 PCIe-NVMe M.2
3 cell Li-Ion 57Wh
65W AC Adapter USB Type-C
Intel Dual Band 8265 Wireless AC & Bluetooth
NO WWAN card
Black


dmesg (running -current):


OpenBSD 6.3-current (GENERIC.MP) #206: Wed Apr 18 10:11:07 MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17052938240 (16262MB)
avail mem = 16528203776 (15762MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x9a65 (62 entries)
bios0: vendor LENOVO version "N22ET34W (1.11 )" date 03/13/2018
bios0: LENOVO 20L7CTO1WW
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT SSDT TPM2 UEFI SSDT SSDT HPET APIC MCFG ECDT SSDT 
SSDT BOOT BATB SSDT SSDT SSDT LPIT WSMT SSDT SSDT SSDT DBGP DBG2 MSDM DMAR ASF! 
FPDT UEFI
acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) 
RP02(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) 
PXSX(S4) RP07(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz, 1397.32 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,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,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,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 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz, 1147.14 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,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,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: failed to identify
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz, 969.69 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,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,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBPcpu2:
 failed to identify
,SENSOR,ARAT,MELTDOWNcpu3 at mainbus0
: cpu2: 256KB 64b/line apid 6 (application processor)
8-way L2 cache
cpu3: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz, 897.92 MHz
cpu3: FPU,VME,DEcpu2: smt 0, core 2, package 0
,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSCcpu3:
 failed to identify
,FSGSBASE,SGX,BMI1,AVX2cpu4 at mainbus0,SMEP: apid 1 (application processor)
,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu3: 256KB 64b/line cpu4: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz, 897.92 MHz
cpu4: 8-way L2 cache
FPU,VME,DEcpu3: smt 0, core 3, package 0
,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNTcpu4:
 failed to identify
,DEADLINE,AEScpu5 at mainbus0,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB: 
,RDTSCP,LONGapid 3 (application processor)
,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBPcpu5:
 Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz, 897.92 MHz
cpu5: 

Re: Trouble with OpenSMTPD - always getting 550 Invalid recipient

[Craig Skinner]

On Wed, 18 Apr 2018 23:48:22 -0400 Implausibility wrote:
> 

OpenSMTPd has a mailing list for this sort of query:
http://www.OpenSMTPd.Org/list.html

Cheers,
-- 
Craig Skinner | http://linkd.in/yGqkv7

Re: kernel relink segfaults on ALIX

[Paul de Weerd]

On Thu, Apr 19, 2018 at 04:15:50AM -0500, Z Ero wrote:
| Coincidently I just logged in to write the misc  list about relinking
| on boot. Is it possible to disable it? What about just relinking on
| the first boot after install? So then every kernel image is different
| but not re-randomized each boot! There are some low memory / slow CPU
| embedded systems like Alix / Soekris where the benefit, in my opinion,
| of re-linking every single boot is not worth the cost. That said
| granted these systems should not be rebooted frequently anyway once in
| production during normal use. I had a soekris recently that performed
| well for the task I needed it for but that I chose to install OpenBSD
| version 5.8 on...because I did not want to put up with the
| relinking...I would have rather used 6.2...would it be possible to
| give users a "switch" to turn off relinking if they want without
| recompiling the kernel...please forgive my ignorance (or flame
| away...) if this already exists.

echo make_me_less_secure_please | doas tee /var/db/kernel.SHA256

Going back to an older release to *avoid* security features in newer
versions... wow.  You do realise that this kernel relinking thing is
not the only improvement that's made in the more than two years since
5.8, right?

Paul 'WEiRD' de Weerd

-- 
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
 http://www.weirdnet.nl/ 

Re: kernel relink segfaults on ALIX

[Z Ero]

Coincidently I just logged in to write the misc  list about relinking
on boot. Is it possible to disable it? What about just relinking on
the first boot after install? So then every kernel image is different
but not re-randomized each boot! There are some low memory / slow CPU
embedded systems like Alix / Soekris where the benefit, in my opinion,
of re-linking every single boot is not worth the cost. That said
granted these systems should not be rebooted frequently anyway once in
production during normal use. I had a soekris recently that performed
well for the task I needed it for but that I chose to install OpenBSD
version 5.8 on...because I did not want to put up with the
relinking...I would have rather used 6.2...would it be possible to
give users a "switch" to turn off relinking if they want without
recompiling the kernel...please forgive my ignorance (or flame
away...) if this already exists.

Thanks.

On Thu, Apr 19, 2018 at 2:16 AM, Darren Tucker  wrote:
> On 19 April 2018 at 16:52, Jan Stary  wrote:
>> This is a fresh upgrade of current/i386 on an ALIX 2D3.
>> Upon start, kernel relinking fails, with relink.log saying:
>
> Do you have any swap configured?  Relinking takes a reasonable amount
> of ram and the ALIX doesn't have a lot.
>
> --
> Darren Tucker (dtucker at dtucker.net)
> GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
> Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.
>

sshfuse: fusefs: libfuse vnode reclaim failed

[Rudolf Sykora]

Hello,

I've been trying to use sshfs.

It started ok, but after a while the program
using it as if froze, in the console I see repeatedly

fusefs: libfuse vnode reclaim failed

The program at that moment can't be terminated,

The whole system at that point starts to be weird.
I was unable to kill sshfs even with -9. I was
unable even to reboot. I had to push the power
button in the end.

Has anybody else experienced something similar?

Thanks for comments

Ruda

Re: kernel relink segfaults on ALIX

[Darren Tucker]

On 19 April 2018 at 16:52, Jan Stary  wrote:
> This is a fresh upgrade of current/i386 on an ALIX 2D3.
> Upon start, kernel relinking fails, with relink.log saying:

Do you have any swap configured?  Relinking takes a reasonable amount
of ram and the ALIX doesn't have a lot.

-- 
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

kernel relink segfaults on ALIX

[Jan Stary]

This is a fresh upgrade of current/i386 on an ALIX 2D3.
Upon start, kernel relinking fails, with relink.log saying:

(SHA256) /bsd: OK
LD="ld" LDFLAGS="-g" sh makegap.sh 0x
ld -T ld.script -X --warn-common -nopie -o newbsd ${SYSTEM_HEAD} vers.o ${OBJS}
Segmentation fault (core dumped) 
*** Error 139 in /usr/share/relink/kernel/GENERIC (Makefile:1045 'newbsd': 
@echo ld -T ld.script -X --warn-common -nopie -o newbsd '${SYSTEM...)

/usr/share/relink is empty, with
/dev/wd0d 1001M801M150M84%/usr

Am I missing something obvious?

Jan