<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 21, 2020 at 8:17 AM Patrick Williams <<a href="mailto:patrick@stwcx.xyz" target="_blank">patrick@stwcx.xyz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Jul 21, 2020 at 12:57:00AM -0700, Nancy Yuen wrote:<br>
> I'm looking into package management for BMCs in our fleet.  I'm wondering<br>
> who else is interested in this, does it make sense for OpenBMC.  What kind<br>
> of features are important?  What kind of package format (rpm, deb,<br>
> something else)?<br>
<br>
We've similarly started playing with package management at Facebook.<br>
One of the reasons for us doing it is that we still have Python<br>
installed in the image and are running out of space, so we're moving<br>
some of the debug tools into packages that can be side-loaded as needed.<br>
We've also implemented 'ptest', which allows you to create packages<br>
containing your unit tests and run them on a real machine.<br></blockquote><div><br></div><div>Our first use case is loading fw packages for other system components managed by the BMC, so not code directly run by the BMC.  But I can see it extending to other things, daemons we want to update independing etc.  We are also running out of space, exploring secondary storage options.  I think that's primarily where the package manager will be managing packages in Google systems.  The BMC flash will have a basic core firmware image, and load other packages from secondary storage.</div><div><br></div><div>How far have you gotten with package management?  What have you considered?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
We found that we had to switch to ipkg instead of rpm because the extra<br>
things rpm needed were too big to fit.  I recall it was on the order of<br>
5MB of content needed to make rpm work and ipkg was almost free. [1]<br></blockquote><div><br></div><div>Today Google has a custom package format but I want to see what other options make sense in the wider OpenBMC community.  I'm not familiar with ipkg so I'll take a look.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
One issue you'll want to be aware of, that many of our recipes have, is<br>
that they often are missing:<br>
<br>
    PACKAGE_ARCH = "${MACHINE_ARCH}"<br>
<br>
This causes the package to be specified as relevant for a generic ARM<br>
system, matching the architecture revision of your underlying AST2xxx<br>
chip, rather than your particular machine.  Any package which can be<br>
customized for a particular machine (such as by machine-specific compile<br>
flags, or YAML/JSON files) should have the above variable set so that a<br>
package compiled for Witherspoon cannot be installed onto a Zaius.<br>
<br>
If you look under your Yocto build tree under `tmp/work` you'll see<br>
`arm1176jzs-openbmc-linux-gnueabi` and<br>
`witherspoon-openbmc-linux-gnueabi`.  I suspect at least most of the<br>
phosphor-* packages under the arm1176jzs subdirectory are likely candidates<br>
for having this PACKAGE_ARCH fixed.  We might want to simply add it to<br>
any '.bbappend' we do in a machine layer.<br></blockquote><div><br></div><div>I wasn't aware of that, thanks!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
1. <a href="https://github.com/facebook/openbmc/commit/43430d38dfd0e5557f96940547594e01373f863e" rel="noreferrer" target="_blank">https://github.com/facebook/openbmc/commit/43430d38dfd0e5557f96940547594e01373f863e</a><br>
<br>
-- <br>
Patrick Williams<br></blockquote><div><br></div><br clear="all"><div><div dir="ltr">----------<br></div></div><div>Nancy </div></div></div>