Re: ral interface is not working

[Hendrik Meyburgh]

Hi Stefan.

Thanks that worked.

> On 24 May 2020, at 16:46, Stefan Sperling  wrote:
> 
> On Sun, May 24, 2020 at 03:08:09PM +0200, Hendrik Meyburgh wrote:
>>> Synopsis:   ral interface is not working
>>> Category:   system
>>> Environment:
>>  System  : OpenBSD 6.7
>>  Details : OpenBSD 6.7-current (GENERIC.MP) #207: Fri May 22 
>> 01:31:04 MDT 2020
>>   
>> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>> 
>>  Architecture: OpenBSD.amd64
>>  Machine : amd64
>>> Description:
>>  IP not working on ral interface 
>>> How-To-Repeat:
>> I completed a sysupgrade on Tuesday the 19th, not sure what snapshot was 
>> running prior, I did not check. After the upgrade the laptop does not 
>> connect to any wireless network. The re0 interface is still working on DHCP. 
>> I looked at some recent posts but could not trace the problem
>> 
>> https://marc.info/?l=openbsd-misc=158861290011220=2
>> https://marc.info/?l=openbsd-bugs=158996211916426=2 
>>  
>> > >
>> 
>> I just tested the 6.7-release bsd.rd and it does work, please see info below 
>> and let me know if you need any additional information.
> 
> Thank you for the report!
> 
> I could reproduce the problem with this device:
> 
> ral0 at pci5 dev 0 function 0 "Ralink RT3090" rev 0x00: apic 5 int 16, 
> address xx:xx:xx:xx:xx:xx
> ral0: MAC/BBP RT3090 (rev 0x3213), RF RT3020 (MIMO 1T1R)
> 
> I had overlooked that ral(4) uses hardware encryption on some of its
> supported devices and accidentally broke decrytion on those devices
> when I fixed replay detection on Intel and Atheros hardware.
> 
> ral(4) devices provide fully decrypted frames with TKIP/CCMP headers already
> stripped. This means replay detection can only be done by hardware.
> My recent changes enforce a software replay check which cannot work on ral(4).
> 
> The following diff repairs the problem. The ne80211 stack will simply have
> to trust that hardware takes care of replay detection when it strips the IV.
> 
> diff 3247d7f3b53b75bbaf4356f06f34208638ba213d /usr/src
> blob - de44d5a0a957f497259735efd5cee2cc081d33bc
> file + sys/net80211/ieee80211_input.c
> --- sys/net80211/ieee80211_input.c
> +++ sys/net80211/ieee80211_input.c
> @@ -178,9 +178,12 @@ ieee80211_input_hwdecrypt(struct ieee80211com *ic, str
>   switch (k->k_cipher) {
>   case IEEE80211_CIPHER_CCMP:
>   if (!(wh->i_fc[1] & IEEE80211_FC1_PROTECTED)) {
> - /* drop unencrypted */
> - ic->ic_stats.is_rx_unencrypted++;
> - return NULL;
> + /*
> +  * If the protected bit is clear then hardware has
> +  * stripped the IV and we must trust that it handles
> +  * replay detection correctly.
> +  */
> + break;
>   }
>   if (ieee80211_ccmp_get_pn(, , m, k) != 0)
>   return NULL;
> @@ -200,9 +203,12 @@ ieee80211_input_hwdecrypt(struct ieee80211com *ic, str
>   break;
>case IEEE80211_CIPHER_TKIP:
>   if (!(wh->i_fc[1] & IEEE80211_FC1_PROTECTED)) {
> - /* drop unencrypted */
> - ic->ic_stats.is_rx_unencrypted++;
> - return NULL;
> + /*
> +  * If the protected bit is clear then hardware has
> +  * stripped the IV and we must trust that it handles
> +  * replay detection correctly.
> +  */
> + break;
>   }
>   if (ieee80211_tkip_get_tsc(, , m, k) != 0)
>   return NULL;

Re: lockspool getting killed by pledge on OpenBSD 6.7

[Bob Beck]

On Mon, May 25, 2020 at 04:15:24PM -0600, Todd C. Miller wrote:
> On Mon, 25 May 2020 16:04:25 -0600, Bob Beck wrote:
> 
> > getlock()'s behaviour changes in the case of a writeable mail spool. if we 
> > want to keep supporting this, I we can modify the pledge as follows:
> 
> I thought we decided not to adjust the pledge when I brought it up
> last time.  Here's the diff I had in my tree to remove support for
> world-writable spool dirs.

Indeed, not supporting a world writable spool is the other option ;)

> 
>  - todd
> 
> Index: libexec/mail.local/locking.c
> ===
> RCS file: /cvs/src/libexec/mail.local/locking.c,v
> retrieving revision 1.14
> diff -u -p -u -r1.14 locking.c
> --- libexec/mail.local/locking.c  9 Feb 2020 14:59:20 -   1.14
> +++ libexec/mail.local/locking.c  9 Feb 2020 15:07:22 -
> @@ -33,7 +33,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -57,9 +56,8 @@ rellock(void)
>  int
>  getlock(const char *name, struct passwd *pw)
>  {
> - struct stat sb, fsb;
> + struct stat sb;
>   int lfd=-1;
> - char buf[8*1024];
>   int tries = 0;
>  
>   (void)snprintf(lpath, sizeof lpath, "%s/%s.lock",
> @@ -67,58 +65,8 @@ getlock(const char *name, struct passwd 
>  
>   if (stat(_PATH_MAILDIR, ) != -1 &&
>   (sb.st_mode & S_IWOTH) == S_IWOTH) {
> - /*
> -  * We have a writeable spool, deal with it as
> -  * securely as possible.
> -  */
> - time_t ctim = -1;
> -
> - seteuid(pw->pw_uid);
> - if (lstat(lpath, ) != -1)
> - ctim = sb.st_ctime;
> - while (1) {
> - /*
> -  * Deal with existing user.lock files
> -  * or directories or symbolic links that
> -  * should not be here.
> -  */
> - if (readlink(lpath, buf, sizeof buf-1) != -1) {
> - if (lstat(lpath, ) != -1 &&
> - S_ISLNK(sb.st_mode)) {
> - seteuid(sb.st_uid);
> - unlink(lpath);
> - seteuid(pw->pw_uid);
> - }
> - goto again;
> - }
> - if ((lfd = open(lpath, O_CREAT|O_WRONLY|O_EXCL|O_EXLOCK,
> - S_IRUSR|S_IWUSR)) != -1)
> - break;
> -again:
> - if (tries > 10) {
> - mwarn("%s: %s", lpath, strerror(errno));
> - seteuid(0);
> - return(-1);
> - }
> - if (tries > 9 &&
> - (lfd = open(lpath, O_WRONLY|O_EXLOCK, 0)) != -1) {
> - if (fstat(lfd, ) != -1 &&
> - lstat(lpath, ) != -1) {
> - if (fsb.st_dev == sb.st_dev &&
> - fsb.st_ino == sb.st_ino &&
> - ctim == fsb.st_ctime ) {
> - seteuid(fsb.st_uid);
> - baditem(lpath);
> - seteuid(pw->pw_uid);
> - }
> - }
> - close(lfd);
> - }
> - sleep(1U << tries);
> - tries++;
> - continue;
> - }
> - seteuid(0);
> + mwarn("%s: will not deliver to world-writable spool",
> + _PATH_MAILDIR);
>   } else {
>   /*
>* Only root can write the spool directory.
> @@ -136,25 +84,6 @@ again:
>   }
>   }
>   return(lfd);
> -}
> -
> -void
> -baditem(char *path)
> -{
> - char npath[PATH_MAX];
> - int fd;
> -
> - if (unlink(path) == 0)
> - return;
> - snprintf(npath, sizeof npath, "%s/mailXX", _PATH_MAILDIR);
> - if ((fd = mkstemp(npath)) == -1)
> - return;
> - close(fd);
> - if (rename(path, npath) == -1)
> - unlink(npath);
> - else
> - mwarn("nasty spool item %s renamed to %s", path, npath);
> - /* XXX if we fail to rename, another attempt will happen later */
>  }
>  
>  void
> Index: libexec/mail.local/mail.local.8
> ===
> RCS file: /cvs/src/libexec/mail.local/mail.local.8,v
> retrieving revision 1.31
> diff -u -p -u -r1.31 mail.local.8
> --- libexec/mail.local/mail.local.8   16 Sep 2014 21:28:51 -  1.31
> +++ 

Re: lockspool getting killed by pledge on OpenBSD 6.7

[Todd C . Miller]

On Mon, 25 May 2020 16:04:25 -0600, Bob Beck wrote:

> getlock()'s behaviour changes in the case of a writeable mail spool. if we 
> want to keep supporting this, I we can modify the pledge as follows:

I thought we decided not to adjust the pledge when I brought it up
last time.  Here's the diff I had in my tree to remove support for
world-writable spool dirs.

 - todd

Index: libexec/mail.local/locking.c
===
RCS file: /cvs/src/libexec/mail.local/locking.c,v
retrieving revision 1.14
diff -u -p -u -r1.14 locking.c
--- libexec/mail.local/locking.c9 Feb 2020 14:59:20 -   1.14
+++ libexec/mail.local/locking.c9 Feb 2020 15:07:22 -
@@ -33,7 +33,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -57,9 +56,8 @@ rellock(void)
 int
 getlock(const char *name, struct passwd *pw)
 {
-   struct stat sb, fsb;
+   struct stat sb;
int lfd=-1;
-   char buf[8*1024];
int tries = 0;
 
(void)snprintf(lpath, sizeof lpath, "%s/%s.lock",
@@ -67,58 +65,8 @@ getlock(const char *name, struct passwd 
 
if (stat(_PATH_MAILDIR, ) != -1 &&
(sb.st_mode & S_IWOTH) == S_IWOTH) {
-   /*
-* We have a writeable spool, deal with it as
-* securely as possible.
-*/
-   time_t ctim = -1;
-
-   seteuid(pw->pw_uid);
-   if (lstat(lpath, ) != -1)
-   ctim = sb.st_ctime;
-   while (1) {
-   /*
-* Deal with existing user.lock files
-* or directories or symbolic links that
-* should not be here.
-*/
-   if (readlink(lpath, buf, sizeof buf-1) != -1) {
-   if (lstat(lpath, ) != -1 &&
-   S_ISLNK(sb.st_mode)) {
-   seteuid(sb.st_uid);
-   unlink(lpath);
-   seteuid(pw->pw_uid);
-   }
-   goto again;
-   }
-   if ((lfd = open(lpath, O_CREAT|O_WRONLY|O_EXCL|O_EXLOCK,
-   S_IRUSR|S_IWUSR)) != -1)
-   break;
-again:
-   if (tries > 10) {
-   mwarn("%s: %s", lpath, strerror(errno));
-   seteuid(0);
-   return(-1);
-   }
-   if (tries > 9 &&
-   (lfd = open(lpath, O_WRONLY|O_EXLOCK, 0)) != -1) {
-   if (fstat(lfd, ) != -1 &&
-   lstat(lpath, ) != -1) {
-   if (fsb.st_dev == sb.st_dev &&
-   fsb.st_ino == sb.st_ino &&
-   ctim == fsb.st_ctime ) {
-   seteuid(fsb.st_uid);
-   baditem(lpath);
-   seteuid(pw->pw_uid);
-   }
-   }
-   close(lfd);
-   }
-   sleep(1U << tries);
-   tries++;
-   continue;
-   }
-   seteuid(0);
+   mwarn("%s: will not deliver to world-writable spool",
+   _PATH_MAILDIR);
} else {
/*
 * Only root can write the spool directory.
@@ -136,25 +84,6 @@ again:
}
}
return(lfd);
-}
-
-void
-baditem(char *path)
-{
-   char npath[PATH_MAX];
-   int fd;
-
-   if (unlink(path) == 0)
-   return;
-   snprintf(npath, sizeof npath, "%s/mailXX", _PATH_MAILDIR);
-   if ((fd = mkstemp(npath)) == -1)
-   return;
-   close(fd);
-   if (rename(path, npath) == -1)
-   unlink(npath);
-   else
-   mwarn("nasty spool item %s renamed to %s", path, npath);
-   /* XXX if we fail to rename, another attempt will happen later */
 }
 
 void
Index: libexec/mail.local/mail.local.8
===
RCS file: /cvs/src/libexec/mail.local/mail.local.8,v
retrieving revision 1.31
diff -u -p -u -r1.31 mail.local.8
--- libexec/mail.local/mail.local.8 16 Sep 2014 21:28:51 -  1.31
+++ libexec/mail.local/mail.local.8 9 Feb 2020 15:18:48 -
@@ -77,19 +77,18 @@ is prepended to any line in the message 
 .Dq "From\&\ "
 delimiter line.
 .Pp
-Significant efforts have been made to ensure that
+Significant effort has been made 

Re: lockspool getting killed by pledge on OpenBSD 6.7

[Bob Beck]

On Mon, May 25, 2020 at 04:05:47PM -0600, Theo de Raadt wrote:
> > +   if (pledge("id flock stdio rpath wpath getpw cpath fattr", NULL) == 
> > -1)
> 
> Please wait for other pledge people to respond.
> 
> But re-order.  Add the new things to the end.
> 
Ack

Re: lockspool getting killed by pledge on OpenBSD 6.7

[Theo de Raadt]

> +   if (pledge("id flock stdio rpath wpath getpw cpath fattr", NULL) == 
> -1)

Please wait for other pledge people to respond.

But re-order.  Add the new things to the end.

Re: lockspool getting killed by pledge on OpenBSD 6.7

[Bob Beck]

On Mon, May 25, 2020 at 11:07:12PM +0200, Dawid Czelu??niak wrote:
> After changing permissions of /var/mail directory to 755:
> 
> $ chmod 755 /var/mail
> 
> everything is fine and seteuid(2) is not called:
>  92121 lockspool NAMI  "/var/mail/root.lock"
>  92121 lockspool RET   unlink 0
>  92121 lockspool CALL  kbind(0x7f7c7f58,24,0xefbb72852ff02523)
>  92121 lockspool RET   kbind 0
>  92121 lockspool CALL  exit(0)
> 
> Killing lockspool(1) by pledge(2) happens when permissions of /var/mail
> are greater than 755. Maybe it would be useful to give user an indication
> that it is the permission issue instead of killing the process by pledge?
> 
> What do you think?

You obviously have a non-default config for this, nevertheless, this is 
supposedly
a supported config according to getlock() which is actually living in 
mail.local's
sources. 

getlock()'s behaviour changes in the case of a writeable mail spool. if we 
want to keep supporting this, I we can modify the pledge as follows:

ok?

Index: lockspool.c
===
RCS file: /cvs/src/libexec/lockspool/lockspool.c,v
retrieving revision 1.21
diff -u -p -u -p -r1.21 lockspool.c
--- lockspool.c 9 Feb 2020 14:59:20 -   1.21
+++ lockspool.c 25 May 2020 22:01:13 -
@@ -55,7 +55,7 @@ main(int argc, char *argv[])
 
if (unveil(_PATH_MAILDIR, "rwc") == -1)
err(1, "unveil");
-   if (pledge("stdio rpath wpath getpw cpath fattr", NULL) == -1)
+   if (pledge("id flock stdio rpath wpath getpw cpath fattr", NULL) == -1)
err(1, "pledge");
 
openlog(__progname, LOG_PERROR, LOG_MAIL);

Re: athn(4): AR9287 instability

[stolen data]

On Sat, May 23, 2020 at 9:57 AM Stefan Sperling  wrote:

> On Fri, May 22, 2020 at 05:12:23PM +0200, stolen data wrote:
> > On Thu, May 21, 2020 at 9:11 AM Stefan Sperling  wrote:
> >
> > > On Thu, May 21, 2020 at 01:04:36AM +0200, stolen data wrote:
> > >
> > > ...
> > >
> >
> > > > >   You can try MCS1, MCS2, ..., all the way up to MCS15.
> > > >
> > > > Unfortunately no change. Some are unusable but none of them offer a
> > > > visible improvement.
> > >
> > > Oh. So they all have the exact same result?
> > >
> >
> > None of MCS0-15 can reach beyond 1200 Kbit/s and some are exceptionally
> > unstable; 5-7 and 13-15 (with emphasis on 7 and 15) are so shaky that
> > the speed drops below 50 Kbit/s and sometimes cause the entire link to
> > choke and drop out. Across the range it seems to be best at 0/8 and
> > degrade towards 7/15. I can't see any difference between the lower and
> > upper range, and autoselect overall seems to work out better over time
> > despite still being very jumpy.
> >
>
> On AR9280 OpenBSD athn(4) will easily do 10 Mbit/s under good conditions,
> if not more. Which is fairly bad given what the hardware is capable of.
> But not nearly as bad as what you're seeing.
>
> It really sounds like a case where someone with AR9287 hardware in front
> of them will need to debug the driver.
>
> Recording packet captures with another device in monitor mode might be
> worth doing just to see if it sheds some light on the problem.
>

Would you be able to instruct me in how to capture traffic for this
particular scenario? Assuming a packet dump from my end would be of
any help that is.

If none of the developers have an AR9287 available I will gladly lend
this card for that purpose, granted that whoever receives it is OK
with returning it afterwards. I'll pay shipping both ways of course.

Re: lockspool getting killed by pledge on OpenBSD 6.7

[Dawid Czeluśniak]

After changing permissions of /var/mail directory to 755:

$ chmod 755 /var/mail

everything is fine and seteuid(2) is not called:
 92121 lockspool NAMI  "/var/mail/root.lock"
 92121 lockspool RET   unlink 0
 92121 lockspool CALL  kbind(0x7f7c7f58,24,0xefbb72852ff02523)
 92121 lockspool RET   kbind 0
 92121 lockspool CALL  exit(0)

Killing lockspool(1) by pledge(2) happens when permissions of /var/mail
are greater than 755. Maybe it would be useful to give user an indication
that it is the permission issue instead of killing the process by pledge?

What do you think?

lockspool getting killed by pledge on OpenBSD 6.7

[Dawid Czeluśniak]

Hi,

I noticed that when I try to run /usr/libexec/lockspool directly as root
I'm getting Abort trap on my machine:

$ /usr/libexec/lockspool
Abort trap
$ echo $?
134

And in dmesg I can see plenty of pledge logs:
lockspool[73511]: pledge "id", syscall 183
lockspool[94755]: pledge "id", syscall 183
lockspool[38910]: pledge "id", syscall 183

1. Is this reproducible on your end?
2. Is "id" pledge request missing here?
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/libexec/lockspool/lockspool.c?rev=1.21

Latest kdump:
   919 lockspool RET   stat 0
   919 lockspool CALL  kbind(0x7f7cb278,24,0xc70598ce16a08728)
   919 lockspool RET   kbind 0
   919 lockspool CALL  seteuid(0<"root">)
   919 lockspool PLDG  seteuid, "id", errno 1 Operation not permitted
   919 lockspool PSIG  SIGABRT SIG_DFL code <74513776>

Seems like seteuid(2) is called...

Dawid

Re: sysupgrade lives in 2021

[Sebastian Benoit]

Kevin Chadwick(m8il1i...@gmail.com) on 2020.05.25 11:57:44 +:
> . did you ever saw something like this? for instance when you
> >want to upgrade java, is says: open-jre 14 does not exist.
> >
> 
> I'm not an OpenBSD dev but are you asking for a more user friendly message
> ratter than a more pertinent one? Seems reasonable, but when I got that
> message. I actually wanted to upgrade to a snapshot and this messsge
> helped. I might have wanted to switch from snaps to release. Not sure that
> switch is supported

"Upgrades are supported, from one release to the next (read upgradeXX.html)"

However, we obviously also allow for upgrades from a snapshot to a later one.
And snapshots are identical with an upcoming release once every six months.

It follows that you can upgrade from a snapshot to the next release after
it.

And you can do that with sysupgrade. Just run sysupgrade -r (when the next
release is available of course).

If you run snapshots, it is implied that you know at what point in the
development cycle the snapshot is from. And when we are close to a release.
The only thing you have to watch out for is to know which parts of
faq/current.html (or upgradeXX.html) apply to your case. 

Re: sysupgrade lives in 2021

[Theo de Raadt]

This conversation is finished.

Move along.


Andreas Kusalananda =?utf-8?B?S8OkaMOkcmk=?=  wrote:

> On Mon, May 25, 2020 at 02:22:42PM +0100, Stuart Henderson wrote:
> > On 2020/05/25 14:46, Andreas Kusalananda Kähäri wrote:
> > > On Mon, May 25, 2020 at 12:26:25PM +, abed wrote:
> > > > I'm expecting when the 6.8 dosen't exist, we have to show a message not
> > > > an error (404 not found )!!!
> > > > 
> > > > On 5/25/20 12:21 PM, Stuart Henderson wrote:
> > > > > On 2020/05/25 11:33, abed wrote:
> > > > >> After installing OpenBSD 6.7 (i mean exactly after that without 
> > > > >> touching
> > > > >> a thing). if you issue sysupgrade, it says: cant find version 6.8, 
> > > > >> which
> > > > >> is absolutely doesn't exist. I wondering is it really hard to firs 
> > > > >> check
> > > > >> the latest version when we heavily connected to the web from seconds 
> > > > >> we
> > > > >> boot or what?
> > > > > What would you do with the result of a check like this? Do you think 
> > > > > the
> > > > > error message is unclear?
> > > > >
> > > > > (sysupgrade follows the supported upgrade path - upgrading to the 
> > > > > _next_
> > > > > release, or a snapshot - not the _latest_ release which might involve
> > > > > skipping a version).
> > > > >
> > > 
> > > 
> > > Abed has a point here.  When trying to upgrade to a newer *snapshot*
> > > when no new snapshot is available, the message is "Already on latest
> > > snapshot."  There would potentially be a point in instead of showing
> > > 
> > > Fetching from https://cdn.openbsd.org/pub/OpenBSD/6.8/amd64/
> > > sysupgrade: Error retrieving 
> > > https://cdn.openbsd.org/pub/OpenBSD/6.8/amd64/SHA256.sig: 404 Not Found
> > > 
> > > saying "The next release after $(uname -r) is not available" or
> > > something similar.
> > 
> > It could, but then you lose information which might be important if the new
> > version *has* been released but the chosen mirror doesn't have it or is 
> > having
> > some problem.
> 
> When upgrading to a new snapshot, the "Fetching from ..." etc. is still
> shown. It may be enough with adding a small additional explanaiton of
> the failure of fetching the release signature as per my previous mail.
> That way, moving between snapshots and to the next release would produce
> similar output.
> 
> That is, when the next release is not available:
> 
> Fetching from https://cdn.openbsd.org/pub/OpenBSD/6.8/amd64/
> sysupgrade: Error retrieving 
> https://cdn.openbsd.org/pub/OpenBSD/6.8/amd64/SHA256.sig: 404 Not Found
> The next release is not avaiable.
> 
> 
> 
> -- 
> Andreas (Kusalananda) Kähäri
> SciLifeLab, NBIS, ICM
> Uppsala University, Sweden
> 
> .
> 

Re: sysupgrade lives in 2021

[Andreas Kusalananda Kähäri]

On Mon, May 25, 2020 at 02:22:42PM +0100, Stuart Henderson wrote:
> On 2020/05/25 14:46, Andreas Kusalananda Kähäri wrote:
> > On Mon, May 25, 2020 at 12:26:25PM +, abed wrote:
> > > I'm expecting when the 6.8 dosen't exist, we have to show a message not
> > > an error (404 not found )!!!
> > > 
> > > On 5/25/20 12:21 PM, Stuart Henderson wrote:
> > > > On 2020/05/25 11:33, abed wrote:
> > > >> After installing OpenBSD 6.7 (i mean exactly after that without 
> > > >> touching
> > > >> a thing). if you issue sysupgrade, it says: cant find version 6.8, 
> > > >> which
> > > >> is absolutely doesn't exist. I wondering is it really hard to firs 
> > > >> check
> > > >> the latest version when we heavily connected to the web from seconds we
> > > >> boot or what?
> > > > What would you do with the result of a check like this? Do you think the
> > > > error message is unclear?
> > > >
> > > > (sysupgrade follows the supported upgrade path - upgrading to the _next_
> > > > release, or a snapshot - not the _latest_ release which might involve
> > > > skipping a version).
> > > >
> > 
> > 
> > Abed has a point here.  When trying to upgrade to a newer *snapshot*
> > when no new snapshot is available, the message is "Already on latest
> > snapshot."  There would potentially be a point in instead of showing
> > 
> > Fetching from https://cdn.openbsd.org/pub/OpenBSD/6.8/amd64/
> > sysupgrade: Error retrieving 
> > https://cdn.openbsd.org/pub/OpenBSD/6.8/amd64/SHA256.sig: 404 Not Found
> > 
> > saying "The next release after $(uname -r) is not available" or
> > something similar.
> 
> It could, but then you lose information which might be important if the new
> version *has* been released but the chosen mirror doesn't have it or is having
> some problem.

When upgrading to a new snapshot, the "Fetching from ..." etc. is still
shown. It may be enough with adding a small additional explanaiton of
the failure of fetching the release signature as per my previous mail.
That way, moving between snapshots and to the next release would produce
similar output.

That is, when the next release is not available:

Fetching from https://cdn.openbsd.org/pub/OpenBSD/6.8/amd64/
sysupgrade: Error retrieving 
https://cdn.openbsd.org/pub/OpenBSD/6.8/amd64/SHA256.sig: 404 Not Found
The next release is not avaiable.



-- 
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden

.

Re: sysupgrade lives in 2021

[Renaud Allard]

On 5/25/20 1:57 PM, Kevin Chadwick wrote:

. did you ever saw something like this? for instance when you

want to upgrade java, is says: open-jre 14 does not exist.



I'm not an OpenBSD dev but are you asking for a more user friendly message 
ratter than a more pertinent one? Seems reasonable, but when I got that 
message. I actually wanted to upgrade to a snapshot and this messsge helped. I 
might have wanted to switch from snaps to release. Not sure that switch is 
supported but I may find the accurate message helpful there too.

Better than Windows hex code, atleast 



You can always modify /usr/sbin/sysupgrade which is a shell script and 
set NEXT_VERSION to whatever you want. Just be aware that this is 
unsupported at best.




smime.p7s
Description: S/MIME Cryptographic Signature

Re: X hangs

[Visa Hankala]

I have reverted the patch. Let's see if I could somehow reproduce
the problem myself so I can study it.


On Mon, May 25, 2020 at 03:21:01PM +0100, Stuart Henderson wrote:
> visa pointed me at sys/kern/kern_event.c r1.132 as a possibility -
> I reverted that yesterday and haven't seen the system hang yet.
> That's not conclusive but considering how things were going before,
> I think it would have happened by now.
> 
> 
> On 2020/05/23 23:41, Stuart Henderson wrote:
> > I have some hangs with my main workstation running -current if I'm
> > running X. I've seen it a couple of times in a day - unsure of anything
> > in particular that triggers it (I thought maybe browser-related but
> > I've seen it while not actively using a browser too). When it happens
> > I can't access DDB via BREAK, and there's nothing on the console
> > from an MP_LOCKDEBUG kernel. Nothing stands out with WITNESS either
> > (vmmaplk/inode lock order reversal during boot after attaching root,
> > but I don't think that's unusual).
> > 
> > I haven't triggered it if X is not running. I've now installed 6.7-release
> > files over the top and haven't triggered it yet with that either (12h
> > uptime on that now - I was lucky if it got to 3 or 4 hours before).
> > (The last couple of times I did trigger it, fsck had to work quite hard
> > afterwards).
> > 
> > Any ideas where to poke or of any suspicious commits? I had a look
> > through the post-6.7 history but nothing stood out. The window of when
> > it started in snapshots seems to be between release and something like
> > GENERIC.MP #201: Tue May 19 18:18:29 MDT.
> > 
> > 
> > OpenBSD 6.7 (GENERIC.MP) #182: Thu May  7 11:11:58 MDT 2020
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > real mem = 34247069696 (32660MB)
> > avail mem = 33196531712 (31658MB)
> > mpath0 at root
> > scsibus0 at mpath0: 256 targets
> > mainbus0 at root
> > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec400 (92 entries)
> > bios0: vendor Dell Inc. version "A12" date 05/11/2017
> > bios0: Dell Inc. PowerEdge T20
> > acpi0 at bios0: ACPI 5.0
> > acpi0: sleep states S0 S4 S5
> > acpi0: tables DSDT FACP APIC FPDT SLIC LPIT SSDT SSDT SSDT HPET SSDT MCFG 
> > SSDT ASF! DMAR
> > acpi0: wakeup devices UAR1(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) PXSX(S4) 
> > RP05(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S3) EHC2(S3) 
> > XHC_(S4) 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) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3392.66 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,SMX,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,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,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) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3392.16 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,SMX,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,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,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 4 (application processor)
> > cpu2: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3392.16 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,SMX,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,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> > cpu2: 256KB 64b/line 8-way L2 cache
> > cpu2: smt 0, core 2, package 0
> > cpu3 at mainbus0: apid 6 (application processor)
> > cpu3: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3392.16 MHz, 06-3c-03
> > cpu3: 
> > 

Re: X hangs

[Stuart Henderson]

visa pointed me at sys/kern/kern_event.c r1.132 as a possibility -
I reverted that yesterday and haven't seen the system hang yet.
That's not conclusive but considering how things were going before,
I think it would have happened by now.


On 2020/05/23 23:41, Stuart Henderson wrote:
> I have some hangs with my main workstation running -current if I'm
> running X. I've seen it a couple of times in a day - unsure of anything
> in particular that triggers it (I thought maybe browser-related but
> I've seen it while not actively using a browser too). When it happens
> I can't access DDB via BREAK, and there's nothing on the console
> from an MP_LOCKDEBUG kernel. Nothing stands out with WITNESS either
> (vmmaplk/inode lock order reversal during boot after attaching root,
> but I don't think that's unusual).
> 
> I haven't triggered it if X is not running. I've now installed 6.7-release
> files over the top and haven't triggered it yet with that either (12h
> uptime on that now - I was lucky if it got to 3 or 4 hours before).
> (The last couple of times I did trigger it, fsck had to work quite hard
> afterwards).
> 
> Any ideas where to poke or of any suspicious commits? I had a look
> through the post-6.7 history but nothing stood out. The window of when
> it started in snapshots seems to be between release and something like
> GENERIC.MP #201: Tue May 19 18:18:29 MDT.
> 
> 
> OpenBSD 6.7 (GENERIC.MP) #182: Thu May  7 11:11:58 MDT 2020
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 34247069696 (32660MB)
> avail mem = 33196531712 (31658MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec400 (92 entries)
> bios0: vendor Dell Inc. version "A12" date 05/11/2017
> bios0: Dell Inc. PowerEdge T20
> acpi0 at bios0: ACPI 5.0
> acpi0: sleep states S0 S4 S5
> acpi0: tables DSDT FACP APIC FPDT SLIC LPIT SSDT SSDT SSDT HPET SSDT MCFG 
> SSDT ASF! DMAR
> acpi0: wakeup devices UAR1(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) PXSX(S4) 
> RP05(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S3) EHC2(S3) 
> XHC_(S4) 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) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3392.66 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,SMX,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,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,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) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3392.16 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,SMX,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,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,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 4 (application processor)
> cpu2: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3392.16 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,SMX,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,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> cpu2: 256KB 64b/line 8-way L2 cache
> cpu2: smt 0, core 2, package 0
> cpu3 at mainbus0: apid 6 (application processor)
> cpu3: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3392.16 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,SMX,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,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> cpu3: 256KB 64b/line 8-way L2 cache
> cpu3: smt 0, core 3, package 0
> ioapic0 at mainbus0: apid 8 pa 0xfec0, 

Re: sysupgrade lives in 2021

[abed]

Yes that right, but how but to make convenience for everybody at least
once? everybody can change the script but i talked about something higher.

On 5/25/20 1:19 PM, Peter N. M. Hansteen wrote:
> On Mon, May 25, 2020 at 01:07:23PM +, abed wrote:
>> How about if next version doesn't exist?
> Please read the previous answers and the sysupgrade man page, or for that 
> matter /usr/sbin/sysupgrade itself - it's a very readable shell script.
>
> OpenBSD 6.8 does not exist yet. sysupgrade told you so, based on checking 
> the $NEXT_VERSION directory on the preferred mirror. If you expected something
> else to happen, you need to adjust that expectation, plain and simple.
>
>

Re: sysupgrade lives in 2021

[abed]

yes, this is exactly what we call a program, we to check them all. if
exist or not. if we mirror is visible or not. if exist but corrupted. so
we need a common criteria.

On 5/25/20 1:22 PM, Stuart Henderson wrote:
> On 2020/05/25 14:46, Andreas Kusalananda Kähäri wrote:
>> On Mon, May 25, 2020 at 12:26:25PM +, abed wrote:
>>> I'm expecting when the 6.8 dosen't exist, we have to show a message not
>>> an error (404 not found )!!!
>>>
>>> On 5/25/20 12:21 PM, Stuart Henderson wrote:
 On 2020/05/25 11:33, abed wrote:
> After installing OpenBSD 6.7 (i mean exactly after that without touching
> a thing). if you issue sysupgrade, it says: cant find version 6.8, which
> is absolutely doesn't exist. I wondering is it really hard to firs check
> the latest version when we heavily connected to the web from seconds we
> boot or what?
 What would you do with the result of a check like this? Do you think the
 error message is unclear?

 (sysupgrade follows the supported upgrade path - upgrading to the _next_
 release, or a snapshot - not the _latest_ release which might involve
 skipping a version).

>>
>> Abed has a point here.  When trying to upgrade to a newer *snapshot*
>> when no new snapshot is available, the message is "Already on latest
>> snapshot."  There would potentially be a point in instead of showing
>>
>> Fetching from https://cdn.openbsd.org/pub/OpenBSD/6.8/amd64/
>> sysupgrade: Error retrieving 
>> https://cdn.openbsd.org/pub/OpenBSD/6.8/amd64/SHA256.sig: 404 Not Found
>>
>> saying "The next release after $(uname -r) is not available" or
>> something similar.
> It could, but then you lose information which might be important if the new
> version *has* been released but the chosen mirror doesn't have it or is having
> some problem.
>

Re: sysupgrade lives in 2021

[Stuart Henderson]

On 2020/05/25 14:46, Andreas Kusalananda Kähäri wrote:
> On Mon, May 25, 2020 at 12:26:25PM +, abed wrote:
> > I'm expecting when the 6.8 dosen't exist, we have to show a message not
> > an error (404 not found )!!!
> > 
> > On 5/25/20 12:21 PM, Stuart Henderson wrote:
> > > On 2020/05/25 11:33, abed wrote:
> > >> After installing OpenBSD 6.7 (i mean exactly after that without touching
> > >> a thing). if you issue sysupgrade, it says: cant find version 6.8, which
> > >> is absolutely doesn't exist. I wondering is it really hard to firs check
> > >> the latest version when we heavily connected to the web from seconds we
> > >> boot or what?
> > > What would you do with the result of a check like this? Do you think the
> > > error message is unclear?
> > >
> > > (sysupgrade follows the supported upgrade path - upgrading to the _next_
> > > release, or a snapshot - not the _latest_ release which might involve
> > > skipping a version).
> > >
> 
> 
> Abed has a point here.  When trying to upgrade to a newer *snapshot*
> when no new snapshot is available, the message is "Already on latest
> snapshot."  There would potentially be a point in instead of showing
> 
> Fetching from https://cdn.openbsd.org/pub/OpenBSD/6.8/amd64/
> sysupgrade: Error retrieving 
> https://cdn.openbsd.org/pub/OpenBSD/6.8/amd64/SHA256.sig: 404 Not Found
> 
> saying "The next release after $(uname -r) is not available" or
> something similar.

It could, but then you lose information which might be important if the new
version *has* been released but the chosen mirror doesn't have it or is having
some problem.

Re: sysupgrade lives in 2021

[Peter N. M. Hansteen]

On Mon, May 25, 2020 at 01:07:23PM +, abed wrote:
> How about if next version doesn't exist?

Please read the previous answers and the sysupgrade man page, or for that 
matter /usr/sbin/sysupgrade itself - it's a very readable shell script.

OpenBSD 6.8 does not exist yet. sysupgrade told you so, based on checking 
the $NEXT_VERSION directory on the preferred mirror. If you expected something
else to happen, you need to adjust that expectation, plain and simple.


-- 
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: sysupgrade lives in 2021

[abed]

Yeah exactly, finally somebody got the point!!!

On 5/25/20 12:46 PM, Andreas Kusalananda Kähäri wrote:
> On Mon, May 25, 2020 at 12:26:25PM +, abed wrote:
>> I'm expecting when the 6.8 dosen't exist, we have to show a message not
>> an error (404 not found )!!!
>>
>> On 5/25/20 12:21 PM, Stuart Henderson wrote:
>>> On 2020/05/25 11:33, abed wrote:
 After installing OpenBSD 6.7 (i mean exactly after that without touching
 a thing). if you issue sysupgrade, it says: cant find version 6.8, which
 is absolutely doesn't exist. I wondering is it really hard to firs check
 the latest version when we heavily connected to the web from seconds we
 boot or what?
>>> What would you do with the result of a check like this? Do you think the
>>> error message is unclear?
>>>
>>> (sysupgrade follows the supported upgrade path - upgrading to the _next_
>>> release, or a snapshot - not the _latest_ release which might involve
>>> skipping a version).
>>>
>
> Abed has a point here.  When trying to upgrade to a newer *snapshot*
> when no new snapshot is available, the message is "Already on latest
> snapshot."  There would potentially be a point in instead of showing
>
> Fetching from https://cdn.openbsd.org/pub/OpenBSD/6.8/amd64/
> sysupgrade: Error retrieving 
> https://cdn.openbsd.org/pub/OpenBSD/6.8/amd64/SHA256.sig: 404 Not Found
>
> saying "The next release after $(uname -r) is not available" or
> something similar.
>

Re: sysupgrade lives in 2021

[abed]

How about if next version doesn't exist?

On 5/25/20 12:42 PM, Peter N. M. Hansteen wrote:
> On Mon, May 25, 2020 at 11:47:33AM +, abed wrote:
>> I'm exactly talking about the logic behind. basically it's not aware of
>> the latest version and only increments the minor (6.7+0.1) and try to
>> download. did you ever saw something like this? for instance when you
>> want to upgrade java, is says: open-jre 14 does not exist.
> The OpenBSD versioning convention is to increment by 0.1 for each release.
> sysupgrade looks for the next version (unless, of course you are upgrading
> snapshot to snapshot, but do read the man page for that special case). 
>
> sysupgrade is working as designed, and ended up demonstrating to (I assume) a
> new user how OpenBSD release versions work.
>

Re: sysupgrade lives in 2021

[Andreas Kusalananda Kähäri]

On Mon, May 25, 2020 at 12:26:25PM +, abed wrote:
> I'm expecting when the 6.8 dosen't exist, we have to show a message not
> an error (404 not found )!!!
> 
> On 5/25/20 12:21 PM, Stuart Henderson wrote:
> > On 2020/05/25 11:33, abed wrote:
> >> After installing OpenBSD 6.7 (i mean exactly after that without touching
> >> a thing). if you issue sysupgrade, it says: cant find version 6.8, which
> >> is absolutely doesn't exist. I wondering is it really hard to firs check
> >> the latest version when we heavily connected to the web from seconds we
> >> boot or what?
> > What would you do with the result of a check like this? Do you think the
> > error message is unclear?
> >
> > (sysupgrade follows the supported upgrade path - upgrading to the _next_
> > release, or a snapshot - not the _latest_ release which might involve
> > skipping a version).
> >


Abed has a point here.  When trying to upgrade to a newer *snapshot*
when no new snapshot is available, the message is "Already on latest
snapshot."  There would potentially be a point in instead of showing

Fetching from https://cdn.openbsd.org/pub/OpenBSD/6.8/amd64/
sysupgrade: Error retrieving 
https://cdn.openbsd.org/pub/OpenBSD/6.8/amd64/SHA256.sig: 404 Not Found

saying "The next release after $(uname -r) is not available" or
something similar.

-- 
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden

.

Re: sysupgrade lives in 2021

[Peter N. M. Hansteen]

On Mon, May 25, 2020 at 11:47:33AM +, abed wrote:
> 
> I'm exactly talking about the logic behind. basically it's not aware of
> the latest version and only increments the minor (6.7+0.1) and try to
> download. did you ever saw something like this? for instance when you
> want to upgrade java, is says: open-jre 14 does not exist.

The OpenBSD versioning convention is to increment by 0.1 for each release.
sysupgrade looks for the next version (unless, of course you are upgrading
snapshot to snapshot, but do read the man page for that special case). 

sysupgrade is working as designed, and ended up demonstrating to (I assume) a
new user how OpenBSD release versions work.

-- 
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: sysupgrade lives in 2021

[Martijn van Duren]

$ man sysupgrade | grep -i smart
$

I see no such promise.

On Mon, 2020-05-25 at 12:07 +, abed wrote:
> OK, but it supposed to be more smart !!!
> 
> On 5/25/20 12:02 PM, Renaud Allard wrote:
> > 
> > On 5/25/20 1:57 PM, Kevin Chadwick wrote:
> > > . did you ever saw something like this? for instance when you
> > > > want to upgrade java, is says: open-jre 14 does not exist.
> > > > 
> > > 
> > > I'm not an OpenBSD dev but are you asking for a more user friendly
> > > message ratter than a more pertinent one? Seems reasonable, but when
> > > I got that message. I actually wanted to upgrade to a snapshot and
> > > this messsge helped. I might have wanted to switch from snaps to
> > > release. Not sure that switch is supported but I may find the
> > > accurate message helpful there too.
> > > 
> > > Better than Windows hex code, atleast 
> > > 
> > 
> > You can always modify /usr/sbin/sysupgrade which is a shell script and
> > set NEXT_VERSION to whatever you want. Just be aware that this is
> > unsupported at best.
> > 

Re: sysupgrade lives in 2021

[abed]

I'm expecting when the 6.8 dosen't exist, we have to show a message not
an error (404 not found )!!!

On 5/25/20 12:21 PM, Stuart Henderson wrote:
> On 2020/05/25 11:33, abed wrote:
>> After installing OpenBSD 6.7 (i mean exactly after that without touching
>> a thing). if you issue sysupgrade, it says: cant find version 6.8, which
>> is absolutely doesn't exist. I wondering is it really hard to firs check
>> the latest version when we heavily connected to the web from seconds we
>> boot or what?
> What would you do with the result of a check like this? Do you think the
> error message is unclear?
>
> (sysupgrade follows the supported upgrade path - upgrading to the _next_
> release, or a snapshot - not the _latest_ release which might involve
> skipping a version).
>

Re: sysupgrade lives in 2021

[Stuart Henderson]

On 2020/05/25 11:33, abed wrote:
> 
> After installing OpenBSD 6.7 (i mean exactly after that without touching
> a thing). if you issue sysupgrade, it says: cant find version 6.8, which
> is absolutely doesn't exist. I wondering is it really hard to firs check
> the latest version when we heavily connected to the web from seconds we
> boot or what?

What would you do with the result of a check like this? Do you think the
error message is unclear?

(sysupgrade follows the supported upgrade path - upgrading to the _next_
release, or a snapshot - not the _latest_ release which might involve
skipping a version).

Re: sysupgrade lives in 2021

[abed]

OK, but it supposed to be more smart !!!

On 5/25/20 12:02 PM, Renaud Allard wrote:
>
>
> On 5/25/20 1:57 PM, Kevin Chadwick wrote:
>> . did you ever saw something like this? for instance when you
>>> want to upgrade java, is says: open-jre 14 does not exist.
>>>
>>
>> I'm not an OpenBSD dev but are you asking for a more user friendly
>> message ratter than a more pertinent one? Seems reasonable, but when
>> I got that message. I actually wanted to upgrade to a snapshot and
>> this messsge helped. I might have wanted to switch from snaps to
>> release. Not sure that switch is supported but I may find the
>> accurate message helpful there too.
>>
>> Better than Windows hex code, atleast 
>>
>
> You can always modify /usr/sbin/sysupgrade which is a shell script and
> set NEXT_VERSION to whatever you want. Just be aware that this is
> unsupported at best.
>

Re: sysupgrade lives in 2021

[abed]

I bet you didn't get the point. it's not about user friendly it's about
accuracy. if you want to write a script to check the repository you cant
find out the issue is about your connection or about anything else. yeah
also better than my bike!!

On 5/25/20 11:57 AM, Kevin Chadwick wrote:
> . did you ever saw something like this? for instance when you
>> want to upgrade java, is says: open-jre 14 does not exist.
>>
> I'm not an OpenBSD dev but are you asking for a more user friendly message 
> ratter than a more pertinent one? Seems reasonable, but when I got that 
> message. I actually wanted to upgrade to a snapshot and this messsge helped. 
> I might have wanted to switch from snaps to release. Not sure that switch is 
> supported but I may find the accurate message helpful there too.
>
> Better than Windows hex code, atleast 
>
>

Re: sysupgrade lives in 2021

[Kevin Chadwick]

. did you ever saw something like this? for instance when you
>want to upgrade java, is says: open-jre 14 does not exist.
>

I'm not an OpenBSD dev but are you asking for a more user friendly message 
ratter than a more pertinent one? Seems reasonable, but when I got that 
message. I actually wanted to upgrade to a snapshot and this messsge helped. I 
might have wanted to switch from snaps to release. Not sure that switch is 
supported but I may find the accurate message helpful there too.

Better than Windows hex code, atleast 

sysupgrade lives in 2021

[abed]

I'm exactly talking about the logic behind. basically it's not aware of
the latest version and only increments the minor (6.7+0.1) and try to
download. did you ever saw something like this? for instance when you
want to upgrade java, is says: open-jre 14 does not exist.

On 5/25/20 11:37 AM, Solene Rapenne wrote:
> Le Mon, 25 May 2020 11:33:10 +,
> abed  a écrit :
>
>> After installing OpenBSD 6.7 (i mean exactly after that without
>> touching a thing). if you issue sysupgrade, it says: cant find
>> version 6.8, which is absolutely doesn't exist. I wondering is it
>> really hard to firs check the latest version when we heavily
>> connected to the web from seconds we boot or what?
>>
> sysupgrade did exactly that, it looked for next release (6.8 in this
> case) on your mirror configured in /etc/installurl and told you it
> didn't find it.
>
>

Re: sysupgrade lives in 2021

[Solene Rapenne]

Le Mon, 25 May 2020 11:33:10 +,
abed  a écrit :

> After installing OpenBSD 6.7 (i mean exactly after that without
> touching a thing). if you issue sysupgrade, it says: cant find
> version 6.8, which is absolutely doesn't exist. I wondering is it
> really hard to firs check the latest version when we heavily
> connected to the web from seconds we boot or what?
> 

sysupgrade did exactly that, it looked for next release (6.8 in this
case) on your mirror configured in /etc/installurl and told you it
didn't find it.

sysupgrade lives in 2021

[abed]

After installing OpenBSD 6.7 (i mean exactly after that without touching
a thing). if you issue sysupgrade, it says: cant find version 6.8, which
is absolutely doesn't exist. I wondering is it really hard to firs check
the latest version when we heavily connected to the web from seconds we
boot or what?

Re: OpenBSD 6.7 crashes on APU2C4 with LTE modem Huawei E3372s-153 HiLink

[Martin Pieuchot]

On 25/05/20(Mon) 12:56, Gerhard Roth wrote:
> On 5/22/20 9:05 PM, Mark Kettenis wrote:
> > > From: Łukasz Lejtkowski 
> > > Date: Fri, 22 May 2020 20:51:57 +0200
> > > 
> > > Probably power supply 12 V is broken. Showing 16,87 V(Fluke 179) -
> > > too high. Should be 12,25-12,50 V. I replaced to the new one.
> > 
> > That might be why the device stops responding.  The fact that cleaning
> > up from a failed USB transaction leads to this panic is a bug though.
> > 
> > And somebody just posted a very similar panic with ure(4).  Something
> > in the network stack is holding a mutex when it shouldn't.
> 
> I think that holding the mutex is ok. The bug is calling the stop
> routine in case of errors.
> 
> This is what common foo_start() does:
> 
>   m_head = ifq_deq_begin(>if_snd);
>   if (foo_encap(sc, m_head, 0)) {
>   ifq_deq_rollback(>if_snd, m_head);
>   ...
>   return;
>   }
>   ifq_deq_commit(>if_snd, m_head);
> 
> Here, ifq_deq_begin() grabs a mutex and it is held while
> calling foo_encap().
> 
> For USB network interfaces foo_encap() mostly does this:
> 
>   err = usbd_transfer(sc->sc_xfer);
>   if (err != USBD_IN_PROGRESS) {
>   foo_stop(sc);
>   return EIO;
>   }
> 
> And foo_stop() calls usbd_abort_pipe() -> xhci_command_submit(),
> which might sleep.
> 
> How to fix? We could do the foo_encap() after the ifq_deq_commit(),
> possibly dropping the current mbuf if encap fails (who cares
> for the packets after foo_stop() anyway).

That's the approach taken by drivers using ifq_dequeue(9) instead of
ifq_deq_begin/commit().

> Or change all the drivers to follow the path that if_aue.c takes:
> 
>   err = usbd_transfer(c->aue_xfer);
>   if (err != USBD_IN_PROGRESS) {
>   ...
>   /* Stop the interface from process context. */
>   usb_add_task(sc->aue_udev, >aue_stop_task);
>   return (EIO);
>   }

That's just trading the current problem for another one with higher
complexity.

> Any ideas, what's better? Or alternative proposals?

Using ifq_dequeue(9) would have the advantage of unifying the code base.
It introduces a behavior change.  A simpler fix would be to call
foo_stop() in the error path after ifq_deq_rollback().

Re: OpenBSD 6.7 crashes on APU2C4 with LTE modem Huawei E3372s-153 HiLink

[Gerhard Roth]

On 5/22/20 9:05 PM, Mark Kettenis wrote:

From: Łukasz Lejtkowski 
Date: Fri, 22 May 2020 20:51:57 +0200

Probably power supply 12 V is broken. Showing 16,87 V(Fluke 179) -
too high. Should be 12,25-12,50 V. I replaced to the new one.


That might be why the device stops responding.  The fact that cleaning
up from a failed USB transaction leads to this panic is a bug though.

And somebody just posted a very similar panic with ure(4).  Something
in the network stack is holding a mutex when it shouldn't.


I think that holding the mutex is ok. The bug is calling the stop
routine in case of errors.

This is what common foo_start() does:

m_head = ifq_deq_begin(>if_snd);
if (foo_encap(sc, m_head, 0)) {
ifq_deq_rollback(>if_snd, m_head);
...
return;
}
ifq_deq_commit(>if_snd, m_head);

Here, ifq_deq_begin() grabs a mutex and it is held while
calling foo_encap().

For USB network interfaces foo_encap() mostly does this:

err = usbd_transfer(sc->sc_xfer);
if (err != USBD_IN_PROGRESS) {
foo_stop(sc);
return EIO;
}

And foo_stop() calls usbd_abort_pipe() -> xhci_command_submit(),
which might sleep.

How to fix? We could do the foo_encap() after the ifq_deq_commit(),
possibly dropping the current mbuf if encap fails (who cares
for the packets after foo_stop() anyway).

Or change all the drivers to follow the path that if_aue.c takes:

err = usbd_transfer(c->aue_xfer);
if (err != USBD_IN_PROGRESS) {
...
/* Stop the interface from process context. */
usb_add_task(sc->aue_udev, >aue_stop_task);
return (EIO);
}

Any ideas, what's better? Or alternative proposals?


Gerhard




On 22 May 2020, at 20:05, Łukasz Lejtkowski  wrote:

30 min ago… :/


OpenBSD/amd64 (master.bsdxxx.xx) (tty00)

login: panic: assertwaitok: non-zero mutex count: 1
Stopped at  db_enter+0x10:  popq%rbp
TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
db_enter() at db_enter+0x10
panic(81c882c4) at panic+0x128
assertwaitok() at assertwaitok+0xc7
mi_switch() at mi_switch+0x40
sleep_finish(8000225b8538,1) at sleep_finish+0x84
sleep_finish_all(8000225b8538,1) at sleep_finish_all+0x21
tsleep(800b1750,16,81c95c7d,33) at tsleep+0xd6
xhci_command_submit(8009c000,8000225b8628,1dcd6500) at xhci_command
_submit+0x13f
xhci_abort_xfer(fd812e90c780,6) at xhci_abort_xfer+0x13a
usbd_abort_pipe(8047b000) at usbd_abort_pipe+0x3d
cdce_stop(8012d000) at cdce_stop+0x46
cdce_encap(8012d000,fd80c0731d00,0) at cdce_encap+0xf7
cdce_start(8012d048) at cdce_start+0x84
if_qstart_compat(8012d2c0) at if_qstart_compat+0x2e
end trace frame: 0x8000225b8840, count: 0
https://www.openbsd.org/ddb.html describes the minimum info required in bug
reports.  Insufficient info makes it difficult to find and fix bugs.
ddb{2}>


On 22 May 2020, at 15:58, Łukasz Lejtkowski  wrote:

Hi everyone,

After a few hours OpenBSD 6.7 crashes to ddb> . Without a LTE modem OpenBSD 6.7 
works stable. Huawei E3372s-153 HiLink on OpenBSD 6.6 works perfectly, stable. 
Something wrong with USB, xHCI or cdce on OpenBSD 6.7 imho.

ddb{2}> show panic
assertwaitok: non-zero mutex count: 1

ddb{2}> trace
db_enter() at db_enter+0x10
panic(81c8ec25) at panic+0x128
assertwaitok() at assertwaitok+0xc7
mi_switch() at mi_switch+0x40
sleep_finish(8000225b8f88,1) at sleep_finish+0x84
sleep_finish_all(8000225b8f88,1) at sleep_finish_all+0x21
tsleep(800a5750,16,81c99248,33) at tsleep+0xd6
xhci_command_submit(8009,8000225b9078,1dcd6500) at xhci_command
_submit+0x13f
xhci_abort_xfer(fd811e918690,6) at xhci_abort_xfer+0x13a
usbd_abort_pipe(8045f000) at usbd_abort_pipe+0x3d
cdce_stop(80119000) at cdce_stop+0x46
cdce_encap(80119000,fd80df8b8400,0) at cdce_encap+0xf7
cdce_start(80119048) at cdce_start+0x84
if_qstart_compat(801192c0) at if_qstart_compat+0x2e
ifq_serialize(801192c0,80119390) at ifq_serialize+0x103
taskq_thread(800290c0) at taskq_thread+0x4d
end trace frame: 0x0, count: -16



PC Engines apu2
coreboot build 20202604
BIOS version v4.11.0.6
4080 MB ECC DRAM
SeaBIOS (version rel-1.12.1.3-0-g300e8b70)


root@master[~]usbdevs -v
Controller /dev/usb0:
addr 01: 1022: AMD, xHCI root hub
 super speed, self powered, config 1, rev 1.00
 driver: uhub0
addr 02: 12d1:14dc HUAWEI_MOBILE, HUAWEI_MOBILE
 high speed, self powered, config 1, rev 1.02
 driver: cdce0
 driver: umass0
Controller /dev/usb1:
addr 01: 1022: AMD, EHCI root hub
 high speed, self powered, config 1, rev 1.00
 driver: uhub1
addr 02: 0438:7900 Advanced Micro Devices, Hub
 high speed, self powered, config 1, rev 0.18
 driver: uhub2