Re: requesting help working around boot failures with supermicro atom board

[Dewey Hylton]

Mike Larkin  azathoth.net> writes:

> 
> On Tue, Sep 15, 2015 at 07:16:40PM +, Dewey Hylton wrote:
> > Dewey Hylton  gmail.com> writes:
> > 
> > > 
> > > Mike Larkin  azathoth.net> writes:
> > 
> > > > acpidump please.
> > > 
> > > my pleasure:
> > > 
> > > [demime removed a uuencoded section named
> > supermicro-X7SPE-HF-D525-acpidump.tgz which was 276 lines]
> > > 
> > > 
> > 
> > alright ... so this didn't work. i'll try to make the acpidump available via
> > another site somewhere. on that note, the bios allows selection between acpi
> > 1/2/3 - would it help at all to have acpidump for each of those three
settings?
> > 
> 
> Sure.
> 
> 

motherboard: supermicro x7spe-hf-d525 rev 1.0
bios: 1.2b

at the end of this link is an archive containing acpidump output for all
three acpi settings in the bios (1.0, 2.0, 3.0). 

https://goo.gl/tWGL6C

i apologize for the somewhat hidden link; gmane wouldn't allow me to post
the full link because it's greater than 80 characters.

please let me know if i can help in any way; i honestly know nothing about
acpi but am willing to learn or assist otherwise if it means understanding
and potentially fixing this issue.

Re: Can't ping IPv6

[Remi Locherer]

On Tue, Sep 15, 2015 at 10:01:03PM +0100, Mark Carroll wrote:
> I have a fairly vanilla OpenBSD 5.7 installation on
> a machine for which my provider told me,
> 
> Net : 5.28.62.155, 2001:41c9:1:41c::155
> 
> My pf.conf is simple; it still has the,
> block return# block stateless traffic
> that I suppose I got from somewhere and generally seems to work fine.
> 
> I can ping 5.28.62.155 just fine from anywhere, and from on the machine
> itself I can ping6 its other address. I don't have IPv6 set up at home
> but from various online IPv6 ping check tools I /don't/ seem to be able
> to ping 2001:41c9:1:41c::155. On the machine "route show" provides a
> bunch of stuff,
> 
> Internet6:
> DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
> ::/104 localhost  UGRS   00 32768 8 lo0  
> ::/96  localhost  UGRS   00 32768 8 lo0  
> localhost  localhost  UHl   140 32768 1 lo0  
> localhost  localhost  UH 00 32768 4 lo0  
> ::127.0.0.0/104localhost  UGRS   00 32768 8 lo0  
> ::224.0.0.0/100localhost  UGRS   00 32768 8 lo0  
> ::255.0.0.0/104localhost  UGRS   00 32768 8 lo0  
> :::0.0.0.0/96  localhost  UGRS   00 32768 8 lo0  
> 2001-41c9-0001-041 link#1 UC 00 - 4 vio0 

Strange notation with "-". Never seen such an output from "routei show" or
"netstat -rn"  command.

> green.ixod.org fe:ff:00:00:4f:1a  UHLl   0   22 - 1 lo0  
> 2002::/24  localhost  UGRS   00 32768 8 lo0  
> 2002:7f00::/24 localhost  UGRS   00 32768 8 lo0  
> 2002:e000::/20 localhost  UGRS   00 32768 8 lo0  
> 2002:ff00::/24 localhost  UGRS   00 32768 8 lo0  
> fe80::/10  localhost  UGRS   00 32768 8 lo0  
> fe80::%vio0/64 link#1 UC 20 - 4 vio0 
> fe80::523d:e5ff:fe 50:3d:e5:3b:a1:3f  UHLc   0  102 - 4 vio0 
> fe80::523d:e5ff:fe 50:3d:e5:3b:d7:3f  UHLc   0  116 - 4 vio0 
> fe80::fcff:ff:fe00 fe:ff:00:00:4f:1a  UHLl   00 - 1 lo0  
> fe80::%lo0/64  fe80::1%lo0U  00 32768 4 lo0  
> fe80::1%lo0fe80::1%lo0UHl00 32768 1 lo0  
> fec0::/10  localhost  UGRS   00 32768 8 lo0  
> ff01::/16  localhost  UGRS   00 32768 8 lo0  
> ff01::%vio0/32 link#1 UC 00 - 4 vio0 
> ff01::%lo0/32  localhost  UC 00 32768 4 lo0  
> ff02::/16  localhost  UGRS   00 32768 8 lo0  
> ff02::%vio0/32 link#1 UC 00 - 4 vio0 
> ff02::%lo0/32  localhost  UC 00 32768 4 lo0  
> 
> When I use one of the online ping6 tools, on tcpdump I can watch
> requests come in, like,
> 
> 21:57:52.144975 2a02:348:82:cb69::6 > green.ixod.org: icmp6: echo request 
> (id:3244 seq:0) [icmp6 cksum ok] (len 40, hlim 248)
> 
> but I never seem to see anything go back out on the interface (and
> neither it seems do they). Should I do something else to make the
> machine pingable via IPv6? Feel free to just point me to the fine manual
> if I missed something, I'm still learning the places where documentation
> lurks.
> 
> -- Mark
> 

