I wanted to quickly generate a page for a database.
I haven't used this for years. I can't remember if it generated a full
list of columns for each table or not.
It had errors, but did produce a simple page.
The errors referred to the column 'adsrc' not existing.
I got the same error with another database I also have.
The HOMEPAGE and MASTER_SITES don't exist anymore.
https://github.com/cbbrowne/autodoc
Has an issue that the author passed away and continuing the project
hadn't been resolved.
https://aws-1.freshports.org/databases/postgresql_autodoc/
marked it as BROKEN
It's just a perl script.
Is anyone else having similar problems? Is anyone else using it?
Is there an alternative to this? I just wanted to get a single page
describing the database structure only.
I need to adapt my own software to this anyway, so I'll be solving the
problem for myself soon-ish.
I just wanted to report the problem.
Chris Bennett
Thursday, September 30, 2021
Re: OpenBSD Errata: September 30, 2021 (libressl)
On 2021-09-30, Sebastian Benoit <benoit-lists@fb12.de> wrote:
> An errata patch for LibreSSL has been released for OpenBSD 6.8 and
> OpenBSD 6.9.
>
> Compensate for the expiry of the DST Root X3 certificate. The use of an
> unnecessary expired certificate in certificate chains can cause validation
> errors.
>
> Binary updates for the amd64, i386 and arm64 platform are available
> via the syspatch utility. Source code patches can be found on the
> respective errata page:
>
> https://www.openbsd.org/errata68.html
> https://www.openbsd.org/errata69.html
>
>
Note: you may have issues fetching the syspatches from your regular
mirror due to this issue.
Try fetching it normally first, as a number of mirrors are either
unaffected, or have a workaround on the server side, but if that fails
you have two options:
- edit /etc/installurl to allow you to fetch the syspatches. Either
switch https to http (the updates are signed and verified anyway), or
use another mirror (including ftp.usa.openbsd.org, ftp.hostserver.de,
cdn.openbsd.org).
- locate the expired certificate in /etc/ssl/cert.pem and remove it, it
is the one with this in the header above:
=== /O=Digital Signature Trust Co./CN=DST Root CA X3
If you're able to install the syspatch anyway (syspatch69-018_cert.tgz
or syspatch68-032_cert.tgz) then you don't need either of the above
steps.
> An errata patch for LibreSSL has been released for OpenBSD 6.8 and
> OpenBSD 6.9.
>
> Compensate for the expiry of the DST Root X3 certificate. The use of an
> unnecessary expired certificate in certificate chains can cause validation
> errors.
>
> Binary updates for the amd64, i386 and arm64 platform are available
> via the syspatch utility. Source code patches can be found on the
> respective errata page:
>
> https://www.openbsd.org/errata68.html
> https://www.openbsd.org/errata69.html
>
>
Note: you may have issues fetching the syspatches from your regular
mirror due to this issue.
Try fetching it normally first, as a number of mirrors are either
unaffected, or have a workaround on the server side, but if that fails
you have two options:
- edit /etc/installurl to allow you to fetch the syspatches. Either
switch https to http (the updates are signed and verified anyway), or
use another mirror (including ftp.usa.openbsd.org, ftp.hostserver.de,
cdn.openbsd.org).
- locate the expired certificate in /etc/ssl/cert.pem and remove it, it
is the one with this in the header above:
=== /O=Digital Signature Trust Co./CN=DST Root CA X3
If you're able to install the syspatch anyway (syspatch69-018_cert.tgz
or syspatch68-032_cert.tgz) then you don't need either of the above
steps.
OpenBSD Errata: September 30, 2021 (libressl)
An errata patch for LibreSSL has been released for OpenBSD 6.8 and
OpenBSD 6.9.
Compensate for the expiry of the DST Root X3 certificate. The use of an
unnecessary expired certificate in certificate chains can cause validation
errors.
Binary updates for the amd64, i386 and arm64 platform are available
via the syspatch utility. Source code patches can be found on the
respective errata page:
https://www.openbsd.org/errata68.html
https://www.openbsd.org/errata69.html
OpenBSD 6.9.
Compensate for the expiry of the DST Root X3 certificate. The use of an
unnecessary expired certificate in certificate chains can cause validation
errors.
Binary updates for the amd64, i386 and arm64 platform are available
via the syspatch utility. Source code patches can be found on the
respective errata page:
https://www.openbsd.org/errata68.html
https://www.openbsd.org/errata69.html
Re: Server certs expired higher up the chain, imaps and https
On Thu, Sep 30, 2021 at 10:02:17AM -0700, Chris Bennett wrote:
> Hi,
>
> I'm getting that the certs are expired, but https works fine in Firefox,
> including when looking at the full chain.
>
>
> openssl s_client -servername mail.strengthcouragewisdom.rocks -connect mail.strengthcouragewisdom.rocks:imaps
>
> openssl s_client -servername mail.strengthcouragewisdom.rocks -connect mail.strengthcouragewisdom.rocks:https
>
> However are not happy. I force updated my ssl certs, syspatch, pkg_add
> -u and rebooted.
>
> I didn't rebuild dh.pem for dovecot.
>
> Is this just a DNS propagation issue?
> Or should I do something further myself?
>
> Thanks
> Chris Bennett
A certificate in LetsEncrypt's chain expired today or yesterday. The
issue is a bit complicated.
There's a page here:
https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/
and a forum thread here:
https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190
Summary: generally, newer clients and web browsers will not give the
cert expired error, because the middle certificate on the chain is a
root cert in its own right. Other clients, including as far as I can
tell the LibreSSL version included in OpenBSD 6.9, are more strict and
reject the whole chain because the last certificate in the chain
expired.
E.g. I just tried "ftp -o x
'https://mail.strengthcouragewisdom.rocks/'" on -current and it
worked.
LetsEncrypt does not want to remove that last one from the chain
because older Android phones don't have that middle certificate as a
root CA.
Some post(s) in the thread claim it is possible to request an alternate
chain from LetsEncrypt, if you want one that doesn't end with the
expired one. I couldn't find this functionality in OpenBSD's
acme-client. However, I tried manually editing the fullchain pem file
downloaded by acme-client, deleting the third of three certificates in
the file, and now my older clients are happy (but presumably old
Android phones will not be happy).
--
James
> Hi,
>
> I'm getting that the certs are expired, but https works fine in Firefox,
> including when looking at the full chain.
>
>
> openssl s_client -servername mail.strengthcouragewisdom.rocks -connect mail.strengthcouragewisdom.rocks:imaps
>
> openssl s_client -servername mail.strengthcouragewisdom.rocks -connect mail.strengthcouragewisdom.rocks:https
>
> However are not happy. I force updated my ssl certs, syspatch, pkg_add
> -u and rebooted.
>
> I didn't rebuild dh.pem for dovecot.
>
> Is this just a DNS propagation issue?
> Or should I do something further myself?
>
> Thanks
> Chris Bennett
A certificate in LetsEncrypt's chain expired today or yesterday. The
issue is a bit complicated.
There's a page here:
https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/
and a forum thread here:
https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190
Summary: generally, newer clients and web browsers will not give the
cert expired error, because the middle certificate on the chain is a
root cert in its own right. Other clients, including as far as I can
tell the LibreSSL version included in OpenBSD 6.9, are more strict and
reject the whole chain because the last certificate in the chain
expired.
E.g. I just tried "ftp -o x
'https://mail.strengthcouragewisdom.rocks/'" on -current and it
worked.
LetsEncrypt does not want to remove that last one from the chain
because older Android phones don't have that middle certificate as a
root CA.
Some post(s) in the thread claim it is possible to request an alternate
chain from LetsEncrypt, if you want one that doesn't end with the
expired one. I couldn't find this functionality in OpenBSD's
acme-client. However, I tried manually editing the fullchain pem file
downloaded by acme-client, deleting the third of three certificates in
the file, and now my older clients are happy (but presumably old
Android phones will not be happy).
--
James
Re: Server certs expired higher up the chain, imaps and https
Chris Bennett(cpb_misc@bennettconstruction.us) on 2021.09.30 10:02:17 -0700:
> Hi,
>
> I'm getting that the certs are expired, but https works fine in Firefox,
> including when looking at the full chain.
>
>
> openssl s_client -servername mail.strengthcouragewisdom.rocks -connect mail.strengthcouragewisdom.rocks:imaps
>
> openssl s_client -servername mail.strengthcouragewisdom.rocks -connect mail.strengthcouragewisdom.rocks:https
>
> However are not happy. I force updated my ssl certs, syspatch, pkg_add
> -u and rebooted.
>
> I didn't rebuild dh.pem for dovecot.
>
> Is this just a DNS propagation issue?
> Or should I do something further myself?
This is an issue with an expired root/intermediate certificate (DST Root X3)
in use by Let's Encrypt.
Stuart Henderson (sthen@) summarized it like this:
LibreSSL in OpenBSD 6.9/earlier is having problems with the expiry of a
CA certificate used to cross-sign Let's Encrypt certs.
LE decided not to switch to using their own root fully, rather they
are continuing to use the expired cross-signer to increase compatibility
with old Android devices, which is tickling this problem.
https://letsencrypt.org/2020/12/21/extending-android-compatibility.html
An errata has just been published, you can install it using syspatch.
Best,
Benno
> Hi,
>
> I'm getting that the certs are expired, but https works fine in Firefox,
> including when looking at the full chain.
>
>
> openssl s_client -servername mail.strengthcouragewisdom.rocks -connect mail.strengthcouragewisdom.rocks:imaps
>
> openssl s_client -servername mail.strengthcouragewisdom.rocks -connect mail.strengthcouragewisdom.rocks:https
>
> However are not happy. I force updated my ssl certs, syspatch, pkg_add
> -u and rebooted.
>
> I didn't rebuild dh.pem for dovecot.
>
> Is this just a DNS propagation issue?
> Or should I do something further myself?
This is an issue with an expired root/intermediate certificate (DST Root X3)
in use by Let's Encrypt.
Stuart Henderson (sthen@) summarized it like this:
LibreSSL in OpenBSD 6.9/earlier is having problems with the expiry of a
CA certificate used to cross-sign Let's Encrypt certs.
LE decided not to switch to using their own root fully, rather they
are continuing to use the expired cross-signer to increase compatibility
with old Android devices, which is tickling this problem.
https://letsencrypt.org/2020/12/21/extending-android-compatibility.html
An errata has just been published, you can install it using syspatch.
Best,
Benno
Re: Server certs expired higher up the chain, imaps and https
O 30/09/21 ás 19:02, Chris Bennett escribiu:
> Hi,
>
> I'm getting that the certs are expired, but https works fine in Firefox,
> including when looking at the full chain.
>
>
> openssl s_client -servername mail.strengthcouragewisdom.rocks -connect
> mail.strengthcouragewisdom.rocks:imaps
>
> openssl s_client -servername mail.strengthcouragewisdom.rocks -connect
> mail.strengthcouragewisdom.rocks:https
>
> However are not happy. I force updated my ssl certs, syspatch, pkg_add
> -u and rebooted.
>
> I didn't rebuild dh.pem for dovecot.
>
> Is this just a DNS propagation issue?
> Or should I do something further myself?
>
> Thanks
> Chris Bennett
>
I just saw a similar thread on freebsd-questions[1], you might have the
same problem that they had.
[1]
https://lists.freebsd.org/pipermail/freebsd-questions/2021-September/294839.html
> Hi,
>
> I'm getting that the certs are expired, but https works fine in Firefox,
> including when looking at the full chain.
>
>
> openssl s_client -servername mail.strengthcouragewisdom.rocks -connect
> mail.strengthcouragewisdom.rocks:imaps
>
> openssl s_client -servername mail.strengthcouragewisdom.rocks -connect
> mail.strengthcouragewisdom.rocks:https
>
> However are not happy. I force updated my ssl certs, syspatch, pkg_add
> -u and rebooted.
>
> I didn't rebuild dh.pem for dovecot.
>
> Is this just a DNS propagation issue?
> Or should I do something further myself?
>
> Thanks
> Chris Bennett
>
I just saw a similar thread on freebsd-questions[1], you might have the
same problem that they had.
[1]
https://lists.freebsd.org/pipermail/freebsd-questions/2021-September/294839.html
Re: relayd, rsae_send_imsg: privenc poll timeout
Allan Streib(astreib@fastmail.fm) on 2021.09.28 17:40:58 -0400:
> On Thu, Sep 16, 2021, at 6:43 PM, Allan Streib wrote:
> > On Tue, Sep 14, 2021, at 5:09 PM, Allan Streib wrote:
> > > Seen a few of these in my logs (OpenBSD 6.9 release amd64)
> > >
> > > Sep 14 02:12:05 xxxxxxxx relayd[78491]: rsae_send_imsg: privenc poll timeout, keyop #946
> > > Sep 14 02:12:06 xxxxxxxx relayd[78491]: relay_dispatch_ca: privenc result after timeout
> > >
> > > The number after "keyop" varies.
> >
> > Seeing a few more of these, the system is lightly loaded but it's a hosted KVM "slice"
> > so perhaps the host system is oversubscribed?
>
> Just to close loop, hosting provider found that host machine was overheating.
>
> Moved VM to another host machine and have not seen any repeat of this problem.
Thanks for the feedback!
> On Thu, Sep 16, 2021, at 6:43 PM, Allan Streib wrote:
> > On Tue, Sep 14, 2021, at 5:09 PM, Allan Streib wrote:
> > > Seen a few of these in my logs (OpenBSD 6.9 release amd64)
> > >
> > > Sep 14 02:12:05 xxxxxxxx relayd[78491]: rsae_send_imsg: privenc poll timeout, keyop #946
> > > Sep 14 02:12:06 xxxxxxxx relayd[78491]: relay_dispatch_ca: privenc result after timeout
> > >
> > > The number after "keyop" varies.
> >
> > Seeing a few more of these, the system is lightly loaded but it's a hosted KVM "slice"
> > so perhaps the host system is oversubscribed?
>
> Just to close loop, hosting provider found that host machine was overheating.
>
> Moved VM to another host machine and have not seen any repeat of this problem.
Thanks for the feedback!
Re: Server certs expired higher up the chain, imaps and https
I think I read in some news (slashdot? HN?) semi-recently that a bunch
of old-style (?) Let's Encrypt certificates are expiring today.
Different software packages may handle it differently, as to how
they determine what to accept...? Sorry vague, but I something
on my phone with one site that I'm guessing is from the same cause.
On 2021-09-30 10:02:17-0700, Chris Bennett <cpb_misc@bennettconstruction.us> wrote:
> Hi,
>
> I'm getting that the certs are expired, but https works fine in Firefox,
> including when looking at the full chain.
>
>
> openssl s_client -servername mail.strengthcouragewisdom.rocks -connect mail.strengthcouragewisdom.rocks:imaps
>
> openssl s_client -servername mail.strengthcouragewisdom.rocks -connect mail.strengthcouragewisdom.rocks:https
>
> However are not happy. I force updated my ssl certs, syspatch, pkg_add
> -u and rebooted.
>
> I didn't rebuild dh.pem for dovecot.
>
> Is this just a DNS propagation issue?
> Or should I do something further myself?
>
> Thanks
> Chris Bennett
>
of old-style (?) Let's Encrypt certificates are expiring today.
Different software packages may handle it differently, as to how
they determine what to accept...? Sorry vague, but I something
on my phone with one site that I'm guessing is from the same cause.
On 2021-09-30 10:02:17-0700, Chris Bennett <cpb_misc@bennettconstruction.us> wrote:
> Hi,
>
> I'm getting that the certs are expired, but https works fine in Firefox,
> including when looking at the full chain.
>
>
> openssl s_client -servername mail.strengthcouragewisdom.rocks -connect mail.strengthcouragewisdom.rocks:imaps
>
> openssl s_client -servername mail.strengthcouragewisdom.rocks -connect mail.strengthcouragewisdom.rocks:https
>
> However are not happy. I force updated my ssl certs, syspatch, pkg_add
> -u and rebooted.
>
> I didn't rebuild dh.pem for dovecot.
>
> Is this just a DNS propagation issue?
> Or should I do something further myself?
>
> Thanks
> Chris Bennett
>
UPDATE: net/nextcloudclient-3.3.5
Index: Makefile
===================================================================
RCS file: /cvs/ports/net/nextcloudclient/Makefile,v
retrieving revision 1.23
diff -u -p -r1.23 Makefile
--- Makefile 7 Sep 2021 06:16:59 -0000 1.23
+++ Makefile 30 Sep 2021 18:24:53 -0000
@@ -2,7 +2,7 @@
COMMENT = desktop sync client for Nextcloud
-V = 3.3.3
+V = 3.3.5
DISTNAME = nextcloudclient-${V}
GH_ACCOUNT = nextcloud
Index: distinfo
===================================================================
RCS file: /cvs/ports/net/nextcloudclient/distinfo,v
retrieving revision 1.20
diff -u -p -r1.20 distinfo
--- distinfo 7 Sep 2021 06:16:59 -0000 1.20
+++ distinfo 30 Sep 2021 18:24:53 -0000
@@ -1,2 +1,2 @@
-SHA256 (nextcloudclient-3.3.3.tar.gz) = p3EEeT4fw06vKBvu/82hvtRmHGak0kkOMnPSq4BjRr0=
-SIZE (nextcloudclient-3.3.3.tar.gz) = 13990016
+SHA256 (nextcloudclient-3.3.5.tar.gz) = XpUr42q2gG/7q20hawW/vZ1+cmh+DSgfSS4QWc00tBk=
+SIZE (nextcloudclient-3.3.5.tar.gz) = 14060100
Hi.
Update for net/nextcloudclient v3.3.5.
Changelog: https://github.com/nextcloud/desktop/releases/tag/v3.3.5
Thank you for testing.
--
Adriano Barbosa
===================================================================
RCS file: /cvs/ports/net/nextcloudclient/Makefile,v
retrieving revision 1.23
diff -u -p -r1.23 Makefile
--- Makefile 7 Sep 2021 06:16:59 -0000 1.23
+++ Makefile 30 Sep 2021 18:24:53 -0000
@@ -2,7 +2,7 @@
COMMENT = desktop sync client for Nextcloud
-V = 3.3.3
+V = 3.3.5
DISTNAME = nextcloudclient-${V}
GH_ACCOUNT = nextcloud
Index: distinfo
===================================================================
RCS file: /cvs/ports/net/nextcloudclient/distinfo,v
retrieving revision 1.20
diff -u -p -r1.20 distinfo
--- distinfo 7 Sep 2021 06:16:59 -0000 1.20
+++ distinfo 30 Sep 2021 18:24:53 -0000
@@ -1,2 +1,2 @@
-SHA256 (nextcloudclient-3.3.3.tar.gz) = p3EEeT4fw06vKBvu/82hvtRmHGak0kkOMnPSq4BjRr0=
-SIZE (nextcloudclient-3.3.3.tar.gz) = 13990016
+SHA256 (nextcloudclient-3.3.5.tar.gz) = XpUr42q2gG/7q20hawW/vZ1+cmh+DSgfSS4QWc00tBk=
+SIZE (nextcloudclient-3.3.5.tar.gz) = 14060100
Hi.
Update for net/nextcloudclient v3.3.5.
Changelog: https://github.com/nextcloud/desktop/releases/tag/v3.3.5
Thank you for testing.
--
Adriano Barbosa
Server certs expired higher up the chain, imaps and https
Hi,
I'm getting that the certs are expired, but https works fine in Firefox,
including when looking at the full chain.
openssl s_client -servername mail.strengthcouragewisdom.rocks -connect mail.strengthcouragewisdom.rocks:imaps
openssl s_client -servername mail.strengthcouragewisdom.rocks -connect mail.strengthcouragewisdom.rocks:https
However are not happy. I force updated my ssl certs, syspatch, pkg_add
-u and rebooted.
I didn't rebuild dh.pem for dovecot.
Is this just a DNS propagation issue?
Or should I do something further myself?
Thanks
Chris Bennett
I'm getting that the certs are expired, but https works fine in Firefox,
including when looking at the full chain.
openssl s_client -servername mail.strengthcouragewisdom.rocks -connect mail.strengthcouragewisdom.rocks:imaps
openssl s_client -servername mail.strengthcouragewisdom.rocks -connect mail.strengthcouragewisdom.rocks:https
However are not happy. I force updated my ssl certs, syspatch, pkg_add
-u and rebooted.
I didn't rebuild dh.pem for dovecot.
Is this just a DNS propagation issue?
Or should I do something further myself?
Thanks
Chris Bennett
Re: Dell PowerEdge 730xd
Jonathan Matthew <jonathan@d14n.org> writes:
> On Mon, Sep 27, 2021 at 05:30:01PM +0200, Manuel Giraud wrote:
>> Hi,
>>
>> Does anyone use one of those? I can reliably freeze them with some I/O
>> load with rsync for example. I don't have much more to say. Here is the
>> dmesg:
>
> Does this IO load involve either of the SSDs you have set up as physical
> disks, or just the logical volumes? mfii(4) has problems with
> physical disks.
This IO load is on the logical volumes… but the OS is on one of those
two physical disks. So this might be a bad idea to have the system on a
physical disk handled by mfii?
--
Manuel Giraud
> On Mon, Sep 27, 2021 at 05:30:01PM +0200, Manuel Giraud wrote:
>> Hi,
>>
>> Does anyone use one of those? I can reliably freeze them with some I/O
>> load with rsync for example. I don't have much more to say. Here is the
>> dmesg:
>
> Does this IO load involve either of the SSDs you have set up as physical
> disks, or just the logical volumes? mfii(4) has problems with
> physical disks.
This IO load is on the logical volumes… but the OS is on one of those
two physical disks. So this might be a bad idea to have the system on a
physical disk handled by mfii?
--
Manuel Giraud
Machinery safety training delivered live
| Training built around current real-world expertise and fully aligned with the regulator |
|
Health and Safety Executive - 5N1 Redgrave Court, Merton Road, Bootle, Merseyside L20 7HS
Wednesday, September 29, 2021
Re: Raspberry Pi 4 Model B
Change the server directory to /pub/OpenBSD/snapshots/arm64. We're in the
awkward time where the version number is just 7.0 so the installer thinks
it is a released version, but the release hasn't been made yet, and there
is no mechanism for the installer to fetch that information online, so you
have to do it manually.
--
Sent from a phone, apologies for poor formatting.
On 30 September 2021 03:18:36 Sandeep Gupta <gupta.sandeep@gmail.com> wrote:
> This is my second attempt to install openBSD on RPI4. I write out the UEFI
> to sdcard and miniroot.img to usb-ssd drive which takes some 16MB of space.
> The rest I create a new fat32 partition. This works -- the boot loader
> kicks off the openBSD installer.
> The installer after asking for disk partitions, reaches till installing
> sets.However,
> it doesn't give me option to install bsd or bsd.rd (see attached pic below).
>
> Not sure if I am messing up the disk partition where openbsd should be
> installed. I tried both sd1 and sd1a. But both end up having the same issue.
>
> -S
>
> On Wednesday, September 29, 2021, Stuart Henderson
> <stu.lists@spacehopper.org> wrote:
>>
>> On 2021-09-28, Peter J. Philipp <pjp@delphinusdns.org> wrote:
>> > On Tue, Sep 28, 2021 at 10:04:25AM -0700, Joseph Olatt wrote:
>> >> I tried the following snapshot:
>> >>
>> >> https://cdn.openbsd.org/pub/OpenBSD/snapshots/arm64/miniroot70.img
>> >>
>> >> Build date: 27-Sep-2021 20:10
>> >> Size: 45088768
>> >>
>> >> Didn't have much luck. The install process rebooted after the following
>> >> error:
>> >>
>> >> bwfm0: failed loadfirmware of file
>> brcmfmac43455-sdio.raspberrypi,4-model-b.bin
>> >> panic: do_el0_error
>> >
>> > What happens when you boot with -c and 'disable bwfm' then exit? Is that not
>> > an option anymore?
>>
>> I am pretty sure the do_el0_error is unrelated to the loadfirmware() failing
>> (which is just because the firmware for the device isn't installed yet).
>>
>>
awkward time where the version number is just 7.0 so the installer thinks
it is a released version, but the release hasn't been made yet, and there
is no mechanism for the installer to fetch that information online, so you
have to do it manually.
--
Sent from a phone, apologies for poor formatting.
On 30 September 2021 03:18:36 Sandeep Gupta <gupta.sandeep@gmail.com> wrote:
> This is my second attempt to install openBSD on RPI4. I write out the UEFI
> to sdcard and miniroot.img to usb-ssd drive which takes some 16MB of space.
> The rest I create a new fat32 partition. This works -- the boot loader
> kicks off the openBSD installer.
> The installer after asking for disk partitions, reaches till installing
> sets.However,
> it doesn't give me option to install bsd or bsd.rd (see attached pic below).
>
> Not sure if I am messing up the disk partition where openbsd should be
> installed. I tried both sd1 and sd1a. But both end up having the same issue.
>
> -S
>
> On Wednesday, September 29, 2021, Stuart Henderson
> <stu.lists@spacehopper.org> wrote:
>>
>> On 2021-09-28, Peter J. Philipp <pjp@delphinusdns.org> wrote:
>> > On Tue, Sep 28, 2021 at 10:04:25AM -0700, Joseph Olatt wrote:
>> >> I tried the following snapshot:
>> >>
>> >> https://cdn.openbsd.org/pub/OpenBSD/snapshots/arm64/miniroot70.img
>> >>
>> >> Build date: 27-Sep-2021 20:10
>> >> Size: 45088768
>> >>
>> >> Didn't have much luck. The install process rebooted after the following
>> >> error:
>> >>
>> >> bwfm0: failed loadfirmware of file
>> brcmfmac43455-sdio.raspberrypi,4-model-b.bin
>> >> panic: do_el0_error
>> >
>> > What happens when you boot with -c and 'disable bwfm' then exit? Is that not
>> > an option anymore?
>>
>> I am pretty sure the do_el0_error is unrelated to the loadfirmware() failing
>> (which is just because the firmware for the device isn't installed yet).
>>
>>
sparc64 bulk build report
Bulk build on sparc64-0a.ports.openbsd.org
Started : Mon Sep 27 09:39:57 MDT 2021
Finished: Wed Sep 29 20:36:36 MDT 2021
Duration: 2 Days 10 hours 57 minutes
Built using OpenBSD 7.0 (GENERIC.MP) #985: Sun Sep 26 13:07:59 MDT 2021
Built 9712 packages
Number of packages built each day:
Sep 27: 7390
Sep 28: 1824
Sep 29: 498
Critical path missing pkgs:
http://build-failures.rhaalovely.net/sparc64/2021-09-27/summary.log
Build failures: 26
http://build-failures.rhaalovely.net/sparc64/2021-09-27/audio/ncmpcpp.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/cad/dxf2gcode.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/devel/avr/gcc.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/emulators/openmsx.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/games/colobot/colobot.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/games/egoboo.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/games/godot.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/games/stepmania.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/graphics/birdfont.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/graphics/enblend-enfuse.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/graphics/gmic.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/graphics/inkscape.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/graphics/makehuman.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/graphics/openexr.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/lang/clazy.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/math/veusz.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/multimedia/mkvtoolnix.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/net/barrier.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/net/ntopng.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/net/pmacct,postgresql.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/productivity/gnucash.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/textproc/docbook-utils.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/www/nextcloud_notify_push.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/x11/gnome/gjs.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/x11/kde-applications/akonadi.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/x11/kde-applications/kmix.log
Recurrent failures:
failures/audio/ncmpcpp.log
failures/cad/dxf2gcode.log
failures/devel/avr/gcc.log
failures/emulators/openmsx.log
failures/games/colobot/colobot.log
failures/graphics/birdfont.log
failures/graphics/enblend-enfuse.log
failures/graphics/gmic.log
failures/graphics/makehuman.log
failures/graphics/openexr.log
failures/lang/clazy.log
failures/net/barrier.log
failures/net/ntopng.log
failures/net/pmacct,postgresql.log
failures/productivity/gnucash.log
failures/textproc/docbook-utils.log
failures/www/nextcloud_notify_push.log
failures/x11/gnome/gjs.log
failures/x11/kde-applications/kmix.log
New failures:
+failures/graphics/inkscape.log
+failures/x11/kde-applications/akonadi.log
Resolved failures:
-failures/databases/xapian-bindings,-main.log
-failures/graphics/krita.log
-failures/net/weechat,-lua.log
-failures/security/arirang.log
-failures/textproc/redland-bindings,-main.log
-failures/x11/kde-applications/kig.log
-failures/x11/kde-applications/kross-interpreters.log
-failures/x11/kde-applications/okular.log
-failures/x11/mate/calc.log
-failures/x11/mate/panel.log
-failures/x11/mate/settings-daemon.log
-failures/x11/qt5/docs,-html.log
Packages newly built:
+databases/xapian-bindings
+databases/xapian-bindings,-main
+databases/xapian-bindings,-python
+databases/xapian-bindings,-ruby
+editors/calligra
+editors/kile
+graphics/krita
+meta/mate
+meta/mate,-main
+net/weechat
+net/weechat,-lua
+net/weechat,-main
+net/weechat,-python
+net/weechat,-ruby
+net/weechat,-tcl
+security/arirang
+textproc/redland-bindings
+textproc/redland-bindings,-main
+textproc/redland-bindings,-python
+textproc/redland-bindings,-ruby
+x11/kde-applications/kig
+x11/kde-applications/kross-interpreters
+x11/kde-applications/okular
+x11/mate/calc
+x11/mate/control-center
+x11/mate/media
+x11/mate/menu-advanced
+x11/mate/notification-daemon
+x11/mate/panel
+x11/mate/power-manager
+x11/mate/screensaver
+x11/mate/session-manager
+x11/mate/settings-daemon
+x11/qt5/docs
+x11/qt5/docs,-html
+x11/qt5/docs,-qch
Packages not built this time:
-graphics/inkscape
-meta/kde,,-utils
-meta/kde,-utils
-productivity/kmymoney
-x11/kde-applications/akonadi
-x11/kde-applications/akonadi-contacts
-x11/kde-applications/akonadi-mime
-x11/kde-applications/akonadi-search
-x11/kde-applications/kalarmcal
-x11/kde-applications/kgpg
-x11/kde-applications/libgravatar
-x11/kde-applications/mailimporter
-x11/kde-applications/pimcommon
Started : Mon Sep 27 09:39:57 MDT 2021
Finished: Wed Sep 29 20:36:36 MDT 2021
Duration: 2 Days 10 hours 57 minutes
Built using OpenBSD 7.0 (GENERIC.MP) #985: Sun Sep 26 13:07:59 MDT 2021
Built 9712 packages
Number of packages built each day:
Sep 27: 7390
Sep 28: 1824
Sep 29: 498
Critical path missing pkgs:
http://build-failures.rhaalovely.net/sparc64/2021-09-27/summary.log
Build failures: 26
http://build-failures.rhaalovely.net/sparc64/2021-09-27/audio/ncmpcpp.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/cad/dxf2gcode.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/devel/avr/gcc.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/emulators/openmsx.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/games/colobot/colobot.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/games/egoboo.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/games/godot.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/games/stepmania.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/graphics/birdfont.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/graphics/enblend-enfuse.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/graphics/gmic.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/graphics/inkscape.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/graphics/makehuman.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/graphics/openexr.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/lang/clazy.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/math/veusz.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/multimedia/mkvtoolnix.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/net/barrier.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/net/ntopng.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/net/pmacct,postgresql.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/productivity/gnucash.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/textproc/docbook-utils.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/www/nextcloud_notify_push.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/x11/gnome/gjs.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/x11/kde-applications/akonadi.log
http://build-failures.rhaalovely.net/sparc64/2021-09-27/x11/kde-applications/kmix.log
Recurrent failures:
failures/audio/ncmpcpp.log
failures/cad/dxf2gcode.log
failures/devel/avr/gcc.log
failures/emulators/openmsx.log
failures/games/colobot/colobot.log
failures/graphics/birdfont.log
failures/graphics/enblend-enfuse.log
failures/graphics/gmic.log
failures/graphics/makehuman.log
failures/graphics/openexr.log
failures/lang/clazy.log
failures/net/barrier.log
failures/net/ntopng.log
failures/net/pmacct,postgresql.log
failures/productivity/gnucash.log
failures/textproc/docbook-utils.log
failures/www/nextcloud_notify_push.log
failures/x11/gnome/gjs.log
failures/x11/kde-applications/kmix.log
New failures:
+failures/graphics/inkscape.log
+failures/x11/kde-applications/akonadi.log
Resolved failures:
-failures/databases/xapian-bindings,-main.log
-failures/graphics/krita.log
-failures/net/weechat,-lua.log
-failures/security/arirang.log
-failures/textproc/redland-bindings,-main.log
-failures/x11/kde-applications/kig.log
-failures/x11/kde-applications/kross-interpreters.log
-failures/x11/kde-applications/okular.log
-failures/x11/mate/calc.log
-failures/x11/mate/panel.log
-failures/x11/mate/settings-daemon.log
-failures/x11/qt5/docs,-html.log
Packages newly built:
+databases/xapian-bindings
+databases/xapian-bindings,-main
+databases/xapian-bindings,-python
+databases/xapian-bindings,-ruby
+editors/calligra
+editors/kile
+graphics/krita
+meta/mate
+meta/mate,-main
+net/weechat
+net/weechat,-lua
+net/weechat,-main
+net/weechat,-python
+net/weechat,-ruby
+net/weechat,-tcl
+security/arirang
+textproc/redland-bindings
+textproc/redland-bindings,-main
+textproc/redland-bindings,-python
+textproc/redland-bindings,-ruby
+x11/kde-applications/kig
+x11/kde-applications/kross-interpreters
+x11/kde-applications/okular
+x11/mate/calc
+x11/mate/control-center
+x11/mate/media
+x11/mate/menu-advanced
+x11/mate/notification-daemon
+x11/mate/panel
+x11/mate/power-manager
+x11/mate/screensaver
+x11/mate/session-manager
+x11/mate/settings-daemon
+x11/qt5/docs
+x11/qt5/docs,-html
+x11/qt5/docs,-qch
Packages not built this time:
-graphics/inkscape
-meta/kde,,-utils
-meta/kde,-utils
-productivity/kmymoney
-x11/kde-applications/akonadi
-x11/kde-applications/akonadi-contacts
-x11/kde-applications/akonadi-mime
-x11/kde-applications/akonadi-search
-x11/kde-applications/kalarmcal
-x11/kde-applications/kgpg
-x11/kde-applications/libgravatar
-x11/kde-applications/mailimporter
-x11/kde-applications/pimcommon
Raspberry Pi 4 Model B
to sdcard and miniroot.img to usb-ssd drive which takes some 16MB of space.
The rest I create a new fat32 partition. This works -- the boot loader
kicks off the openBSD installer.
The installer after asking for disk partitions, reaches till installing
sets.However,
it doesn't give me option to install bsd or bsd.rd (see attached pic
below).
Not sure if I am messing up the disk partition where openbsd should be
installed. I tried both sd1 and sd1a. But both end up having the same issue.
-S
On Wednesday, September 29, 2021, Stuart Henderson <
stu.lists@spacehopper.org> wrote:
>
> On 2021-09-28, Peter J. Philipp <pjp@delphinusdns.org> wrote:
> > On Tue, Sep 28, 2021 at 10:04:25AM -0700, Joseph Olatt wrote:
> >> I tried the following snapshot:
> >>
> >> https://cdn.openbsd.org/pub/OpenBSD/snapshots/arm64/miniroot70.img
> >>
> >> Build date: 27-Sep-2021 20:10
> >> Size: 45088768
> >>
> >> Didn't have much luck. The install process rebooted after the following
> >> error:
> >>
> >> bwfm0: failed loadfirmware of file brcmfmac43455-sdio.
raspberrypi,4-model-b.bin
> >> panic: do_el0_error
> >
> > What happens when you boot with -c and 'disable bwfm' then exit? Is
that not
> > an option anymore?
>
> I am pretty sure the do_el0_error is unrelated to the loadfirmware()
failing
> (which is just because the firmware for the device isn't installed yet).
>
>
Re: 6.9/amd64 runaway acpi process on Thinkpad T580
Mike Larkin <mlarkin@nested.page> wrote:
> On Wed, Sep 29, 2021 at 08:44:54PM -0400, David Anthony wrote:
> > After enabling "BIOS Thunderbolt Assist", I experience consistent machine
> > slowdown on my T480. Previously, I experienced slowdown after power cycling
> > my machine occasionally. Currently, with this BIOS setting enabled, I
> > experience slowdown consistently.
> >
> > I am sorry but I don't know enough technically as to discern why. I am
> > simply reporting my user experience. I will re-disable the Thunderbolt
> > assist for now.
> >
>
> If someone would build an ACPI_DEBUG kernel and show us what GPE is stuck
> then we can make forward progress (we need an acpidump of that machine
> also).
>
> Otherwise, its like throwing darts in the dark.
Or, someone with a machine which has the problem can give it to Mike,
or a few other developers who understand this problem area.
I'm not joking. Give it. It would be a public service.
> On Wed, Sep 29, 2021 at 08:44:54PM -0400, David Anthony wrote:
> > After enabling "BIOS Thunderbolt Assist", I experience consistent machine
> > slowdown on my T480. Previously, I experienced slowdown after power cycling
> > my machine occasionally. Currently, with this BIOS setting enabled, I
> > experience slowdown consistently.
> >
> > I am sorry but I don't know enough technically as to discern why. I am
> > simply reporting my user experience. I will re-disable the Thunderbolt
> > assist for now.
> >
>
> If someone would build an ACPI_DEBUG kernel and show us what GPE is stuck
> then we can make forward progress (we need an acpidump of that machine
> also).
>
> Otherwise, its like throwing darts in the dark.
Or, someone with a machine which has the problem can give it to Mike,
or a few other developers who understand this problem area.
I'm not joking. Give it. It would be a public service.
Re: 6.9/amd64 runaway acpi process on Thinkpad T580
On Wed, Sep 29, 2021 at 06:29:08PM -0700, Mike Larkin wrote:
> On Wed, Sep 29, 2021 at 08:44:54PM -0400, David Anthony wrote:
> > After enabling "BIOS Thunderbolt Assist", I experience consistent machine
> > slowdown on my T480. Previously, I experienced slowdown after power cycling
> > my machine occasionally. Currently, with this BIOS setting enabled, I
> > experience slowdown consistently.
> >
> > I am sorry but I don't know enough technically as to discern why. I am
> > simply reporting my user experience. I will re-disable the Thunderbolt
> > assist for now.
> >
>
> If someone would build an ACPI_DEBUG kernel and show us what GPE is stuck
> then we can make forward progress (we need an acpidump of that machine
> also).
>
> Otherwise, its like throwing darts in the dark.
>
> -ml
I could give it a shot. Do you want all three possible states for the
dumps? (disabled, working. Disabled, looped acpi0. Enabled, working.)
It probably won't be until tomorrow since it's already pretty late,
though.
Danny
> On Wed, Sep 29, 2021 at 08:44:54PM -0400, David Anthony wrote:
> > After enabling "BIOS Thunderbolt Assist", I experience consistent machine
> > slowdown on my T480. Previously, I experienced slowdown after power cycling
> > my machine occasionally. Currently, with this BIOS setting enabled, I
> > experience slowdown consistently.
> >
> > I am sorry but I don't know enough technically as to discern why. I am
> > simply reporting my user experience. I will re-disable the Thunderbolt
> > assist for now.
> >
>
> If someone would build an ACPI_DEBUG kernel and show us what GPE is stuck
> then we can make forward progress (we need an acpidump of that machine
> also).
>
> Otherwise, its like throwing darts in the dark.
>
> -ml
I could give it a shot. Do you want all three possible states for the
dumps? (disabled, working. Disabled, looped acpi0. Enabled, working.)
It probably won't be until tomorrow since it's already pretty late,
though.
Danny
Re: 6.9/amd64 runaway acpi process on Thinkpad T580
On Wed, Sep 29, 2021 at 08:44:54PM -0400, David Anthony wrote:
> After enabling "BIOS Thunderbolt Assist", I experience consistent machine
> slowdown on my T480. Previously, I experienced slowdown after power cycling
> my machine occasionally. Currently, with this BIOS setting enabled, I
> experience slowdown consistently.
>
> I am sorry but I don't know enough technically as to discern why. I am
> simply reporting my user experience. I will re-disable the Thunderbolt
> assist for now.
>
If someone would build an ACPI_DEBUG kernel and show us what GPE is stuck
then we can make forward progress (we need an acpidump of that machine
also).
Otherwise, its like throwing darts in the dark.
-ml
> On 9/29/21 2:58 PM, David Anthony wrote:
> > Another T480 user who has noticed the same problem. Per advice given,
> > I've just enabled "BIOS Thunderbolt Assist". I will report back if I
> > notice the problem persists.
> >
> > On 9/19/21 4:50 AM, Daniel Wilkins wrote:
> > > I've ran into this on my T480, it seems most consistently triggered
> > > by power
> > > cycles caused by running out of battery. The bug's existed for quite
> > > a few
> > > years (I think I first noticed it in 2019.) If I recall correctly I've
> > > posted it to the list a couple of times but I don't think any
> > > concrete answers
> > > ever emerged; your report is more thorough than mine were though.
> > > I do remember that it never happened on my T430, but that's quite the
> > > hardware gap.
> > >
> >
>
> After enabling "BIOS Thunderbolt Assist", I experience consistent machine
> slowdown on my T480. Previously, I experienced slowdown after power cycling
> my machine occasionally. Currently, with this BIOS setting enabled, I
> experience slowdown consistently.
>
> I am sorry but I don't know enough technically as to discern why. I am
> simply reporting my user experience. I will re-disable the Thunderbolt
> assist for now.
>
If someone would build an ACPI_DEBUG kernel and show us what GPE is stuck
then we can make forward progress (we need an acpidump of that machine
also).
Otherwise, its like throwing darts in the dark.
-ml
> On 9/29/21 2:58 PM, David Anthony wrote:
> > Another T480 user who has noticed the same problem. Per advice given,
> > I've just enabled "BIOS Thunderbolt Assist". I will report back if I
> > notice the problem persists.
> >
> > On 9/19/21 4:50 AM, Daniel Wilkins wrote:
> > > I've ran into this on my T480, it seems most consistently triggered
> > > by power
> > > cycles caused by running out of battery. The bug's existed for quite
> > > a few
> > > years (I think I first noticed it in 2019.) If I recall correctly I've
> > > posted it to the list a couple of times but I don't think any
> > > concrete answers
> > > ever emerged; your report is more thorough than mine were though.
> > > I do remember that it never happened on my T430, but that's quite the
> > > hardware gap.
> > >
> >
>
Re: 6.9/amd64 runaway acpi process on Thinkpad T580
After enabling "BIOS Thunderbolt Assist", I experience consistent
machine slowdown on my T480. Previously, I experienced slowdown after
power cycling my machine occasionally. Currently, with this BIOS setting
enabled, I experience slowdown consistently.
I am sorry but I don't know enough technically as to discern why. I am
simply reporting my user experience. I will re-disable the Thunderbolt
assist for now.
On 9/29/21 2:58 PM, David Anthony wrote:
> Another T480 user who has noticed the same problem. Per advice given,
> I've just enabled "BIOS Thunderbolt Assist". I will report back if I
> notice the problem persists.
>
> On 9/19/21 4:50 AM, Daniel Wilkins wrote:
>> I've ran into this on my T480, it seems most consistently triggered
>> by power
>> cycles caused by running out of battery. The bug's existed for quite
>> a few
>> years (I think I first noticed it in 2019.) If I recall correctly I've
>> posted it to the list a couple of times but I don't think any
>> concrete answers
>> ever emerged; your report is more thorough than mine were though.
>> I do remember that it never happened on my T430, but that's quite the
>> hardware gap.
>>
>
machine slowdown on my T480. Previously, I experienced slowdown after
power cycling my machine occasionally. Currently, with this BIOS setting
enabled, I experience slowdown consistently.
I am sorry but I don't know enough technically as to discern why. I am
simply reporting my user experience. I will re-disable the Thunderbolt
assist for now.
On 9/29/21 2:58 PM, David Anthony wrote:
> Another T480 user who has noticed the same problem. Per advice given,
> I've just enabled "BIOS Thunderbolt Assist". I will report back if I
> notice the problem persists.
>
> On 9/19/21 4:50 AM, Daniel Wilkins wrote:
>> I've ran into this on my T480, it seems most consistently triggered
>> by power
>> cycles caused by running out of battery. The bug's existed for quite
>> a few
>> years (I think I first noticed it in 2019.) If I recall correctly I've
>> posted it to the list a couple of times but I don't think any
>> concrete answers
>> ever emerged; your report is more thorough than mine were though.
>> I do remember that it never happened on my T430, but that's quite the
>> hardware gap.
>>
>
Re: 6.9/amd64 runaway acpi process on Thinkpad T580
Another T480 user who has noticed the same problem. Per advice given,
I've just enabled "BIOS Thunderbolt Assist". I will report back if I
notice the problem persists.
On 9/19/21 4:50 AM, Daniel Wilkins wrote:
> I've ran into this on my T480, it seems most consistently triggered by power
> cycles caused by running out of battery. The bug's existed for quite a few
> years (I think I first noticed it in 2019.) If I recall correctly I've
> posted it to the list a couple of times but I don't think any concrete answers
> ever emerged; your report is more thorough than mine were though.
> I do remember that it never happened on my T430, but that's quite the
> hardware gap.
>
I've just enabled "BIOS Thunderbolt Assist". I will report back if I
notice the problem persists.
On 9/19/21 4:50 AM, Daniel Wilkins wrote:
> I've ran into this on my T480, it seems most consistently triggered by power
> cycles caused by running out of battery. The bug's existed for quite a few
> years (I think I first noticed it in 2019.) If I recall correctly I've
> posted it to the list a couple of times but I don't think any concrete answers
> ever emerged; your report is more thorough than mine were though.
> I do remember that it never happened on my T430, but that's quite the
> hardware gap.
>
Re: SOLVED Re: 6.9/amd64 runaway acpi process on Thinkpad T580
On Wed, Sep 29, 2021 at 11:47:34AM -0600, Theo de Raadt wrote:
> It would be great if someone figures out why "BIOS Thunderbolt Assist"
> disable, causes a pin to get stuck on resume, and/or figures out how we
> can recognize to handle/clear the event.
The detail in my BIOS options specifically mentions it as a Linux
workaround. Obviously patches couldn't be imported but I'll poke
around to see if there's any discussion/a description of what
exactly is happening.
Aside from that is there any data I can send y'all? Jonathan's built up
a pretty comprehensive set of dmesgs at this point, it seems like.
(No need to cc me, I'm on misc@)
Danny
> It would be great if someone figures out why "BIOS Thunderbolt Assist"
> disable, causes a pin to get stuck on resume, and/or figures out how we
> can recognize to handle/clear the event.
The detail in my BIOS options specifically mentions it as a Linux
workaround. Obviously patches couldn't be imported but I'll poke
around to see if there's any discussion/a description of what
exactly is happening.
Aside from that is there any data I can send y'all? Jonathan's built up
a pretty comprehensive set of dmesgs at this point, it seems like.
(No need to cc me, I'm on misc@)
Danny
Re: SOLVED Re: 6.9/amd64 runaway acpi process on Thinkpad T580
Jonathan Thornburg <jthorn4242@gmail.com> wrote:
> On 2021-09-28 14>18>49, Daniel Wilkins wrote
> > All you have to do is go into your bios' settings and turn on
> > "BIOS Thunderbolt Assist" then everything will work 100% fine.
> >
> > Thanks to jcs on IRC for pointing me at that (dunno what his
> > email is.)
>
> Success! With this (and the 7.0 snapshot I installed yesterday; dmesg
> in my message <https://marc.info/?l=openbsd-misc&m=163289489310163&w=1>)
> the problem is gone, and my T580 now does suspend/resume perfectly
> (including idling with CPU usage under 1%).
>
> A big thank-you to Daniel and to jcs (I'm guessing that's Joshua Stein,
> https://jcs.org/) for the solution, and to Theo and Mike for their
> suggestions too!
It would be great if someone figures out why "BIOS Thunderbolt Assist"
disable, causes a pin to get stuck on resume, and/or figures out how we
can recognize to handle/clear the event.
> On 2021-09-28 14>18>49, Daniel Wilkins wrote
> > All you have to do is go into your bios' settings and turn on
> > "BIOS Thunderbolt Assist" then everything will work 100% fine.
> >
> > Thanks to jcs on IRC for pointing me at that (dunno what his
> > email is.)
>
> Success! With this (and the 7.0 snapshot I installed yesterday; dmesg
> in my message <https://marc.info/?l=openbsd-misc&m=163289489310163&w=1>)
> the problem is gone, and my T580 now does suspend/resume perfectly
> (including idling with CPU usage under 1%).
>
> A big thank-you to Daniel and to jcs (I'm guessing that's Joshua Stein,
> https://jcs.org/) for the solution, and to Theo and Mike for their
> suggestions too!
It would be great if someone figures out why "BIOS Thunderbolt Assist"
disable, causes a pin to get stuck on resume, and/or figures out how we
can recognize to handle/clear the event.
SOLVED Re: 6.9/amd64 runaway acpi process on Thinkpad T580
Hi,
On 2021-09-28 14>18>49, Daniel Wilkins wrote
> All you have to do is go into your bios' settings and turn on
> "BIOS Thunderbolt Assist" then everything will work 100% fine.
>
> Thanks to jcs on IRC for pointing me at that (dunno what his
> email is.)
Success! With this (and the 7.0 snapshot I installed yesterday; dmesg
in my message <https://marc.info/?l=openbsd-misc&m=163289489310163&w=1>)
the problem is gone, and my T580 now does suspend/resume perfectly
(including idling with CPU usage under 1%).
A big thank-you to Daniel and to jcs (I'm guessing that's Joshua Stein,
https://jcs.org/) for the solution, and to Theo and Mike for their
suggestions too!
Thanks again,
--
-- "Jonathan Thornburg [remove color- to reply]" <jthorn4242@pink-gmail.com>
on the west coast of Canada, eh?
"There was of course no way of knowing whether you were being watched
at any given moment. How often, or on what system, the Thought Police
plugged in on any individual wire was guesswork. It was even conceivable
that they watched everybody all the time." -- George Orwell, "1984"
On 2021-09-28 14>18>49, Daniel Wilkins wrote
> All you have to do is go into your bios' settings and turn on
> "BIOS Thunderbolt Assist" then everything will work 100% fine.
>
> Thanks to jcs on IRC for pointing me at that (dunno what his
> email is.)
Success! With this (and the 7.0 snapshot I installed yesterday; dmesg
in my message <https://marc.info/?l=openbsd-misc&m=163289489310163&w=1>)
the problem is gone, and my T580 now does suspend/resume perfectly
(including idling with CPU usage under 1%).
A big thank-you to Daniel and to jcs (I'm guessing that's Joshua Stein,
https://jcs.org/) for the solution, and to Theo and Mike for their
suggestions too!
Thanks again,
--
-- "Jonathan Thornburg [remove color- to reply]" <jthorn4242@pink-gmail.com>
on the west coast of Canada, eh?
"There was of course no way of knowing whether you were being watched
at any given moment. How often, or on what system, the Thought Police
plugged in on any individual wire was guesswork. It was even conceivable
that they watched everybody all the time." -- George Orwell, "1984"
Re: nmap segfault fix
On Wed, Sep 29, 2021 at 05:45:06PM +0100, Stuart Henderson wrote:
> The version of nmap in ports is the last one under the old licence. I'd like
> if someone who knows about such things could review the new nmap licence
> before we start taking diffs from anything newer (we might want to stop
> distributing packages).
After some Linux distributions pushed back and even rolled back to
7.80, the 7.92 release (which includes this fix) is also released under
the nmap-v7.80 license.
https://nmap.org/npsl/ states
To ease the transition to the NPSL, the first three Nmap releases made
under that license (Nmap 7.90, 7.91, and 7.92) may also be used under
the previous Nmap license terms by anyone who prefers those.
I'll bump the comment in the Makefile to 7.92
See also https://github.com/nmap/nmap/issues/2199#issuecomment-894812634
> The version of nmap in ports is the last one under the old licence. I'd like
> if someone who knows about such things could review the new nmap licence
> before we start taking diffs from anything newer (we might want to stop
> distributing packages).
After some Linux distributions pushed back and even rolled back to
7.80, the 7.92 release (which includes this fix) is also released under
the nmap-v7.80 license.
https://nmap.org/npsl/ states
To ease the transition to the NPSL, the first three Nmap releases made
under that license (Nmap 7.90, 7.91, and 7.92) may also be used under
the previous Nmap license terms by anyone who prefers those.
I'll bump the comment in the Makefile to 7.92
See also https://github.com/nmap/nmap/issues/2199#issuecomment-894812634
Re: Mellanox driver support details https://man.openbsd.org/mcx.4
On 2021-09-29, Andrew Lemin <andrew.lemin@gmail.com> wrote:
> And to answer my last question about SMP capabilities, it looks like the
> only locking going on is when the driver is talking to the Kernel itself
> through kstat which would make sense. So yes it looks like mcx does have
> SMP support :)
$ cd /sys/dev/pci; grep pci_intr_establish_cpu *
if_bnxt.c: bq->q_ihc = pci_intr_establish_cpu(sc->sc_pc, ih,
if_ix.c: que->tag = pci_intr_establish_cpu(pa->pa_pc, ih,
if_ixl.c: iv->iv_ihc = pci_intr_establish_cpu(sc->sc_pc, ih,
if_mcx.c: q->q_ihc = pci_intr_establish_cpu(sc->sc_pc, ih,
if_vmx.c: q->ih = pci_intr_establish_cpu(pa->pa_pc, ih,
> Well its enough for me to buy a card from ebay to play with
> as the ConnectX-4 Lx cards are pretty cheap now.
new (from fs) aren't much more expensive either btw.
>> I was able to decipher some of it using this
>> https://www.mellanox.com/related-docs/user_manuals/Ethernet_Adapters_Programming_Manual.pdf
>> (this is very well written).
nvidia bought the company so that might be the high point in the documentation
for these..
> And to answer my last question about SMP capabilities, it looks like the
> only locking going on is when the driver is talking to the Kernel itself
> through kstat which would make sense. So yes it looks like mcx does have
> SMP support :)
$ cd /sys/dev/pci; grep pci_intr_establish_cpu *
if_bnxt.c: bq->q_ihc = pci_intr_establish_cpu(sc->sc_pc, ih,
if_ix.c: que->tag = pci_intr_establish_cpu(pa->pa_pc, ih,
if_ixl.c: iv->iv_ihc = pci_intr_establish_cpu(sc->sc_pc, ih,
if_mcx.c: q->q_ihc = pci_intr_establish_cpu(sc->sc_pc, ih,
if_vmx.c: q->ih = pci_intr_establish_cpu(pa->pa_pc, ih,
> Well its enough for me to buy a card from ebay to play with
> as the ConnectX-4 Lx cards are pretty cheap now.
new (from fs) aren't much more expensive either btw.
>> I was able to decipher some of it using this
>> https://www.mellanox.com/related-docs/user_manuals/Ethernet_Adapters_Programming_Manual.pdf
>> (this is very well written).
nvidia bought the company so that might be the high point in the documentation
for these..
Re: nmap segfault fix
The version of nmap in ports is the last one under the old licence. I'd
like if someone who knows about such things could review the new nmap
licence before we start taking diffs from anything newer (we might want to
stop distributing packages).
--
Sent from a phone, apologies for poor formatting.
On 29 September 2021 16:50:22 JR Aquino <tanawts@gmail.com> wrote:
> Thanks Niklas!
>
> The patches apply, build, and run cleanly.
>
> The fix makes sense to incorporate in our OpenBSD port for nmap 7.91, but
> we should revisit it in the future with any new upstream releases in case
> there are subtle changes from what is in their github repo today.
>
> Unless anyone else has strong opinions, I'm good with the patches and would
> like to ask another port maintainer with CVS privileges to review and
> commit.
>
> -JR
>
> On Wed, Sep 29, 2021 at 8:37 AM Niklas Hallqvist <niklas@appli.se> wrote:
>
>> Hi!
>>
>> While testing 7.0 packages I got an nmap segfault. It has been fixed
>> upstream in their github, but I don't know if it's part of any release yet.
>>
>> However their fix may be incomplete as there are other opportunities for
>> a negative buffer overflow in nmap_dns.cc, at least without knowing all
>> callers of the ptrToIp method.
>>
>> I attach a patch that works for me (tm) as well as a patch to add a
>> debug package for nmap, which was needed for me to debug this issue.
>>
>> Even if its too late for 7.0, at least the segfault fix might make
>> 7.0-stable package, I reckon.
>>
>> The fault is indeterministic, and triggered by a PTR name being aligned
>> at the beginning of a page immediately preceded by an unmapped page.
>> The case which triggers it fairly often for me was just a nmap of a
>> single TCP port over some seven or so /24-networks.
>>
>> /Niklas
>>
like if someone who knows about such things could review the new nmap
licence before we start taking diffs from anything newer (we might want to
stop distributing packages).
--
Sent from a phone, apologies for poor formatting.
On 29 September 2021 16:50:22 JR Aquino <tanawts@gmail.com> wrote:
> Thanks Niklas!
>
> The patches apply, build, and run cleanly.
>
> The fix makes sense to incorporate in our OpenBSD port for nmap 7.91, but
> we should revisit it in the future with any new upstream releases in case
> there are subtle changes from what is in their github repo today.
>
> Unless anyone else has strong opinions, I'm good with the patches and would
> like to ask another port maintainer with CVS privileges to review and
> commit.
>
> -JR
>
> On Wed, Sep 29, 2021 at 8:37 AM Niklas Hallqvist <niklas@appli.se> wrote:
>
>> Hi!
>>
>> While testing 7.0 packages I got an nmap segfault. It has been fixed
>> upstream in their github, but I don't know if it's part of any release yet.
>>
>> However their fix may be incomplete as there are other opportunities for
>> a negative buffer overflow in nmap_dns.cc, at least without knowing all
>> callers of the ptrToIp method.
>>
>> I attach a patch that works for me (tm) as well as a patch to add a
>> debug package for nmap, which was needed for me to debug this issue.
>>
>> Even if its too late for 7.0, at least the segfault fix might make
>> 7.0-stable package, I reckon.
>>
>> The fault is indeterministic, and triggered by a PTR name being aligned
>> at the beginning of a page immediately preceded by an unmapped page.
>> The case which triggers it fairly often for me was just a nmap of a
>> single TCP port over some seven or so /24-networks.
>>
>> /Niklas
>>
Re: nmap segfault fix
On Wed, Sep 29, 2021 at 09:10:14AM -0700, JR Aquino wrote:
> How about now?
Thanks, that's better.
I think the part of the diff which is the upstream fix is simple enough
that we do not need to worry about the license.
I'll land this in -current once the tree unlocks and will also land it
in 7.0-stable.
Index: Makefile
===================================================================
RCS file: /cvs/ports/net/nmap/Makefile,v
retrieving revision 1.140
diff -u -p -r1.140 Makefile
--- Makefile 20 Jul 2021 22:28:24 -0000 1.140
+++ Makefile 29 Sep 2021 16:36:20 -0000
@@ -7,6 +7,7 @@ MODPY_EGG_VERSION= 7.91
DISTNAME= nmap-${MODPY_EGG_VERSION}
PKGNAME-main= ${DISTNAME}
PKGNAME-zenmap= nmap-zenmap-${MODPY_EGG_VERSION}
+REVISION= 0
CATEGORIES= net security
MASTER_SITES= ${HOMEPAGE}/dist/
@@ -33,6 +34,7 @@ MODULES= lang/python \
lang/lua
MODPY_VERSION= ${MODPY_DEFAULT_VERSION_2}
+DEBUG_PACKAGES= ${BUILD_PACKAGES}
CONFIGURE_STYLE=autoconf
AUTOCONF_VERSION=2.69
Index: patches/patch-nmap_dns_cc
===================================================================
RCS file: patches/patch-nmap_dns_cc
diff -N patches/patch-nmap_dns_cc
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-nmap_dns_cc 29 Sep 2021 16:35:25 -0000
@@ -0,0 +1,44 @@
+$OpenBSD$
+
+Avoid careless dereferences outside the domain name buffer.
+Part of this is
+https://github.com/nmap/nmap/commit/3adaa69cb211b00f9bfc66263a56cbd87cc9e521
+
+Index: nmap_dns.cc
+--- nmap_dns.cc.orig
++++ nmap_dns.cc
+@@ -1352,7 +1352,7 @@ bool DNS::Factory::ptrToIp(const std::string &ptr, soc
+ memset(&ip, 0, sizeof(sockaddr_storage));
+
+ // Check whether the name ends with the IPv4 PTR domain
+- if (NULL != (p = strcasestr(cptr + ptr.length() + 1 - sizeof(C_IPV4_PTR_DOMAIN), C_IPV4_PTR_DOMAIN)))
++ if (ptr.length() >= sizeof(C_IPV4_PTR_DOMAIN) - 1 && NULL != (p = strcasestr(cptr + ptr.length() + 1 - sizeof(C_IPV4_PTR_DOMAIN), C_IPV4_PTR_DOMAIN)))
+ {
+ struct sockaddr_in *ip4 = (struct sockaddr_in *)&ip;
+ u8 place_value[] = {1, 10, 100};
+@@ -1361,7 +1361,7 @@ bool DNS::Factory::ptrToIp(const std::string &ptr, soc
+ size_t i = 0;
+
+ p--;
+- while (i < sizeof(ip4->sin_addr.s_addr))
++ while (p >= cptr && i < sizeof(ip4->sin_addr.s_addr))
+ {
+ if (*p == '.')
+ {
+@@ -1387,14 +1387,14 @@ bool DNS::Factory::ptrToIp(const std::string &ptr, soc
+ ip.ss_family = AF_INET;
+ }
+ // If not, check IPv6
+- else if (NULL != (p = strcasestr(cptr + ptr.length() + 1 - sizeof(C_IPV6_PTR_DOMAIN), C_IPV6_PTR_DOMAIN)))
++ else if (ptr.length() >= sizeof(C_IPV6_PTR_DOMAIN) - 1 && NULL != (p = strcasestr(cptr + ptr.length() + 1 - sizeof(C_IPV6_PTR_DOMAIN), C_IPV6_PTR_DOMAIN)))
+ {
+ struct sockaddr_in6 *ip6 = (struct sockaddr_in6 *)&ip;
+ u8 alt = 0;
+ size_t i=0;
+
+ p--;
+- while (i < sizeof(ip6->sin6_addr.s6_addr))
++ while (p >= cptr && i < sizeof(ip6->sin6_addr.s6_addr))
+ {
+ if (*p == '.')
+ {
> How about now?
Thanks, that's better.
I think the part of the diff which is the upstream fix is simple enough
that we do not need to worry about the license.
I'll land this in -current once the tree unlocks and will also land it
in 7.0-stable.
Index: Makefile
===================================================================
RCS file: /cvs/ports/net/nmap/Makefile,v
retrieving revision 1.140
diff -u -p -r1.140 Makefile
--- Makefile 20 Jul 2021 22:28:24 -0000 1.140
+++ Makefile 29 Sep 2021 16:36:20 -0000
@@ -7,6 +7,7 @@ MODPY_EGG_VERSION= 7.91
DISTNAME= nmap-${MODPY_EGG_VERSION}
PKGNAME-main= ${DISTNAME}
PKGNAME-zenmap= nmap-zenmap-${MODPY_EGG_VERSION}
+REVISION= 0
CATEGORIES= net security
MASTER_SITES= ${HOMEPAGE}/dist/
@@ -33,6 +34,7 @@ MODULES= lang/python \
lang/lua
MODPY_VERSION= ${MODPY_DEFAULT_VERSION_2}
+DEBUG_PACKAGES= ${BUILD_PACKAGES}
CONFIGURE_STYLE=autoconf
AUTOCONF_VERSION=2.69
Index: patches/patch-nmap_dns_cc
===================================================================
RCS file: patches/patch-nmap_dns_cc
diff -N patches/patch-nmap_dns_cc
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-nmap_dns_cc 29 Sep 2021 16:35:25 -0000
@@ -0,0 +1,44 @@
+$OpenBSD$
+
+Avoid careless dereferences outside the domain name buffer.
+Part of this is
+https://github.com/nmap/nmap/commit/3adaa69cb211b00f9bfc66263a56cbd87cc9e521
+
+Index: nmap_dns.cc
+--- nmap_dns.cc.orig
++++ nmap_dns.cc
+@@ -1352,7 +1352,7 @@ bool DNS::Factory::ptrToIp(const std::string &ptr, soc
+ memset(&ip, 0, sizeof(sockaddr_storage));
+
+ // Check whether the name ends with the IPv4 PTR domain
+- if (NULL != (p = strcasestr(cptr + ptr.length() + 1 - sizeof(C_IPV4_PTR_DOMAIN), C_IPV4_PTR_DOMAIN)))
++ if (ptr.length() >= sizeof(C_IPV4_PTR_DOMAIN) - 1 && NULL != (p = strcasestr(cptr + ptr.length() + 1 - sizeof(C_IPV4_PTR_DOMAIN), C_IPV4_PTR_DOMAIN)))
+ {
+ struct sockaddr_in *ip4 = (struct sockaddr_in *)&ip;
+ u8 place_value[] = {1, 10, 100};
+@@ -1361,7 +1361,7 @@ bool DNS::Factory::ptrToIp(const std::string &ptr, soc
+ size_t i = 0;
+
+ p--;
+- while (i < sizeof(ip4->sin_addr.s_addr))
++ while (p >= cptr && i < sizeof(ip4->sin_addr.s_addr))
+ {
+ if (*p == '.')
+ {
+@@ -1387,14 +1387,14 @@ bool DNS::Factory::ptrToIp(const std::string &ptr, soc
+ ip.ss_family = AF_INET;
+ }
+ // If not, check IPv6
+- else if (NULL != (p = strcasestr(cptr + ptr.length() + 1 - sizeof(C_IPV6_PTR_DOMAIN), C_IPV6_PTR_DOMAIN)))
++ else if (ptr.length() >= sizeof(C_IPV6_PTR_DOMAIN) - 1 && NULL != (p = strcasestr(cptr + ptr.length() + 1 - sizeof(C_IPV6_PTR_DOMAIN), C_IPV6_PTR_DOMAIN)))
+ {
+ struct sockaddr_in6 *ip6 = (struct sockaddr_in6 *)&ip;
+ u8 alt = 0;
+ size_t i=0;
+
+ p--;
+- while (i < sizeof(ip6->sin6_addr.s6_addr))
++ while (p >= cptr && i < sizeof(ip6->sin6_addr.s6_addr))
+ {
+ if (*p == '.')
+ {
Re: nmap segfault fix
How about now?
-JR
On Wed, Sep 29, 2021 at 8:59 AM Theo Buehler <tb@theobuehler.org> wrote:
> On Wed, Sep 29, 2021 at 08:49:06AM -0700, JR Aquino wrote:
> > Thanks Niklas!
> >
> > The patches apply, build, and run cleanly.
>
> The patches did not make it to the list.
>
> >
> > The fix makes sense to incorporate in our OpenBSD port for nmap 7.91, but
> > we should revisit it in the future with any new upstream releases in case
> > there are subtle changes from what is in their github repo today.
> >
> > Unless anyone else has strong opinions, I'm good with the patches and
> would
> > like to ask another port maintainer with CVS privileges to review and
> > commit.
> >
> > -JR
> >
> > On Wed, Sep 29, 2021 at 8:37 AM Niklas Hallqvist <niklas@appli.se>
> wrote:
> >
> > > Hi!
> > >
> > > While testing 7.0 packages I got an nmap segfault. It has been fixed
> > > upstream in their github, but I don't know if it's part of any release
> yet.
> > >
> > > However their fix may be incomplete as there are other opportunities
> for
> > > a negative buffer overflow in nmap_dns.cc, at least without knowing all
> > > callers of the ptrToIp method.
> > >
> > > I attach a patch that works for me (tm) as well as a patch to add a
> > > debug package for nmap, which was needed for me to debug this issue.
> > >
> > > Even if its too late for 7.0, at least the segfault fix might make
> > > 7.0-stable package, I reckon.
> > >
> > > The fault is indeterministic, and triggered by a PTR name being aligned
> > > at the beginning of a page immediately preceded by an unmapped page.
> > > The case which triggers it fairly often for me was just a nmap of a
> > > single TCP port over some seven or so /24-networks.
> > >
> > > /Niklas
> > >
>
-JR
On Wed, Sep 29, 2021 at 8:59 AM Theo Buehler <tb@theobuehler.org> wrote:
> On Wed, Sep 29, 2021 at 08:49:06AM -0700, JR Aquino wrote:
> > Thanks Niklas!
> >
> > The patches apply, build, and run cleanly.
>
> The patches did not make it to the list.
>
> >
> > The fix makes sense to incorporate in our OpenBSD port for nmap 7.91, but
> > we should revisit it in the future with any new upstream releases in case
> > there are subtle changes from what is in their github repo today.
> >
> > Unless anyone else has strong opinions, I'm good with the patches and
> would
> > like to ask another port maintainer with CVS privileges to review and
> > commit.
> >
> > -JR
> >
> > On Wed, Sep 29, 2021 at 8:37 AM Niklas Hallqvist <niklas@appli.se>
> wrote:
> >
> > > Hi!
> > >
> > > While testing 7.0 packages I got an nmap segfault. It has been fixed
> > > upstream in their github, but I don't know if it's part of any release
> yet.
> > >
> > > However their fix may be incomplete as there are other opportunities
> for
> > > a negative buffer overflow in nmap_dns.cc, at least without knowing all
> > > callers of the ptrToIp method.
> > >
> > > I attach a patch that works for me (tm) as well as a patch to add a
> > > debug package for nmap, which was needed for me to debug this issue.
> > >
> > > Even if its too late for 7.0, at least the segfault fix might make
> > > 7.0-stable package, I reckon.
> > >
> > > The fault is indeterministic, and triggered by a PTR name being aligned
> > > at the beginning of a page immediately preceded by an unmapped page.
> > > The case which triggers it fairly often for me was just a nmap of a
> > > single TCP port over some seven or so /24-networks.
> > >
> > > /Niklas
> > >
>
Re: nmap segfault fix
On Wed, Sep 29, 2021 at 08:49:06AM -0700, JR Aquino wrote:
> Thanks Niklas!
>
> The patches apply, build, and run cleanly.
The patches did not make it to the list.
>
> The fix makes sense to incorporate in our OpenBSD port for nmap 7.91, but
> we should revisit it in the future with any new upstream releases in case
> there are subtle changes from what is in their github repo today.
>
> Unless anyone else has strong opinions, I'm good with the patches and would
> like to ask another port maintainer with CVS privileges to review and
> commit.
>
> -JR
>
> On Wed, Sep 29, 2021 at 8:37 AM Niklas Hallqvist <niklas@appli.se> wrote:
>
> > Hi!
> >
> > While testing 7.0 packages I got an nmap segfault. It has been fixed
> > upstream in their github, but I don't know if it's part of any release yet.
> >
> > However their fix may be incomplete as there are other opportunities for
> > a negative buffer overflow in nmap_dns.cc, at least without knowing all
> > callers of the ptrToIp method.
> >
> > I attach a patch that works for me (tm) as well as a patch to add a
> > debug package for nmap, which was needed for me to debug this issue.
> >
> > Even if its too late for 7.0, at least the segfault fix might make
> > 7.0-stable package, I reckon.
> >
> > The fault is indeterministic, and triggered by a PTR name being aligned
> > at the beginning of a page immediately preceded by an unmapped page.
> > The case which triggers it fairly often for me was just a nmap of a
> > single TCP port over some seven or so /24-networks.
> >
> > /Niklas
> >
> Thanks Niklas!
>
> The patches apply, build, and run cleanly.
The patches did not make it to the list.
>
> The fix makes sense to incorporate in our OpenBSD port for nmap 7.91, but
> we should revisit it in the future with any new upstream releases in case
> there are subtle changes from what is in their github repo today.
>
> Unless anyone else has strong opinions, I'm good with the patches and would
> like to ask another port maintainer with CVS privileges to review and
> commit.
>
> -JR
>
> On Wed, Sep 29, 2021 at 8:37 AM Niklas Hallqvist <niklas@appli.se> wrote:
>
> > Hi!
> >
> > While testing 7.0 packages I got an nmap segfault. It has been fixed
> > upstream in their github, but I don't know if it's part of any release yet.
> >
> > However their fix may be incomplete as there are other opportunities for
> > a negative buffer overflow in nmap_dns.cc, at least without knowing all
> > callers of the ptrToIp method.
> >
> > I attach a patch that works for me (tm) as well as a patch to add a
> > debug package for nmap, which was needed for me to debug this issue.
> >
> > Even if its too late for 7.0, at least the segfault fix might make
> > 7.0-stable package, I reckon.
> >
> > The fault is indeterministic, and triggered by a PTR name being aligned
> > at the beginning of a page immediately preceded by an unmapped page.
> > The case which triggers it fairly often for me was just a nmap of a
> > single TCP port over some seven or so /24-networks.
> >
> > /Niklas
> >
Re: nmap segfault fix
Thanks Niklas!
The patches apply, build, and run cleanly.
The fix makes sense to incorporate in our OpenBSD port for nmap 7.91, but
we should revisit it in the future with any new upstream releases in case
there are subtle changes from what is in their github repo today.
Unless anyone else has strong opinions, I'm good with the patches and would
like to ask another port maintainer with CVS privileges to review and
commit.
-JR
On Wed, Sep 29, 2021 at 8:37 AM Niklas Hallqvist <niklas@appli.se> wrote:
> Hi!
>
> While testing 7.0 packages I got an nmap segfault. It has been fixed
> upstream in their github, but I don't know if it's part of any release yet.
>
> However their fix may be incomplete as there are other opportunities for
> a negative buffer overflow in nmap_dns.cc, at least without knowing all
> callers of the ptrToIp method.
>
> I attach a patch that works for me (tm) as well as a patch to add a
> debug package for nmap, which was needed for me to debug this issue.
>
> Even if its too late for 7.0, at least the segfault fix might make
> 7.0-stable package, I reckon.
>
> The fault is indeterministic, and triggered by a PTR name being aligned
> at the beginning of a page immediately preceded by an unmapped page.
> The case which triggers it fairly often for me was just a nmap of a
> single TCP port over some seven or so /24-networks.
>
> /Niklas
>
The patches apply, build, and run cleanly.
The fix makes sense to incorporate in our OpenBSD port for nmap 7.91, but
we should revisit it in the future with any new upstream releases in case
there are subtle changes from what is in their github repo today.
Unless anyone else has strong opinions, I'm good with the patches and would
like to ask another port maintainer with CVS privileges to review and
commit.
-JR
On Wed, Sep 29, 2021 at 8:37 AM Niklas Hallqvist <niklas@appli.se> wrote:
> Hi!
>
> While testing 7.0 packages I got an nmap segfault. It has been fixed
> upstream in their github, but I don't know if it's part of any release yet.
>
> However their fix may be incomplete as there are other opportunities for
> a negative buffer overflow in nmap_dns.cc, at least without knowing all
> callers of the ptrToIp method.
>
> I attach a patch that works for me (tm) as well as a patch to add a
> debug package for nmap, which was needed for me to debug this issue.
>
> Even if its too late for 7.0, at least the segfault fix might make
> 7.0-stable package, I reckon.
>
> The fault is indeterministic, and triggered by a PTR name being aligned
> at the beginning of a page immediately preceded by an unmapped page.
> The case which triggers it fairly often for me was just a nmap of a
> single TCP port over some seven or so /24-networks.
>
> /Niklas
>
Subscribe to:
Posts (Atom)