Re: How do I get the man page for a package I haven't installed yet?

[Eric Furman]

Let us say just for example I am running Mono on Windows OS.
If I need to look at docs would I go to Microsoft.com?
Of course I wouldn't. That would be silly. I would go to Mono's
website. So why would people think that all the ports docs should
be at OpenBSD.com?

Re: How do I get the man page for a package I haven't installed yet?

[Jordan Geoghegan]

On 2020-06-26 20:03, Theo de Raadt wrote:

Jordan Geoghegan  wrote:


On 2020-06-26 18:45, Theo de Raadt wrote:

Jordan Geoghegan  wrote:



On 2020-06-26 13:43, Marc Espie wrote:

On Tue, Jun 23, 2020 at 12:20:35PM -0600, Theo de Raadt wrote:

Ottavio Caruso  wrote:


Hi,

Unless I've got it all wrong,  will only
display man pages for programs and commands in base. Is there a way to
display the man page for a package/port I haven't installed and/or
downloaded yet? (This assumes I haven't downloaded the ports cvs
tree).

Doing that would be very annoying and painful, and very few people
would want it.  It would also substantially degrade the clarity at
man.openbsd.org

Actually, it ought to be feasible to have the same mechanism in place for
base  as a third party mechanism.

I don't think it would be that difficult to setup, this obviously ought to
be separate from the main OpenBSD installation, as the quality of manpages
from ports is often not up-to-par compared to base.

Both Ingo and naddy and I, we've been routinely passing all manpages from
all packages through groff and mandoc and makewhatis to the point that
over 99% of them would be clean for a usage similar to man.openbsd.org


FreeBSD appears to offer manual pages from ports on their man page
website: https://www.freebsd.org/cgi/man.cgi

Not advocating for anything, just thought I'd point it out.

Completely irrelevant.


I thought it was relevant for folks looking for http access to ports
manpages, as the FreeBSD and OpenBSD ports trees overlap
significantly. I often use that site when I'm on a machine that
doesn't happen to have the particular package installed whose manpage
I want to view.

It is very easy for outsiders to ask a project to do more, MORE MORE
MORE, and not understand there are a limited number of people doing the
work.

So if this gets done, something else will not get done, or will get done
less well.

And it will be your fault.




I wasn't asking for anything, I was just trying to be helpful and share 
a resource I've personally found useful. I don't feel strongly about any 
of this, so consider the conversation over.


Regards,

Jordan

Re: How do I get the man page for a package I haven't installed yet?

[Theo de Raadt]

Jordan Geoghegan  wrote:

> On 2020-06-26 18:45, Theo de Raadt wrote:
> > Jordan Geoghegan  wrote:
> >
> >>
> >>
> >> On 2020-06-26 13:43, Marc Espie wrote:
> >>> On Tue, Jun 23, 2020 at 12:20:35PM -0600, Theo de Raadt wrote:
>  Ottavio Caruso  wrote:
> 
> > Hi,
> >
> > Unless I've got it all wrong,  will only
> > display man pages for programs and commands in base. Is there a way to
> > display the man page for a package/port I haven't installed and/or
> > downloaded yet? (This assumes I haven't downloaded the ports cvs
> > tree).
>  Doing that would be very annoying and painful, and very few people
>  would want it.  It would also substantially degrade the clarity at
>  man.openbsd.org
> >>> Actually, it ought to be feasible to have the same mechanism in place for
> >>> base  as a third party mechanism.
> >>>
> >>> I don't think it would be that difficult to setup, this obviously ought to
> >>> be separate from the main OpenBSD installation, as the quality of manpages
> >>> from ports is often not up-to-par compared to base.
> >>>
> >>> Both Ingo and naddy and I, we've been routinely passing all manpages from
> >>> all packages through groff and mandoc and makewhatis to the point that
> >>> over 99% of them would be clean for a usage similar to man.openbsd.org
> >>>
> >> FreeBSD appears to offer manual pages from ports on their man page
> >> website: https://www.freebsd.org/cgi/man.cgi
> >>
> >> Not advocating for anything, just thought I'd point it out.
> > Completely irrelevant.
> >
> 
> I thought it was relevant for folks looking for http access to ports
> manpages, as the FreeBSD and OpenBSD ports trees overlap
> significantly. I often use that site when I'm on a machine that
> doesn't happen to have the particular package installed whose manpage
> I want to view.

