Re: Problem with keyboard layout
On Tue, Oct 23, 2018 at 01:19:18PM +0200, Stefan Wollny wrote: > Am 22.10.18 um 10:45 schrieb Stefan Wollny: > > Am 10/22/18 um 9:57 AM schrieb Stefan Wollny: > > [ ... ] > >> > >> $ cat /etc/wsconsctl.conf | grep encoding > >> keyboard.encoding=de# use different keyboard encoding > >> > >> Yet this setting seems not to be recognized: > >> $ doas wsconsctl | grep encoding > >> keyboard.encoding=unknown_0 This probably means that you have some other wsconsctl commands that modify the layout after the initial switch to the 'de' layout. > >> > > [ ... ] > > Additional information: > > This issue seems to be related to the X server. Initially I noticed this > > behaviour when starting with xenodm. Switching to a console outside of X > > gives me the expected German keyboard layout. The same if I disable > > xenodm in /etc/rc.conf.local and start OpenBSD into a console: Initially > > I have the German keyboard layout but once I start X via 'startx' I get > > the US layout. > > *At least I know now where to find the symbols blindly :/ * If the X server can't recognize the layout returned by wscons, and there is no explicit configuration in /etc/X11/xorg.conf, the default is what you see below. > > > > Thus here is the Xorg.0.log which has the line > > Option "XkbLayout" "us" > > close to the end. > > > -- Matthieu Herrb
Re: pledge & unveil
thx andrew, i read bob beck´s paper on the events.html and listened his talk on youtube yesterday. very informative. He makes things clear. Gesendet: Dienstag, 23. Oktober 2018 um 22:52 Uhr Von: "andrew fabbro" An: h.kampm...@web.de Cc: misc@openbsd.org Betreff: Re: pledge & unveil Also worth searching YouTube for "openbsd pledge" and/or "openbsd unveil". There's at least four talks by Theo on pledge and a recent presentation by Bob Beck on pledge/unveil, as well as many others. On Sun, Oct 21, 2018 at 3:02 PM Heinz Kampmann wrote: > Hello, > > is there a paper on the web that explains work and relationship > from pledge and unveil for dummies? > > Best wishes, > Heinz > > -- andrew fabbro and...@fabbro.org
Re: Bootloader failing to install on 2012 Mac Mini (Openbsd 6.4)
Thanks for the reply, I actually tried the install again after wiping the
disk and noticed that it seems like and efi partition wasn't auto-created
as part of the partitioning which seems odd since I swear it usually is for
efi systems but then again maybe I just don't remember. Install.txt doesn't
mention needing to create one even though one old guide I saw did as part
of the procedure. The previous efi partition I noticed when playing around
before wiping the disk must have been from the old Linux install.
Regardless the error is identical almost to the previous one but with new
numbers and letters after the ".".
The exact and full error message is as follows:
installboot: mkdir('/tmp/installboot.hP11Q78IbS/efi') failed: Invalid
argument
Failed to install bootlocks.
You will not be able to book OpenBSD from sd0.
The output of df -k (Sorry about the formatting, I tried to replicate it as
best I could):
Filesystem 1K-blocks Used AvailCapacity Mounted on
/dev/rd0a3535 5256279 92%/
/dev/sd0a 102887869194 908242 7% /mnt
/dev/sd0l 312080952 36 296476872 0%/mnt/home
/dev/sd0d 4125406 2 3919134 0% /mnt/tmp
/dev/sd0f2061054 577930 1380072 30% /mnt/usr
/dev/sd0g 1028878190628 786808 20% /mnt/usr/X11R6
/dev/sd0h 20636942 218 19604878 0% /mnt/usr/local
/dev/sd0k 6189758 2 58802700% /mnt/usr/obj
/dev/sd0j2061054 2 19580000% /mnt/usr/src
/dev/sd0e 20425598 3394 19400926 0% /mnt/var
On Wed, Oct 24, 2018 at 1:51 PM Philip Guenther wrote:
> On Tue, Oct 23, 2018 at 4:38 PM Liam Wigney wrote:
>
>> I've used Openbsd before but my installs have gone smoothly with no issues
>> and this is really the first time it's been a problem. The install is a
>> super boring one, it's whole disk Openbsd with the default gpt partition
>> layout and nothing else special.
>>
>> During the install after the sets are successfully installed there's a
>> notification that the bootloader has failed to install due to mkdir being
>> called with an invalid argument.
>
>
> All the error messages from installboot from mkdir failing include both
> the path and the specific error message. Those are included because
> they're helpful in understanding exactly what failed (and thus what could
> be wrong). Including the _exact_ and _full_ error message would make it
> easier to assist.
>
> (Ruling out stuff that _didn't_ fail is key to figuring out root causes.)
>
>
>
>> Some research online said that I should
>> try to do installboot manually in the subsequent prrompt, so I called
>> installboot sd0 and got the following error
>>
>> installboot: /usr/mdec/biosboot: No such file or directory
>>
>
> Yes, when running from the bsd.rd ramdisk additional argument are
> necessary so that installboot can find the files it needs and disk on which
> to install them. ...but doing that will just replicate what the upgrade
> script already did and the error it gave you...
>
> At this point, the two pieces of information that would help the most are:
> 1) the *EXACT AND FULL* error message that the upgrader reported from
> installboot
> 2) what your disklabel and partition layout looks like. The output of "df
> -k" from the ramdisk shell prompt after the upgrade fails would be good,
> for example, as it has everything mounted under /mnt.
>
>
> Philip Guenther
>
>
Re: dmesg for edgerouter 6p
On Tue, Oct 23, 2018 at 12:14 PM Holger Glaess wrote: > i upgrade from an native 6.4 beta installation , no problems at all. > To quote the email sent to your local 'root' user after install/upgrade: If you wish to ensure that OpenBSD runs better on your machines, please do us a favor (after you have your mail system configured!) and type something like: # (dmesg; sysctl hw.sensors) | \ mail -s "Sony VAIO 505R laptop, apm works OK" dm...@openbsd.org so that we can see what kinds of configurations people are running. As shown, including a bit of information about your machine in the subject or the body can help us even further. We will use this information to improve device driver support in future releases. (Please do this using the supplied GENERIC kernel, not for a custom compiled kernel, unless you're unable to boot the GENERIC kernel. If you have a multi-processor machine, dmesg results of both GENERIC.MP and GENERIC kernels are appreciated.) The device driver information we get from this helps us fix existing drivers. Thank you!
Re: Bootloader failing to install on 2012 Mac Mini (Openbsd 6.4)
On Tue, Oct 23, 2018 at 4:38 PM Liam Wigney wrote: > I've used Openbsd before but my installs have gone smoothly with no issues > and this is really the first time it's been a problem. The install is a > super boring one, it's whole disk Openbsd with the default gpt partition > layout and nothing else special. > > During the install after the sets are successfully installed there's a > notification that the bootloader has failed to install due to mkdir being > called with an invalid argument. All the error messages from installboot from mkdir failing include both the path and the specific error message. Those are included because they're helpful in understanding exactly what failed (and thus what could be wrong). Including the _exact_ and _full_ error message would make it easier to assist. (Ruling out stuff that _didn't_ fail is key to figuring out root causes.) > Some research online said that I should > try to do installboot manually in the subsequent prrompt, so I called > installboot sd0 and got the following error > > installboot: /usr/mdec/biosboot: No such file or directory > Yes, when running from the bsd.rd ramdisk additional argument are necessary so that installboot can find the files it needs and disk on which to install them. ...but doing that will just replicate what the upgrade script already did and the error it gave you... At this point, the two pieces of information that would help the most are: 1) the *EXACT AND FULL* error message that the upgrader reported from installboot 2) what your disklabel and partition layout looks like. The output of "df -k" from the ramdisk shell prompt after the upgrade fails would be good, for example, as it has everything mounted under /mnt. Philip Guenther
Bootloader failing to install on 2012 Mac Mini (Openbsd 6.4)
I've used Openbsd before but my installs have gone smoothly with no issues and this is really the first time it's been a problem. The install is a super boring one, it's whole disk Openbsd with the default gpt partition layout and nothing else special. During the install after the sets are successfully installed there's a notification that the bootloader has failed to install due to mkdir being called with an invalid argument. Some research online said that I should try to do installboot manually in the subsequent prrompt, so I called installboot sd0 and got the following error installboot: /usr/mdec/biosboot: No such file or directory Looking in /usr/medc/ the only program is mbr. Using installboot -v I saw that the second stage is supposed to be /usr/medc/boot which is also missing. It's my understanding anyway that these are for mbr legacy boot situations not gtp efi ones and Mac's use efi so I don't know if this is the issue. So I really don't know where to go from here. I saw a few other references in the mailing list to missing biosboot but they don't seem relevant to this case as it seems like they had other issues as well. I don't know if it's an Mac efi problem or not but I've noticed that lots of the community use(d) Macbooks including airs but I didn't notice any specific things to do when installing. Sorry if I've missed something obvious, I've actually never had any trouble with the install before so it's my first time actually trying to work out what's up. I just have no clue how to debug this issue so any pointers would be much appreciated.
Re: dmesg for edgerouter 6p
On Tue, Oct 23, 2018 at 4:24 PM Holger Glaess wrote: > hi > > i upgrade from an native 6.4 beta installation , no problems at all. > > > / 29>dmesg > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > Copyright (c) 1995-2018 OpenBSD. All rights reserved. > https://www.OpenBSD.org > > OpenBSD 6.4 (GENERIC.MP) #0: Sat Oct 13 03:52:37 UTC 2018 > visa@octeon:/usr/src/sys/arch/octeon/compile/GENERIC.MP > real mem = 1073741824 (1024MB) > avail mem = 1038041088 (989MB) > mainbus0 at root: board 20300 rev 1.20 > cpu0 at mainbus0: CN70xx/CN71xx CPU rev 0.2 1000 MHz, CN70xx/CN71xx FPU > rev 0.0 > cpu0: cache L1-I 78KB 39 way D 32KB 32 way, L2 1024KB 8 way > cpu1 at mainbus0: CN70xx/CN71xx CPU rev 0.2 1000 MHz, CN70xx/CN71xx FPU > rev 0.0 > cpu1: cache L1-I 78KB 39 way D 32KB 32 way, L2 1024KB 8 way > cpu2 at mainbus0: CN70xx/CN71xx CPU rev 0.2 1000 MHz, CN70xx/CN71xx FPU > rev 0.0 > cpu2: cache L1-I 78KB 39 way D 32KB 32 way, L2 1024KB 8 way > cpu3 at mainbus0: CN70xx/CN71xx CPU rev 0.2 1000 MHz, CN70xx/CN71xx FPU > rev 0.0 > cpu3: cache L1-I 78KB 39 way D 32KB 32 way, L2 1024KB 8 way > clock0 at mainbus0: int 5 > octcrypto0 at mainbus0 > iobus0 at mainbus0 > simplebus0 at iobus0: "soc" > octciu0 at simplebus0 > octcib0 at simplebus0: max-bits 23 > octcib1 at simplebus0: max-bits 12 > octcib2 at simplebus0: max-bits 6 > octcib3 at simplebus0: max-bits 15 > octcib4 at simplebus0: max-bits 4 > octcib5 at simplebus0: max-bits 11 > octcib6 at simplebus0: max-bits 11 > cn30xxsmi0 at simplebus0 > octxctl0 at simplebus0: DWC3 rev 0x250a > xhci0 at octxctl0, xHCI 1.0 > usb0 at xhci0: USB revision 3.0 > uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev > 3.00/1.00 addr 1 > octxctl1 at simplebus0: DWC3 rev 0x250a > xhci1 at octxctl1, xHCI 1.0 > usb1 at xhci1: USB revision 3.0 > uhub1 at usb1 configuration 1 interface 0 "Generic xHCI root hub" rev > 3.00/1.00 addr 1 > com0 at simplebus0: ns16550a, 64 byte fifo > com0: console > com1 at simplebus0: ns16550a, 64 byte fifo > com1: probed fifo depth: 0 bytes > octmmc0 at simplebus0 > sdmmc0 at octmmc0: 8-bit, mmc high-speed > sdmmc1 at octmmc0: 8-bit, mmc high-speed > octrng0 at iobus0 base 0x14000 irq 0 > cn30xxgmx0 at iobus0 base 0x118000800 > cnmac0 at cn30xxgmx0: SGMII, address fc:ec:da:40:fa:42 > ukphy0 at cnmac0 phy 4: Generic IEEE 802.3u media interface, rev. 2: OUI > 0x0001c1, model 0x000c > cnmac1 at cn30xxgmx0: SGMII, address fc:ec:da:40:fa:43 > ukphy1 at cnmac1 phy 5: Generic IEEE 802.3u media interface, rev. 2: OUI > 0x0001c1, model 0x000c > cnmac2 at cn30xxgmx0: SGMII, address fc:ec:da:40:fa:44 > ukphy2 at cnmac2 phy 6: Generic IEEE 802.3u media interface, rev. 2: OUI > 0x0001c1, model 0x000c > cnmac3 at cn30xxgmx0: SGMII, address fc:ec:da:40:fa:45 > ukphy3 at cnmac3 phy 7: Generic IEEE 802.3u media interface, rev. 2: OUI > 0x0001c1, model 0x000c > cn30xxgmx1 at iobus0 base 0x118001000 > cnmac4 at cn30xxgmx1: SGMII, address fc:ec:da:40:fa:46 > ukphy4 at cnmac4 phy 8: Generic IEEE 802.3u media interface, rev. 0: OUI > 0x0001c1, model 0x0027 > cnmac5 at cn30xxgmx1: SGMII, address fc:ec:da:40:fa:47 > ukphy5 at cnmac5 phy 9: Generic IEEE 802.3u media interface, rev. 0: OUI > 0x0001c1, model 0x0027 > Do the six ports work? Thanks > /dev/ksyms: Symbol table not valid. > umass0 at uhub0 port 2 configuration 1 interface 0 "Generic USB3.0 Card > Reader" rev 3.00/15.32 addr 2 > umass0: using SCSI over Bulk-Only > scsibus0 at umass0: 2 targets, initiator 0 > sd0 at scsibus0 targ 1 lun 0: SCSI4 > 0/direct removable serial.05e307491532 > sd0: 61056MB, 512 bytes/sector, 125042688 sectors > sdmmc1: can't enable card > scsibus1 at sdmmc0: 2 targets, initiator 0 > sd1 at scsibus1 targ 1 lun 0: SCSI2 0/direct > removable > sd1: 3776MB, 512 bytes/sector, 7733248 sectors > vscsi0 at root > scsibus2 at vscsi0: 256 targets > softraid0 at root > scsibus3 at softraid0: 256 targets > boot device: sd0 > root on sd0a (1e8c6ddb499f7a0a.a) swap on sd0b dump on sd0b > WARNING: No TOD clock, believing file system. > WARNING: CHECK AND RESET THE DATE! > 20:25:13 Mon Aug 20 > > > holger > > >
dmesg for edgerouter 6p
hi i upgrade from an native 6.4 beta installation , no problems at all. / 29>dmesg Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2018 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.4 (GENERIC.MP) #0: Sat Oct 13 03:52:37 UTC 2018 visa@octeon:/usr/src/sys/arch/octeon/compile/GENERIC.MP real mem = 1073741824 (1024MB) avail mem = 1038041088 (989MB) mainbus0 at root: board 20300 rev 1.20 cpu0 at mainbus0: CN70xx/CN71xx CPU rev 0.2 1000 MHz, CN70xx/CN71xx FPU rev 0.0 cpu0: cache L1-I 78KB 39 way D 32KB 32 way, L2 1024KB 8 way cpu1 at mainbus0: CN70xx/CN71xx CPU rev 0.2 1000 MHz, CN70xx/CN71xx FPU rev 0.0 cpu1: cache L1-I 78KB 39 way D 32KB 32 way, L2 1024KB 8 way cpu2 at mainbus0: CN70xx/CN71xx CPU rev 0.2 1000 MHz, CN70xx/CN71xx FPU rev 0.0 cpu2: cache L1-I 78KB 39 way D 32KB 32 way, L2 1024KB 8 way cpu3 at mainbus0: CN70xx/CN71xx CPU rev 0.2 1000 MHz, CN70xx/CN71xx FPU rev 0.0 cpu3: cache L1-I 78KB 39 way D 32KB 32 way, L2 1024KB 8 way clock0 at mainbus0: int 5 octcrypto0 at mainbus0 iobus0 at mainbus0 simplebus0 at iobus0: "soc" octciu0 at simplebus0 octcib0 at simplebus0: max-bits 23 octcib1 at simplebus0: max-bits 12 octcib2 at simplebus0: max-bits 6 octcib3 at simplebus0: max-bits 15 octcib4 at simplebus0: max-bits 4 octcib5 at simplebus0: max-bits 11 octcib6 at simplebus0: max-bits 11 cn30xxsmi0 at simplebus0 octxctl0 at simplebus0: DWC3 rev 0x250a xhci0 at octxctl0, xHCI 1.0 usb0 at xhci0: USB revision 3.0 uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1 octxctl1 at simplebus0: DWC3 rev 0x250a xhci1 at octxctl1, xHCI 1.0 usb1 at xhci1: USB revision 3.0 uhub1 at usb1 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1 com0 at simplebus0: ns16550a, 64 byte fifo com0: console com1 at simplebus0: ns16550a, 64 byte fifo com1: probed fifo depth: 0 bytes octmmc0 at simplebus0 sdmmc0 at octmmc0: 8-bit, mmc high-speed sdmmc1 at octmmc0: 8-bit, mmc high-speed octrng0 at iobus0 base 0x14000 irq 0 cn30xxgmx0 at iobus0 base 0x118000800 cnmac0 at cn30xxgmx0: SGMII, address fc:ec:da:40:fa:42 ukphy0 at cnmac0 phy 4: Generic IEEE 802.3u media interface, rev. 2: OUI 0x0001c1, model 0x000c cnmac1 at cn30xxgmx0: SGMII, address fc:ec:da:40:fa:43 ukphy1 at cnmac1 phy 5: Generic IEEE 802.3u media interface, rev. 2: OUI 0x0001c1, model 0x000c cnmac2 at cn30xxgmx0: SGMII, address fc:ec:da:40:fa:44 ukphy2 at cnmac2 phy 6: Generic IEEE 802.3u media interface, rev. 2: OUI 0x0001c1, model 0x000c cnmac3 at cn30xxgmx0: SGMII, address fc:ec:da:40:fa:45 ukphy3 at cnmac3 phy 7: Generic IEEE 802.3u media interface, rev. 2: OUI 0x0001c1, model 0x000c cn30xxgmx1 at iobus0 base 0x118001000 cnmac4 at cn30xxgmx1: SGMII, address fc:ec:da:40:fa:46 ukphy4 at cnmac4 phy 8: Generic IEEE 802.3u media interface, rev. 0: OUI 0x0001c1, model 0x0027 cnmac5 at cn30xxgmx1: SGMII, address fc:ec:da:40:fa:47 ukphy5 at cnmac5 phy 9: Generic IEEE 802.3u media interface, rev. 0: OUI 0x0001c1, model 0x0027 /dev/ksyms: Symbol table not valid. umass0 at uhub0 port 2 configuration 1 interface 0 "Generic USB3.0 Card Reader" rev 3.00/15.32 addr 2 umass0: using SCSI over Bulk-Only scsibus0 at umass0: 2 targets, initiator 0 sd0 at scsibus0 targ 1 lun 0: SCSI4 0/direct removable serial.05e307491532 sd0: 61056MB, 512 bytes/sector, 125042688 sectors sdmmc1: can't enable card scsibus1 at sdmmc0: 2 targets, initiator 0 sd1 at scsibus1 targ 1 lun 0: SCSI2 0/direct removable sd1: 3776MB, 512 bytes/sector, 7733248 sectors vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets boot device: sd0 root on sd0a (1e8c6ddb499f7a0a.a) swap on sd0b dump on sd0b WARNING: No TOD clock, believing file system. WARNING: CHECK AND RESET THE DATE! 20:25:13 Mon Aug 20 holger
Re: pledge & unveil
Also worth searching YouTube for "openbsd pledge" and/or "openbsd unveil". There's at least four talks by Theo on pledge and a recent presentation by Bob Beck on pledge/unveil, as well as many others. On Sun, Oct 21, 2018 at 3:02 PM Heinz Kampmann wrote: > Hello, > > is there a paper on the web that explains work and relationship > from pledge and unveil for dummies? > > Best wishes, > Heinz > > -- andrew fabbro and...@fabbro.org
Re: VMM sh: time sleep 30 takes 56 seconds
On Tue, Oct 23, 2018 at 04:47:06AM +, Mike Larkin wrote: > On Mon, Oct 22, 2018 at 02:52:42AM -0200, Daniel Bolgheroni wrote: > > On Fri, Oct 19, 2018 at 04:16:51AM +, Mike Larkin wrote: > > > On Thu, Oct 18, 2018 at 10:34:20PM -0300, Daniel Bolgheroni wrote: > > > > On Wed, Oct 17, 2018 at 08:42:46PM +, Mike Larkin wrote: > > > > > A 1000Hz host helps here. I get 10.32s real time on sleep 10 with > > > > > that setting. > > > > > > > > > > Note that qemu behaves the same way on OpenBSD. > > > > > > > > OK, the output is still slow when on serial, but things improved > > > > > > Is the console baudrate 9600 or 115200? > > > > It's running at 115200. > > > > $ vmctl start 1 -c > > Connected to /dev/ttyp7 (speed 115200) > > ^^^ if this is what you are using to determine that, I'd ask you to ensure > that you stty com0 115200 in /etc/boot.conf and that the /etc/ttys line > has 115200 for the console also. The baudrate from the output of the 'cu' > used by 'vmctl console' always prints 115200 in this case, even if vmd > is only outputting at 9600. Yes, it was my assumption. I already had 'stty com0 115200' in /etc/boot.conf and now adjusted /etc/ttys to 115200 where appropriate. And things improved: 9600 in /etc/ttys: # time cat /etc/ttys (...) 1m09.27s real 0m00.00s user 0m00.00s system # 115200 in /etc/ttys: # time cat /etc/ttys 0m11.66s real 0m00.00s user 0m00.00s system # As for comparison, I made the same test connected to a Orange Pi Zero, also at 115200, using a USB-to-serial converter uftdi(4): # time cat /etc/ttys 0m04.03s real 0m00.00s user 0m00.00s system # I don't know if this is somehow related to interrupts previously discussed and, in these cases, it's running -current snapshots, e.g. HZ=100. Thank you. -- db
Re: phonetic alphabet on OpenBSD
My apologies for the noise. You are absolutely right. Chris Bennett
Re: ospfd fib and kernel fib
On Tue, Oct 23, 2018 at 01:14:52PM +0200, open...@kene.nu wrote:
> Hello,
> On Mon, Oct 22, 2018 at 4:24 PM Remi Locherer wrote:
> >
> > On Mon, Oct 22, 2018 at 08:48:28AM +0200, open...@kene.nu wrote:
> > > Hello,
> > >
> > > I am having trouble with ospfd not updating the kernel fib as it
> > > should (I think). This is in my lab environment on vagrant.
> > >
> > > host# uname -a
> > > OpenBSD host 6.4 GENERIC.MP#329 amd64
> > > host# ospfctl sh rib | grep 172.29.21.2
> > > 172.29.21.2/32 172.29.2.10 Intra-Area Network 20
> > > 00:03:12
> > > host# ospfctl sh fib | grep 172.29.21.2
> > > *O 32 172.29.21.2/32 172.29.2.10
> > > host# netstat -rn | grep 172.29.21.2
> > > host# cat /etc/ospfd.conf
> > > router-id 172.29.23.2
> > >
> > > area 0.0.0.0 {
> > > auth-type crypt
> > > auth-md 1 "one"
> > > auth-md 2 "two"
> > > auth-md-keyid 1
> > > }
> >
> > Is this the config that was active while you produced above outputs?
> > It does not contain any interface statements.
> >
>
> Oh, I accidentally, and erroneously, stripped those along with other
> non relevant config. Assume the interface statements are there.
It's really hard to help with config snippets containing only what is
considered "relevant" by some.
It's much more likely that someone tries to understand your problem if you
post all information. In this case I would expect the full ospf config, the
full output of netstat -rn and the ospf rib and fib.
>
> > >
> > > So, what is going on? The route is in the ospfd fib but not in the
> > > kernel fib. I understand that the next hop must be reachable, and it
> > > is. Other than that I have no idea what qualifies a route to be
> > > propagated from ospf fib to kernel fib.
> > >
>
Re: Problem with keyboard layout
Am 22.10.18 um 10:45 schrieb Stefan Wollny: > Am 10/22/18 um 9:57 AM schrieb Stefan Wollny: > [ ... ] >> >> $ cat /etc/wsconsctl.conf | grep encoding >> keyboard.encoding=de# use different keyboard encoding >> >> Yet this setting seems not to be recognized: >> $ doas wsconsctl | grep encoding >> keyboard.encoding=unknown_0 >> > [ ... ] > Additional information: > This issue seems to be related to the X server. Initially I noticed this > behaviour when starting with xenodm. Switching to a console outside of X > gives me the expected German keyboard layout. The same if I disable > xenodm in /etc/rc.conf.local and start OpenBSD into a console: Initially > I have the German keyboard layout but once I start X via 'startx' I get > the US layout. > *At least I know now where to find the symbols blindly :/ * > > Thus here is the Xorg.0.log which has the line > Option "XkbLayout" "us" > close to the end. > Unfortunately the issue persists with the last published version of amd64/current. New dmesg and Xorg.0.log below. Anyone with a clue what might be cause of wsconsctl not using the encoding as defined in the conf-file? unveil(2)-related? Any other information I should provide? TIA. Best, STEFAN OpenBSD 6.4-current (GENERIC.MP) #380: Mon Oct 22 20:06:50 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17079074816 (16287MB) avail mem = 16552185856 (15785MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb500 (35 entries) bios0: vendor American Megatrends Inc. version "1.03.06" date 06/25/2014 bios0: Notebook W65_67SZ acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT ASF! SSDT SSDT SSDT MCFG HPET SSDT SSDT SSDT DMAR acpi0: wakeup devices PXSX(S4) RP01(S4) PXSX(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S3) EHC2(S3) XHC_(S3) HDEF(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-4210M CPU @ 2.60GHz, 3093.33 MHz, 06-3c-03 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,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-4210M CPU @ 2.60GHz, 3092.85 MHz, 06-3c-03 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,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) i5-4210M CPU @ 2.60GHz, 3092.85 MHz, 06-3c-03 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,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-4210M CPU @ 2.60GHz, 3092.85 MHz, 06-3c-03 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 2 (RP01) acpiprt2 at acpi0: bus 3 (RP03) acpiprt3 at acpi0: bus 4 (RP04) acpiprt4 at acpi0: bus 1 (P0P2) acpiprt5 at acpi0: bus -1 (P0PA) acpiprt6 at acpi0: bus -1 (P0PB) acpiprt7 at acpi0: bus 1 (PEG0)
Re: ospfd fib and kernel fib
Hello,
On Mon, Oct 22, 2018 at 4:24 PM Remi Locherer wrote:
>
> On Mon, Oct 22, 2018 at 08:48:28AM +0200, open...@kene.nu wrote:
> > Hello,
> >
> > I am having trouble with ospfd not updating the kernel fib as it
> > should (I think). This is in my lab environment on vagrant.
> >
> > host# uname -a
> > OpenBSD host 6.4 GENERIC.MP#329 amd64
> > host# ospfctl sh rib | grep 172.29.21.2
> > 172.29.21.2/32 172.29.2.10 Intra-Area Network 20
> > 00:03:12
> > host# ospfctl sh fib | grep 172.29.21.2
> > *O 32 172.29.21.2/32 172.29.2.10
> > host# netstat -rn | grep 172.29.21.2
> > host# cat /etc/ospfd.conf
> > router-id 172.29.23.2
> >
> > area 0.0.0.0 {
> > auth-type crypt
> > auth-md 1 "one"
> > auth-md 2 "two"
> > auth-md-keyid 1
> > }
>
> Is this the config that was active while you produced above outputs?
> It does not contain any interface statements.
>
Oh, I accidentally, and erroneously, stripped those along with other
non relevant config. Assume the interface statements are there.
> >
> > So, what is going on? The route is in the ospfd fib but not in the
> > kernel fib. I understand that the next hop must be reachable, and it
> > is. Other than that I have no idea what qualifies a route to be
> > propagated from ospf fib to kernel fib.
> >
Re: pf keep sate
On 2018-10-22, Daniel Corbe wrote: > at 10:04 AM, Frédéric Goudal wrote: > >> - is there any reason to add keep state to a pass rule ? > > 1) UDP rules don’t keep state by default. That's not correct. > 2) Even for TCP connections, it’s better to explicitly throw a keep state > on there for clarity, so that people who come in behind you and actually > bother reading the documentation don’t have to ask the same question. > There’s also other available options for TCP connections that you might > want to look into, such as flags S/SA (only allow initial handshake between > endpoints that don’t have an established state) and modulate state, which > generates strong, random ISNs for new connections. "flags s/sa" is done by default, unless overridden with a different "flags" setting. It's down to personal opinion but I don't find that adding boilerplate to every "pass" rule makes things any more clear..
