diff options
| author | Valentin Rothberg <rothberg@redhat.com> | 2021-03-01 09:39:03 +0100 |
|---|---|---|
| committer | Valentin Rothberg <rothberg@redhat.com> | 2021-03-01 09:52:03 +0100 |
| commit | 3752016338da27e0aca6334a287cb76954ff109c (patch) | |
| tree | 3e1782946ce3330644f119923c612bab12ab914f /libpod/runtime_cstorage.go | |
| parent | b154c519ace790f4e0ada60b6e0c6985cf213acb (diff) | |
| download | podman-3752016338da27e0aca6334a287cb76954ff109c.tar.gz podman-3752016338da27e0aca6334a287cb76954ff109c.tar.bz2 podman-3752016338da27e0aca6334a287cb76954ff109c.zip | |
podman rmi: handle corrupted storage better
The storage can easily be corrupted when a build or pull process (or any
process *writing* to the storage) has been killed. The corruption
surfaces in Podman reporting that a given layer could not be found in
the layer tree. Those errors must not be fatal but only logged, such
that the image removal may continue. Otherwise, a user may be unable to
remove an image.
[NO TESTS NEEDED] as I do not yet have a reliable way to cause such a
storage corruption.
Reported-in: https://github.com/containers/podman/issues/8148#issuecomment-787598940
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Diffstat (limited to 'libpod/runtime_cstorage.go')
0 files changed, 0 insertions, 0 deletions