You don't have a default route set for IPv6.

Remi

Faulty memory - not the hardware

[Rod Whitworth]

About 18 months I set up two i386 boxes running 5.5. 

One is called HOME and the other is AWAY and they were set up with SSH
confugured to allow AWAY to call HOME to get some data by using the
home data to be seen at AWAY and to use AWAY to remotely modify data at
HOME.

It worked perfectly... but I haven't used it for about nine months
and I managed to forget where the docs are and my memory can find
neither the paper nor the neurons.

I'm looking for a way to preserve all of the setups except for the SSH
security configs.

Anybody with a more reliable brain than mine and experience of a like
config ?

Thanks,

Rod/



*** NOTE *** Please DO NOT CC me. I  subscribed to the list.
Mail to the sender address that does not originate at the list server is 
tarpitted. The reply-to: address is provided for those who feel compelled to 
reply off list. Thankyou.

Rod/
---
This life is not the real thing.
It is not even in Beta.
If it was, then OpenBSD would already have a man page for it.

Re: Faulty memory - not the hardware

[Rod Whitworth]

Whoops!

Forgot to say both ends are running XFCE4.

*** NOTE *** Please DO NOT CC me. I  subscribed to the list.
Mail to the sender address that does not originate at the list server is 
tarpitted. The reply-to: address is provided for those who feel compelled to 
reply off list. Thankyou.

Rod/
---
This life is not the real thing.
It is not even in Beta.
If it was, then OpenBSD would already have a man page for it.

Re: Native EFI Bootloader Support

[Chris Cappuccio]

Toby Slight [tobysli...@gmail.com] wrote:
> On 15 September 2015 at 18:09, Chris Cappuccio  wrote:
> 
> >
> > Sounds like a bug in the brand new EFI boot blocks which affects your uefi
> > firmware and not some others. It seems all of your tests are pointing in
> > the
> > same direction, they are not a result of differences in the kernels,
> > rather,
> > they are a result of some bug or bugs in the efiblocks.
> >
> 
> Do you think it's a efiblock bug for both issues (the usb installer kernel
> not loading 90% of the time AND an encrypted install not fully booting)?

Sounds like it.

> Why do you think the un-encrypted install and bsd.rd from an encrypted
> install boot without issue? Aren't the same efiblocks used in each case?

The boot blocks work in a tough environment with limited information.

You're beta testing. It's fun.

Chris

Sep 13 snapshot doesn't cleanly unmount / on reboot?

[Darren Tucker]

Hi all.

I've got a pcengines APU running a recent snap (upgraded via bsd.rd),
and it doesn't seem to cleanly unmount the root filesystem on reboot,
always claiming "/mnt was not properly unmounted".  Any ideas ideas why?

