On Sun, Mar 29, 2020 at 08:11:16PM -0700, Nathan Whitehorn wrote: > > > On 2020-03-29 20:02, Simon J. Gerraty wrote: > > Nathan Whitehorn <nwhiteh...@freebsd.org> wrote: > >> It's basically this that has been the problem: we need a way to manage > >> updates of the EFI loader in this situation, which we don't currently > >> have. The ESP needs to be mounted at a standard point, > >> installworld/freebsd-update/etc. need to know to replace files there, we > >> need to fall back cleanly on older systems, etc. The original (failed -- > > Actually if you are doing secure boot, the *last* thing you want is to > > update /efi/boot with an unsigned update. > > > > So I would think it should be done as a unique operation - do you don't > > do it accidentally. > > > > At least that's how I'm handling it for embedded devices. > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > > > The problem then is that we have treated loader as a > continuously-updatable part of the OS, like the kernel, and the update > system and development process assumes they get updated in sync.
I do not see problems with boot1.efi. I use it in a way you described: I put it on ESP (in fact manually, but it does not matter) and only update loader.efi on /root. This works quite satisfactory for my updates 11->12-13 CURRENT and stable. I would highly prefer this model was not broken, whatever additional update options for loader are added. It is zero-maintaince for me. _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
