On Sun, Mar 29, 2020 at 9:14 PM Nathan Whitehorn <nwhitehorn_at_freebsd.org> wrote: > > > On 2020-03-29 20:02, Simon J. Gerraty wrote: > > Nathan Whitehorn <nwhitehorn_at_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_at_freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscribe_at_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. > It's thorny issues like this which have led me to believe we need to have an install-loader target and separate it out just like we separate out world from kernel because the loader has become more like a kernel and it may need to be updated asynchronously to all other parts of the system. However, this also breaks all the instructions in the world, and often times will make things worse, not better. Things like etcupdate shouldn't be used to paper over this problem, though: it needs to be solved systematically. Ideally, we'd impose a one true location for the ESP, have a make variable to override that one true location, and have a WITHOUT_LOADER_INSTALL or somesuch flag if we don't go the install-loader router. This would make it safe to do automatically because the unsafe installations can just turn it off. WarnerReceived on Mon Mar 30 2020 - 01:32:27 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:23 UTC