On Wed, 2016-12-28 at 14:54 -0800, Ricardo Neri wrote:
> On Wed, 2016-12-21 at 14:11 +0100, Patrick Ohly wrote:
> > The recipe now compiles OVMF twice, once without Secure Boot, once
> > with. This is the same approach as in
> > https://src.fedoraproject.org/cgit/rpms/edk2.git/tree/edk2.spec
>
> Besides the fact that Fedora does it, is there a particular reason to
> build twice?
The ${build_dir}/FV/OVMF.fd file changes depending on the configuration.
There's only one such file after a build.
> On my side, I am able to build with secure boot with a
> single build. Also, the Ubuntu documentation does not mention that two
> builds are needed [1].
Can you build with and without secure boot in a single build? I wasn't
sure how to achieve that, so I just copied what Fedora does.
> Also, I think it would be nice if we could choose between to not have
> secure boot at all for OVMF. Maybe this could be achieved by having a
> common ovmf.inc and two ovmf_git.bb and ovmf_sb_git.bb with the
> different the specific things to support secure boot or not. Maybe all
> that is needed in the secure boot recipe are the extra variables for
> OpenSSL and a prepend to do_compile_class-target with the OpenSSL
> patching. Something to ponder.
I think I would prefer to have a single recipe with a PACKAGECONFIG for
secure boot. Having different recipes doesn't scale when adding more
such options. If you agree, then I'll add that.
> > + ( cd ${S}/CryptoPkg/Library/OpensslLib/ && ./Install.sh )
> > + ${S}/OvmfPkg/build.sh $PARALLEL_JOBS -a $OVMF_ARCH -b RELEASE -t
> > ${FIXED_GCCVER} ${OVMF_SECURE_BOOT_FLAGS}
> > + ln ${build_dir}/FV/OVMF.fd ${WORKDIR}/ovmf/OVMF.secboot.fd
>
> At this point both ${WORKDIR}/ovmf/OVMF.secboot.fd and
> ${WORKDIR}/ovmf/OVMF.fd will be linked to the same OVMF.fd with secure
> boot support. Maybe this could be fixed by copying the files rather than
> creating a symbolic link.
This is intentionally a hardlink, not a symbolic link, exactly because
of the problem you mentioned ;-)
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
