All of lore.kernel.org
 help / color / mirror / Atom feed
* Handling persistent files during BMC updates
@ 2018-03-21 15:07 Adriana Kobylak
  0 siblings, 0 replies; only message in thread
From: Adriana Kobylak @ 2018-03-21 15:07 UTC (permalink / raw)
  To: openbmc; +Cc: ratagupt

Hi all,

Two scenarios I wanted to get your thoughts on regarding persistent 
files during BMC updates:

1. Persistent file whitelists

The static code update method has various options to remove persistent 
files and preserve specific ones such as network configuration and those 
listed in a whitelist 
(https://github.com/openbmc/docs/blob/master/code-update/code-update.md#configure-update-settings).

Do you think the delete persistent files and/or whitelist option should 
be added to the software d-bus interfaces that implement the firmware 
update process 
(https://github.com/openbmc/phosphor-dbus-interfaces/tree/master/xyz/openbmc_project/Software)?


2. Updating / merging persistent files

Ratan brought up this scenario that if for example a BMC image that has 
additional user accounts (and therefore a bigger /etc/group file) is 
installed on the BMC, the /etc/group file would not be updated because 
is part of the persistent files, so the old /etc/group file would 
remain.

A workaround would be for the user to clear the persistent filesystem 
prior the update, which may be undesired, and also how would the user 
know that they should clear the persistent filesystem before updating to 
a specific version.

Some options could include a list or flag that tells the update code 
that overwrite the persistent file during an update. We could also have 
options to merge the contents. Any thoughts?

Thanks!

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2018-03-21 15:07 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-03-21 15:07 Handling persistent files during BMC updates Adriana Kobylak

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.