Incorrect Platform Backup partition size after install without wipedisk

Bug #1887448 reported by Frank Miller
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
StarlingX
Fix Released
Medium
Don Penney

Bug Description

Brief Description
-----------------
After a lab was re-installed the Platform Backup partition was incorrectly set at 200M. The proper size is 10G.

Severity
--------
Major: The AIO-SX configuration needs the Platform Backup partition to be 10G to store a backup used for upgrades.

Steps to Reproduce
------------------
Re-install an AIO-SX after it has been previously installed with a different OS and without 1st wiping the disk. Or install a new system with a disk that was previously used for some other purpose other than StarlingX ISO.

Expected Behavior
------------------
The install completes and the partition table has the right size for the Platform Backup partition:
# Start End Size Type Name
1 2048 20482047 9.8G unknown Platform Backup
2 20482048 21096447 300M EFI System EFI System Partition
3 21096448 22120447 500M Microsoft basic primary
4 22120448 63080447 19.5G Microsoft basic primary
5 63080448 539133951 227G Linux LVM extended

Actual Behavior
----------------
The install completed and the partition table had an incorrect size for the Platform Backup partition:
# Start End Size Type Name
1 2099200 2508799 200M unknown Platform Backup
2 20482048 21096447 300M EFI System EFI System Partition
3 21096448 22120447 500M Microsoft basic primary
4 22120448 63080447 19.5G Microsoft basic primary
5 63080448 522356735 219G Linux LVM extended
6 522356736 1002604543 229G unknown LVM Physical Volume

Reproducibility
---------------
Would only be seen if a user does not wipedisk before the install and the disk was not using a StarlingX load before it is installed.

System Configuration
--------------------
AIO-SX

Branch/Pull Time/Commit
-----------------------
n/a

Last Pass
---------
n/a

Timestamp/Logs
--------------
n/a

Test Activity
-------------
Installation

Workaround
----------
Run wipedisk and re-install.

Revision history for this message
Frank Miller (sensfan22) wrote :

Setting to medium priority and tagging for stx.5.0 as this issue has a workaround.

Changed in starlingx:
status: New → Triaged
importance: Undecided → Medium
tags: added: stx.5.0 stx.config
Changed in starlingx:
assignee: nobody → Don Penney (dpenney)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to metal (master)

Fix proposed to branch: master
Review: https://review.opendev.org/740829

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to metal (master)

Reviewed: https://review.opendev.org/740829
Committed: https://git.openstack.org/cgit/starlingx/metal/commit/?id=d438836abe54998ecc4d125a404d29c8f23c9214
Submitter: Zuul
Branch: master

commit d438836abe54998ecc4d125a404d29c8f23c9214
Author: Don Penney <email address hidden>
Date: Mon Jul 13 19:39:02 2020 -0400

    Enhance kickstart check for backup partition

    Add a check of the FS type to the kickstart when checking for a
    pre-existing backup partition. If a node has been installed with
    starlingx using EFI, setting up the first partition to be the backup
    partition, and then reinstalled with a non-starlingx OS that uses
    the first partition for EFI boot, there is a possiblity that the GUID
    metadata is not reset by the non-starlingx OS. When the node is
    reinstalled with starlingx, checking just the GUID could make it
    appear this EFI boot partition is actually a pre-existing backup.

    Enhancing this check to also validate that the FS type is ext4 ensures
    that the backup partition at least has the correct FS type and can be
    resized by the kickstart if needed.

    Change-Id: Ibb64efb495bd07b7999d068f2e3b2dc37fd9cae4
    Close-Bug: 1887448
    Signed-off-by: Don Penney <email address hidden>

Ghada Khalil (gkhalil)
Changed in starlingx:
status: Triaged → Fix Released
Revision history for this message
Ghada Khalil (gkhalil) wrote :

Setting to Fix Released -- the LP didn't close automatically as the commit message didn't have the proper Closes-bug

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.