How to deal with incorrect firmware image in phosphor-bmc-code-mgmt?

[Troy Lee]

Greeting,

Apologize for delayed reply.

Since it would not be possible to obtain the percentage of TFTP transmission.
It would be nice to know when does TFTP transmission completed.

The current behavior, we observed, has slightly different.
Before we upload the image, the BMC.Update has the entry of current
activated software, but not the Software.Version.
After we upload the image into /tmp/images, the entry of
Software.Version is generated, and BMC.Update remain the same as
before.

- We're not able to activate the version from BMC.Updater, because it
is already activated. (Expected)
- We're not able to deleted the version from Software.Version and
/tmp/images, because the delete method is not working if the version
is currently activated.
  Then the image is laying in /tmp/images until next reboot. (Unexpected)
  https://github.com/openbmc/phosphor-bmc-code-mgmt/blob/991af7ecfb579e72613b6c2ab5036a4dc7834636/item_updater.cpp#L233-L246


## Before uploading the image
```
root at romulus:~# busctl tree xyz.openbmc_project.Software.BMC.Updater --no-page
└─/xyz
  └─/xyz/openbmc_project
    └─/xyz/openbmc_project/software
      └─/xyz/openbmc_project/software/02faf2c1
root at romulus:~# busctl tree xyz.openbmc_project.Software.Version --no-page
└─/xyz
  └─/xyz/openbmc_project
    └─/xyz/openbmc_project/software
```

## After uploading the image has the same version ID
```
root at romulus:~# busctl tree xyz.openbmc_project.Software.BMC.Updater --no-page
└─/xyz
  └─/xyz/openbmc_project
    └─/xyz/openbmc_project/software
      └─/xyz/openbmc_project/software/02faf2c1
root at romulus:~# busctl tree xyz.openbmc_project.Software.Version --no-page
└─/xyz
  └─/xyz/openbmc_project
    └─/xyz/openbmc_project/software
      └─/xyz/openbmc_project/software/02faf2c1

root at romulus:~# busctl call xyz.openbmc_project.Software.Version
/xyz/openbmc_project/software/02faf2c1
xyz.openbmc_project.Object.Delete Delete
May 14 17:10:06 romulus phosphor-version-software-manager[1180]:
Error: Version 02faf2c1 is currently running on the BMC. Unable to
remove.

root at romulus:~# busctl tree xyz.openbmc_project.Software.Version --no-page
└─/xyz
  └─/xyz/openbmc_project
    └─/xyz/openbmc_project/software
      └─/xyz/openbmc_project/software/02faf2c1
root at romulus:~# ls /tmp/images
02faf2c1
root at romulus:~# ls /tmp/images/02faf2c1/
MANIFEST          image-kernel      image-rofs        image-rwfs
 image-u-boot      publickey
MANIFEST.sig      image-kernel.sig  image-rofs.sig    image-rwfs.sig
 image-u-boot.sig  publickey.sig
```

Thanks,
Yu-Ting Lee (Troy Lee) <LeeTroy at gmail.com>

Adriana Kobylak <anoo at linux.ibm.com> 於 2019年5月14日 週二 上午12:32寫道：
>
> On 2019-05-08 03:56, Lei YU wrote:
> > On Wed, May 8, 2019 at 4:37 PM Troy Lee <leetroy at gmail.com> wrote:
> >>
> >> Greeting,
> >>
> >> With the method xyz.openbmc_project.Common.TFTP.DownloadViaTFTP,
> >> does OpenBMC have a way to know that TFTP download status(completed)
> >> and the downloaded image is incorrect?
>
> The challenge is the time that takes to perform the TFTP transfer. A
> transfer from a remote server can take minutes to complete, which would
> cause timeouts on the REST server. If we can solve this, then we could
> return a download status.
> See issue for reference : https://github.com/openbmc/openbmc/issues/1691
>
> >>
> >> It would not be a problem if the image is correct, since we'll have an
> >> InterfacesAdded signal.
> >> But if the image is incorrect (untar failure/signature mismatch),
> >> we'll only have an error log entry generated.
> >
> > What is the expected behavior if the image is incorrect?
> >
> >> Or if the image has the same version id with currently running image,
> >> the behavior will become unexpected.
> >
> > I met this problem before, and I think we may discuss the expected
> > behavior,
> > and fix this case.
> >
>
> The current behavior is that a new Version D-Bus object is not created
> because one already exists. If this is unexpected, what should the
> expected
> behavior be?
>
> >>
> >> Because we have another service wants to integrate with firmware
> >> update service, having a way to confirm the image file is nice to
> >> have.
> >>
> >> Thanks,
> >> Troy Lee
> >> --
> >> Yu-Ting Lee (Troy Lee) <LeeTroy at gmail.com>
>