<= b>[CAUTION: This Email is from outside the Orga= nization. Unless you trust the sender, Don=92t click links or open attachments as it may be a Phishing email, which can s= teal your Information and compromise your Computer.]

Can we use extraversion field in manifest file to = identify host id.

In manifest file, if purpose is host then we can c= heck extra version

and find out which host it is applicable for.

Or lese we can add another property in /xyz/openbmc_project/software,

name= as host id and user can set this property after uploading image.

I do= n=92t agree with creating multiple interfaces for single image

upgr= ade. Because image will be deleted after successful activation.

F= rom: openbmc <openbmc-bounc= es+vijaykhemka=3Dfb.com@lists.ozlabs.org> on behalf of "P. Priyatha= rshan" <PriyatharshanP@hcl.com>
Date: Thursday, October 15, 2020 at 10:18 AM
To: Adriana Kobylak <anoo@linux.ibm.com>
Cc: "openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.or= g>, "anoo@us.ibm.com" <anoo@us.ibm.com>, "ojayanth@= in.ibm.com" <ojayanth@in.ibm.com>, "gmills@linux.vnet.ibm.c= om" <gmills@linux.vnet.ibm.com>, "Velumani T-ERS, HCLTech&q= uot; <velumanit@hcl.com>, "ratagupt@linux.vnet.ibm.com" <ratagupt@linux.vnet.ibm.com>
Subject: Re: Multi host bios upgrade support in phosphor-bmc-code-mg= mt:

Than= ks Adriana for the clarification.

&nbs= p;

For = host bios update, the images will be copied to BMC(/tmp/images) and will st= art flashing by making RequestedActivation field "xyz.openbmc_project.= Software.Activation.RequestedActivations.Active". In our case, the device location will be same for all the bios images (BMC= /tmp/images).So I think the above design you proposed[id =3D version+volum= e ID] may not work effectively for multi host as the id is still goin= g to be same for all the hosts.

&nbs= p;

We w= ould like to propose the following approach for your review.Kindly go throu= gh the below steps and share your valuable suggestions.

&nbs= p;

1.Nu= mber of host will be identified from machine layer [OBMC_HOST_INSTANCES]

&nbs= p;

2.Co= de will be modified to create n number of objects based on number of hosts<= /span>

&nbs= p;

&nbs= p; Ex: Log taken in YosemiteV2 [4 host]

&nbs= p;

root= @yosemitev2:~# busctl tree xyz.openbmc_project.Software.BMC.Updater<= /p>

`-/x= yz

&nbs= p; `-/xyz/openbmc_project

&nbs= p; `-/xyz/openbmc_project/software

&nbs= p; |-/xyz/openbmc_project/software/1929c585

&nbs= p; |-/xyz/openbmc_project/software/host1

&nbs= p; | `-/xyz/openbmc_project/software/host1/28bd62d9

&nbs= p; |-/xyz/openbmc_project/software/host2

&nbs= p; | `-/xyz/openbmc_project/software/host2/28bd62d9

&nbs= p; |-/xyz/openbmc_project/software/host3

&nbs= p; | `-/xyz/openbmc_project/software/host3/28bd62d9

&nbs= p; `-/xyz/openbmc_project/software/host4

&nbs= p; `-/xyz/openbmc_project/software/host4/28bd62d9

root= @yosemitev2:~# busctl tree xyz.openbmc_project.Software.Version

`-/x= yz

&nbs= p; `-/xyz/openbmc_project

&nbs= p; `-/xyz/openbmc_project/software

&nbs= p; |-/xyz/openbmc_project/software/host1

&nbs= p; | `-/xyz/openbmc_project/software/host1/28bd62d9

&nbs= p; |-/xyz/openbmc_project/software/host2

&nbs= p; | `-/xyz/openbmc_project/software/host2/28bd62d9

&nbs= p; |-/xyz/openbmc_project/software/host3

&nbs= p; | `-/xyz/openbmc_project/software/host3/28bd62d9

