This bug should be filed to OE since gummiboot recipe to be replaced is in OE. But I filed it to meta-intel initially for prototype, considering more document work and validation around a replacement of gummiboot in OE may not be a small and quick work. The gummiboot project in OE is already dead and it has been merged into systemd project which is also partly enabled in OE. But we consider to make a standalone systems-boot outside systemd in yocto so that people can replace old gummiboot with this new systemd-boot without any dependency on systemd, when they just want a gummiboot-like boot loader. If this task should be forward to OE, Document content for gummiboot should be updated. Otherwise, at least README files in meta-intel shall be updated with this change.
Created attachment 3139 [details] [Draft][patch] enabling systemd-boot as a standalone bootloader Saul, Refer to the attached patch to meta-intel, I am not sure if I am on the right approach so please have a look on it. I don't it is ready to submission since I just made the progress today without much test. I tried a minimal image for intel-corei7-64 machine on NUC. It looks working now from build to live-boot. I will do more test and cleaning up but your feedback is necessary before my submission. Or you guys may want to have such change in OE eventually.
Today I did more test against the draft patch on 32 bit machines including intel-quark. Basic boot is okay with minimal image. Saul, I think I am close to submission but still hope you can have a look first. I think we can take this as bootloader for RMC work in parallel. Thanks
(In reply to comment #2) > Today I did more test against the draft patch on 32 bit machines including > intel-quark. Basic boot is okay with minimal image. > > Saul, > I think I am close to submission but still hope you can have a look first. I > think we can take this as bootloader for RMC work in parallel. > > Thanks This is great, but I would actually like to see it against oe-core, we can do the RMC work in meta-intel, but I would like the systemd-boot recipe in OE-core proper. I found one missing DEPEND on intltool-native (which is in the orignal list) and Robert Yang is reporting that he needs coreutils-native when building on Ubuntu machine. Please go ahead with an oe-core version and if you want me to reveiw it, that would be great.
Saul, I will try to migrate to OE, no problem. There is already systemd package in OE, my question is if it still look nice and justified when we put systemd and a new stand alone systemd-boot side by side, from fetch to deploy. For example, they are based on same source package so we may want to have a common recipe to be updated for new revisions so that we won't need to update two recipes every time. (I don't know if having two recipes fetch same package is okay...) The differentiation could happen at later steps from config to deployment. For dependency, I tried "bitbake systemd-boot" to find out only the necessary packages in APPENDS. It works to build out boot loader only. That's why I didn't bother some packages. This approach may not be very accurate, however.
Saul, I think this would be a migration plan in OE: () Implement systemd-boot piece so that EFI_PROVIDER=systemd-boot" in conf is the only required step to developers. We could need another talk on how independent the systemd-boot can be from existing systemd. EFI stub will not be built. We only support gummiboot-like EFI app in OE. () The existing approach in systemd to build out EFI bootloader and stub will be kept. We just don't want to break any customer's temporary solution derived from this currently uncompleted support in OE. () Update document to _replace_ gummiboot with new "systemd-boot" along with grub2, () Migrate targets using gummiboot to systemd-boot in our scope, like intel-quark () Submit another OE patch to invalid gummiboot build with an error message " Gummiboot is dead, please consider to use systemd-boot, balabala..." () After 1~2 releases, finally purge gummiboot recipe and bbclass in OE.
(In reply to comment #4) > Saul, > > I will try to migrate to OE, no problem. There is already systemd package in > OE, my question is if it still look nice and justified when we put systemd > and a new stand alone systemd-boot side by side, from fetch to deploy. > Yes, we still want seperate recipes for systemd and systemd-boot, because as I said it's possible for systemd-boot to be used without systemd. They could be co-located in the same meta/recipes-core/systemd, but I think it makes more sense to have the bootloader recipe be co-located with the other BSP related recipes. > For example, they are based on same source package so we may want to have a > common recipe to be updated for new revisions so that we won't need to > update two recipes every time. (I don't know if having two recipes fetch > same package is okay...) > This can be done with a .inc that both include for pointing to the source location, but it may still require both recipes .bb files to be updated since the version is encoded in the file name. > The differentiation could happen at later steps from config to deployment. > > For dependency, I tried "bitbake systemd-boot" to find out only the > necessary packages in APPENDS. It works to build out boot loader only. > That's why I didn't bother some packages. This approach may not be very > accurate, however. You mean DEPENDS here I think. Correct that approach of iterative building can be hazardous, you need to understand what's needed, you might have already had something built or as pointed out different Host Distro OSes can have different native requirements.
(In reply to comment #5) > Saul, > I think this would be a migration plan in OE: > > () Implement systemd-boot piece so that EFI_PROVIDER=systemd-boot" in conf > is the only required step to developers. We could need another talk on how > independent the systemd-boot can be from existing systemd. EFI stub will not > be built. We only support gummiboot-like EFI app in OE. > At this point correct, that might change later in the release cycle, something to be disccused later. > () The existing approach in systemd to build out EFI bootloader and stub > will be kept. We just don't want to break any customer's temporary solution > derived from this currently uncompleted support in OE. > Not sure I understand what you are saying here, if you are suggesting having systemd-boot be deployed from the systemd recipe, then no, systemd-boot should be a completely standalone recipe as you have prototyped it. > () Update document to _replace_ gummiboot with new "systemd-boot" along with > grub2, > Correct > () Migrate targets using gummiboot to systemd-boot in our scope, like > intel-quark > Correct > () Submit another OE patch to invalid gummiboot build with an error message > " Gummiboot is dead, please consider to use systemd-boot, balabala..." > > () After 1~2 releases, finally purge gummiboot recipe and bbclass in OE. Not sure about these two vs just removing it and let the commit message tell the tale.
Created attachment 3163 [details] [OE] enabling systemd-boot as a standalone bootloader Basic tested on x86 32 and 64 bit, with and without systemd in DISTRO_FEATURES. Need to check intel-quark later. Still need more test to see if change impacts systemd itself. Todo: Document self-test support of new systemd-boot
http://lists.openembedded.org/pipermail/openembedded-core/2016-May/121026.html http://lists.openembedded.org/pipermail/openembedded-core/2016-May/121027.html Patch has been submitted to OE core for review. I will create other two tickets to track the following up once patch is accepted. () new oe-selftest cases in bugzilla, and test script to support systemd-boot. () documentation change () replace gummiboot for intel-quark and any machine using it with systemd-boot. () cleanup gummiboot
Update estimation. I will create new tickets for further steps in plan since they require some effort.
Patch is in poky master now. http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=c71f5ab37416629793b9f826480d440d67531791 I have opened two tickets as following up. https://bugzilla.yoctoproject.org/show_bug.cgi?id=9706 https://bugzilla.yoctoproject.org/show_bug.cgi?id=9707