Delete orphaned pnor read-write volumes.
We have seen many instances where the read-only volumes were
deleted but the read-write partitions were preserved. This
had causes subsequent PNOR updates to fail as the space on
PNOR chip was occupied by these orphaned rw volumes.
Resolves openbmc/openbmc#2376
Change-Id: Id0d750680e4e972ee991d95e8b00f4c6cc1fa72e
Signed-off-by: Saqib Khan <khansa@us.ibm.com>
diff --git a/item_updater.cpp b/item_updater.cpp
index 1014890..e9a283d 100644
--- a/item_updater.cpp
+++ b/item_updater.cpp
@@ -158,6 +158,7 @@
auto activationState = server::Activation::Activations::Active;
static const auto PNOR_RO_PREFIX_LEN = strlen(PNOR_RO_PREFIX);
+ static const auto PNOR_RW_PREFIX_LEN = strlen(PNOR_RW_PREFIX);
// Check if the PNOR_RO_PREFIX is the prefix of the iter.path
if (0 == iter.path().native().compare(0, PNOR_RO_PREFIX_LEN,
@@ -249,6 +250,18 @@
"",
*this)));
}
+ else if (0 == iter.path().native().compare(0, PNOR_RW_PREFIX_LEN,
+ PNOR_RW_PREFIX))
+ {
+ auto id = iter.path().native().substr(PNOR_RW_PREFIX_LEN);
+ auto roDir = PNOR_RO_PREFIX + id;
+ if (!fs::is_directory(roDir))
+ {
+ log<level::ERR>("No corresponding read-only volume found.",
+ entry("DIRNAME=%s", roDir));
+ ItemUpdater::erase(id);
+ }
+ }
}
// Look at the RO symlink to determine if there is a functional image