Age | Commit message (Collapse) | Author | Files | Lines |
|
This adds a new OS identification parameter (EXTENDED_VERSION) to
the /etc/os-release file in the generated OpenBMC image to indicate
the extended version of the OpenBMC image.
Note the extended version is typically set in the
openbmc/meta-*/meta-MACHINE/conf/local.conf.sample file
(This is where TEMPLATECONF points to.) by "EXTENDED_VERSION"
variable.
Tested: On the build system, `cat $IMAGE_ROOTFS/etc/os-release`
shows the correct value.
Signed-off-by: Chanh Nguyen <chanh@amperemail.onmicrosoft.com>
Change-Id: I34d52e3799d83902e12be95d12f4036b70d721cd
|
|
The --long was added to address the issue described in
openbmc/openbmc#1692 where a tag name may not have a '-' separator, ex:
v1.99.6. The parsing of the tag name would then fail. But the parsing
was recently refactored so it no longer fails, we can remove the extra
verbosity of the VERSION_ID field now.
In simplified form, the previous parsing:
"version = versionList[0] + "-" + versionList[1]"
Current parsing that doesn't fail if versionList[1] doesn't exist:
"versionList[0:2]"
Tested: Created a tag 2.10.99 and verified the build succeeded and
the output of os-release reflected the change in the VERSION_ID:
ID=openbmc-witherspoon
NAME="Phosphor OpenBMC (Phosphor OpenBMC Project Reference Distro)"
VERSION="2.10.99"
VERSION_ID=2.10.99
PRETTY_NAME="Phosphor OpenBMC (Phosphor OpenBMC Project Reference Distro) 2.10.99"
BUILD_ID="2.10.99"
OPENBMC_TARGET_MACHINE="witherspoon"
Change-Id: I502c72a5c3bfd49913b34bbaa041086c11845421
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>
|
|
bitbake recipes are run under a process monitor called 'pseudo'.
We are observing cases where these are triggering a "Pseudo Abort" due
to inode reuse (https://wiki.yoctoproject.org/wiki/Pseudo_Abort) of
some sort. 'pseudo' is used for running operations which may require
higher levels of privledge and recording them so they can be re-applied
when building a file system. The `git` calls we are doing are to
determine the revision of the repository and therefore do not need
'pseudo' support. Disable it with the PSEUDO_DISABLED=1 env var.
Also, add a bb.warn call of any exception that is caused by the `git`
call for future debugging.
(From meta-phosphor rev: 64cdbcfa62b5009f7282091b54d10e1149cf0689)
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I6ac3fbb1ee15f435ce53ce8f82830120446205a9
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
|
|
The previous implementation of the OpenBMC os-release.bbappends
used a python function to inject `git` results into Python
variables. Since the python function is then executed at multiple
task phases, it can result in the hash value changing between tasks,
which causes bitbake failures.
Rewrite the os-release implementation to use forced immediate
variable expansion, rather than a python function. This, combined
with BB_DONT_CACHE, allows the variables to be expanded once at
recipe parse time and the values to continue through to the rest of
the task phases without affecting the hash.
Fixes openbmc/openbmc#3720.
(From meta-phosphor rev: 5266d02bd2a8a6d3a6e047b212f06c7e7aaacb36)
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: If221573cdfefc2b0496a0ef2aca4d3cbc82abb7b
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
|
|
This reverts commit f2b07859cc9586f96b072678d1f5f4586e77850b.
This turned out to only help hide the issue. Builds would pass but the
os-release value in the flash image would not be correct when this bug
hit.
(From meta-phosphor rev: aae84925dc578f2025aa19c90a718d012aee2577)
Change-Id: I4d6c436297687469116709ebc535bf1d343936f4
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
|
|
Chasing an intermittent os-release build failure via
openbmc/openbmc#3720. Not clear if this fix will resolve
that issue but there does not appear to be any reason to
run the logic in the bbappend outside of the do_compile
step since that is the only place the OS_RELEASE_FIELDS
are utilized by the base recipe.
(From meta-phosphor rev: f2b07859cc9586f96b072678d1f5f4586e77850b)
Change-Id: I5f14da2babc852f3d39f2ca6bae4bf993d5e22da
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
|
|
This adds a new OS identification parameter (OPENBMC_TARGET_MACHINE) to
the /etc/os-release file in the generated OpenBMC image to indicate the
kind of device the OpenBMC image is targeted to control.
This is needed to be able to track the image back to its source code: the
distro and version indicate the exact source code that was used, and the
target machine says which Bitbake layer configuration within that source
was used.
Note the target machine name is typically set in the
openbmc/meta-*/meta-MACHINE/conf/local.conf.sample file.
(This is where TEMPLATECONF points to.)
The "uname" command options -m (machine) and -i (hardware platform) will
continue to refer to the BMC and not its target machine.
Tested: On the build system, `cat $IMAGE_ROOTFS/etc/os-release` shows
the correct value.
(From meta-phosphor rev: e9319a8c4b7bc9b737fbb6e5359f878d5ab13e7a)
Change-Id: I29483ef4a72ae80c30399c795177ed446456740d
Signed-off-by: Joseph Reynolds <jrey@us.ibm.com>
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
|
|
Adopt a more conventional directory hierarchy. meta-phosphor is still
a _long_ way from suitable for hosting on yoctoproject.org but things
like this don't help.
(From meta-phosphor rev: 471cfcefa74b8c7ceb704cb670e6d915cf27c63b)
Change-Id: I3f106b2f6cdc6cec734be28a6090800546f362eb
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
|