From: Mark Kettenis Subject: Re: installer: defer installboot to pick up apple-boot firmware To: "Theo de Raadt" Cc: tech@openbsd.org Date: Tue, 09 Apr 2024 22:20:28 +0200 > From: "Theo de Raadt" > Date: Tue, 09 Apr 2024 13:11:55 -0600 > > Stuart Henderson 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. > > 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. There may be a better we to solve the first install issue. If we provide our own zip file with boot firmware, bootloader and bsd.rd for the Asahi installer, we can make sure the right boot firmware is used.