<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
A Gentle Reminder..</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Partrick/Adriyana/Vijay, <br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Kindly share your thoughts whether the below approach can be implemented.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<div>>Adriana's below approach could also be considered for implementation. Please suggest.</div>
<div><br>
</div>
<div><br>
</div>
<div>>> One thought is to create a property that the user specifies for which</div>
<div>>> Host they want to update. This would require creating the</div>
<div>>> /xyz/openbmc_project/software/hostX interfaces and the new property when</div>
<div>>> the BMC starts up. Then for example:</div>
<div>>> - User sets the new "this should be updated" property for host1 and</div>
<div>>> host3.</div>
<div>>> - User calls the Redfish API and select the bios image to upload.</div>
<div>>> - The BMC updater sees it's a host bios image and creates</div>
<div>>> hostX/<versionid> interfaces</div>
<div>>> - THe BMC updater calls the bios_X updater script for only the host</div>
<div>>> instances that have the "this should be updated" property set.</div>
<div><br>
</div>
<div>>The image can be deleted after successfully updating all the hosts having "this should be updated" property set.</div>
<br>
</div>
<div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="Signature">
<div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Thanks,</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Priyatharshan P</div>
</div>
</div>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> P. Priyatharshan <PriyatharshanP@hcl.com><br>
<b>Sent:</b> 23 October 2020 19:04<br>
<b>To:</b> Vijay Khemka <vijaykhemka@fb.com>; Adriana Kobylak <anoo@linux.ibm.com><br>
<b>Cc:</b> patrick@stwcx.xyz <patrick@stwcx.xyz>; openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>; anoo@us.ibm.com <anoo@us.ibm.com>; ojayanth@in.ibm.com <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com <gmills@linux.vnet.ibm.com>; Velumani T-ERS,HCLTech
 <velumanit@hcl.com>; ratagupt@linux.vnet.ibm.com <ratagupt@linux.vnet.ibm.com><br>
<b>Subject:</b> Re: Multi host bios upgrade support in phosphor-bmc-code-mgmt:</font>
<div> </div>
</div>
<style type="text/css" style="display:none">
<!--
p
        {margin-top:0;
        margin-bottom:0}
-->
</style>
<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<div style="box-sizing:border-box; font-family:"Segoe UI",system-ui,"Apple Color Emoji","Segoe UI Emoji",sans-serif; font-size:14px; orphans:2; widows:2">
Partrick/Adriyana/Vijay, Can you please help finalyzing the approach? Based on that we will start the implementation.</div>
<br>
</div>
<div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div id="x_Signature">
<div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Thanks,</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Priyatharshan P</div>
</div>
</div>
</div>
<div id="x_appendonsend"></div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> P. Priyatharshan <PriyatharshanP@hcl.com><br>
<b>Sent:</b> 21 October 2020 10:57<br>
<b>To:</b> Vijay Khemka <vijaykhemka@fb.com>; Adriana Kobylak <anoo@linux.ibm.com><br>
<b>Cc:</b> patrick@stwcx.xyz <patrick@stwcx.xyz>; openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>; anoo@us.ibm.com <anoo@us.ibm.com>; ojayanth@in.ibm.com <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com <gmills@linux.vnet.ibm.com>; Velumani T-ERS,HCLTech
 <velumanit@hcl.com>; ratagupt@linux.vnet.ibm.com <ratagupt@linux.vnet.ibm.com><br>
<b>Subject:</b> Re: Multi host bios upgrade support in phosphor-bmc-code-mgmt:</font>
<div> </div>
</div>
<style type="text/css" style="display:none">
<!--
p
        {margin-top:0;
        margin-bottom:0}
