/etc/rc.firsttime Runs Too Early?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

/etc/rc.firsttime Runs Too Early?

Ken.Hendrickson

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.

/etc/rc.firsttime DOES run correctly later, after DNS
resolving is working.

MORE INFO

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.

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.

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

Thanks,
Ken

PS  I didn't put fw_update in /etc/rc.firsttime.
    It was already there.

PPS  This week, I saw the problem with a Soekris Net5501,
     and also a PcEngines apu.1d4


 

CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient and may contain material that is proprietary, confidential, privileged or otherwise legally protected or restricted under applicable government laws. Any review, disclosure, distributing or other use without expressed permission of the sender is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies without reading, printing, or saving.


Reply | Threaded
Open this post in threaded view
|

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

Ken.Hendrickson
--- I asked:
> /etc/rc.firsttime Runs Too Early?  DNS issues.

MORE INFO:

I am putting all of /var/unbound and /var/nsd in my install scripts,
so they are fully installed before first boot.  In other words,
OpenBSD is starting nsd and unbound.  I am NOT starting them from
/etc/rc.firsttime, the first time the machine boots.

The lines in my /etc/rc.conf.local for nsd and unbound are:
nsd_flags=""
unbound_flags=""

Could this be the problem?

If it is, I see another issue to solve.  The normal OpenBSD install
system puts fw_update as the first line in /etc/rc.firsttime.
DNS must be working for fw_update to work.  What do I need to do
to have DNS working before /etc/rc.firsttime is run?

Thanks,
Ken



 

CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient and may contain material that is proprietary, confidential, privileged or otherwise legally protected or restricted under applicable government laws. Any review, disclosure, distributing or other use without expressed permission of the sender is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies without reading, printing, or saving.


Reply | Threaded
Open this post in threaded view
|

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

Stuart Henderson
In reply to this post by Ken.Hendrickson
On 2020/07/15 02:32, [hidden email] 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?

Reply | Threaded
Open this post in threaded view
|

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

Theo de Raadt-2
Stuart Henderson <[hidden email]> wrote:

> On 2020/07/15 02:32, [hidden email] 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.