boot> 
booting hd0a:/bsd: 6699132+2139392+259080+0+647168 [72+565392+375639]=0xa32eb0
entry point at 0x1000160 [7205c766, 3404, 24448b12, 9060a304]
[ using 941744 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-2015 OpenBSD. All rights reserved.  http://www.OpenBSD.org

OpenBSD 5.8-current (GENERIC.MP) #1368: Sun Sep 13 20:53:28 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2098511872 (2001MB)
avail mem = 2031009792 (1936MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7e16d820 (7 entries)
bios0: vendor coreboot version "4.0" date 09/08/2014
bios0: PC Engines APU
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT
acpi0: wakeup devices AGPB(S4) HDMI(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) 
PE20(S4) PE21(S4) PE22(S4) PE23(S4) PIBR(S4) UOH1(S3) UOH2(S3) UOH3(S3) 
UOH4(S3) UOH5(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 14318180 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD G-T40N Processor, 1000.14 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
16-way L2 cache
cpu0: 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 199MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD G-T40N Processor, 1000.00 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
16-way L2 cache
cpu1: 8 4MB entries fully associative
cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins
acpiprt0 at acpi0: bus -1 (AGPB)
acpiprt1 at acpi0: bus -1 (HDMI)
acpiprt2 at acpi0: bus 1 (PBR4)
acpiprt3 at acpi0: bus 2 (PBR5)
acpiprt4 at acpi0: bus 3 (PBR6)
acpiprt5 at acpi0: bus -1 (PBR7)
acpiprt6 at acpi0: bus 5 (PE20)
acpiprt7 at acpi0: bus -1 (PE21)
acpiprt8 at acpi0: bus -1 (PE22)
acpiprt9 at acpi0: bus -1 (PE23)
acpiprt10 at acpi0: bus 0 (PCI0)
acpiprt11 at acpi0: bus 4 (PIBR)
acpicpu0 at acpi0: !C2(0@100 io@0x841), C1(@1 halt!), PSS
acpicpu1 at acpi0: !C2(0@100 io@0x841), C1(@1 halt!), PSS
acpibtn0 at acpi0: PWRB
cpu0: 1000 MHz: speeds: 1000 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "AMD AMD64 14h Host" rev 0x00
ppb0 at pci0 dev 4 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi
pci1 at ppb0 bus 1
re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E (0x2c00), 
msi, address 00:0d:b9:31:30:74
rgephy0 at re0 phy 7: RTL8169S/8110S/8211 PHY, rev. 4
ppb1 at pci0 dev 5 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi
pci2 at ppb1 bus 2
re1 at pci2 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E (0x2c00), 
msi, address 00:0d:b9:31:30:75
rgephy1 at re1 phy 7: RTL8169S/8110S/8211 PHY, rev. 4
ppb2 at pci0 dev 6 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi
pci3 at ppb2 bus 3
re2 at pci3 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E (0x2c00), 
msi, address 00:0d:b9:31:30:76
rgephy2 at re2 phy 7: RTL8169S/8110S/8211 PHY, rev. 4
ahci0 at pci0 dev 17 function 0 "ATI SBx00 SATA" rev 0x40: apic 2 int 19, AHCI 
1.2
scsibus1 at ahci0: 32 targets
ohci0 at pci0 dev 18 function 0 "ATI SB700 USB" rev 0x00: apic 2 int 18, 
version 1.0, legacy support
ehci0 at pci0 dev 18 function 2 "ATI SB700 USB2" rev 0x00: apic 2 int 17
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "ATI EHCI root hub" rev 2.00/1.00 addr 1
ohci1 at pci0 dev 19 function 0 "ATI SB700 USB" rev 0x00: apic 2 int 18, 
version 1.0, legacy support
ehci1 at pci0 dev 19 function 2 "ATI SB700 USB2" rev 0x00: apic 2 int 17
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 "ATI EHCI root hub" rev 2.00/1.00 addr 1
piixpm0 at pci0 dev 20 function 0 "ATI SBx00 SMBus" rev 0x42: polling
iic0 at piixpm0
pcib0 at pci0 dev 20 function 3 "ATI SB700 ISA" rev 0x40
ppb3 at pci0 dev 20 function 4 "ATI SB600 PCI" rev 0x40
pci4 at 

Re: Native EFI Bootloader Support

[Toby Slight]

On 15 September 2015 at 18:09, Chris Cappuccio  wrote:

>
> Sounds like a bug in the brand new EFI boot blocks which affects your uefi
> firmware and not some others. It seems all of your tests are pointing in
> the
> same direction, they are not a result of differences in the kernels,
> rather,
> they are a result of some bug or bugs in the efiblocks.
>

Do you think it's a efiblock bug for both issues (the usb installer kernel
not loading 90% of the time AND an encrypted install not fully booting)?
Why do you think the un-encrypted install and bsd.rd from an encrypted
install boot without issue? Aren't the same efiblocks used in each case?
-- 
0x2b || !0x2b

Re: Native EFI Bootloader Support

[YASUOKA Masahiko]

On Tue, 15 Sep 2015 23:35:16 +0100
Toby Slight  wrote:
> On 15 September 2015 at 18:09, Chris Cappuccio  wrote:
>> Sounds like a bug in the brand new EFI boot blocks which affects your uefi
>> firmware and not some others. It seems all of your tests are pointing in
>> the
>> same direction, they are not a result of differences in the kernels,
>> rather,
>> they are a result of some bug or bugs in the efiblocks.
> 
> Do you think it's a efiblock bug for both issues (the usb installer kernel
> not loading 90% of the time AND an encrypted install not fully booting)?
> Why do you think the un-encrypted install and bsd.rd from an encrypted
> install boot without issue? Aren't the same efiblocks used in each case?

I'm not sure but I'm thinking the efi boot cannot load the kernel
properly from the disk.  There may be a bug in reading disk or
handling memory.  Differences of bsd, bsd.rd or softraid is changing
the broken part in the kernel.

Can you try

  http://yasuoka.net/~yasuoka/BOOTX64.EFI

this and "machine test" on boot prompt?  It will show

 0 blocksize=512

like this.  Disk number and blocksize.

Can you also try gzipped kernels (gzip /bsd, then "boot bsd.gz")?  I
suspect loading the kernel will always fail because the gzipped file
has a checksum.

--yasuoka

Re: Native EFI Bootloader Support

[Christoph R. Murauer]

Am 15. September 2015 15:09:43 MESZ, schrieb Toby Slight :
>The plot thickens...
>
>So I finally managed a successful UEFI install (I won't tell you how
>many
>chickens I had to sacrifice...) with the latest snapshots (15/09/2015),
>and
>following http://blog.jasper.la/openbsd-uefi-bootloader-howto/.
>
>This time I opted to keep it simple and not attempt my usual encrypted
>install, so I'm not sure whether there was a fix in the latest snapshot
>or
>the encryption of the previous attempt was to praise/blame respectively
>...
>I did intend to test an encrypted install with the latest sets, however
>the
>randomly booting installer bug is still very much present (see chicken
>sacrificing...), and after 30+ attempts to boot the usb again, my
>patience
>gave out and I'm writing this email instead!
>
>Anyone have any ideas why loading the installer kernel is so flaky? It
>doesn't happen when booting the installed kernels (both the previous,
>broken, encrypted install, and the current, unencrypted, successful
>install
>have no trouble getting past this stage). Anyway I have another
>picture, as
>on one of my 50 odd attempts, it threw me a new error message that I
>hope
>might be of use to someone...
>
>http://i.imgur.com/XOg0AM1.jpg