-->
</style>
<div dir="ltr">Hi Vijay,
<div><br>
</div>
<div>As mentioned, the MANIFEST file approach was discussed already. As it is a factory ship-out, it may not be appropriate to add the host IDs into it.</div>
<div><br>
</div>
<div>Partrik was also not inclined towards adding host id into MANIFEST file. Provided below Ptricks response for reference.</div>
<div><br>
</div>
<div>> Why would a MANIFEST file have a different value for a different host</div>
<div>> position anyhow?  Isn't the appropriate firmware image for your host</div>
<div>> card dependent on which host-card-hardware you have installed and not</div>
<div>> which position the card is in?  The type of hardware should be handled</div>
<div>> by ExtendedVersion</div>
<div><br>
</div>
<div>@Patrick, @Adriana Your comments/suggestion helps.</div>
<div><br>
</div>
<div><br>
</div>
<div>Adriana's below approach could also be considered for implementation. Please suggest.</div>
<div><br>
</div>
<div><br>
</div>
<div>> One thought is to create a property that the user specifies for which</div>
<div>> Host they want to update. This would require creating the</div>
<div>> /xyz/openbmc_project/software/hostX interfaces and the new property when</div>
<div>> the BMC starts up. Then for example:</div>
<div>> - User sets the new "this should be updated" property for host1 and</div>
<div>> host3.</div>
<div>> - User calls the Redfish API and select the bios image to upload.</div>
<div>> - The BMC updater sees it's a host bios image and creates</div>
<div>> hostX/<versionid> interfaces</div>
<div>> - THe BMC updater calls the bios_X updater script for only the host</div>
<div>> instances that have the "this should be updated" property set.</div>
<div><br>
</div>
<div>The image can be deleted after successfully updating all the hosts having "this should be updated" property set.</div>
<div><br>
</div>
<div><br>
</div>
<div>Thanks,</div>
Priyatharshan P<br>
<div id="x_x_appendonsend"></div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Vijay Khemka <vijaykhemka@fb.com><br>
<b>Sent:</b> 21 October 2020 05:40<br>
<b>To:</b> Adriana Kobylak <anoo@linux.ibm.com>; P. Priyatharshan <PriyatharshanP@hcl.com><br>
<b>Cc:</b> patrick@stwcx.xyz <patrick@stwcx.xyz>; openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>; anoo@us.ibm.com <anoo@us.ibm.com>; ojayanth@in.ibm.com <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com <gmills@linux.vnet.ibm.com>; Velumani T-ERS,HCLTech
 <velumanit@hcl.com>; ratagupt@linux.vnet.ibm.com <ratagupt@linux.vnet.ibm.com><br>
<b>Subject:</b> Re: Multi host bios upgrade support in phosphor-bmc-code-mgmt:</font>
<div> </div>
</div>
<div class="x_x_BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="x_x_PlainText">[CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.]<br>
<br>
I have another idea of mentioning host details in manifest file to have single<br>
upload only. You can put a single host id or an array of host id in extra version.<br>
Format can be defined, this way as soon as we see bios image uploaded and<br>
based on extra version, it will create as many version interface and allow to<br>
activate them. Once we call all the bios upgrade script, we should delete<br>
image.<br>
<br>
On 10/19/20, 12:26 PM, "Adriana Kobylak" <anoo@linux.ibm.com> wrote:<br>
<br>
    Vijay is correct in that today the image file is deleted after a<br>
    successful activation. Therefore today's logic will for example delete<br>
    the file from /tmp/images/ after Host1 was updated, and a subsequent<br>
    request to update Host2 would fail because the image file would not<br>
    exist anymore. The reason for deleting the file is to preserve space<br>
    since the file is assumed that it's not needed anymore after it was used<br>
    for activation. Otherwise we can potentially fill up the /tmp space.<br>
<br>
    Let's say we keep the image files around forever in /tmp/images/, next<br>
    I'm thinking about the Redfish API where the upload and activation is a<br>
    single step, we'd need to figure out how to specify which Host instances<br>
    should be updated.<br>
<br>
    One thought is to create a property that the user specifies for which<br>
    Host they want to update. This would require creating the<br>
    /xyz/openbmc_project/software/hostX interfaces and the new property when<br>
    the BMC starts up. Then for example:<br>
    - User sets the new "this should be updated" property for host1 and<br>
    host3.<br>
    - User calls the Redfish API and select the bios image to upload.<br>
    - The BMC updater sees it's a host bios image and creates<br>
    hostX/<versionid> interfaces<br>
    - THe BMC updater calls the bios_X updater script for only the host<br>
    instances that have the "this should be updated" property set.<br>
<br>
    It'd also be good if you could check if Redfish has an ability to<br>
    somehow specify the target that needs to be updated, or if others have<br>
    implemented this ability in some other way.<br>
<br>
<br>
<br>
    On 2020-10-19 12:08, P. Priyatharshan wrote:<br>
    > [Vijay's Comment] >Can we use extraversion field in manifest file to<br>
    > identify host...<br>
    ><br>
    >            This Message Is From an External Sender<br>
    ><br>
    >            This message came from outside your organization.<br>
    ><br>
    >  [Vijay's Comment]<br>
    >> Can we use extraversion field in manifest file to identify host id.<br>
    > In manifest file, if purpose is >host then we can check extra version<br>
    > and >find out which host it is applicable for.<br>
    ><br>
    >  [Priyatharshan Response]<br>
    > We have already brought up the point of using manifest file. As a<br>
    > response, Patrick mentioned as<br>
    > "I can't imagine that a 16-blade BladeCenter would want to have 16<br>
    > different files for each slot in the BladeCenter. That doesn't sound<br>
    > like a great user experience".<br>
    ><br>
    > [Vijay's Comment]<br>
    >> Or lese we can add another property in /xyz/openbmc_project/software,<br>
    ><br>
    >> name as host id and user can set this property after uploading image.<br>
    ><br>
    >> I don’t agree with creating multiple interfaces for single image<br>
    >> upgrade. Because image will be deleted after successful activation.<br>
    ><br>
    >  [Priyatharshan Response]<br>
    > Your suggestion of adding "host id" property is a good idea, but has<br>
    > few caveates<br>
    > *. If the image is deleted after programming each host, this brings a<br>
    > sequential nature where bios upgrade time prolongs as many times in<br>
    > multi-host environment (for ex 16-BladeCenter)<br>
    > *. the image needs to be copied into the target every time and the<br>
    > upgrades needs to be started. The bios.bin file copy causes additional<br>
    > delay in the upgradation<br>
    > Based on the approach which we porposed,<br>
    > *. with the single bios image, multiple host can be upgraded using<br>
    > "RequestActivation" in each interface without deleting the bios image<br>
    > *. as it is multi object approach (one for each host), multiple host<br>
    > could be programmed concurrently<br>
    > This would save bios upgrade time.<br>
    ><br>
    >  @Vijay Khemka @patrick@stwcx.xyz @Adriana Kobylak: Kindly share your<br>
    > thoughts on this.<br>
    ><br>
    >  Thanks,<br>
    >  Priyatharshan P<br>
    ><br>
    > -------------------------<br>
    ><br>
    > FROM: Vijay Khemka <vijaykhemka@fb.com><br>
    >  SENT: 16 October 2020 00:58<br>
    >  TO: P. Priyatharshan <PriyatharshanP@hcl.com>; Adriana Kobylak<br>
    > <anoo@linux.ibm.com><br>
    >  CC: openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>;<br>
    > anoo@us.ibm.com <anoo@us.ibm.com>; ojayanth@in.ibm.com<br>
    > <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com<br>
    > <gmills@linux.vnet.ibm.com>; Velumani T-ERS,HCLTech<br>
    > <velumanit@hcl.com>; ratagupt@linux.vnet.ibm.com<br>
    > <ratagupt@linux.vnet.ibm.com><br>
    >  SUBJECT: Re: Multi host bios upgrade support in<br>
    > phosphor-bmc-code-mgmt:<br>
    ><br>
    > [CAUTION: This Email is from outside the Organization. Unless you<br>
    > trust the sender, Don’t click links or open attachments as it may be<br>
    > a Phishing email, which can steal your Information and compromise your<br>
    > Computer.]<br>
    ><br>
    > Can we use extraversion field in manifest file to identify host id.<br>
    ><br>
    > In manifest file, if purpose is host then we can check extra version<br>
    ><br>
    > and find out which host it is applicable for.<br>
    ><br>
    > Or lese we can add another property in /xyz/openbmc_project/software,<br>
    ><br>
    > name as host id and user can set this property after uploading image.<br>
    ><br>
    > I don’t agree with creating multiple interfaces for single image<br>
    ><br>
    > upgrade. Because image will be deleted after successful activation.<br>
    ><br>
    > FROM: openbmc <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org> on<br>
    > behalf of "P. Priyatharshan" <PriyatharshanP@hcl.com><br>
    >  DATE: Thursday, October 15, 2020 at 10:18 AM<br>
    >  TO: Adriana Kobylak <anoo@linux.ibm.com><br>
    >  CC: "openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,<br>
    > "anoo@us.ibm.com" <anoo@us.ibm.com>, "ojayanth@in.ibm.com"<br>
    > <ojayanth@in.ibm.com>, "gmills@linux.vnet.ibm.com"<br>
    > <gmills@linux.vnet.ibm.com>, "Velumani T-ERS, HCLTech"<br>
    > <velumanit@hcl.com>, "ratagupt@linux.vnet.ibm.com"<br>
    > <ratagupt@linux.vnet.ibm.com><br>
    >  SUBJECT: Re: Multi host bios upgrade support in<br>
    > phosphor-bmc-code-mgmt:<br>
    ><br>
    > Thanks Adriana for the clarification.<br>
    ><br>
    > For host bios update, the images will be copied to BMC(/tmp/images)<br>
    > and will start flashing by making RequestedActivation field<br>
    > "xyz.openbmc_project.Software.Activation.RequestedActivations.Active".<br>
    > In our case, the device location will be same for all the bios images<br>
    > (BMC /tmp/images).So I think the above design you proposed[id =<br>
    > version+volume ID] may not work effectively for multi host as the id<br>
    > is still going to be same for all the hosts.<br>
    ><br>
    > We would like to propose the following approach for your review.Kindly<br>
    > go through the below steps and share your valuable suggestions.<br>
    ><br>
    > 1.Number of host will be identified from machine layer<br>
    > [OBMC_HOST_INSTANCES]<br>
    ><br>
    > 2.Code will be modified to create n number of objects based on number<br>
    > of hosts<br>
    ><br>
    >  Ex: Log taken in YosemiteV2 [4 host]<br>
    ><br>
    > root@yosemitev2:~# busctl tree<br>
    > xyz.openbmc_project.Software.BMC.Updater<br>
    ><br>
    > `-/xyz<br>
    ><br>
    >  `-/xyz/openbmc_project<br>
    ><br>
    >  `-/xyz/openbmc_project/software<br>
    ><br>
    >  |-/xyz/openbmc_project/software/1929c585<br>
    ><br>
    >  |-/xyz/openbmc_project/software/host1<br>
    ><br>
    >  | `-/xyz/openbmc_project/software/host1/28bd62d9<br>
    ><br>
    >  |-/xyz/openbmc_project/software/host2<br>
    ><br>
    >  | `-/xyz/openbmc_project/software/host2/28bd62d9<br>
    ><br>
    >  |-/xyz/openbmc_project/software/host3<br>
    ><br>
    >  | `-/xyz/openbmc_project/software/host3/28bd62d9<br>
    ><br>
    >  `-/xyz/openbmc_project/software/host4<br>
    ><br>
    >  `-/xyz/openbmc_project/software/host4/28bd62d9<br>
    ><br>
    > root@yosemitev2:~# busctl tree xyz.openbmc_project.Software.Version<br>
    ><br>
    > `-/xyz<br>
    ><br>
    >  `-/xyz/openbmc_project<br>
    ><br>
    >  `-/xyz/openbmc_project/software<br>
    ><br>
    >  |-/xyz/openbmc_project/software/host1<br>
    ><br>
    >  | `-/xyz/openbmc_project/software/host1/28bd62d9<br>
    ><br>
    >  |-/xyz/openbmc_project/software/host2<br>
    ><br>
    >  | `-/xyz/openbmc_project/software/host2/28bd62d9<br>
    ><br>
    >  |-/xyz/openbmc_project/software/host3<br>
    ><br>
    >  | `-/xyz/openbmc_project/software/host3/28bd62d9<br>
    ><br>
    >  `-/xyz/openbmc_project/software/host4<br>
    ><br>
    >  `-/xyz/openbmc_project/software/host4/28bd62d9<br>
    ><br>
    > 3.This will create activation interface for each host. For a<br>
    > multi-host system if the RequestedActivation is set to<br>
    > "xyz.openbmc_project.Software.Activation.RequestedActivations.Active",<br>
    > then different bios service file will be called based the host.<br>
    ><br>
    > For single host : biosServiceFile = "obmc-flash-host-bios@" +<br>
    > versionId + ".service";<br>
    ><br>
    > For multi host : biosServiceFile = "obmc-flash-host" + host + "-bios@"<br>
    > + versionId + ".service";<br>
    ><br>
    > Then it can be used for multi host even if the firmware image we want<br>
    > to install is the same for multiple host targets.<br>
    ><br>
    > I have created a WIP patch for the design proposed above.Kindly have a<br>
    > glance and share your comments.<br>
    ><br>
    > <a href="https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgerrit.openbmc-project.xyz%2Fc%2Fopenbmc%2Fphosphor-bmc-code-mgmt%2F%2B%2F37448&amp;data=04%7C01%7CPriyatharshanP%40hcl.com%7Cef0c97b4694f44db53a508d87555c902%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637388358605381286%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=SWOdfla2MDRK4ostBDNzozQBpoyNdyvDNXPMpQo05Tk%3D&amp;reserved=0">
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgerrit.openbmc-project.xyz%2Fc%2Fopenbmc%2Fphosphor-bmc-code-mgmt%2F%2B%2F37448&amp;data=04%7C01%7CPriyatharshanP%40hcl.com%7Cef0c97b4694f44db53a508d87555c902%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637388358605381286%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=SWOdfla2MDRK4ostBDNzozQBpoyNdyvDNXPMpQo05Tk%3D&amp;reserved=0</a><br>
    > [1]<br>
    ><br>
    > Thanks,<br>
    ><br>
    > Priyatharshan P<br>
    ><br>
    > -------------------------<br>
    ><br>
    > FROM: Adriana Kobylak <anoo@linux.ibm.com><br>
    >  SENT: 06 October 2020 03:11<br>
    >  TO: P. Priyatharshan <PriyatharshanP@hcl.com><br>
    >  CC: Patrick Williams <patrick@stwcx.xyz>; Velumani T-ERS,HCLTech<br>
    > <velumanit@hcl.com>; openbmc@lists.ozlabs.org<br>
    > <openbmc@lists.ozlabs.org>; anoo@us.ibm.com <anoo@us.ibm.com>;<br>
    > ojayanth@in.ibm.com <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com<br>
    > <gmills@linux.vnet.ibm.com>; ratagupt@linux.vnet.ibm.com<br>
    > <ratagupt@linux.vnet.ibm.com><br>
    >  SUBJECT: Re: Multi host bios upgrade support in<br>
    > phosphor-bmc-code-mgmt:<br>
    ><br>
    > [CAUTION: This Email is from outside the Organization. Unless you<br>
    > trust the sender, Don’t click links or open attachments as it may be<br>
    > a Phishing email, which can steal your Information and compromise your<br>
    > Computer.]<br>
    ><br>
    >  Hi Priyatharshan,<br>
    ><br>
    >  > Object : /xyz/openbmc_project/software/[FIRMWARE_VERSION]_[DEVICE]<br>
    >  > where device could be host1, 2, ...,N<br>
    >  > Interface : xyz.openbmc_project.Software.Activation<br>
    >  ><br>
    >  > Please confirm if our understanding is correct.<br>
    ><br>
    >  I meant that to generate the id, which currently uses the version<br>
    >  string, would instead use the version string plus the string for the<br>
    >  name of the device where it's stored in order to generate the hash.<br>
    > For<br>
    >  example, today the code calls "SHA512_Update("version")", where<br>
    >  "version" is for example "2.9.0-dev-663-g2e34bb673". Instead the code<br>
    >  would detect this version is stored let's say in device "mtd1" or<br>
    >  "mmcblk0p1", it'd then append that device string to version, ex:<br>
    >  "2.9.0-dev-663-g2e34bb673-mmcblk0p1" and pass that string to<br>
    >  SHA512_Update(), therefore creating a different hash depending where<br>
    >  that version of bmc code is stored.<br>
    ><br>
    >  Note that this is for BMC versions only. We discussed that for host<br>
    >  versions, we'd need to modify the code to add a "os-release" file<br>
    > under<br>
    >  /media/ that contained the host version information similar to the<br>
    > BMC's<br>
    >  os-release file. In addition, we'd need to somehow determine that<br>
    > those<br>
    >  files were for host (Bios) versions instead of BMC ones. Perhaps<br>
    >  os-release could have an additional field added to specify the<br>
    > purpose.<br>
    ><br>
    >  > Adriana, Any tentative timeline on your commits availability<br>
    > [generate<br>
    >  > the id based on firmware version plus the device or volume ]<br>
    ><br>
    >  I'd say by early next year at the latest.<br>
    ><br>
    > ::DISCLAIMER::<br>
    ><br>
    > -------------------------<br>
    ><br>
    > The contents of this e-mail and any attachment(s) are confidential and<br>
    > intended for the named recipient(s) only. E-mail transmission is not<br>
    > guaranteed to be secure or error-free as information could be<br>
    > intercepted, corrupted, lost, destroyed, arrive late or incomplete, or<br>
    > may contain viruses in transmission. The e mail and its contents (with<br>
    > or without referred errors) shall therefore not attach any liability<br>
    > on the originator or HCL or its affiliates. Views or opinions, if any,<br>
    > presented in this email are solely those of the author and may not<br>
    > necessarily reflect the views or opinions of HCL or its affiliates.<br>
    > Any form of reproduction, dissemination, copying, disclosure,<br>
    > modification, distribution and / or publication of this message<br>
    > without the prior written consent of authorized representative of HCL<br>
    > is strictly prohibited. If you have received this email in error<br>
    > please delete it and notify the sender immediately. Before opening any<br>
    > email and/or attachments, please check them for viruses and other<br>
    > defects.<br>
    ><br>
    > -------------------------<br>
    ><br>
    ><br>
    > Links:<br>
    > ------<br>
    > [1]<br>
    > <a href="https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgerrit.openbmc-project.xyz%2Fc%2Fopenbmc%2Fphosphor-bmc-code-mgmt%2F%2B%2F37448&amp;data=04%7C01%7CPriyatharshanP%40hcl.com%7Cef0c97b4694f44db53a508d87555c902%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637388358605381286%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=SWOdfla2MDRK4ostBDNzozQBpoyNdyvDNXPMpQo05Tk%3D&amp;reserved=0">
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgerrit.openbmc-project.xyz%2Fc%2Fopenbmc%2Fphosphor-bmc-code-mgmt%2F%2B%2F37448&amp;data=04%7C01%7CPriyatharshanP%40hcl.com%7Cef0c97b4694f44db53a508d87555c902%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637388358605381286%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=SWOdfla2MDRK4ostBDNzozQBpoyNdyvDNXPMpQo05Tk%3D&amp;reserved=0</a><br>
<br>
</div>
</span></font></div>
</div>
</div>
</body>
</html>