Re: /etc/rc.firsttime Runs Too Early?

[Theo de Raadt]

Stuart Henderson  wrote:

> On 2020/07/15 02:32, ken.hendrick...@l3harris.com wrote:
> > 
> > Perhaps I am doing something wrong.  Or maybe there is a bug.
> > 
> > I have done quite a few installs in the last couple of weeks,
> > and on first boot, /etc/rc.firsttime doesn't work.  It seems
> > that DNS isn't working yet, and perhaps /etc/rc.firsttime
> > runs too early in the process.
> 
> It needs to run early, because after updating the OS, daemons starting
> (including name server daemons) may depend on changes made by sysmerge.

"run_upgrade_script firsttime" actually occurs quite late in /etc/rc.
Majority of base daemons are started beforehands.

> > The failures are all due to DNS resolving not working yet.
> 
> So the only DNS server you list is on the local machine? This isn't the
> only place you'll have a problem - you will also have failures if you
> boot the install kernel and do an upgrade from there using a network
> source (which is where most people have run into this problem).

Indeed, something else is not working right.

> There are suggestions of doing something different for fw_update but
> changes there won't help your local commands that expect to have DNS
> before the daemon is running.

OP - I suggest you modify /etc/rc to diagnose this. Search for
"run_upgrade_script firsttime" in /etc/rc, and put some diagnostics
at that point.  Or, put some diagnostics into the firsttime script
itself.

Re: /etc/rc.firsttime Runs Too Early?

[Stuart Henderson]

On 2020/07/15 02:32, ken.hendrick...@l3harris.com wrote:
> 
> Perhaps I am doing something wrong.  Or maybe there is a bug.
> 
> I have done quite a few installs in the last couple of weeks,
> and on first boot, /etc/rc.firsttime doesn't work.  It seems
> that DNS isn't working yet, and perhaps /etc/rc.firsttime
> runs too early in the process.

It needs to run early, because after updating the OS, daemons starting
(including name server daemons) may depend on changes made by sysmerge.

> fw_update doesn't work when /etc/rc.firsttime runs, but it
> DOES work later.
> 
> I have added a bunch of stuff in my install scripts to
> /etc/rc.firsttime.  Specifically, I try to download and
> install sys.tar.gz, src.tar.gz, xenocara.tar.gz, and ports.tar.gz.
> None of them work when /etc/rc.firsttime runs on the first boot,
> but they all work later.
> 
> The failures are all due to DNS resolving not working yet.

So the only DNS server you list is on the local machine? This isn't the
only place you'll have a problem - you will also have failures if you
boot the install kernel and do an upgrade from there using a network
source (which is where most people have run into this problem).

> I must be doing something wrong.  Because I would be shocked
> if nobody else ever noticed this problem.  I first noticed
> that the wireless devices on the PcEngines apu.1d4 didn't work
> with OpenBSD starting in about 2016.  Only this week did I
> figure out that it was because fw_update wasn't working.

There are suggestions of doing something different for fw_update but
changes there won't help your local commands that expect to have DNS
before the daemon is running.

> So, is there a bug (not likely), or what am I doing wrong?

My recommendation would be to either run a second nameserver locally
and list both, or if you don't have another suitable machine, then
also list a nameserver on the internet (with overrides in /etc/hosts
if you need split-horizon dns).

Or for src.tar.gz etc, why not fetch them directly in install.site
rather than deferring to rc.firsttime?