It is very easy for outsiders to ask a project to do more, MORE MORE
MORE, and not understand there are a limited number of people doing the
work.

So if this gets done, something else will not get done, or will get done
less well.

And it will be your fault.

Re: How do I get the man page for a package I haven't installed yet?

[Jordan Geoghegan]

On 2020-06-26 18:45, Theo de Raadt wrote:

Jordan Geoghegan  wrote:




On 2020-06-26 13:43, Marc Espie wrote:

On Tue, Jun 23, 2020 at 12:20:35PM -0600, Theo de Raadt wrote:

Ottavio Caruso  wrote:


Hi,

Unless I've got it all wrong,  will only
display man pages for programs and commands in base. Is there a way to
display the man page for a package/port I haven't installed and/or
downloaded yet? (This assumes I haven't downloaded the ports cvs
tree).

Doing that would be very annoying and painful, and very few people
would want it.  It would also substantially degrade the clarity at
man.openbsd.org

Actually, it ought to be feasible to have the same mechanism in place for
base  as a third party mechanism.

I don't think it would be that difficult to setup, this obviously ought to
be separate from the main OpenBSD installation, as the quality of manpages
from ports is often not up-to-par compared to base.

Both Ingo and naddy and I, we've been routinely passing all manpages from
all packages through groff and mandoc and makewhatis to the point that
over 99% of them would be clean for a usage similar to man.openbsd.org


FreeBSD appears to offer manual pages from ports on their man page
website: https://www.freebsd.org/cgi/man.cgi

Not advocating for anything, just thought I'd point it out.

Completely irrelevant.



I thought it was relevant for folks looking for http access to ports 
manpages, as the FreeBSD and OpenBSD ports trees overlap significantly. 
I often use that site when I'm on a machine that doesn't happen to have 
the particular package installed whose manpage I want to view.


Regards,

Jordan

Re: How do I get the man page for a package I haven't installed yet?

[Theo de Raadt]

Jordan Geoghegan  wrote:

> 
> 
> 
> On 2020-06-26 13:43, Marc Espie wrote:
> > On Tue, Jun 23, 2020 at 12:20:35PM -0600, Theo de Raadt wrote:
> >> Ottavio Caruso  wrote:
> >>
> >>> Hi,
> >>>
> >>> Unless I've got it all wrong,  will only
> >>> display man pages for programs and commands in base. Is there a way to
> >>> display the man page for a package/port I haven't installed and/or
> >>> downloaded yet? (This assumes I haven't downloaded the ports cvs
> >>> tree).
> >> Doing that would be very annoying and painful, and very few people
> >> would want it.  It would also substantially degrade the clarity at
> >> man.openbsd.org
> > Actually, it ought to be feasible to have the same mechanism in place for
> > base  as a third party mechanism.
> >
> > I don't think it would be that difficult to setup, this obviously ought to
> > be separate from the main OpenBSD installation, as the quality of manpages
> > from ports is often not up-to-par compared to base.
> >
> > Both Ingo and naddy and I, we've been routinely passing all manpages from
> > all packages through groff and mandoc and makewhatis to the point that
> > over 99% of them would be clean for a usage similar to man.openbsd.org
> >
> 
> FreeBSD appears to offer manual pages from ports on their man page
> website: https://www.freebsd.org/cgi/man.cgi
> 
> Not advocating for anything, just thought I'd point it out.

Completely irrelevant.

Re: OpenBSD Readonly File System

[Marko Cupać]

On 2020-06-24, Aaron Mason  wrote:
Auto filesystem repair is bad juju.



On 2020-06-25 11:17, Stuart Henderson wrote:
Nonsense. For many, the possible downsides of automatically running
fsck -y are much less a problem than the downsides of *not* running it.


Some time ago I wrote here on misc@ about read-only setup, where I 
intended to modify rc(8) in order to be able to relink kernel before 
mounting filesystems read-only, and - if I remember correctly - I was 
warned never to modify rc(8) directly as it's considered as part of base 
system, and I should only affect it with rc.local, which I did.


Is there a way to run fsck -y automatically without modifying rc(8)? Is 
modifying rc(8) now supported?


--
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

disklabel: autoalloc failed

[Rupert Gallagher]

Ref. disklabel(8)
> The maximum disk and partition size is 64PB.

Is that so? Let see...

OpenBSD 6.7 (GENERIC.MP) #2: Thu Jun  4 09:55:08 MDT 2020

$> doas dmesg | grep sd3
sd3 at scsibus2 targ 2 lun 0:  naa.5000c500c3ad5c90
sd3: 4769307MB, 512 bytes/sector, 9767541168 sectors

$> doas disklabel -p t sd3
# /dev/rsd3c:
type: SCSI
disk: SCSI disk
label: ST5000LM000-2AN1
duid: [omitted]
flags:
bytes/sector: 512
sectors/track: 255
tracks/cylinder: 511
sectors/cylinder: 130305
cylinders: 74959
total sectors: 9767541168 # total bytes: 4.5T
boundstart: 256
boundend: 4294852800
drivedata: 0

16 partitions:
#    size   offset  fstype [fsize bsize   cpg]
  c: 4.5T    0  unused

$> doas disklabel -E sd3
sd3> p t
OpenBSD area: 256-4294852800; size: 2.0T; free: 2.0T
..^^ :(
#    size   offset  fstype [fsize bsize   cpg]
  c: 4.5T    0  unused

$> echo "/ 4T" >label

$> doas disklabel -w -A -T label sd3
disklabel: autoalloc failed

:(

$> doas disklabel -E sd3
Label editor (enter '?' for help at any prompt)
sd3> p t
OpenBSD area: 256-4294852800; size: 2.0T; free: 2.0T
#size   offset  fstype [fsize bsize   cpg]
  c: 4.5T0  unused
sd3> a
partition: [a]
offset: [256]
size: [4294852544]
FS type: [4.2BSD]
sd3*> p t
OpenBSD area: 256-4294852800; size: 2.0T; free: 0.0T
#size   offset  fstype [fsize bsize   cpg]
  a: 2.0T  256  4.2BSD   8192 65536 1
  c: 4.5T0  unused
sd3*>

:(

Re: How do I get the man page for a package I haven't installed yet?

[Jordan Geoghegan]

On 2020-06-26 13:43, Marc Espie wrote:

On Tue, Jun 23, 2020 at 12:20:35PM -0600, Theo de Raadt wrote:

Ottavio Caruso  wrote:


Hi,

Unless I've got it all wrong,  will only
display man pages for programs and commands in base. Is there a way to
display the man page for a package/port I haven't installed and/or
downloaded yet? (This assumes I haven't downloaded the ports cvs
tree).

Doing that would be very annoying and painful, and very few people
would want it.  It would also substantially degrade the clarity at
man.openbsd.org

Actually, it ought to be feasible to have the same mechanism in place for
base  as a third party mechanism.

I don't think it would be that difficult to setup, this obviously ought to
be separate from the main OpenBSD installation, as the quality of manpages
from ports is often not up-to-par compared to base.

Both Ingo and naddy and I, we've been routinely passing all manpages from
all packages through groff and mandoc and makewhatis to the point that
over 99% of them would be clean for a usage similar to man.openbsd.org



FreeBSD appears to offer manual pages from ports on their man page 
website: https://www.freebsd.org/cgi/man.cgi


Not advocating for anything, just thought I'd point it out.

Re: How do I get the man page for a package I haven't installed yet?

[Marc Espie]

On Tue, Jun 23, 2020 at 12:20:35PM -0600, Theo de Raadt wrote:
> Ottavio Caruso  wrote:
> 
> > Hi,
> > 
> > Unless I've got it all wrong,  will only
> > display man pages for programs and commands in base. Is there a way to
> > display the man page for a package/port I haven't installed and/or
> > downloaded yet? (This assumes I haven't downloaded the ports cvs
> > tree).
> 
> Doing that would be very annoying and painful, and very few people
> would want it.  It would also substantially degrade the clarity at
> man.openbsd.org

Actually, it ought to be feasible to have the same mechanism in place for
base  as a third party mechanism.

I don't think it would be that difficult to setup, this obviously ought to
be separate from the main OpenBSD installation, as the quality of manpages
from ports is often not up-to-par compared to base.

Both Ingo and naddy and I, we've been routinely passing all manpages from
all packages through groff and mandoc and makewhatis to the point that
over 99% of them would be clean for a usage similar to man.openbsd.org

Re: disklabel: autoalloc failed

[Stuart Henderson]

On 2020-06-26, Rupert Gallagher  wrote:
> Ref. disklabel(8)
>> The maximum disk and partition size is 64PB.
>
> Is that so? Let see...

Yes, that is the maximum size for a disklabel

> OpenBSD 6.7 (GENERIC.MP) #2: Thu Jun  4 09:55:08 MDT 2020
>
> $> doas dmesg | grep sd3
> sd3 at scsibus2 targ 2 lun 0:  
> naa.5000c500c3ad5c90
> sd3: 4769307MB, 512 bytes/sector, 9767541168 sectors
>
> $> doas disklabel -p t sd3
> # /dev/rsd3c:
> type: SCSI
> disk: SCSI disk
> label: ST5000LM000-2AN1
> duid: [omitted]
> flags:
> bytes/sector: 512
> sectors/track: 255
> tracks/cylinder: 511
> sectors/cylinder: 130305
> cylinders: 74959
> total sectors: 9767541168 # total bytes: 4.5T
> boundstart: 256
> boundend: 4294852800
> drivedata: 0
>
> 16 partitions:
> #\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0
>  
> size\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0
>  offset\xc2\xa0 fstype [fsize bsize\xc2\xa0\xc2\xa0 cpg]
> \xc2\xa0 
> c:\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0
>  
> 4.5T\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0
>  0\xc2\xa0 unused
>
> $> doas disklabel -E sd3
> sd3> p t
> OpenBSD area: 256-4294852800; size: 2.0T; free: 2.0T

either use disklabel's "b" command to override the boundaries coming from
MBR and use larger ones in the disklabel (enter * for the end to use the
whole disk), or use GPT instead of MBR.

Re: disklabel: autoalloc failed

[Otto Moerbeek]

On Fri, Jun 26, 2020 at 05:53:24PM +, Rupert Gallagher wrote:

> Ref. disklabel(8)
> > The maximum disk and partition size is 64PB.
> 
> Is that so? Let see...
> 
> OpenBSD 6.7 (GENERIC.MP) #2: Thu Jun  4 09:55:08 MDT 2020
> 
> $> doas dmesg | grep sd3
> sd3 at scsibus2 targ 2 lun 0:  
> naa.5000c500c3ad5c90
> sd3: 4769307MB, 512 bytes/sector, 9767541168 sectors
> 
> $> doas disklabel -p t sd3
> # /dev/rsd3c:
> type: SCSI
> disk: SCSI disk
> label: ST5000LM000-2AN1
> duid: [omitted]
> flags:
> bytes/sector: 512
> sectors/track: 255
> tracks/cylinder: 511
> sectors/cylinder: 130305
> cylinders: 74959
> total sectors: 9767541168 # total bytes: 4.5T
> boundstart: 256
> boundend: 4294852800

Here's our problem. Use the b command to exend the OpenBSD to the
whole disk.

-Otto

> drivedata: 0
> 
> 16 partitions:
> #    size   offset  fstype [fsize bsize   cpg]
>   c: 4.5T    0  unused
> 
> $> doas disklabel -E sd3
> sd3> p t
> OpenBSD area: 256-4294852800; size: 2.0T; free: 2.0T
> ..^^ :(
> #    size   offset  fstype [fsize bsize   cpg]
>   c: 4.5T    0  unused
> 
> $> echo "/ 4T" >label
> 
> $> doas disklabel -w -A -T label sd3
> disklabel: autoalloc failed
> 
> :(
> 
> $> doas disklabel -E sd3
> Label editor (enter '?' for help at any prompt)
> sd3> p t
> OpenBSD area: 256-4294852800; size: 2.0T; free: 2.0T
> #size   offset  fstype [fsize bsize   cpg]
>   c: 4.5T0  unused
> sd3> a
> partition: [a]
> offset: [256]
> size: [4294852544]
> FS type: [4.2BSD]
> sd3*> p t
> OpenBSD area: 256-4294852800; size: 2.0T; free: 0.0T
> #size   offset  fstype [fsize bsize   cpg]
>   a: 2.0T  256  4.2BSD   8192 65536 1
>   c: 4.5T0  unused
> sd3*>
> 
> :(
> 

Re: disklabel: autoalloc failed

[Abel Abraham Camarillo Ojeda]

On Fri, Jun 26, 2020 at 1:43 PM Rupert Gallagher 
wrote:

> Ref. disklabel(8)
> > The maximum disk and partition size is 64PB.
>
> Is that so? Let see...
>
> OpenBSD 6.7 (GENERIC.MP) #2: Thu Jun  4 09:55:08 MDT 2020
>
> $> doas dmesg | grep sd3
> sd3 at scsibus2 targ 2 lun 0: 
> naa.5000c500c3ad5c90
> sd3: 4769307MB, 512 bytes/sector, 9767541168 sectors
>
> $> doas disklabel -p t sd3
> # /dev/rsd3c:
> type: SCSI
> disk: SCSI disk
> label: ST5000LM000-2AN1
> duid: [omitted]
> flags:
> bytes/sector: 512
> sectors/track: 255
> tracks/cylinder: 511
> sectors/cylinder: 130305
> cylinders: 74959
> total sectors: 9767541168 # total bytes: 4.5T
> boundstart: 256
> boundend: 4294852800
> drivedata: 0
>
> 16 partitions:
> #size   offset  fstype [fsize bsize   cpg]
>   c: 4.5T0  unused
>
> $> doas disklabel -E sd3
> sd3> p t
> OpenBSD area: 256-4294852800; size: 2.0T; free: 2.0T
> ..^^ :(
>

are you using MBR or GPT?


> #size   offset  fstype [fsize bsize   cpg]
>   c: 4.5T0  unused
>
> $> echo "/ 4T" >label
>
> $> doas disklabel -w -A -T label sd3
> disklabel: autoalloc failed
>
> :(
>
> $> doas disklabel -E sd3
> Label editor (enter '?' for help at any prompt)
> sd3> p t
> OpenBSD area: 256-4294852800; size: 2.0T; free: 2.0T
> #size   offset  fstype [fsize bsize   cpg]
>   c: 4.5T0  unused
> sd3> a
> partition: [a]
> offset: [256]
> size: [4294852544]
> FS type: [4.2BSD]
> sd3*> p t
> OpenBSD area: 256-4294852800; size: 2.0T; free: 0.0T
> #size   offset  fstype [fsize bsize   cpg]
>   a: 2.0T  256  4.2BSD   8192 65536 1
>   c: 4.5T0  unused
> sd3*>
>
> :(
>
>

Re: OpenBSD Readonly File System

[Vertigo Altair]

Hi,

Thanks to Stuart's recommendations, I made progress but got stuck at
another point:
When i mount /dev on fstab as this:
swap /dev mfs rw,async,noatime,nosuid,-s2M,-i8,-P/dev_src 0 0
Freeradius doesn't work. Here error message:
Error opening /dev/null: Permission denied

I've changed /dev/null permissions to _freeradius even made it 777.
But nothing changed.

Any thoughts?

On Thu, 25 Jun 2020 at 12:19, Stuart Henderson  wrote:

> > On Mon, Jun 22, 2020 at 4:24 PM Mogens Jensen
> > wrote:
> >> +# NOTE: The do_fsck() function has been patched to run 'fsck -y' if an
> >> +#  automatic file system check fails with exit code 8.
>
> I have quite a few machines patched like this.
>
> On 2020-06-24, Aaron Mason  wrote:
> > Auto filesystem repair is bad juju.
>
> Nonsense. For many, the possible downsides of automatically running
> fsck -y are much less a problem than the downsides of *not* running it.
>
> Even if there is corruption, there's still a fair chance the machine
> will come up far enough to fix things.
>
> What else is someone going to do other than OOB/drive/fly/whatever
> to the machine, press enter and type "fsck -y"? They're not going to
> suddenly try to backup a dirty fs where they wouldn't already have
> backups. Someone who cares about the data will already have a way
> to rebuild or restore from backups.
>
>
>

Re: IKEDv2 and alias addresses

[Sonic]

On Thu, Jun 25, 2020 at 4:10 PM Tobias Heider  wrote:
> I tried to reproduce your bug (on current) but it seems to work as intended
> for me.  It would certainly help to have a bit more info such as an iked log
> and a tcpdump of your failed handshake as well as the used openbsd version.

The passive side is a much older version. At this point Ikev1 is
working and once I update that box to current I'll most likely test
and, if successful, switch to Watchguard as rumor has it that its
performance is much better.

Thanks for your assistance!

Chris

Re: [Thunderbird] How to correctly set Mail-Followup-To header?

[Alessandro De Laurenzis]

I'm answering to my own question: that variable needs to be created... after 
that, the header is properly added.

Sorry for the noise


On June 25, 2020 5:55:49 PM GMT+02:00, Alessandro De Laurenzis 
 wrote:
>
>Greetings,
>
>Disclaimer: the topic isn't strictly OpenBSD related, but I'd love
>hearing comments from this community.
>
>I'm trying to get used (after a very long long time) to Thunderbird
>(mutt user for last 10 years or so...) and I'm struggling with mailing
>lists setting.
>
>In partucular, in mutt I declare the subscribed ones and the
>'Mail-Followup-To' header is automatically added:
>
>[...]
>> subscribe ^b...@openbsd.org$ ^misc@openbsd.org$ ^po...@openbsd.org$
>^t...@openbsd.org$
>> set followup_to = yes   # Prevent receiving
>duplicate copies of replies to messages sent to mailing lists
>> # Get a reply
>separately for any messages sent to known but not subscribed lists
>> set honor_followup_to = yes # Honor
>Mail-Followup-To header when group-replying to a message
>[...]
>
>For Thunderbird (68.9.0), I found this very well written wiki article
>[1], but 'mail.identity.default.subscribed_mailing_lists' preference
>seems not to be there anymore.
>
>Of course, I could always set the header by hand, adding it to
>'mail.compose.other.header', but I hope there is a smarter way...
>
>Any hints?
>
>All the best
>
>[1] 
>https://wiki.mozilla.org/Thunderbird:Help_Documentation:Mail-Followup-To_and_Mail-Reply-To
>
>-- 
>Alessandro De Laurenzis
>[mailto:jus...@atlantide.mooo.com]
>Web: http://www.atlantide.mooo.com
>LinkedIn: http://it.linkedin.com/in/delaurenzis

-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.

An Athn ar9280 client seems to require cold boots of late?

[Kevin Chadwick]

After upgrading via sysupgrade for a few releases, I have had to cold boot to
get dhclient athn0 working on an ar9280 in client mode.

Since my latest upgrade to a snapshot of Jun 17 kernel #275 with the previous
kernel being from Jun 2nd #237. I seem to have to cold boot after running
ifconfig athn0 down and then back up, where I'm *fairly* sure that I didn't need
to before that Jun 17th upgrade. ifconfig debug mode shows the wireless
handshake completing 4/4. Yet dhclient can't establish a link until cold booted.
A warm reboot does not resolve the problem.

Has anyone else seen this or can reproduce it?

I'll try a sysupgrade in the meantime but I'm not sure there has been any code
changes in areas that could resolve it.

Re: Suggestions re error: "USB read failed" accessing Infinite Noise TRNG?

[Chris Bennett]

On Thu, Jun 25, 2020 at 09:41:41PM +0200, Why 42? The lists account. wrote:
> 
> A quick search on the net didn't show much, apart from a suggestion that
> a USB keyboard won't work at this point because the USB subsystem hasn't
> yet been discovered (that was back in 2015 though). I'm using both a USB
> keyboard and mouse.

That is correct. Just to make sure everybody knows this. It is not
related to your problem.
Stuart's suggestion solves that problem. I have put that (for a
different problem) into my /etc/rc.shutdown. Which survives moving to a
newer snapshot or release.

Chris