Hello !

Sorry, this is OT. But I tried the instructions on a Shuttle XS35V4 and, was 
able to install the snapshot from September 15. It works only with enabled USB 
3 (USB 2 get's disable during boot) and, only with install58.fs (miniroot58.fs 
and install58.iso doesn't worked). I was also not able to boot using bsd.rd 
(maybe my fault - I don't know). It was a quick try, if someone likes to get 
more informations / a dmesg, I could provide that tomorrow.

Regards,


Christoph

P.S. The BIOS provides only the option to disable secure boot (which I used) 
but no option to set CSM. Boot mode select is always set to UEFI and can't be 
changed. OS selection provides only Win 7 or Win 8 and 1 must be selected (I 
used Win 7).

Re: spamdb

[Fran. J Ballesteros]

just FYI. our spamd indeed had problems leading to corrupt db entries so some 
where never white listed. 

I changed it to use a simple in memory db and it now white lists as it should. 
the change is ok for us but not for openbsd, so I didn't submit any patch 
anywhere. 

the symptom of the problem is that some mails get rejected with temporary 
failures forever. I would pay attention to the logs and the db if using the 
stock spamd. 

Also, in case it affects, we are using the software raid. 

hth others googling for spamd. 

> El 10/9/2015, a las 15:41, Peter N. M. Hansteen  escribió:
> 
>> On Thu, Sep 10, 2015 at 03:04:26PM +0200, Fran. J Ballesteros wrote:
>> 
>> with 5.7 our spamdb becomes corrupt after a while. Are we the only ones with 
>> this problem? Anyone else using it?
> 
> using spamd with related tools including spamdb through the 5.7 cycle and 
> past, yes.
> 
> seeing spamdb corrupted, not that I've noticed. What are the symptoms more 
> specifically?
> 
> 
> -- 
> 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: Native EFI Bootloader Support

[Chris Cappuccio]

Toby Slight [tobysli...@gmail.com] wrote:
> 
> Finally, is this kind of testing and information at all useful to the devs,
> or am I just creating unnecessary noise on the list, and should I just wait
> until it's a little further down the line? I've got a fair bit of free time
> in the next week or so, before the new term starts, so am happy to test.
> 

Sounds like a bug in the brand new EFI boot blocks which affects your uefi
firmware and not some others. It seems all of your tests are pointing in the
same direction, they are not a result of differences in the kernels, rather,
they are a result of some bug or bugs in the efiblocks.

Re: OpenSMTPD + mysql users (no baseuser system)

[ilyes aiouaz - google mail]

Hi,
3 sec on google :
http://comments.gmane.org/gmane.mail.opensmtpd.general/2310

Regards,

Le 15/09/2015 14:37, Krzysztof Strzeszewski a écrit :

Hi,
How to configure smtpd.conf for users from mysql or other file .db?

Regards,
Krzysztof Strzeszewski

Re: OpenSMTPD + mysql users (no baseuser system)

[ilyes aiouaz - google mail]

OR
https://www.mail-archive.com/misc@opensmtpd.org/msg01426.html

Regards,

Le 15/09/2015 16:45, ilyes aiouaz - google mail a écrit :

Hi,
3 sec on google :
http://comments.gmane.org/gmane.mail.opensmtpd.general/2310

Regards,

Le 15/09/2015 14:37, Krzysztof Strzeszewski a écrit :

Hi,
How to configure smtpd.conf for users from mysql or other file .db?

Regards,
Krzysztof Strzeszewski

Re: Native EFI Bootloader Support

[Toby Slight]

On 15 September 2015 at 14:09, Toby Slight  wrote:

> The plot thickens...
>
> So I finally managed a successful UEFI install (I won't tell you how many
> chickens I had to sacrifice...) with the latest snapshots (15/09/2015), and
> following http://blog.jasper.la/openbsd-uefi-bootloader-howto/.
>
> This time I opted to keep it simple and not attempt my usual encrypted
> install, so I'm not sure whether there was a fix in the latest snapshot or
> the encryption of the previous attempt was to praise/blame respectively ...
> I did intend to test an encrypted install with the latest sets, however the
> randomly booting installer bug is still very much present (see chicken
> sacrificing...), and after 30+ attempts to boot the usb again, my patience
> gave out and I'm writing this email instead!
>
> Anyone have any ideas why loading the installer kernel is so flaky? It
> doesn't happen when booting the installed kernels (both the previous,
> broken, encrypted install, and the current, unencrypted, successful install
> have no trouble getting past this stage). Anyway I have another picture, as
> on one of my 50 odd attempts, it threw me a new error message that I hope
> might be of use to someone...
>
> http://i.imgur.com/XOg0AM1.jpg
>
>
Suddenly realised I could just attempt the encrypted install from the
ramdisk kernel of the current install - doh!

Unfortunately - it wasn't sucessful. I followed the exact same steps as
yesterday:

fdisk -ib 960 sd0
disklabel -E sd0 as one big RAID
bioctl -c C -l /dev/sd0a softraid0

do stock install (wondered if I should have used the new fdisk -b flag to
make the sd4 volume created by the bioctl command also and efi bootable
disk?)

After install formatted sd0i as msdos, mounted and copied over BOOTX64.EFI

It did seem to get a bit further through the boot process this time before
hitting ddb:

http://i.imgur.com/4LjKoB6.jpg
http://i.imgur.com/95dLnP7.jpg

Strangely the bsd.sp kernel wouldn't boot at all, unlike with the 12th's
snapshot, which got further than the mp kernel:

http://i.imgur.com/z5RCzfw.jpg

On a second attempt with the default mp kernel, it shit the bed earlier for
some reason:

http://i.imgur.com/yL33y8k.jpg
http://i.imgur.com/VhjD6vz.jpg

I also wondered how much these issues might have to do with a relatively
recent BIOS update? I'm on Lenovo's latest - "G1ETA8WW (2.68 )" from
03/06/2015?

Finally, is this kind of testing and information at all useful to the devs,
or am I just creating unnecessary noise on the list, and should I just wait
until it's a little further down the line? I've got a fair bit of free time
in the next week or so, before the new term starts, so am happy to test.


-- 
0x2b || !0x2b

Re: requesting help working around boot failures with supermicro atom board

[Mike Larkin]

On Tue, Sep 15, 2015 at 07:16:40PM +, Dewey Hylton wrote:
> Dewey Hylton  gmail.com> writes:
> 
> > 
> > Mike Larkin  azathoth.net> writes:
> 
> > > acpidump please.
> > 
> > my pleasure:
> > 
> > [demime removed a uuencoded section named
> supermicro-X7SPE-HF-D525-acpidump.tgz which was 276 lines]
> > 
> > 
> 
> alright ... so this didn't work. i'll try to make the acpidump available via
> another site somewhere. on that note, the bios allows selection between acpi
> 1/2/3 - would it help at all to have acpidump for each of those three 
> settings?
> 

Sure.

Re: requesting help working around boot failures with supermicro atom board

[Dewey Hylton]

Dewey Hylton  gmail.com> writes:

> 
> Mark Kettenis  xs4all.nl> writes:

> > Oh that is interesting.  Can you try disabling the lm(4) driver in
> > your kernel?  You can do:
> > 
> > # config -ef /bsd
> > ...
> > ukc> disable lm
> > 254 lm0 disabled
> > 255 lm* disabled
> > 256 lm* disabled
> > ukc> quit
> > Saving modified kernel.
> > # reboot
> > 
> > That reboot will probably still hang.  But it'd be interesting to see
> > if any subsequent reboots work better.
> 


sadly, the first thing i heard when entering the lab this morning was BEP!

so disabling the sensor drivers in the kernel did not do the trick. without
other ideas, i'm down to providing acpidump output and hoping someone can
tell me where to go next ...

Re: requesting help working around boot failures with supermicro atom board

[Dewey Hylton]

Dewey Hylton  gmail.com> writes:

> 
> Mike Larkin  azathoth.net> writes:

> > acpidump please.
> 
> my pleasure:
> 
> [demime removed a uuencoded section named
supermicro-X7SPE-HF-D525-acpidump.tgz which was 276 lines]
> 
> 

alright ... so this didn't work. i'll try to make the acpidump available via
another site somewhere. on that note, the bios allows selection between acpi
1/2/3 - would it help at all to have acpidump for each of those three settings?

Re: Can't ping IPv6

[Mark Carroll]

Ha, probably it would help if I added, ifconfig vio0

vio0: flags=8843 mtu 1500
lladdr fe:ff:00:00:4f:1a
priority: 0
groups: egress
media: Ethernet autoselect
status: active
inet 5.28.62.155 netmask 0xff00 broadcast 5.28.62.255
inet6 fe80::fcff:ff:fe00:4f1a%vio0 prefixlen 64 scopeid 0x1
inet6 2001:41c9:1:41c::155 prefixlen 64

-- Mark

Can't ping IPv6

[Mark Carroll]

I have a fairly vanilla OpenBSD 5.7 installation on
a machine for which my provider told me,

Net : 5.28.62.155, 2001:41c9:1:41c::155

My pf.conf is simple; it still has the,
block return# block stateless traffic
that I suppose I got from somewhere and generally seems to work fine.

I can ping 5.28.62.155 just fine from anywhere, and from on the machine
itself I can ping6 its other address. I don't have IPv6 set up at home
but from various online IPv6 ping check tools I /don't/ seem to be able
to ping 2001:41c9:1:41c::155. On the machine "route show" provides a
bunch of stuff,

Internet6:
DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
::/104 localhost  UGRS   00 32768 8 lo0  
::/96  localhost  UGRS   00 32768 8 lo0  
localhost  localhost  UHl   140 32768 1 lo0  
localhost  localhost  UH 00 32768 4 lo0  
::127.0.0.0/104localhost  UGRS   00 32768 8 lo0  
::224.0.0.0/100localhost  UGRS   00 32768 8 lo0  
::255.0.0.0/104localhost  UGRS   00 32768 8 lo0  
:::0.0.0.0/96  localhost  UGRS   00 32768 8 lo0  
2001-41c9-0001-041 link#1 UC 00 - 4 vio0 
green.ixod.org fe:ff:00:00:4f:1a  UHLl   0   22 - 1 lo0  
2002::/24  localhost  UGRS   00 32768 8 lo0  
2002:7f00::/24 localhost  UGRS   00 32768 8 lo0  
2002:e000::/20 localhost  UGRS   00 32768 8 lo0  
2002:ff00::/24 localhost  UGRS   00 32768 8 lo0  
fe80::/10  localhost  UGRS   00 32768 8 lo0  
fe80::%vio0/64 link#1 UC 20 - 4 vio0 
fe80::523d:e5ff:fe 50:3d:e5:3b:a1:3f  UHLc   0  102 - 4 vio0 
fe80::523d:e5ff:fe 50:3d:e5:3b:d7:3f  UHLc   0  116 - 4 vio0 
fe80::fcff:ff:fe00 fe:ff:00:00:4f:1a  UHLl   00 - 1 lo0  
fe80::%lo0/64  fe80::1%lo0U  00 32768 4 lo0  
fe80::1%lo0fe80::1%lo0UHl00 32768 1 lo0  
fec0::/10  localhost  UGRS   00 32768 8 lo0  
ff01::/16  localhost  UGRS   00 32768 8 lo0  
ff01::%vio0/32 link#1 UC 00 - 4 vio0 
ff01::%lo0/32  localhost  UC 00 32768 4 lo0  
ff02::/16  localhost  UGRS   00 32768 8 lo0  
ff02::%vio0/32 link#1 UC 00 - 4 vio0 
ff02::%lo0/32  localhost  UC 00 32768 4 lo0  

When I use one of the online ping6 tools, on tcpdump I can watch
requests come in, like,

21:57:52.144975 2a02:348:82:cb69::6 > green.ixod.org: icmp6: echo request 
(id:3244 seq:0) [icmp6 cksum ok] (len 40, hlim 248)

but I never seem to see anything go back out on the interface (and
neither it seems do they). Should I do something else to make the
machine pingable via IPv6? Feel free to just point me to the fine manual
if I missed something, I'm still learning the places where documentation
lurks.

-- Mark

OpenSMTPD + mysql users (no baseuser system)

[Krzysztof Strzeszewski]

Hi,
How to configure smtpd.conf for users from mysql or other file .db?

Regards,
Krzysztof Strzeszewski

Re: Native EFI Bootloader Support

[Toby Slight]

The plot thickens...

So I finally managed a successful UEFI install (I won't tell you how many
chickens I had to sacrifice...) with the latest snapshots (15/09/2015), and
following http://blog.jasper.la/openbsd-uefi-bootloader-howto/.

This time I opted to keep it simple and not attempt my usual encrypted
install, so I'm not sure whether there was a fix in the latest snapshot or
the encryption of the previous attempt was to praise/blame respectively ...
I did intend to test an encrypted install with the latest sets, however the
randomly booting installer bug is still very much present (see chicken
sacrificing...), and after 30+ attempts to boot the usb again, my patience
gave out and I'm writing this email instead!

Anyone have any ideas why loading the installer kernel is so flaky? It
doesn't happen when booting the installed kernels (both the previous,
broken, encrypted install, and the current, unencrypted, successful install
have no trouble getting past this stage). Anyway I have another picture, as
on one of my 50 odd attempts, it threw me a new error message that I hope
might be of use to someone...

http://i.imgur.com/XOg0AM1.jpg


-- 
0x2b || !0x2b