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