Re: [yocto] suggestions for version controlling multi-layer reproducible builds?
On 12-12-16 16:20, Robert P. J. Day wrote: (if there's already a doc section for this somewhere, a pointer to it would be just ducky.) if one is building an image for a releasable, commercial product, and that image involves pulling in numerous layers, then dumping all sorts of proprietary apps on top of it, what are the possibilities for how to version number the released images such that, if a client has an issue, they can identify precisely the state of components that went into the system they're working with? I always make a top-level git repository for the project. It contains all the "meta" layers as submodules (sometimes nested). That way, the version of the top layer is the version of the whole product and can be reproduced any time. in addition to all of the layers involved in the build, one has to take into account that, when critical bugs are identified, an updated RPM might be sent out and applied, whereupon that system's version number is no longer perfectly accurate. in the end, the state of someone's running system will be determined by a possibly huge combination of selected packages, preferred package versions, build config options, additional user space apps, hot fixes that have been applied and so on. The only way to version such a system is to actually dump the whole package version table (e.g. "opkg list-installed"). You could compare the table to the initially installed one and only send the difference, as an optimization. what sort of meaningful "version number" can be applied to something like that? i'm sure at least a few other people have to be doing something like that, so i'm open to suggestions. Version "numbers" are for marketing purposes only and have no useful meaning in version management. The git hash is the "technical" version number. Create a table somewhere to map the commercial version number to a git hash. The simplest implementation is to "tag" the version numbers in the top-level repository. Kind regards, Mike Looijmans System Expert TOPIC Products Materiaalweg 4, NL-5681 RJ Best Postbus 440, NL-5680 AK Best Telefoon: +31 (0) 499 33 69 79 E-mail: mike.looijm...@topicproducts.com Website: www.topicproducts.com Please consider the environment before printing this e-mail -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] update mechanisms
On 09-12-16 16:13, Patrick Ohly wrote: Hello everyone! Thanks for contributing directly to the page. It's great to see this done collaboratively. Nice informative page. Only thing lacking is simple, OE-built in upgrade procedures like: "Just run 'opkg update && opkg upgrade'" Kind regards, Mike Looijmans System Expert TOPIC Products Materiaalweg 4, NL-5681 RJ Best Postbus 440, NL-5680 AK Best Telefoon: +31 (0) 499 33 69 79 E-mail: mike.looijm...@topicproducts.com Website: www.topicproducts.com Please consider the environment before printing this e-mail -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] update mechanisms
On Tue, 2016-12-13 at 09:51 +0100, Mike Looijmans wrote: > On 09-12-16 16:13, Patrick Ohly wrote: > > Hello everyone! > > > > Thanks for contributing directly to the page. It's great to see this > > done collaboratively. > > Nice informative page. > > Only thing lacking is simple, OE-built in upgrade procedures like: "Just run > 'opkg update && opkg upgrade'" Want to add it? :-) Seriously, it would be a good addition. -- 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. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-zephyr layer
Hello Juro, first off, thanks for taking the kick, whatever its count is. On 12.12.2016 23:15, Bystricky, Juro wrote: Building of Zephyr images in Yocto can now be done fairly unobtrusively via a new layer "meta-zephyr" and specifying a new distro in local.conf: DISTRO="zephyr" Leaving out the poky/non-poky discussion, zephyr.conf currently contains an include for tune-cortexm3.conf which certainly should not be there, as it is machine specific. My local fix here is to create a warped version of qemuarm.conf named qemuarmm3.conf which fixes that. The repository for the meta-zephyr is here: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=juro/meta-zephyr. The new meta-zephyr layer contains several recipes to build (and run in QEMUs) various Zephyr tests. There is also a sample recipe to build Zephyr sample "philosophers" with instructions how to run it in QEMU. The instructions seem to be missing that poky-contrib/meta is also needed in the bblayers for the tune-cortexm3 include. The new meta-zephyr is work based on previous original work by Randy Witt and Richard Purdie, so it is actually a second kick at the can. Thanks to those too, of course. This is a work in progress, any feedback is appreciated. Feedback was above - do you also want patches? ;-) Greetz -- Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] update mechanisms
On 12/12/2016 1:02 PM, Patrick Ohly wrote: On Mon, 2016-12-12 at 09:49 -0600, Mariano Lopez wrote: On 12/12/16 09:41, Patrick Ohly wrote: On Mon, 2016-12-12 at 08:59 -0600, Mariano Lopez wrote: In particular the "complexity" column is a bit subjective. Stefano, I hope you don't mind that I did not quite buy the "easy to use" characterization of swupdate ;-) No worry...and I have not written myself. It was inserted by Mariano, so it looks like that swupdate at least for Mariano is "easy to use". I think it is correct to point out that customization is required. Compared to other update mechanism that I tested it was the easier to implement. Which "getting started" document or presentation were you using? The documentation for mender (https://docs.mender.io/) is very straight-forward (partly of course because it doesn't need to cover many variations), while for swupdate (http://sbabic.github.io/swupdate/swupdate.html) I found it less clear how to begin. When I did a research in update mechanism, mender wasn't yet available, and indeed it seems very straight forward (need to test it before final veredict). But if you compare SWUpdate, swupd, and OSTree; SWUpdate is by far less complex than the other two Ease-of-use is not necessarily determined by the complexity. Good integration and documentation can go a long way towards making a complex solution easy to use - when sticking to the pre-defined usage patterns. The opposite is also true: a simple solution may be hard to use if all one gets is the source code and one first has to reverse-engineer the usage model. Completely agree with you Patrick, it could be a simple solution very hard to use because of the lack of documentation I agree that the complexity is roughly swupdate < ostree < swupd and there's also no doubt that the latter two aren't easy to use (mostly due to lacking documentation and integration), but I'm still not sure what documentation the "easy to use" verdict for swupdate is based on. I based my verdict using this source: https://sbabic.github.io/swupdate/ You can follow this and create your update image few hours. Cheers Mariano -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Issues Updating Asterisk/Dahdi recipes from meta-telephony
Hi, I have got around to updating these recipes and found a few issues: asterisk has a autoconf macro file for pjproject in ./third-party/pjproject/, which does not get picked up by autobuild.bbclass. This uses find with a -maxdepth of 2 but but 3 would be needed. I found a temp fix by copying the m4 file manually to ./m4 directory in configure_prepend but what would the best long term solution be? /etc/init.d/functions stopped being installed for dahdi-tools and asterisk. update-rc.d.bbclass adds a run-time dependency on initscripts-functions if the installed init.d script contains the literal string "/etc/init.d/functions" at the packet-split stage. dahdi doesn't contain this literally but asterisk does so I am confused - but adding an explicit run-time dependency on initscripts-functions to dahdi-tools solved this. Any ideas on why this isn't working be default? asterisk also seems to have an issue locating neon but I have not started to investigate that yet. Regards, Chris morty 5aa481d asterisk 13.13.1 dahdi-tools 2.10.2 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-zephyr layer
Thanks, good point. The need for is poky.conf historic, not really needed at all anymore. From: Burton, Ross [mailto:ross.bur...@intel.com] Sent: Monday, December 12, 2016 4:00 PM To: Bystricky, Juro Cc: Philip Balister ; yocto@yoctoproject.org Subject: Re: [yocto] meta-zephyr layer On 12 December 2016 at 22:52, Bystricky, Juro mailto:juro.bystri...@intel.com>> wrote: you need poky to build QEMUs and toolchains You should just need *OpenEmbedded* to build the qemus and toolchains. Why does zephyr.conf include poky.conf? I'd say that any variables that are useful - such as using the Yocto source mirrors - should just be copied into zephyr.conf (or even better, moved into oe-core). Ross Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-zephyr layer
Hello Josef, I will find a better place for the meta-zephyr repository eventually. As for your patches, I would definitely like to see them. I added the cortex-m3 tune as one of the last steps, just to get the Zephyr ARM test suite to pass. It works well, but probably not an optimal implementation. > -Original Message- > From: Josef Holzmayr [mailto:holzm...@rsi-elektrotechnik.de] > Sent: Tuesday, December 13, 2016 5:51 AM > To: yocto@yoctoproject.org; Bystricky, Juro > Subject: Re: [yocto] meta-zephyr layer > > Hello Juro, > > first off, thanks for taking the kick, whatever its count is. > > On 12.12.2016 23:15, Bystricky, Juro wrote: > > Building of Zephyr images in Yocto can now be done fairly unobtrusively > > via a new layer "meta-zephyr" and specifying a new distro in local.conf: > > DISTRO="zephyr" > > Leaving out the poky/non-poky discussion, zephyr.conf currently contains > an include for tune-cortexm3.conf which certainly should not be there, > as it is machine specific. My local fix here is to create a warped > version of qemuarm.conf named qemuarmm3.conf which fixes that. > > > > > The repository for the meta-zephyr is here: > > http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=juro/meta- > zephyr. > > > > The new meta-zephyr layer contains several recipes to build (and run > > in QEMUs) various Zephyr tests. There is also a sample recipe to build > > Zephyr sample "philosophers" with instructions how to run it in QEMU. > > The instructions seem to be missing that poky-contrib/meta is also > needed in the bblayers for the tune-cortexm3 include. > > > The new meta-zephyr is work based on previous original work by > > Randy Witt and Richard Purdie, so it is actually a second kick at the > can. > > Thanks to those too, of course. > > > > > This is a work in progress, any feedback is appreciated. > > Feedback was above - do you also want patches? ;-) > > Greetz > > -- > Josef Holzmayr > Software Developer Embedded Systems > > Tel: +49 8444 9204-48 > Fax: +49 8444 9204-50 > > R-S-I Elektrotechnik GmbH & Co. KG > Woelkestrasse 11 > D-85301 Schweitenkirchen > www.rsi-elektrotechnik.de > --- > Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170393 > Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg > Ust-IdNr: DE 128592548 > > _ > Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 > Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg > USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-inte][rmc][PATCH 1/1] rmc: add support for alternative EFI bootloaders
RMC was previously configured to work only with the systemd-boot EFI
bootloader. With this commit we can specify alternative bootloaders by
setting the RMC_BOOTLOADER variable in local.conf. If RMC_BOOTLOADER is
not set systemd-boot will be used by default.
Example for grub-efi:
RMC_BOOTLOADER = "grub-efi"
Signed-off-by: Todor Minchev
---
.../{rmc-systemd-boot.bbclass => rmc-boot.bbclass} | 5 +++--
conf/machine/include/meta-intel.inc| 2 +-
documentation/rmc/README | 26 +++---
3 files changed, 27 insertions(+), 6 deletions(-)
rename classes/{rmc-systemd-boot.bbclass => rmc-boot.bbclass} (73%)
diff --git a/classes/rmc-systemd-boot.bbclass b/classes/rmc-boot.bbclass
similarity index 73%
rename from classes/rmc-systemd-boot.bbclass
rename to classes/rmc-boot.bbclass
index ad2cf10..a1f2093 100644
--- a/classes/rmc-systemd-boot.bbclass
+++ b/classes/rmc-boot.bbclass
@@ -1,9 +1,10 @@
-# rmc-systemd-boot bbclass
+# rmc-boot bbclass
# Deploy central RMC database file to ESP
IMAGE_INSTALL_append = " rmc"
+RMC_BOOTLOADER ?= "systemd-boot"
-inherit systemd-boot
+inherit ${RMC_BOOTLOADER}
do_bootimg[depends] += "${MLPREFIX}rmc-db:do_deploy"
diff --git a/conf/machine/include/meta-intel.inc
b/conf/machine/include/meta-intel.inc
index c7555ce..fd0a792 100644
--- a/conf/machine/include/meta-intel.inc
+++ b/conf/machine/include/meta-intel.inc
@@ -32,7 +32,7 @@ MACHINE_ESSENTIAL_EXTRA_RDEPENDS_append =
"${@bb.utils.contains('MACHINE_FEATURE
# merge the microcode data in the final initrd image.
INITRD_LIVE_prepend = "${@bb.utils.contains('MACHINE_FEATURES', 'intel-ucode',
'${DEPLOY_DIR_IMAGE}/microcode.cpio ', '', d)}"
-EFI_PROVIDER ?= "rmc-systemd-boot"
+EFI_PROVIDER ?= "rmc-boot"
# Add general MACHINEOVERRIDE for meta-intel
MACHINEOVERRIDES =. "intel-x86-common:"
diff --git a/documentation/rmc/README b/documentation/rmc/README
index 2427ffd..7dde8a4 100644
--- a/documentation/rmc/README
+++ b/documentation/rmc/README
@@ -165,14 +165,34 @@ steps still can override results from this hook for boot
entries and KBOOTPARAM.
Enable RMC Feature
-To Enable RMC feature in build, add the below lines in a conf file:
+To enable the RMC feature please add the following variables to your
local.conf.
+
DISTRO_FEATURES_append = " rmc"
-EFI_PROVIDER = "rmc-systemd-boot"
+EFI_PROVIDER = "rmc-boot"
+
+The default EFI bootloader used with RMC is systemd-boot. To change the default
+bootloader please overwrite the RMC_BOOTLOADER variable in your local.conf
+
+For example
+
+to use grub-efi:
+RMC_BOOTLOADER = "grub-efi"
+
+OR
+
+to use gummiboot:
+RMC_BOOTLOADER = "gummiboot"
Note:
Image could be still bootable if you only have either of two lines, but RMC
feature won't be fully functional.
+To install only the RMC client with the systemd-boot bootloader without
+including a default RMC database file, add the following lines to your
+local.conf:
+
+EFI_PROVIDER = "systemd-boot"
+IMAGE_INSTALL_append = " rmc"
Examples
@@ -190,7 +210,7 @@ EXAMPLE 1: Support a new board type:
(1) enable the feature and do a build to get a live-boot image by adding these
lines in conf/local.conf:
DISTRO_FEATURES_append = " rmc"
-EFI_PROVIDER = "rmc-systemd-boot"
+EFI_PROVIDER = "rmc-boot"
(2) flash the image to a USB stick and boot it on your board
--
2.11.0
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-inte][rmc][PATCH v2 1/1] rmc: add support for alternative EFI bootloaders
RMC was previously configured to work only with the systemd-boot EFI
bootloader. With this commit we can specify alternative bootloaders by
setting the RMC_BOOTLOADER variable in local.conf. If RMC_BOOTLOADER is
not set systemd-boot will be used by default.
Signed-off-by: Todor Minchev
---
Remove references to grub-efi and gummiboot from V1.
classes/{rmc-systemd-boot.bbclass => rmc-boot.bbclass} | 5 +++--
conf/machine/include/meta-intel.inc| 2 +-
documentation/rmc/README | 16 +---
3 files changed, 17 insertions(+), 6 deletions(-)
rename classes/{rmc-systemd-boot.bbclass => rmc-boot.bbclass} (73%)
diff --git a/classes/rmc-systemd-boot.bbclass b/classes/rmc-boot.bbclass
similarity index 73%
rename from classes/rmc-systemd-boot.bbclass
rename to classes/rmc-boot.bbclass
index ad2cf10..a1f2093 100644
--- a/classes/rmc-systemd-boot.bbclass
+++ b/classes/rmc-boot.bbclass
@@ -1,9 +1,10 @@
-# rmc-systemd-boot bbclass
+# rmc-boot bbclass
# Deploy central RMC database file to ESP
IMAGE_INSTALL_append = " rmc"
+RMC_BOOTLOADER ?= "systemd-boot"
-inherit systemd-boot
+inherit ${RMC_BOOTLOADER}
do_bootimg[depends] += "${MLPREFIX}rmc-db:do_deploy"
diff --git a/conf/machine/include/meta-intel.inc
b/conf/machine/include/meta-intel.inc
index c7555ce..fd0a792 100644
--- a/conf/machine/include/meta-intel.inc
+++ b/conf/machine/include/meta-intel.inc
@@ -32,7 +32,7 @@ MACHINE_ESSENTIAL_EXTRA_RDEPENDS_append =
"${@bb.utils.contains('MACHINE_FEATURE
# merge the microcode data in the final initrd image.
INITRD_LIVE_prepend = "${@bb.utils.contains('MACHINE_FEATURES', 'intel-ucode',
'${DEPLOY_DIR_IMAGE}/microcode.cpio ', '', d)}"
-EFI_PROVIDER ?= "rmc-systemd-boot"
+EFI_PROVIDER ?= "rmc-boot"
# Add general MACHINEOVERRIDE for meta-intel
MACHINEOVERRIDES =. "intel-x86-common:"
diff --git a/documentation/rmc/README b/documentation/rmc/README
index 2427ffd..dbee6b6 100644
--- a/documentation/rmc/README
+++ b/documentation/rmc/README
@@ -165,14 +165,24 @@ steps still can override results from this hook for boot
entries and KBOOTPARAM.
Enable RMC Feature
-To Enable RMC feature in build, add the below lines in a conf file:
+To enable the RMC feature please add the following variables to your
local.conf.
+
DISTRO_FEATURES_append = " rmc"
-EFI_PROVIDER = "rmc-systemd-boot"
+EFI_PROVIDER = "rmc-boot"
+
+The default EFI bootloader used with RMC is systemd-boot. To change the default
+bootloader please overwrite the RMC_BOOTLOADER variable in your local.conf
Note:
Image could be still bootable if you only have either of two lines, but RMC
feature won't be fully functional.
+To install only the RMC client with the systemd-boot bootloader without
+including a default RMC database file, add the following lines to your
+local.conf:
+
+EFI_PROVIDER = "systemd-boot"
+IMAGE_INSTALL_append = " rmc"
Examples
@@ -190,7 +200,7 @@ EXAMPLE 1: Support a new board type:
(1) enable the feature and do a build to get a live-boot image by adding these
lines in conf/local.conf:
DISTRO_FEATURES_append = " rmc"
-EFI_PROVIDER = "rmc-systemd-boot"
+EFI_PROVIDER = "rmc-boot"
(2) flash the image to a USB stick and boot it on your board
--
2.11.0
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-inte][rmc][PATCH v2 1/1] rmc: add support for alternative EFI bootloaders
> On Dec 13, 2016, at 2:56 PM, Todor Minchev
> wrote:
>
> RMC was previously configured to work only with the systemd-boot EFI
> bootloader. With this commit we can specify alternative bootloaders by
> setting the RMC_BOOTLOADER variable in local.conf. If RMC_BOOTLOADER is
> not set systemd-boot will be used by default.
>
> Signed-off-by: Todor Minchev
> ---
> Remove references to grub-efi and gummiboot from V1.
>
> classes/{rmc-systemd-boot.bbclass => rmc-boot.bbclass} | 5 +++--
> conf/machine/include/meta-intel.inc| 2 +-
> documentation/rmc/README | 16 +---
> 3 files changed, 17 insertions(+), 6 deletions(-)
> rename classes/{rmc-systemd-boot.bbclass => rmc-boot.bbclass} (73%)
>
> diff --git a/classes/rmc-systemd-boot.bbclass b/classes/rmc-boot.bbclass
> similarity index 73%
> rename from classes/rmc-systemd-boot.bbclass
> rename to classes/rmc-boot.bbclass
> index ad2cf10..a1f2093 100644
> --- a/classes/rmc-systemd-boot.bbclass
> +++ b/classes/rmc-boot.bbclass
> @@ -1,9 +1,10 @@
> -# rmc-systemd-boot bbclass
> +# rmc-boot bbclass
> # Deploy central RMC database file to ESP
>
> IMAGE_INSTALL_append = " rmc"
> +RMC_BOOTLOADER ?= "systemd-boot”
Maybe this is what we could have now without bothering OE. It is better than
the corrent code at the cost of another variable to user. I hope in the future
we could get rid of the dependency to EFI_PROVIDER (e.g. bz10084).
Also refer to my comment for the document change at the below.
>
> -inherit systemd-boot
> +inherit ${RMC_BOOTLOADER}
>
> do_bootimg[depends] += "${MLPREFIX}rmc-db:do_deploy"
>
> diff --git a/conf/machine/include/meta-intel.inc
> b/conf/machine/include/meta-intel.inc
> index c7555ce..fd0a792 100644
> --- a/conf/machine/include/meta-intel.inc
> +++ b/conf/machine/include/meta-intel.inc
> @@ -32,7 +32,7 @@ MACHINE_ESSENTIAL_EXTRA_RDEPENDS_append =
> "${@bb.utils.contains('MACHINE_FEATURE
> # merge the microcode data in the final initrd image.
> INITRD_LIVE_prepend = "${@bb.utils.contains('MACHINE_FEATURES',
> 'intel-ucode', '${DEPLOY_DIR_IMAGE}/microcode.cpio ', '', d)}"
>
> -EFI_PROVIDER ?= "rmc-systemd-boot"
> +EFI_PROVIDER ?= "rmc-boot"
>
> # Add general MACHINEOVERRIDE for meta-intel
> MACHINEOVERRIDES =. "intel-x86-common:"
> diff --git a/documentation/rmc/README b/documentation/rmc/README
> index 2427ffd..dbee6b6 100644
> --- a/documentation/rmc/README
> +++ b/documentation/rmc/README
> @@ -165,14 +165,24 @@ steps still can override results from this hook for
> boot entries and KBOOTPARAM.
>
> Enable RMC Feature
>
> -To Enable RMC feature in build, add the below lines in a conf file:
> +To enable the RMC feature please add the following variables to your
> local.conf.
> +
> DISTRO_FEATURES_append = " rmc"
> -EFI_PROVIDER = "rmc-systemd-boot"
> +EFI_PROVIDER = "rmc-boot"
> +
> +The default EFI bootloader used with RMC is systemd-boot. To change the
> default
> +bootloader please overwrite the RMC_BOOTLOADER variable in your local.conf
>
> Note:
> Image could be still bootable if you only have either of two lines, but RMC
> feature won't be fully functional.
>
> +To install only the RMC client with the systemd-boot bootloader without
> +including a default RMC database file, add the following lines to your
> +local.conf:
> +
> +EFI_PROVIDER = "systemd-boot"
> +IMAGE_INSTALL_append = " rmc”
I think this use case could confuse for user without much benefit. And actually
they still can set EFI_PROVIDER to any available efi bootloaders to get this
effect as long as it is not “rmc-boot”, right?
Maybe we should just say “you won’t get rmc database deployed if you set
EFI_PROVIDER to any values not rmc-boot."
>
>
>
> Examples
> @@ -190,7 +200,7 @@ EXAMPLE 1: Support a new board type:
> (1) enable the feature and do a build to get a live-boot image by adding these
> lines in conf/local.conf:
> DISTRO_FEATURES_append = " rmc"
> -EFI_PROVIDER = "rmc-systemd-boot"
> +EFI_PROVIDER = "rmc-boot"
>
> (2) flash the image to a USB stick and boot it on your board
>
> --
> 2.11.0
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-inte][rmc][PATCH v2 1/1] rmc: add support for alternative EFI bootloaders
On Tue, 2016-12-13 at 16:22 -0800, Jianxun Zhang wrote:
> > On Dec 13, 2016, at 2:56 PM, Todor Minchev
> > wrote:
> >
> > RMC was previously configured to work only with the systemd-boot EFI
> > bootloader. With this commit we can specify alternative bootloaders by
> > setting the RMC_BOOTLOADER variable in local.conf. If RMC_BOOTLOADER is
> > not set systemd-boot will be used by default.
> >
> > Signed-off-by: Todor Minchev
> > ---
> > Remove references to grub-efi and gummiboot from V1.
> >
> > classes/{rmc-systemd-boot.bbclass => rmc-boot.bbclass} | 5 +++--
> > conf/machine/include/meta-intel.inc| 2 +-
> > documentation/rmc/README | 16 +---
> > 3 files changed, 17 insertions(+), 6 deletions(-)
> > rename classes/{rmc-systemd-boot.bbclass => rmc-boot.bbclass} (73%)
> >
> > diff --git a/classes/rmc-systemd-boot.bbclass b/classes/rmc-boot.bbclass
> > similarity index 73%
> > rename from classes/rmc-systemd-boot.bbclass
> > rename to classes/rmc-boot.bbclass
> > index ad2cf10..a1f2093 100644
> > --- a/classes/rmc-systemd-boot.bbclass
> > +++ b/classes/rmc-boot.bbclass
> > @@ -1,9 +1,10 @@
> > -# rmc-systemd-boot bbclass
> > +# rmc-boot bbclass
> > # Deploy central RMC database file to ESP
> >
> > IMAGE_INSTALL_append = " rmc"
> > +RMC_BOOTLOADER ?= "systemd-boot”
> Maybe this is what we could have now without bothering OE. It is better than
> the corrent code at the cost of another variable to user. I hope in the
> future we could get rid of the dependency to EFI_PROVIDER (e.g. bz10084).
>
> Also refer to my comment for the document change at the below.
> >
> > -inherit systemd-boot
> > +inherit ${RMC_BOOTLOADER}
> >
> > do_bootimg[depends] += "${MLPREFIX}rmc-db:do_deploy"
> >
> > diff --git a/conf/machine/include/meta-intel.inc
> > b/conf/machine/include/meta-intel.inc
> > index c7555ce..fd0a792 100644
> > --- a/conf/machine/include/meta-intel.inc
> > +++ b/conf/machine/include/meta-intel.inc
> > @@ -32,7 +32,7 @@ MACHINE_ESSENTIAL_EXTRA_RDEPENDS_append =
> > "${@bb.utils.contains('MACHINE_FEATURE
> > # merge the microcode data in the final initrd image.
> > INITRD_LIVE_prepend = "${@bb.utils.contains('MACHINE_FEATURES',
> > 'intel-ucode', '${DEPLOY_DIR_IMAGE}/microcode.cpio ', '', d)}"
> >
> > -EFI_PROVIDER ?= "rmc-systemd-boot"
> > +EFI_PROVIDER ?= "rmc-boot"
> >
> > # Add general MACHINEOVERRIDE for meta-intel
> > MACHINEOVERRIDES =. "intel-x86-common:"
> > diff --git a/documentation/rmc/README b/documentation/rmc/README
> > index 2427ffd..dbee6b6 100644
> > --- a/documentation/rmc/README
> > +++ b/documentation/rmc/README
> > @@ -165,14 +165,24 @@ steps still can override results from this hook for
> > boot entries and KBOOTPARAM.
> >
> > Enable RMC Feature
> >
> > -To Enable RMC feature in build, add the below lines in a conf file:
> > +To enable the RMC feature please add the following variables to your
> > local.conf.
> > +
> > DISTRO_FEATURES_append = " rmc"
> > -EFI_PROVIDER = "rmc-systemd-boot"
> > +EFI_PROVIDER = "rmc-boot"
> > +
> > +The default EFI bootloader used with RMC is systemd-boot. To change the
> > default
> > +bootloader please overwrite the RMC_BOOTLOADER variable in your local.conf
> >
> > Note:
> > Image could be still bootable if you only have either of two lines, but RMC
> > feature won't be fully functional.
> >
> > +To install only the RMC client with the systemd-boot bootloader without
> > +including a default RMC database file, add the following lines to your
> > +local.conf:
> > +
> > +EFI_PROVIDER = "systemd-boot"
> > +IMAGE_INSTALL_append = " rmc”
> I think this use case could confuse for user without much benefit. And
> actually they still can set EFI_PROVIDER to any available efi bootloaders to
> get this effect as long as it is not “rmc-boot”, right?
> Maybe we should just say “you won’t get rmc database deployed if you set
> EFI_PROVIDER to any values not rmc-boot."
Yes, this can be another way to phrase this.
> >
> > Examples
> > @@ -190,7 +200,7 @@ EXAMPLE 1: Support a new board type:
> > (1) enable the feature and do a build to get a live-boot image by adding
> > these
> > lines in conf/local.conf:
> > DISTRO_FEATURES_append = " rmc"
> > -EFI_PROVIDER = "rmc-systemd-boot"
> > +EFI_PROVIDER = "rmc-boot"
> >
> > (2) flash the image to a USB stick and boot it on your board
> >
> > --
> > 2.11.0
> >
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-zephyr layer
The new meta-zephyr is work based on previous original work by Randy Witt and Richard Purdie, so it is actually a second kick at the can. One of the things I did when I originally put this together that could now change is qemuzephyrrunner.py which is used in the tests. I did it because runqemu previously had quite a bit of machine specific configuration in it. As of 2.2, runqemu now allows for qemu configuration to be specified in the bsp in the form of qemuboot.conf. So now, theoretically qemuzephyrunner.py could be removed, and instead the configuration could be moved into the "bsp". This would also remove the need for manually specifying a qemu commandline argument, since you could use runqemu. Another great add if anyone is interested would be to have a menuconfig task that works similar to the kernel. Juro said he had filed some bugs for these items and more, so if anyone is interested please take a look at bugzilla. :) This is a work in progress, any feedback is appreciated. Juro -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-inte][rmc][PATCH v2 1/1] rmc: add support for alternative EFI bootloaders
I like where this is heading but does RMC function with bootloaders
besides systemd-boot yet?
A quick boot test with this patch and RMC_BOOTLOADER = "grub-efi" seems
to give me vanilla grub-efi.
Thanks,
Cal
On 12/13/2016 04:50 PM, Todor Minchev wrote:
On Tue, 2016-12-13 at 16:22 -0800, Jianxun Zhang wrote:
On Dec 13, 2016, at 2:56 PM, Todor Minchev
wrote:
RMC was previously configured to work only with the systemd-boot EFI
bootloader. With this commit we can specify alternative bootloaders by
setting the RMC_BOOTLOADER variable in local.conf. If RMC_BOOTLOADER is
not set systemd-boot will be used by default.
Signed-off-by: Todor Minchev
---
Remove references to grub-efi and gummiboot from V1.
classes/{rmc-systemd-boot.bbclass => rmc-boot.bbclass} | 5 +++--
conf/machine/include/meta-intel.inc| 2 +-
documentation/rmc/README | 16 +---
3 files changed, 17 insertions(+), 6 deletions(-)
rename classes/{rmc-systemd-boot.bbclass => rmc-boot.bbclass} (73%)
diff --git a/classes/rmc-systemd-boot.bbclass b/classes/rmc-boot.bbclass
similarity index 73%
rename from classes/rmc-systemd-boot.bbclass
rename to classes/rmc-boot.bbclass
index ad2cf10..a1f2093 100644
--- a/classes/rmc-systemd-boot.bbclass
+++ b/classes/rmc-boot.bbclass
@@ -1,9 +1,10 @@
-# rmc-systemd-boot bbclass
+# rmc-boot bbclass
# Deploy central RMC database file to ESP
IMAGE_INSTALL_append = " rmc"
+RMC_BOOTLOADER ?= "systemd-boot”
Maybe this is what we could have now without bothering OE. It is better than
the corrent code at the cost of another variable to user. I hope in the future
we could get rid of the dependency to EFI_PROVIDER (e.g. bz10084).
Also refer to my comment for the document change at the below.
-inherit systemd-boot
+inherit ${RMC_BOOTLOADER}
do_bootimg[depends] += "${MLPREFIX}rmc-db:do_deploy"
diff --git a/conf/machine/include/meta-intel.inc
b/conf/machine/include/meta-intel.inc
index c7555ce..fd0a792 100644
--- a/conf/machine/include/meta-intel.inc
+++ b/conf/machine/include/meta-intel.inc
@@ -32,7 +32,7 @@ MACHINE_ESSENTIAL_EXTRA_RDEPENDS_append =
"${@bb.utils.contains('MACHINE_FEATURE
# merge the microcode data in the final initrd image.
INITRD_LIVE_prepend = "${@bb.utils.contains('MACHINE_FEATURES', 'intel-ucode',
'${DEPLOY_DIR_IMAGE}/microcode.cpio ', '', d)}"
-EFI_PROVIDER ?= "rmc-systemd-boot"
+EFI_PROVIDER ?= "rmc-boot"
# Add general MACHINEOVERRIDE for meta-intel
MACHINEOVERRIDES =. "intel-x86-common:"
diff --git a/documentation/rmc/README b/documentation/rmc/README
index 2427ffd..dbee6b6 100644
--- a/documentation/rmc/README
+++ b/documentation/rmc/README
@@ -165,14 +165,24 @@ steps still can override results from this hook for boot
entries and KBOOTPARAM.
Enable RMC Feature
-To Enable RMC feature in build, add the below lines in a conf file:
+To enable the RMC feature please add the following variables to your
local.conf.
+
DISTRO_FEATURES_append = " rmc"
-EFI_PROVIDER = "rmc-systemd-boot"
+EFI_PROVIDER = "rmc-boot"
+
+The default EFI bootloader used with RMC is systemd-boot. To change the default
+bootloader please overwrite the RMC_BOOTLOADER variable in your local.conf
Note:
Image could be still bootable if you only have either of two lines, but RMC
feature won't be fully functional.
+To install only the RMC client with the systemd-boot bootloader without
+including a default RMC database file, add the following lines to your
+local.conf:
+
+EFI_PROVIDER = "systemd-boot"
+IMAGE_INSTALL_append = " rmc”
I think this use case could confuse for user without much benefit. And actually
they still can set EFI_PROVIDER to any available efi bootloaders to get this
effect as long as it is not “rmc-boot”, right?
Maybe we should just say “you won’t get rmc database deployed if you set
EFI_PROVIDER to any values not rmc-boot."
Yes, this can be another way to phrase this.
Examples
@@ -190,7 +200,7 @@ EXAMPLE 1: Support a new board type:
(1) enable the feature and do a build to get a live-boot image by adding these
lines in conf/local.conf:
DISTRO_FEATURES_append = " rmc"
-EFI_PROVIDER = "rmc-systemd-boot"
+EFI_PROVIDER = "rmc-boot"
(2) flash the image to a USB stick and boot it on your board
--
2.11.0
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] possible bug with dpkg-native with sstate-cache
I have found what I think is a sneaky nasty bug when using package_deb with
SSTATE_MIRRORS on RPM based build hosts. Below is a short description of what
I found and our workaround. A patch that adds a patch that is applied to the
packager that packages the real packager. To avoid this sneaking failure mode
when building without building when using the cache (its all so very
meta, btw.).
Don't ask how we found this; it wasn't pretty.
Note: the fix approach below actually patches dpkg on the target too,
but I do not
know how to easily make the patch only apply to dpkg-native and not also dpkg.
But in this case it should be fine anyhow; there is no reason that dpkg on the
target should not behave this way too. I have checked the upstream and the
lines in question have never been touched - it is possible they may want to
eventually upstream this too (???).
For future knowledge, is there an easy way to have a SRC_URI list that is
different for dpkg-native than for dpkg?
Also, this is my first post to the group, so apologies if this is not the
right place or way to upload a potential patch; set me straight if so.
Thanks, guys.
Anders.
The dpkg binary contains a hard-coded CONFIGDIR path which normally points
to /etc/dpkg. However, if /etc/dpkg/dpkg.cfg.d doesn't exist (ENOTDIR) it
fails with an error, even though it does not fail when the directory exists
but is empty (ENOENT).
Normally this is not an issue, but when dpkg-native is built, CONFIGDIR
points to a directory in the sysroot under work. If that binary is later
cached in the sstate-cache and mirrored to another host that does not
contain the same work directory, the dpkg binary fails due to this missing
directory during certain packaging steps involving apt-get. This "leaks"
information about the build host into the sstate-cache in an unintended way
that causes a failure.
The dpkg utility does not currently allow a command line or environment
override of CONFIGDIR, so this patches dpkg so that a missing directory is
the same as an empty one and the failure is avoided. The dpkg-native is
always passed command line arguments and does not need, nor contain, any
configuration data in this directory in the first place
commit 48441318ced298e58ba2ea4ae1e2332259dcb6f8
Author: Anders
Date: Tue Dec 13 20:10:25 2016 -0800
patch to workaround sstate-cache bug in dpkg
The dpkg binary contains a hard-coded CONFIGDIR path which normally points
to
/etc/dpkg. However, if /etc/dpkg/dpkg.cfg.d doesn't exist (ENOTDIR) it fails
with an error, even though it does not fail when the directory exists but is
empty (ENOENT).
Normally this is not an issue, but when dpkg-native is built, CONFIGDIR
points
to a directory in the sysroot under work. If that binary is later cached in
the sstate-cache and mirrored to another host that does not contain the same
work directory, the dpkg binary fails due to this missing directory during
certain packaging steps involving apt-get. This "leaks" information about
the
build host into the sstate-cache in an unintended way that causes a failure.
The dpkg utility does not currently allow a command line or environment
override of CONFIGDIR, so this patches dpkg so that a missing directory is
the
same as an empty one and the failure is avoided. The dpkg-native is always
passed command line arguments and does not need, nor contain, any
configuration data in this directory in the first place.
diff --git a/meta/recipes-devtools/dpkg/dpkg/allow-missing-config-dir.patch
b/meta/recipes-devtools/dpkg/dpkg/allow-missing-config-dir.patch
new file mode 100644
index 000..8a52065
--- /dev/null
+++ b/meta/recipes-devtools/dpkg/dpkg/allow-missing-config-dir.patch
@@ -0,0 +1,16 @@
+Index: dpkg-1.18.7/lib/dpkg/options.c
+===
+--- dpkg-1.18.7.orig/lib/dpkg/options.c
dpkg-1.18.7/lib/dpkg/options.c
+@@ -172,11 +172,8 @@ dpkg_options_load_dir(const char *prog,
+
+ dlist_n = scandir(dirname, &dlist, valid_config_filename, alphasort);
+ if (dlist_n < 0) {
+-if (errno == ENOENT) {
+ free(dirname);
+ return;
+-} else
+- ohshite(_("error opening configuration directory '%s'"), dirname);
+ }
+
+ for (i = 0; i < dlist_n; i++) {
diff --git a/meta/recipes-devtools/dpkg/dpkg_1.18.7.bb
b/meta/recipes-devtools/dpkg/dpkg_1.18.7.bb
index 28fdc13..981fc6b 100644
--- a/meta/recipes-devtools/dpkg/dpkg_1.18.7.bb
+++ b/meta/recipes-devtools/dpkg/dpkg_1.18.7.bb
@@ -7,6 +7,7 @@ SRC_URI =
"http://snapshot.debian.org/archive/debian/20160509T100042Z/pool/main/
file://arch_pm.patch \
file://dpkg-configure.service \
file://add_armeb_triplet_entry.patch \
+ file://allow-missing-config-dir.patch \
file://0002-Adapt-to-linux-wrs-kernel-version-which-has-characte.patch \
