periodic network access failure when accessing nextcloud via relayd
Hello,
I have Nextcloud 21 running with php-7.4, httpd(8) and relayd(8).
On my laptop, a script regularly runs nextcloudcmd to synchonize the files
with the nextcloud instance. And quite often, nextcloudcmd returns such error:
03-31 23:28:56:089 [ info nextcloud.sync.networkjob.lscol ]:LSCOL of
QUrl("https://nextcloud.tumfatig.net/remote.php/dav/files/user85419/Uploads;)
FINISHED
WITH STATUS "UnknownNetworkError Network access is disabled."
Both run OpenBSD 6.8/amd64.
It seems that it only happens when I access nextcloud via relayd. If I access
nextcloud straight via httpd, the error never pops up.
Running relayd in debug mode, I saw the following difference:
* when traffic works ok
relay https_lan, session 2 (1 active), 0, 192.168.1.76 -> :8083, done, [Host:
nextcloud.tumfatig.net] [User-Agent: Mozilla/5.0 (OpenBSD) mirall/3.0.1git
(Nextcloud)] [nextcloud.tumfatig.net/ocs/v1.php/cloud/capabilities:
format=json] GET
-> 127.0.0.1:8083; [Host: nextcloud.tumfatig.net] [User-Agent: Mozilla/5.0
(OpenBSD)
mirall/3.0.1git (Nextcloud)]
[nextcloud.tumfatig.net/remote.php/dav/files/user85419/Uploads] PROPFIND;
* when the error occurs
relay https_lan, session 1 (1 active), 0, 192.168.1.76 -> 127.0.0.1:8083, done,
[Host: nextcloud.tumfatig.net] [User-Agent: Mozilla/5.0 (OpenBSD)
mirall/3.0.1git
(Nextcloud)] [nextcloud.tumfatig.net/ocs/v1.php/cloud/capabilit
ies: format=json] GET -> 127.0.0.1:8083;
As you may notice, we can see "192.168.1.76 -> :8083" when it's working and
"192.168.1.76 -> 127.0.0.1:8083" when it fails. But I can't see the reason for
it in my relayd configuration. I've attached it to this mail.
Any thoughts on what I'm doing wrong?
Thank you,
Jo
# vim: ft=pf syntax=pf
lan_ip="192.168.1.1"
table { 127.0.0.1 }
table { 127.0.0.1 }
table { 127.0.0.1 }
log state changes
log connection
# HTTP ###
http protocol "http" {
match header log "Host"
match header log "X-Forwarded-For"
match header log "User-Agent"
match header log "Referer"
match url log
match header set "X-Forwarded-For" value "$REMOTE_ADDR"
match header set "X-Forwarded-By" value "$SERVER_ADDR:$SERVER_PORT"
match header set "Keep-Alive" value "$TIMEOUT"
match response header set "X-Powered-By" value "Powered by OpenBSD"
match request path "/.well-known/acme-challenge/*" forward to
tcp { nodelay, socket buffer 65536, backlog 100 }
}
relay "http" {
listen on $lan_ip port 80
protocol "http"
forward to port 8080 check tcp # HTTP to HTTPS redirection
forward to port 8081 check tcp # Let's Encrypt renewal
}
# HTTPS ##
http protocol "https" {
match header log "Host"
match header log "X-Forwarded-For"
match header log "User-Agent"
match header log "Referer"
match url log
match header set "X-Forwarded-For" value "$REMOTE_ADDR"
match header set "X-Forwarded-By" value
"$SERVER_ADDR:$SERVER_PORT"
match header set "Keep-Alive" value "$TIMEOUT"
match response header set "X-Powered-by" value "OpenBSD"
tcp { nodelay, socket buffer 65536, backlog 100 }
tls keypair nextcloud.tumfatig.net
# Default block
block request path "/*"
# Allow Let's Encrypt operations
pass request path "/.well-known/acme-challenge/*" forward to
# Nextcloud
pass request forward to
}
relay "https_lan" {
listen on $lan_ip port 443 tls
protocol "https"
forward to port 8081 check tcp # Let's Encrypt renewal
forward to port 8083 check tcp # Nextcloud
}
Re: Issue with Ubiquiti ERL upgrade from 6.7 to 6.8 via sysupgrade (octeon)
Yes, that was it... The bootcmd was set to 'fatload usb 0 $loadaddr bsd; bootoctlinux rootdev=/dev/sd0', which I had to change to 'fatload usb 0 $loadaddr boot; bootoctlinux rootdev=/dev/sd0' and then the upgrade went through fine. Thanks for the help, Theo. -Amarendra erl$ dmesg [ using 746200 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2020 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.8 (GENERIC.MP) #322: Sun Oct 4 21:22:50 MDT 2020 dera...@octeon.openbsd.org:/usr/src/sys/arch/octeon/compile/GENERIC.MP real mem = 536870912 (512MB) avail mem = 521469952 (497MB) random: good seed from bootblocks mainbus0 at root: board 20002 rev 2.18, model CN3xxx/CN5xxx cpu0 at mainbus0: CN50xx CPU rev 0.1 500 MHz, Software FP emulation cpu0: cache L1-I 32KB 4 way D 16KB 64 way, L2 128KB 8 way clock0 at mainbus0: int 5 octcrypto0 at mainbus0 iobus0 at mainbus0 simplebus0 at iobus0: "soc" octciu0 at simplebus0 octsmi0 at simplebus0 octpip0 at simplebus0 octgmx0 at octpip0 interface 0 cnmac0 at octgmx0: port 0 RGMII, address 78:8a:20:46:a8:c0 atphy0 at cnmac0 phy 7: AR8035 10/100/1000 PHY, rev. 2 cnmac1 at octgmx0: port 1 RGMII, address 78:8a:20:46:a8:c1 atphy1 at cnmac1 phy 6: AR8035 10/100/1000 PHY, rev. 2 cnmac2 at octgmx0: port 2 RGMII, address 78:8a:20:46:a8:c2 atphy2 at cnmac2 phy 5: AR8035 10/100/1000 PHY, rev. 2 com0 at simplebus0: ns16550a, 64 byte fifo com0: console dwctwo0 at iobus0 base 0x118006800 irq 56 usb0 at dwctwo0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "Octeon DWC2 root hub" rev 2.00/1.00 addr 1 octrng0 at iobus0 base 0x14000 irq 0 umass0 at uhub0 port 1 configuration 1 interface 0 "Lexar USB Flash Drive" rev 2.10/11.00 addr 2 umass0: using SCSI over Bulk-Only scsibus0 at umass0: 2 targets, initiator 0 sd0 at scsibus0 targ 1 lun 0: removable serial.21c40cd1719080003000 sd0: 30526MB, 512 bytes/sector, 62517248 sectors vscsi0 at root scsibus1 at vscsi0: 256 targets softraid0 at root scsibus2 at softraid0: 256 targets root on sd0a (2124441bc835a462.a) swap on sd0b dump on sd0b WARNING: CHECK AND RESET THE DATE! On Wed, Mar 31, 2021 at 8:14 AM Theo de Raadt wrote: > your PROM is likely setup to boot a "bsd" kernel in the msdos partition, > rather than the "boot" file. The "boot" file will load /bsd from the ffs > partition. > > Amarendra Godbole wrote: > > > So I used sysupgrade to upgrade the ERL from 6.7 to 6.8. It went through > > everything fine, downloaded the sets, extracts, etc. and reboots. > However, > > it boots back into the old 6.7 kernel. I can see /bsd.upgrade created, > and > > /home/_sysupgrade is empty. but did not see any option to trigger the > > upgrade. I thought it should have been automatically handled by > sysupgrade. > > > > What did I miss? > > > > Thanks. > > > > -Amarendra > > > > > > erl# uname -a > > OpenBSD erl.lan 6.7 GENERIC.MP#134 octeon > > > > erl# ls -l > > total 79128 > > -rw-r--r-- 1 root wheel 578 May 7 2020 .cshrc > > -rw-r--r-- 1 root wheel 468 May 7 2020 .profile > > drwxr-xr-x 2 root wheel 512 May 7 2020 altroot > > -rw-r--r-- 1 root wheel 160 Mar 31 00:08 auto_upgrade.conf > > drwxr-xr-x 2 root wheel 1024 May 7 2020 bin > > -rwx-- 1 root wheel 7626800 Mar 31 00:10 bsd > > -rwx-- 1 root wheel 7623592 Mar 31 00:01 bsd.booted > > -rw--- 1 root wheel 8843608 May 7 2020 bsd.rd > > -rw--- 1 root wheel 7568260 May 7 2020 bsd.sp > > -rwx-- 1 root wheel 8823044 Mar 31 00:09 bsd.upgrade > > drwxr-xr-x 4 root wheel18432 Mar 31 00:10 dev > > drwxr-xr-x 23 root wheel 2048 Mar 31 00:11 etc > > drwxr-xr-x 4 root wheel 512 Oct 15 21:09 home > > drwxr-xr-x 2 root wheel 512 May 7 2020 mnt > > drwx-- 3 root wheel 512 Mar 31 01:30 root > > drwxr-xr-x 2 root wheel 1536 May 7 2020 sbin > > lrwxrwx--- 1 root wheel 11 May 7 2020 sys -> usr/src/sys > > drwxrwxrwt 6 root wheel 512 Mar 31 07:45 tmp > > drwxr-xr-x 16 root wheel 512 Sep 7 2020 usr > > drwxr-xr-x 23 root wheel 512 May 7 2020 var > > erl# > > > > erl# dmesg > > Copyright (c) 1982, 1986, 1989, 1991, 1993 > > The Regents of the University of California. All rights reserved. > > Copyright (c) 1995-2020 OpenBSD. All rights reserved. > > https://www.OpenBSD.org > > > > OpenBSD 6.7 (GENERIC.MP) #134: Thu May 7 16:05:06 MDT 2020 > > dera...@octeon.openbsd.org:/usr/src/sys/arch/octeon/compile/ > GENERIC.MP > > real mem = 536870912 (512MB) > > avail mem = 506740736 (483MB) > > mainbus0 at root: board 20002 rev 2.18 > > cpu0 at mainbus0: CN50xx CPU rev 0.1 500 MHz, Software FP emulation > > cpu0: cache L1-I 32KB 4 way D 16KB 64 way, L2 128KB 8 way > > cpu1 at mainbus0: CN50xx CPU rev 0.1 500 MHz, Software FP emulation > > cpu1: cache L1-I 32KB 4 way D 16KB 64 way, L2 128KB
Re: Issue with Ubiquiti ERL upgrade from 6.7 to 6.8 via sysupgrade (octeon)
your PROM is likely setup to boot a "bsd" kernel in the msdos partition, rather than the "boot" file. The "boot" file will load /bsd from the ffs partition. Amarendra Godbole wrote: > So I used sysupgrade to upgrade the ERL from 6.7 to 6.8. It went through > everything fine, downloaded the sets, extracts, etc. and reboots. However, > it boots back into the old 6.7 kernel. I can see /bsd.upgrade created, and > /home/_sysupgrade is empty. but did not see any option to trigger the > upgrade. I thought it should have been automatically handled by sysupgrade. > > What did I miss? > > Thanks. > > -Amarendra > > > erl# uname -a > OpenBSD erl.lan 6.7 GENERIC.MP#134 octeon > > erl# ls -l > total 79128 > -rw-r--r-- 1 root wheel 578 May 7 2020 .cshrc > -rw-r--r-- 1 root wheel 468 May 7 2020 .profile > drwxr-xr-x 2 root wheel 512 May 7 2020 altroot > -rw-r--r-- 1 root wheel 160 Mar 31 00:08 auto_upgrade.conf > drwxr-xr-x 2 root wheel 1024 May 7 2020 bin > -rwx-- 1 root wheel 7626800 Mar 31 00:10 bsd > -rwx-- 1 root wheel 7623592 Mar 31 00:01 bsd.booted > -rw--- 1 root wheel 8843608 May 7 2020 bsd.rd > -rw--- 1 root wheel 7568260 May 7 2020 bsd.sp > -rwx-- 1 root wheel 8823044 Mar 31 00:09 bsd.upgrade > drwxr-xr-x 4 root wheel18432 Mar 31 00:10 dev > drwxr-xr-x 23 root wheel 2048 Mar 31 00:11 etc > drwxr-xr-x 4 root wheel 512 Oct 15 21:09 home > drwxr-xr-x 2 root wheel 512 May 7 2020 mnt > drwx-- 3 root wheel 512 Mar 31 01:30 root > drwxr-xr-x 2 root wheel 1536 May 7 2020 sbin > lrwxrwx--- 1 root wheel 11 May 7 2020 sys -> usr/src/sys > drwxrwxrwt 6 root wheel 512 Mar 31 07:45 tmp > drwxr-xr-x 16 root wheel 512 Sep 7 2020 usr > drwxr-xr-x 23 root wheel 512 May 7 2020 var > erl# > > erl# dmesg > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > Copyright (c) 1995-2020 OpenBSD. All rights reserved. > https://www.OpenBSD.org > > OpenBSD 6.7 (GENERIC.MP) #134: Thu May 7 16:05:06 MDT 2020 > dera...@octeon.openbsd.org:/usr/src/sys/arch/octeon/compile/GENERIC.MP > real mem = 536870912 (512MB) > avail mem = 506740736 (483MB) > mainbus0 at root: board 20002 rev 2.18 > cpu0 at mainbus0: CN50xx CPU rev 0.1 500 MHz, Software FP emulation > cpu0: cache L1-I 32KB 4 way D 16KB 64 way, L2 128KB 8 way > cpu1 at mainbus0: CN50xx CPU rev 0.1 500 MHz, Software FP emulation > cpu1: cache L1-I 32KB 4 way D 16KB 64 way, L2 128KB 8 way > clock0 at mainbus0: int 5 > octcrypto0 at mainbus0 > iobus0 at mainbus0 > simplebus0 at iobus0: "soc" > octciu0 at simplebus0 > octsmi0 at simplebus0 > octpip0 at simplebus0 > octgmx0 at octpip0 interface 0 > cnmac0 at octgmx0: RGMII, address 78:8a:20:46:a8:c0 > atphy0 at cnmac0 phy 7: AR8035 10/100/1000 PHY, rev. 2 > cnmac1 at octgmx0: RGMII, address 78:8a:20:46:a8:c1 > atphy1 at cnmac1 phy 6: AR8035 10/100/1000 PHY, rev. 2 > cnmac2 at octgmx0: RGMII, address 78:8a:20:46:a8:c2 > atphy2 at cnmac2 phy 5: AR8035 10/100/1000 PHY, rev. 2 > com0 at simplebus0: ns16550a, 64 byte fifo > com0: console > dwctwo0 at iobus0 base 0x118006800 irq 56 > usb0 at dwctwo0: USB revision 2.0 > uhub0 at usb0 configuration 1 interface 0 "Octeon DWC2 root hub" rev > 2.00/1.00 addr 1 > octrng0 at iobus0 base 0x14000 irq 0 > /dev/ksyms: Symbol table not valid. > umass0 at uhub0 port 1 configuration 1 interface 0 "Lexar USB Flash Drive" > rev 2.10/11.00 addr 2 > umass0: using SCSI over Bulk-Only > scsibus0 at umass0: 2 targets, initiator 0 > sd0 at scsibus0 targ 1 lun 0: removable > serial.21c40cd1719080003000 > sd0: 30526MB, 512 bytes/sector, 62517248 sectors > vscsi0 at root > scsibus1 at vscsi0: 256 targets > softraid0 at root > scsibus2 at softraid0: 256 targets > boot device: sd0 > root on sd0a (2124441bc835a462.a) swap on sd0b dump on sd0b > WARNING: No TOD clock, believing file system. > WARNING: CHECK AND RESET THE DATE!
Issue with Ubiquiti ERL upgrade from 6.7 to 6.8 via sysupgrade (octeon)
So I used sysupgrade to upgrade the ERL from 6.7 to 6.8. It went through everything fine, downloaded the sets, extracts, etc. and reboots. However, it boots back into the old 6.7 kernel. I can see /bsd.upgrade created, and /home/_sysupgrade is empty. but did not see any option to trigger the upgrade. I thought it should have been automatically handled by sysupgrade. What did I miss? Thanks. -Amarendra erl# uname -a OpenBSD erl.lan 6.7 GENERIC.MP#134 octeon erl# ls -l total 79128 -rw-r--r-- 1 root wheel 578 May 7 2020 .cshrc -rw-r--r-- 1 root wheel 468 May 7 2020 .profile drwxr-xr-x 2 root wheel 512 May 7 2020 altroot -rw-r--r-- 1 root wheel 160 Mar 31 00:08 auto_upgrade.conf drwxr-xr-x 2 root wheel 1024 May 7 2020 bin -rwx-- 1 root wheel 7626800 Mar 31 00:10 bsd -rwx-- 1 root wheel 7623592 Mar 31 00:01 bsd.booted -rw--- 1 root wheel 8843608 May 7 2020 bsd.rd -rw--- 1 root wheel 7568260 May 7 2020 bsd.sp -rwx-- 1 root wheel 8823044 Mar 31 00:09 bsd.upgrade drwxr-xr-x 4 root wheel18432 Mar 31 00:10 dev drwxr-xr-x 23 root wheel 2048 Mar 31 00:11 etc drwxr-xr-x 4 root wheel 512 Oct 15 21:09 home drwxr-xr-x 2 root wheel 512 May 7 2020 mnt drwx-- 3 root wheel 512 Mar 31 01:30 root drwxr-xr-x 2 root wheel 1536 May 7 2020 sbin lrwxrwx--- 1 root wheel 11 May 7 2020 sys -> usr/src/sys drwxrwxrwt 6 root wheel 512 Mar 31 07:45 tmp drwxr-xr-x 16 root wheel 512 Sep 7 2020 usr drwxr-xr-x 23 root wheel 512 May 7 2020 var erl# erl# dmesg Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2020 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.7 (GENERIC.MP) #134: Thu May 7 16:05:06 MDT 2020 dera...@octeon.openbsd.org:/usr/src/sys/arch/octeon/compile/GENERIC.MP real mem = 536870912 (512MB) avail mem = 506740736 (483MB) mainbus0 at root: board 20002 rev 2.18 cpu0 at mainbus0: CN50xx CPU rev 0.1 500 MHz, Software FP emulation cpu0: cache L1-I 32KB 4 way D 16KB 64 way, L2 128KB 8 way cpu1 at mainbus0: CN50xx CPU rev 0.1 500 MHz, Software FP emulation cpu1: cache L1-I 32KB 4 way D 16KB 64 way, L2 128KB 8 way clock0 at mainbus0: int 5 octcrypto0 at mainbus0 iobus0 at mainbus0 simplebus0 at iobus0: "soc" octciu0 at simplebus0 octsmi0 at simplebus0 octpip0 at simplebus0 octgmx0 at octpip0 interface 0 cnmac0 at octgmx0: RGMII, address 78:8a:20:46:a8:c0 atphy0 at cnmac0 phy 7: AR8035 10/100/1000 PHY, rev. 2 cnmac1 at octgmx0: RGMII, address 78:8a:20:46:a8:c1 atphy1 at cnmac1 phy 6: AR8035 10/100/1000 PHY, rev. 2 cnmac2 at octgmx0: RGMII, address 78:8a:20:46:a8:c2 atphy2 at cnmac2 phy 5: AR8035 10/100/1000 PHY, rev. 2 com0 at simplebus0: ns16550a, 64 byte fifo com0: console dwctwo0 at iobus0 base 0x118006800 irq 56 usb0 at dwctwo0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "Octeon DWC2 root hub" rev 2.00/1.00 addr 1 octrng0 at iobus0 base 0x14000 irq 0 /dev/ksyms: Symbol table not valid. umass0 at uhub0 port 1 configuration 1 interface 0 "Lexar USB Flash Drive" rev 2.10/11.00 addr 2 umass0: using SCSI over Bulk-Only scsibus0 at umass0: 2 targets, initiator 0 sd0 at scsibus0 targ 1 lun 0: removable serial.21c40cd1719080003000 sd0: 30526MB, 512 bytes/sector, 62517248 sectors vscsi0 at root scsibus1 at vscsi0: 256 targets softraid0 at root scsibus2 at softraid0: 256 targets boot device: sd0 root on sd0a (2124441bc835a462.a) swap on sd0b dump on sd0b WARNING: No TOD clock, believing file system. WARNING: CHECK AND RESET THE DATE!
Re: Gigenet Mirror x*69.tgz Failing to Verify Sets
On 2021-03-30, Charlie Burnett wrote: > Hi, > Currently the gigenet mirror is failing to verify for all four X packages > on snapshot. They verify fine when I point it towards cdn.openbsd.org, but > this is the case for both when trying to install from both bsd.rd and an > install iso. This is in a VM but I wouldn't see how that'd affect it. Oddly > enough, I just upgraded my personal machine earlier today without any > issues. Not sure what would need to be done about it, but I figured someone > oughta be told! > > Best Regards, > Charlie Burnett > It happens with snapshots from time to time. Try another mirror or wait a while.
Re: Documentation on OpenBSD's 3-process privsep model?
On 31/03/2021 04:46, Marc Espie wrote: On Tue, Mar 23, 2021 at 09:41:06AM +, Ottavio Caruso wrote: On 23/03/2021 05:53, misopolemiac wrote: I'd appreciate some pointers to documentation or minimal examples of the 3-process privilege separation model for OpenBSD's daemons. Internet searches pointed to skeleton examples at github.com/krwesterback/newd and github.com/krwesterback/newdctl, but those repos are now dead and it's unclear how authoritative they were in the first place. Blind leading the blind here, but I think a good starting point would be recent presentations by Marc Espie, who, I believe but I might be wrong, is the developer who worked the most on privsep. http://www.openbsd.org/events.html Definitely not at all. I haven't worked the most on privsep, by far. and the examples I've worked on are highly specific and probably not applicable to most of the base code. I was wrong then. My apologies. Still, it's worth giving a look at the events page. I have learnt a lot about OpenBSD going through all presentations and papers, despite understanding only 0.1% of the technical details. -- Ottavio Caruso
Re: Documentation on OpenBSD's 3-process privsep model?
On Mar 31, 2021 3:02 AM, Ottavio Caruso wrote: On 31/03/2021 04:46, Marc Espie wrote: > On Tue, Mar 23, 2021 at 09:41:06AM +, Ottavio Caruso wrote: >> On 23/03/2021 05:53, misopolemiac wrote: >>> I'd appreciate some pointers to documentation or minimal examples of >>> the 3-process privilege separation model for OpenBSD's daemons. >>> Internet searches pointed to skeleton examples at >>> github.com/krwesterback/newd and github.com/krwesterback/newdctl, but >>> those repos are now dead and it's unclear how authoritative they were >>> in the first place. >>> >>> >> >> Blind leading the blind here, but I think a good starting point would be >> recent presentations by Marc Espie, who, I believe but I might be wrong, is >> the developer who worked the most on privsep. >> >> http://www.openbsd.org/events.html > > Definitely not at all. > > I haven't worked the most on privsep, by far. > > and the examples I've worked on are highly specific and probably > not applicable to most of the base code. > > I was wrong then. My apologies. Still, it's worth giving a look at the events page. I have learnt a lot about OpenBSD going through all presentations and papers, despite understanding only 0.1% of the technical details. -- Ottavio Caruso I often use the source for identd as a template. It's a fairly simple daemon. So it's easy to gut it and rework it to fit your needs. Edgar
Re: cgit about-filter in chroot (httpd + slowcgi)
On 2021-03-28 19:33, Kristaps Dzonsons wrote: Instead of downloading, recompiling, and installing lowdown; then building and installing a program that execs the downloaded lowdown; why don't you cut out the first step and call through to the C API installed with the lowdown port? There's a full example in the EXAMPLES section of lowdown_file(3). Sorry Kristaps I didn't see this because I was not previous subscribed to the list. Thanks for pointing me in this direction, it does look like the optimal approach. At my current point in The C Programming Language book the example still looks like Greek to me (I'm not up to structs or pointers) but one day... Thanks!
gl.inet Brume (GL-MV1000): sdcard works with 6.8 but not -current
Hi.
I have a gl.inet GL-MV1000 aka Brume[0] and out of curiosity I tried
booting -current miniroot on it. The sdcard didn't work ("sdmmc0: can't
enable card" and I was going to chalk that up to it not ever having worked.
A bit later I later booted from the wrong previously used sdcard and
discovered that it worked in 6.8, and in fact would boot multiuser
including network.
It's not something that I'm looking to use for real, but if anyone is
interested in chasing this down I'm willing to test patches or kernels.
[0] https://www.gl-inet.com/products/gl-mv1000/
Marvell>> load mmc 0:1 ${fdt_addr} armada-gl-mv1000-emmc.dtb
8834 bytes read in 9 ms (958 KiB/s)
Marvell>> load mmc 1:1 ${kernel_addr} efi/boot/bootaa64.efi
reading efi/boot/bootaa64.efi
168968 bytes read in 46 ms (3.5 MiB/s)
Marvell>> bootefi ${kernel_addr} ${fdt_addr}
## Starting EFI application at 0500 ...
Scanning disk sd...@d8000.blk...
Scanning disk sd...@d.blk...
Found 2 disks
disks: sd0* sd1
>> OpenBSD/arm64 BOOTAA64 1.4
|/boot>
-\|cannot open sd0a:/etc/random.seed: No such file or directory
booting sd0a:/bsd: /2477748-\|/-+685596\|+8792352/+630936-
[204441\|+109+603192/+226352-\|/-]=0xff94f0
type 0x2 pa 0x0 va 0x0 pages 0x4000 attr 0x8
type 0x7 pa 0x400 va 0x0 pages 0x4000 attr 0x8
[... lots snipped ...]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2021 OpenBSD. All rights reserved. https://www.OpenBSD.org
OpenBSD 6.9-beta (RAMDISK) #1023: Thu Mar 25 13:33:07 MDT 2021
dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/RAMDISK
real mem = 1033142272 (985MB)
avail mem = 968544256 (923MB)
random: boothowto does not indicate good seed
mainbus0 at root: GL.inet GL-MV1000 (Marvell)
psci0 at mainbus0: PSCI 1.0
cpu0 at mainbus0 mpidr 0: ARM Cortex-A53 r0p4
cpu0: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache
cpu0: 256KB 64b/line 16-way L2 cache
cpu0: CRC32,SHA2,SHA1,AES+PMULL,ASID16
efi0 at mainbus0: UEFI 2.0.5
efi0: Das U-boot rev 0x0
agtimer0 at mainbus0: 12500 kHz
"pmu" at mainbus0 not configured
simplebus0 at mainbus0: "soc"
simplebus1 at simplebus0: "internal-regs"
mvclock0 at simplebus1
mvclock1 at simplebus1
mvclock2 at simplebus1
mvpinctrl0 at simplebus1
syscon0 at simplebus1: "syscon"
mvpinctrl1 at simplebus1
agintc0 at simplebus1 shift 4:3 nirq 224 nredist 2: "interrupt-controller"
"spi" at simplebus1 not configured
mvuart0 at simplebus1
mvneta0 at simplebus1
mvneta0: Ethernet address 94:83:c4:03:b0:d9
mvmdio0 at simplebus1: "mdio"
mvsw0 at mvmdio0 phy 1: 88E6141 rev 0
xhci0 at simplebus1, xHCI 1.0
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00
addr 1
"usb" at simplebus1 not configured
"u3d" at simplebus1 not configured
"udc" at simplebus1 not configured
"xor" at simplebus1 not configured
sdhc0 at simplebus1
sdhc0: SDHC 3.0, 400 MHz base clock
sdmmc0 at sdhc0: 4-bit, sd high-speed, mmc high-speed, dma
sdhc1 at simplebus1
sdhc1: SDHC 3.0, 400 MHz base clock
sdmmc1 at sdhc1: 8-bit, sd high-speed, mmc high-speed, ddr52, dma
"sata" at simplebus1 not configured
mvkpcie0 at simplebus0
mvkpcie0: timeout
"regulator" at mainbus0 not configured
sdmmc0: can't enable card
sdmmc1: can't enable card
softraid0 at root
scsibus0 at softraid0: 256 targets
root on rd0a swap on rd0b dump on rd0b
WARNING: CHECK AND RESET THE DATE!
erase ^?, werase ^W, kill ^U, intr ^C, status ^T
Welcome to the OpenBSD/arm64 6.9 installation program.
(I)nstall, (U)pgrade, (A)utoinstall or (S)hell? s
Compared to 6.8 bsd.rd:
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2020 OpenBSD. All rights reserved. https://www.OpenBSD.org
OpenBSD 6.8 (RAMDISK) #780: Sun Oct 4 20:57:28 MDT 2020
dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/RAMDISK
real mem = 1034010624 (986MB)
avail mem = 969404416 (924MB)
random: boothowto does not indicate good seed
mainbus0 at root: GL.inet GL-MV1000 (Marvell)
psci0 at mainbus0: PSCI 1.0
cpu0 at mainbus0 mpidr 0: ARM Cortex-A53 r0p4
cpu0: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache
cpu0: 256KB 64b/line 16-way L2 cache
efi0 at mainbus0: UEFI 2.0.5
efi0: Das U-boot rev 0x0
agtimer0 at mainbus0: tick rate 12500 KHz
"pmu" at mainbus0 not configured
simplebus0 at mainbus0: "soc"
simplebus1 at simplebus0: "internal-regs"
mvclock0 at simplebus1
mvclock1 at simplebus1
mvclock2 at simplebus1
mvpinctrl0 at simplebus1
syscon0 at simplebus1: "syscon"
mvpinctrl1 at simplebus1
agintc0 at simplebus1 shift 4:3 nirq 224 nredist 2: "interrupt-controller"
"spi" at simplebus1 not configured
mvuart0 at simplebus1
mvneta0 at simplebus1
mvneta0: Ethernet address 94:83:c4:03:b0:d9
mvmdio0 at simplebus1
xhci0 at simplebus1, xHCI 1.0
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev
