Commisioned drive is not selected for boot

Bug #1499513 reported by Chris Gregan on 2015-09-24
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MAAS
High
Unassigned
curtin
Undecided
Unassigned

Bug Description

Version: MAAS Version 1.8.2+bzr4041-0ubuntu1 (trusty1)
Environment: HP Proliant

Description:
After re-commissioning a previously used node, juju environment fails to complete with node stuck in Deploying state. With further investigation, the /var/log/juju directory is full of old Openstack logs. It seems MAAS commissioned one drive, but then the hardware booted another. Previous version of MAAS consistently chose the same drive as the machine did for boot.

1) Deploy services using a maas juju env
2) Destroy and re-commision
3) Bootstrap the maas env again
4) ssh into deploying system
5) poke around and look for files from old install

Expected Result:
System is completely wiped during commissioning and same drive is used in all cases

Actual Result:
It seems boot and commission have used different drives, or the process has become confused by an existing OS. Dirty OS is booted for deployment.

Blake Rouse (blake-rouse) wrote :

On MAAS 1.9 during deployment we clear all superblocks on all disks and partitions. This is not an issue in MAAS 1.9, I don't see this as something that we can fix in MAAS 1.8 as it requires custom storage configuration to get those features.

Changed in maas:
status: New → Fix Committed
milestone: none → 1.9.0
tags: added: storage
Changed in curtin:
status: New → Fix Committed
Changed in maas:
importance: Undecided → High
Changed in maas:
status: Fix Committed → Fix Released

This bug is believed to be fixed in curtin in 17.1. If this is still a problem for you, please make a comment and set the state back to New

Thank you.

Changed in curtin:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers