Since we reported the first bits of powerpc64 support going into the tree on 16 May, work has progressed at a steady pace, resulting in snapshots now being available for this platform.
So, if you have a POWER9 system idling around, go to your nearest
mirror
and fetch this snapshot. Keep in mind that as this is still very early days, very little handholding is available - you are basically on your own.
Contributed by
Janne Johansson
on
from the passive vpns with aggressive cryptos dept.
In the following
commit
(and a bunch of others), David Gwynne (dlg@) imported most of the code submitted recently by Jason A. Donenfeld and Matt Dunwoodie to allow you to use WireGuard natively on OpenBSD:
Contributed by
Janne Johansson
on
from the so detailed you might need to zoom in a lot dept.
Wesley Mouedine Assaby who runs the OpenBSD Jumpstart webpage with hints and tips for beginners about OpenBSD in general has produced a visualization of how PCs boot into OpenBSD.
Contributed by
Tom Smyth
on
from the all routes nominal dept.
I presented a talk on how I used OpenBGPd as a control plane for my ISP.
I cover areas such as Routing fundamentals, a lightning introduction to BGP.
An interesting aspect of the design is how the OpenBSD / OpenBGPd
is used to control the routing information in my ISP yet the
forwarding of packets is offloaded to hardware Layer 3 switches.
I also outline my favourite new feature of OpenBGPd max prefix out
which I'm sure will save my blushes if/when I fat finger my Prefix filters
(although if my hair cut is anything to go by it is clear I have no shame anyway!).
You can check out the talk here!
Tom would welcome comments and feedback on the talk.
I hope the talk will help others in deploying OpenBGPd and OpenBSD in their networks.
I would also suggest that those interested in learning more about OpenBGPd
check out Peter Hessler's Tutorial on OpenBGPd which served as an
essential aid in getting comfortable in configuring BGP on OpenBSD / OpenBGPd.
Peter usually runs the Tutorial in advance of BSD Conferences.
I would like to give a big shout out to the people who write the
code in OpenBSD and OpenBGPd, and that your effort makes my life running
my network and ISP easier.
A huge word of thanks is due to Dan Langielle and the
BSDCAN2020 Volunteers who organised the virtual
BSDCAN 2020 conference this year
in quite difficult circumstances.
Jonathan Gray (jsg@) has just committed an update to the
DRM code to the tree.
This update brings support for newer AMD and Intel graphics parts.
Date: Sun, 7 Jun 2020 22:48:16 -0600 (MDT)
From: Jonathan Gray <jsg@openbsd.org>
To: source-changes@openbsd.org
Subject: CVS: cvs.openbsd.org: src
CVSROOT: /cvs
Module name: src
Changes by: jsg@cvs.openbsd.org 2020/06/07 22:48:16
Modified files:
sys/arch/amd64/conf: Makefile.amd64
sys/arch/arm64/conf: Makefile.arm64
sys/arch/i386/conf: Makefile.i386
...
Log message:
update drm to linux 5.7
adds kernel support for
amdgpu: vega20, raven2, renoir, navi10, navi14
inteldrm: icelake, tigerlake
Thanks to the OpenBSD Foundation for sponsoring this work, kettenis@ for
helping, patrick@ for helping adapt rockchip drm and many developers for
testing.
As is clear from Jonathan's commit message, this work was sponsored by the
OpenBSD Foundation
- it shows how your financial support of the foundation can directly improve (in this case) hardware support. Many thanks to Jonathan for working on this.
Contributed by
rueda
on
from the filesystem-asked-questions dept.
Otto Moerbeek (otto@)
posted to misc@
a useful summary of the state of play of FFS2
in the 6.7 release (and, to some extent, -current).
In his mail, Otto clarifies some things about the latest release:
In OpenBSD 6.7, ffs2 is the default for new filesystems during install (with some exceptions).
In OpenBSD 6.7, if you create a new filesystem manually (using newfs(8)) you will still get an FFS1 filesystem unless you force -O2 or if the filesystem will be larger than 1 TB.
In a commit touching quite a few files, Theo recently renamed the installation images from installXX.fs to installXX.img:
Date: Sun, 17 May 2020 11:04:29 -0600 (MDT)
From: Theo de Raadt <deraadt@openbsd.org>
To: source-changes@openbsd.org
Subject: CVS: cvs.openbsd.org: src
CVSROOT: /cvs
Module name: src
Changes by: deraadt@cvs.openbsd.org 2020/05/17 11:04:29
Modified files:
distrib/alpha/miniroot: Makefile
distrib/amd64/iso: Makefile
...
bin/dd : dd.1
usr.sbin/ldomctl: ldomctl.8
Log message:
Change install images called *.fs to *.img. These are UFS filesystem images,
but additionally have a bootblock in the first 8K (since UFS does not use that
space). There are some UEFI direct-from-internet bootloaders that require
the name *.img. So this makes things more convenient for those, while keeping
it consistant in all architectures.
ok kettenis beck kn
This means that with recent snapshots, you should use the .img file to prepare your installation medium, where you were previously using the .fs file. It also means that you can install 'direct-from-internet' on these fancy UEFI machines! Note that if you want to install the OpenBSD 6.7 release, you still need to use install67.fs.
We are constantly on the lookout for stories of how you put OpenBSD to work.
Please submit any informative articles on how OpenBSD is helping your company.