&nbs= p; `-/xyz/openbmc_project/software/host4

&nbs= p; `-/xyz/openbmc_project/software/host4/28bd62d9

&nbs= p;

3.Th= is will create activation interface for each host. For a multi-host system = if the RequestedActivation is set to "xyz.openbmc_project.Softwa= re.Activation.RequestedActivations.Active", then different bios service file will be called based the host.

&nbs= p;

For = single host : biosServiceFile =3D "obmc-flash-host-bios@" + versi= onId + ".service";

For = multi host : biosServiceFile =3D "obmc-flash-host" + = host + "-bios@" + versionId + ".service";

&nbs= p;

Then= it can be used for multi host even if the firmware image we want to instal= l is the same for multiple host targets.

&nbs= p;

I ha= ve created a WIP patch for the design proposed above.Kindly have a glance a= nd share your comments.

&nbs= p;

https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-bmc-code-mgmt/+/= 37448

&nbs= p;

Than= ks,

Priy= atharshan P

&nbs= p;

From: Adriana Kobylak <anoo@linux.ibm.com>
Sent: 06 October 2020 03:11
To: P. Priyatharshan <PriyatharshanP@hcl.com>
Cc: Patrick Williams <patrick@stwcx.xyz>; Velumani T-ERS,HCLTe= ch <velumanit@hcl.com>; openbmc@lists.ozlabs.org <openbmc@lists.oz= labs.org>; anoo@us.ibm.com <anoo@us.ibm.com>; ojayanth@in.ibm.com = <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com <gmills@linux.vne= t.ibm.com>; ratagupt@linux.vnet.ibm.com <ratagupt@linux.vnet.ibm.com>
Subject: Re: Multi host bios upgrade support in phosphor-bmc-code-mg= mt:

[CAUTION: This Email is from outside the Organizat= ion. Unless you trust the sender, Don=92t click links or open attachments a= s it may be a Phishing email, which can steal your Information and compromi= se your Computer.]

Hi Priyatharshan,

> Object : /xyz/openbmc_project/software/[FIRMWARE_VERSION]_[DEVIC= E]
> where device could be host1, 2, ...,N
> Interface : xyz.openbmc_project.Software.Activation
>
> Please confirm if our understanding is correct.

I meant that to generate the id, which currently uses the version
string, would instead use the version string plus the string for the
name of the device where it's stored in order to generate the hash. For
example, today the code calls "SHA512_Update("version")"= ;, where
"version" is for example "2.9.0-dev-663-g2e34bb673". In= stead the code
would detect this version is stored let's say in device "mtd1" or=
"mmcblk0p1", it'd then append that device string to version, ex:<= br> "2.9.0-dev-663-g2e34bb673-mmcblk0p1" and pass that string to
SHA512_Update(), therefore creating a different hash depending where
that version of bmc code is stored.

Note that this is for BMC versions only. We discussed that for host
versions, we'd need to modify the code to add a "os-release" file= under
/media/ that contained the host version information similar to the BMC's os-release file. In addition, we'd need to somehow determine that those
files were for host (Bios) versions instead of BMC ones. Perhaps
os-release could have an additional field added to specify the purpose.

> Adriana, Any tentative timeline on your commits availability [generate=
> the id based on firmware version plus the device or volume ]

I'd say by early next year at the latest.

::DISCLAIMER::

The contents of this e-mail and any att= achment(s) are confidential and intended for the named recipient(s) only. E= -mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destro= yed, arrive late or incomplete, or may contain viruses in transmission. The= e mail and its contents (with or without referred errors) shall therefore = not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented = in this email are solely those of the author and may not necessarily reflec= t the views or opinions of HCL or its affiliates. Any form of reproduction,= dissemination, copying, disclosure, modification, distribution and / or publication of this message without th= e prior written consent of authorized representative of HCL is strictly pro= hibited. If you have received this email in error please delete it and noti= fy the sender immediately. Before opening any email and/or attachments, please check them for viruses and ot= her defects.