Date: Tue, 30 Apr 2019 15:15:14 -0600 From: Warner Losh <imp@bsdimp.com> To: Lev Serebryakov <lev@freebsd.org> Cc: Toomas Soome <tsoome@me.com>, Rebecca Cran <bcran@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config) Message-ID: <CANCZdfp5zFpbh5x253kQJ-XfCJ0jPhff_i_5GZ4EpJaVZHj8eQ@mail.gmail.com> In-Reply-To: <0bbb962f-cc59-f29d-b26d-fa675cbb1082@FreeBSD.org> References: <912985968.20190119125228@serebryakov.spb.ru> <etPan.5c433dd9.327b23c6.1973@bluestop.org> <1951151017.20190119235425@serebryakov.spb.ru> <4636753.YNO7O01DYZ@photon.int.bluestop.org> <17710465740.20190120134042@serebryakov.spb.ru> <CANCZdfq%2BmuSr=CX4V9_ebWwNv1S49=mJZms0ZVoCB2onp%2BqHNA@mail.gmail.com> <3f4214e2-36af-cc87-0a3c-2c7ce26cffd8@FreeBSD.org> <DE6A295D-80CF-4E9A-88EE-F9F63ED66286@me.com> <b4100160-d30d-a696-a2cb-be4f7f0d5305@FreeBSD.org> <C7DBCEA9-42AE-4ACC-84D8-10035DF0529E@me.com> <0bbb962f-cc59-f29d-b26d-fa675cbb1082@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 21, 2019 at 6:13 AM Lev Serebryakov <lev@freebsd.org> wrote: > On 21.01.2019 15:59, Toomas Soome wrote: > > >>>>> Is too complicated? Boot1.efi doesn't allow that, but loader.efi > does. > >>>> loader.efi lives on ESP partition, do I understand it right? So, it > >>>> could not be damaged with "bad" upgrade? > >>> > >>> It could, unless the backup is created. > >> Does it live on code (root) FS or ESP? I understand, that when you > >> upgrade ESP partition, you could ruin it, but typically root FS is > >> upgraded much more often than ESP/boot0/boot1 parts. > > > > If you are using boot1.efi, the loader.efi is in OS /boot/loader.efi > annd boot1.efi is stored to ESP and will execute loader.efi as bios boot2 > programs do. > So, Warner's advice to use > > set currdev=diskXpY: > boot > > with loader.efi is not direct replacement to choosing boot partition > via boot0 now (as "boot1.eif doesn't allow that" and /boot/loader.efi > could be broken with unsuccessful upgrade), am I right? > Yes. And after my latest fixes, you can add 'set currdev=diskXpY' to ESP's /efi/freebsd/loader.env as well. boot1.efi is really super limited and tries too much DWIM to be useful, so it's being retired in favor of loader.efi. > > we will drop boot1.efi (it is already dropped in illumos btw), and will > only use loader.efi - and in this case, the loader.efi is installed to ESP > and will only start the kernel. > Ok, I need to wait for it. > I think all the features are there. You can install loader.efi as you used to install boot1.efi and have it work as well or better than boot1.efi. > > But then again, if you are using stock (generic) OS on embedded system, > you are already doing it wrong and will get into the trouble sooner or > later:) > I can not say, is NanoBSD "stock" or not :-) > One of the big reasons I did the latest changes was to make it possible for NanoBSD to work better. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfp5zFpbh5x253kQJ-XfCJ0jPhff_i_5GZ4EpJaVZHj8eQ>