> >
> > I concur.
> >
>
> I think Josh is looking for similar behaviour to syspatch(8). To be able
> to distinguish, upgrade is ready (exit 0), system is up to date (exit 2)
> or error occurred (exit 1).
>
> I have the same need to distinguish between nothing to do -
For ease of running sysupgrade from within a script.
diff --git a/usr.sbin/sysupgrade/sysupgrade.sh
b/usr.sbin/sysupgrade/sysupgrade.sh
index d80ff127ffa..ce5800093c9 100644
--- a/usr.sbin/sysupgrade/sysupgrade.sh
+++ b/usr.sbin/sysupgrade/sysupgrade.sh
@@ -153,7 +153,7 @@ rm SHA256.sig
if
On Thu, Nov 11, 2021 at 02:42:39PM +0100, Stefan Sperling wrote:
> Testing on 4965 by jsg@ revealed an unrelated issue on those devices.
> A fix for this problem has just been committed.
> This new version of the 40MHz patch applies on top of that fix.
Working fine on my "Intel Centrino
On Mon, Nov 01, 2021 at 01:05:22PM +0100, Stefan Sperling wrote:
> On Mon, Nov 01, 2021 at 12:56:26PM +0100, Stefan Sperling wrote:
> > To check whether your access point uses a 40MHz channel, run this command
> > while associated to the access point:
> > tcpdump -n -i iwm0 -v -y
Here's my take at documenting the missing pledge promises in pledge.2
and placing them in a reasonable order with the others. Each of these
just enabled various ioctl or sysctl interfaces.
I'm unhappy with the explanation for drm, but don't know how to
explain the purpose of these ioctls, and
On Wed, Jun 09, 2021 at 06:01:59PM +, Klemens Nanni wrote:
> > There were three promises which are not documented in pledge(2):
> > disklabel, drm, and vmm. I've just left these at the end.
> Sounds good.
Are the undocumented promises intentional, or bugs in pledge(2)?
> Either way, a small
I was surprised to find that ps -O pledge did not list the pledge
promise names in the same order as the pledge(2) manpage. Besides
lacking consistency, this was also making it difficult to quickly find
which promises are not granted to a process which requires most of
them (e.g. chrome).
I
thanks Otto for the dmesg.
I'd like to get one B550 mobo as well. Which version of Gigabyte B550
AORUS ELITE do you have exactly? ATX? mATX ?
Most of them listed here[1] have either RLT8118 or RLT8125 chipset and
re(4) doesn't list them...
Can't find any reference to your model there[1] (RTL8168
On Tue, Apr 27, 2021 at 01:11:03PM +0200, Stefan Sperling wrote:
> Christian Ehrhardt reported an issue where changes in the ERP protection
> settings in beacons caused noticeable packet loss on iwm(4).
>
> I've found that there are a few parameters in beacons which can change at
> run-time but
On Tue, Apr 27, 2021 at 03:46:56PM +0200, Stefan Sperling wrote:
> Refactor softraid crypto code to allow use of a discipline-specific data
> structure for RAID1C volumes, as requested by jsing@ during review of my
> initial RAID1C patch.
>
> This patch should effectively be a cosmetic change.
>
On Tue, Apr 27, 2021 at 03:03:10PM +0200, Stefan Sperling wrote:
> This patch tweaks the heuristic RA is using to decide whether enough
> statistics have been gathered for a candidate Tx rate. The goal is to
> avoid Tx rate choices that might turn out to be too optimistic.
>
> In my testing RA
gt; > works for me and I worked with Josh on the bugs@ thread to arrive at
> > this diff.
> I agree to handle those separately; thank you both.
>
> OK kn
Friendly reminder that this never got merged.
I see we're out of -beta now and think it's important to get this fix
in before release occurs.
On Thu, Apr 01, 2021 at 06:43:30PM -0500, Scott Cheloha wrote:
> On Thu, Apr 01, 2021 at 03:41:24PM -0400, Josh Rickmar wrote:
> > On Thu, Apr 01, 2021 at 03:22:00PM -0400, Josh Rickmar wrote:
> > > On Thu, Apr 01, 2021 at 02:15:48PM -0500, Scott Cheloha wrote:
> > > &
On Thu, Apr 01, 2021 at 03:22:00PM -0400, Josh Rickmar wrote:
> On Thu, Apr 01, 2021 at 02:15:48PM -0500, Scott Cheloha wrote:
> > On Sat, Mar 27, 2021 at 02:20:21AM +, Stefmorino wrote:
> > > > Feel free to share your raw data.
> > >
> > > Also incl
# dmesg | egrep -i 'tsc|clocksource'
>
> 2. Second, is there a more recent BIOS revision for this machine?
>Perhaps (assuming this is in fact a BIOS problem) Lenovo is aware
>of it and has fixed it. This is unlikely but worth a look.
>
> Long version:
>
> I thin
On Thu, Mar 25, 2021 at 05:28:54PM -0500, Scott Cheloha wrote:
> Feel free to share your raw data.
Attached.
e485skews.tgz
Description: application/tar-gz
On Mon, Feb 01, 2021 at 08:18:53PM +, Josh Rickmar wrote:
> The kern.somaxconn sysctl was previously permitted under the inet
> pledge, which allowed pledged Go applications to listen on AF_INET and
> AF_INET6 domains.
>
> https://marc.info/?l=openbsd-tech=1580695958
On Thu, Mar 25, 2021 at 01:18:04PM -0500, Scott Cheloha wrote:
> > On Mar 24, 2021, at 8:29 AM, Josh Rickmar wrote:
> >
> > On Wed, Mar 24, 2021 at 05:40:21PM +0900, YASUOKA Masahiko wrote:
> >> Hi,
> >>
> >> I hit a problem which is caused by g
On Wed, Mar 24, 2021 at 05:40:21PM +0900, YASUOKA Masahiko wrote:
> Hi,
>
> I hit a problem which is caused by going back of monotonic time. It
> happens on hosts on VMware ESXi.
>
> I wrote the program which repeats the problem.
>
> % cc -o monotime monotime.c -lpthread
> % ./monotime
>
On Fri, Mar 19, 2021 at 03:26:46PM -0400, Josh Rickmar wrote:
> I got some emails off list asking about the removal and if it affected
> them. Worth adding to current.html?
sorry for the noise, missed a
diff 0d7807046bcfacd3249f4c62031ac970d9b42ace /home/jrick/ww
I got some emails off list asking about the removal and if it affected
them. Worth adding to current.html?
diff 0d7807046bcfacd3249f4c62031ac970d9b42ace /home/jrick/www
blob - 9452b3672627fb39fa0c7ec17a17e08f57406afa
file + faq/current.html
--- faq/current.html
+++ faq/current.html
@@ -274,6
On Fri, Mar 19, 2021 at 10:29:10AM -0400, Josh Rickmar wrote:
> Here's an updated version of the patch I had originally posted to
> bugs@ adding support for reading gzipped kernels (needed to boot amd64
> bsd.rd without manually decompressing first), now that the support for
> boot
Here's an updated version of the patch I had originally posted to
bugs@ adding support for reading gzipped kernels (needed to boot amd64
bsd.rd without manually decompressing first), now that the support for
booting a kernel discovered on a ffs filesystem in the image file is
removed.
I've kept
The compress(3) family of utility functions return and operate on
gzFile, a typedef for void*. The extra pointer to this gzFile in
grep(1) can be removed. Other uses of these compress(3) functions in
tree (spamd, mandoc, smtpd) do not use the extra pointer.
diff
David Gwynne wrote:
> I'd vote that way, but I am biased.
>
> Some test reports that it's working well for people would be nice too.=
This is working well in my testing as a replacement for bridge/vether
usage as told in the virtualization FAQ, but I was unaware that the
vport interface needed
The kern.somaxconn sysctl was previously permitted under the inet
pledge, which allowed pledged Go applications to listen on AF_INET and
AF_INET6 domains.
https://marc.info/?l=openbsd-tech=158069595809463=2
https://marc.info/?l=openbsd-cvs=158081099810301=2
But Go will also read this sysctl when
On Wed, Dec 16, 2020 at 03:40:41PM -0700, Theo de Raadt wrote:
> the term "suid" includes setgid executables... so your conclusions
> are way wrong.
>
> Heck, you should give it a try. Good luck logging in afterwards.
Indeed, please disregard.
Playing around with find ${dir} -type f -perm -04000, I see that there
are no longer any more suid executables placed in /usr/libexec or
/usr/X11R6, so I believe these can be removed from install.sub. Based
on the comments, this hasn't been touched in a long while.
diff
Hello,
Recently I tested OpenBSD's OpenFlow support with the FAUCET SDN controller
(https://faucet.nz).
There were some minor issues - OpenFlow spec ambiguity with length checks,
endianness of the cookie in the packet in message, not able to match a
packet with no VLAN, and matches running
Some email accounts use account names that include the @host portion,
and this broke the server and credentials parsing in smtp(1). Sometimes
I see these @ characters encoded as %40, but smtp(1) was not decoding
these url escape sequences before base64 encoding and talking with the
server.
On Fri, Nov 29, 2019 at 10:12:10AM +0100, Thomas de Grivel wrote:
> Maybe Go is not the only problem, I see SBCL compiling syscalls too.
>
> Truth is libc is for C and not all programs are written in C nowadays.
Where are you seeing SBCL compiling direct syscalls? In my testing,
SBCL self-hosts
I came across some code which uses __clear_cache() from
libgcc/libcompiler_rt on 32-bit arm. Currently that just falls through
to abort(), but enabling the existing sysarch() code works for me.
diff --git a/lib/libcompiler_rt/clear_cache.c b/lib/libcompiler_rt/clear_cache.c
index
On Thu, Nov 22, 2018 at 06:33:57PM +0100, Reyk Floeter wrote:
> On Thu, Nov 22, 2018 at 11:50:52AM -0500, Josh Grosse wrote:
> > The page refers to vmx0 rather than vxlan0 in its pf.conf
> > guidance.
> >
>
> ... I committed a change to use em0 instead of vmx0.
>
&
The page refers to vmx0 rather than vxlan0 in its pf.conf
guidance.
Index: vxlan.4
===
RCS file: /systems/cvs/src/share/man/man4/vxlan.4,v
retrieving revision 1.7
diff -u -p -r1.7 vxlan.4
--- vxlan.4 22 Feb 2018 01:35:04 -
It unmaps for each thread when it is destroyed, but never for the
initial thread.
On Sat, Jan 13, 2018 at 03:45:52PM -0700, Theo de Raadt wrote:
> Does it not free it somewhere eventually? How is that handled.
>
>
> > lang/sbcl will need a small patch:
> >
> > $OpenBSD$
> >
> > Index:
On Thu, Jan 11, 2018 at 08:39:25PM -0700, Theo de Raadt wrote:
> Stefan (stefan@) and I have been working for a few months on this
> diff, with help from a few others.
>
> At every trap and system call, it checks if the stack-pointer is on a
> page that is marked MAP_STACK. execve() is changed
On Wed, Apr 12, 2017 at 01:44:48PM +0200, Reyk Floeter wrote:
> Hi,
>
> we want to make it easier to run NAT'ed and auto-configured VMs that
> don't need switches, L2, manual scripts, or any additional servers on
> the host. I wrote a new mode that just needs vmd, pf, and forwarding.
Tested on
On Fri, Apr 14, 2017 at 12:29:53PM -0400, Josh Grosse wrote:
> Tested on an amd64 host...
Following up on my own post to state this was tested both
with "local" in vm.conf as well as with vmctl -L.
alled may not refer
back to faq4.html when they later run into partition size issues after
following the untar guidance in faq15.
A link to #AddThoughts in this section of faq15.html might be appropriate.
> 2016-07-19 3:29 GMT+02:00 Josh Grosse <j...@jggimi.homeip.net>:
> > I had a
I had a conversation with a new OpenBSD user who thought that he
may have either misunderstood or been misled by the guidance to unpack
the ports tree tarball in /usr. He quickly discovered his 2G /usr
default allocation was too small when he began to build ports.
FAQ 15 doesn't warn users who
On Fri, Apr 01, 2016 at 04:19:46PM -0600, Todd C. Miller wrote:
> The problem is that fopen(tty, "w") uses O_CREAT. If we use open
> + fdopen we can avoid that.
>
> Can you try this diff?
Works well. Thank you!
e308 in *_libc_fopen (file=0xcf7fba93 "/dev/ttyp0", mode=0x3a8d2068
"w") at /usr/src/lib/libc/stdio/fopen.c:54
#2 0x1a8d362b in notify (utp=0x89966a20, offset=556) at
/usr/src/libexec/comsat/comsat.c:260
#3 0x1a8d39cb in mailfor (name=0xcf7fc080 "josh") at
/usr/src/
The following patch permits kern_xxx.c to build with SYSCALL_DEBUG.
Index: kern_xxx.c
===
RCS file: /systems/cvs/src/sys/kern/kern_xxx.c,v
retrieving revision 1.29
diff -u -p -u -r1.29 kern_xxx.c
--- kern_xxx.c 5 Dec 2015 10:11:53
Hi Mark,
Just tried amd64 snapshot (1st Nov) on Intel NUC5i7RYH and building
world from source (updated around 4PM UTC, 1st Nov).
While I do not get any kernel panic or crash as others may have faced,
the behavior of some programs such as firefox, dillo under X (startx
with default install) will
The root cause for a recent problem reported on misc@ [0] was
determined to be setting kern.securelevel=2 in sysctl.conf. [1]
To perhaps prevent the provisioning error from happening to others,
I propose the following clarification to securelevel(7). I percieve the
setting as little more than
On Sat, Jan 10, 2015 at 06:09:21PM +, Stuart Henderson wrote:
On 2015/01/10 14:54, Florian Obser wrote:
I don't think this is entirely correct. eui64 enables IPv6 on an interface
by setting a link local address. For lo0 it also sets ::1.
I'm unsure what eui64 was supposed to do
when
Joel Sing joel at sing.id.au writes:
The following diff provides a softraid CONCAT discipline, which serially
concatenates data over the given chunks. This relies on the previous
metadata initialisation cleanup diff that I just sent out.
All testing appreciated.
This seems to work just
On Fri, Jul 15, 2011 at 08:13:59PM -0300, Christiano F. Haesbaert wrote:
Hi, this diff adds a sysctl to disable kernel icmp echo processing and pass it
to userland via raw sockets. I'm terrible with names but I chose userecho, so
net.inet.icmp.userecho.
I did some basic tests and it seems to
On Mon, Dec 27, 2010 at 12:07:55PM -0800, Philip Guenther wrote:
Okay, check out the revised diff below. I've tested the updated amd64
part; I would appreciate a confirmation from an i386 w/X11 user for that
part.
Works for me, X runs and test program no longer drops us into ddb:
OpenBSD
On Tue, Jul 13, 2010 at 10:28:47PM +, Christian Weisgerber wrote:
Theo de Raadt dera...@cvs.openbsd.org wrote:
- posix_openpt(), grantpt(), unlockpt() and ptsname(), and
- utmpx.
This causes a real burden on people trying to write network login
services, terminal emulators,
On 2010-07-09 14:01:41, Christopher Zimmermann wrote:
On 07/09/10 14:19, Christopher Zimmermann wrote:
Hi,
I just upgraded to the very latest snapshot(9.7. 1:50) on i386. Now my
system does not boot anymore. The only thing I get is:
Using drive 0, partition 3.
Loading...
[cursor
51 matches
Mail list logo
