On Tue, Apr 09, 2024 at 01:11:55PM -0600, Theo de Raadt wrote:
> Stuart Henderson <stu@spacehopper.org> wrote:
> 
> > On 2024/04/09 14:52, Klemens Nanni wrote:
> > > On Sun, Apr 07, 2024 at 01:17:16PM -0600, Theo de Raadt wrote:
> > > > > If fw_update hangs are a real problem, they should be fixed;  this isn't
> > > > > the only place we run fw_update.
> > > > 
> > > > fw_update is the first time we actually depend upon internet working.
> > > > I've seen it not work, and I've seen it slap against a proxy for a while
> > > > thinking it will work.  Regardless, let's say it times out.  (Meaning,
> > > > we must make sure it gives up quickly, and nicely.  I think afresh1 designed
> > > > that into the new one).
> > > > 
> > > > In that case, do you have the files neccessary to proceed?
> > > 
> > > With install?  Sure, installboot works the same, whether fw_update
> > > ran or failed before or after.
> > > 
> > > > 
> > > > If we do, that's OK.
> > > > 
> > > > So it mostly comes down to fw_update must not hangs. If it hangs, people
> > > > hit the power button.  Now the machine is not bootable.
> > > 
> > > If we do fw_update before installboot (my diff) and people force-reboot
> > > their machine, then no, fresh^Wpartial installs won't boot as boot blocks
> > > haven't been installed, but what do you expect of manually aborted installs?
> > > 
> > > Upgrades abrupted this way ought to still boot from their root disk,
> > > unless there's a bootloader/kernel compat break or filesystem damage from
> > > resetting the box or whatever...
> > 
> > Remember that machines booting in this way maybe remote installs
> > or repairs where someone has manually put a USB stick in to a machine
> > somewhere else in the world and set a temporary boot device as a
> > one-off.
> > 
> > It can be quite helpful in those cases if the installer can try to
> > leave the machine bootable as early as possible (and definitely if
> > network is broken; you might be trying to mend a machine which is
> > providing the network and things may be in a state where connections
> > hang rather than terminate quickly).
> 
> Yes, I agree strongly.
> 
> Trying to be too clever can hurt us.  On a majority or our machines,
> installboot is independent of fw_update.  We should not allow a fw_update
> issue (like any sort of freeze) to result in such machines being broken.

Sure, then we keep trying our best to leave users with a usable install.

Thanks for the input.

> Do not allow the obscure needs of 1 architecture to break other
> architectures.  The previous fw_update positioning in the script was
> PERFECT, meaning, we landed it in that sequence more than a decade ago.
> 
> So there's two choices.
> 
> Either we work harder to make sure the booting firwares are present
> ahead of time, via other data flows, and skip this change.
>    or
> 
> We installboot twice.

Let's do that now and not stop improving on it.

I'll look at how to best do the second run and send a diff soon.