On Mon, Oct 12, 2015 at 11:08:24PM +0300, Andrei Borzenkov wrote: > 12.10.2015 19:39, Daniel Kiper пишет: > >On Mon, Oct 12, 2015 at 12:31:54PM +0300, Andrei Borzenkov wrote: > >>On Tue, Sep 8, 2015 at 12:39 AM, Barry Jackson <zen25...@zen.co.uk> wrote: > >>>On 06/06/15 09:38, Andrei Borzenkov wrote: > >>>> > >>>>?? Fri, 05 Jun 2015 14:56:20 +0100 > >>>>Barry Jackson <zen25...@zen.co.uk> ??????????: > >>> > >>> > >>>>>Any progress on this? > >>>>> > >>>> > >>>> > >>>>Not really, sorry. Do you have any suggestion how such option should be > >>>>named? > >>>> > >>> > >>>Sorry for delay - this got lost in the noise. > >>> > >>>Well something like --no-id-or-nvram ?? > >>> > >>>Not really bothered about the name! :) > >> > >>I was about to suggest a patch when I realized that this probably is > >>currently useless on EFI. I.e. to actually chainload grub on EFI it > >>must reside on a partition accessible by firmware which practically > >>means it should be ESP. > >> > >>Unless someone submits patch to make grub2 EFI core.img multiboot2 > >>compliant with tag to skip ExitBootServices. > > > >Relevant patches waiting for review for months. I am working on v3. > >If they are upstreamed I will be happy too. > > > > Your patches implement "client side" support (loading MB2 images);
OK but they provide what you need here. So, it does not fully invalidate what I said earlier. > but EFI grub is not MB2 and has no provision for being loaded this > way. Also it is PE, not ELF. MB2 header may live in PE, ELF or even in file which does not have commonly known format. > Actually chainloading probably could be made to work on arbitrary > filesystem if argument parsing is added (to pass along cmdpath). So, it looks that MB2 with my extensions should make it work. Daniel _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
