Ubuntu installer errors on creating lvm volumes

Bug #1375481 reported by Sam Stoelinga
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Fuel for OpenStack
Fix Committed
High
Vladimir Kozhukalov

Bug Description

Description: When deploying an Ubuntu environment on custom hardware the LVM volumes won't get created succesfully. Note when using CentOS environment on the same hardware it works as it should.

The attachment sosreport-node-39 includes all the system information of node that has the problematic hardware.

After first using CentOS to deploy the nodes, which clears the previous disk partitions and then deploy ubuntu it's working fine. So it seems this issue is also specific to existing partitioning and ubuntu not able to cleanly delete previous existing partitioning.

Fuel version: 5.1
build_id: "2014-09-17_21-40-34"
build_number: "11"

Steps to reproduce:
1. Use same hardware environment as sos-report
2. Deploy Ubuntu environment

Actual results:
Deployment failed because it couldn't create the LVM volumes

Expected results:
Deployment succeeds for both CentOS and Ubuntu

Interesting log to see of fuel master is /var/log/remote/10.10.10.24/root.log

Revision history for this message
Sam Stoelinga (sammiestoel) wrote :
Revision history for this message
Sam Stoelinga (sammiestoel) wrote :
description: updated
description: updated
description: updated
Mike Scherbakov (mihgen)
Changed in fuel:
milestone: none → 6.0
Mike Scherbakov (mihgen)
Changed in fuel:
assignee: nobody → Vladimir Kozhukalov (kozhukalov)
Changed in fuel:
importance: Undecided → High
Revision history for this message
Vladimir Kozhukalov (kozhukalov) wrote :

Sam,

could you please provide a diagnostic snapshot which is not touched? That one you attached to this bug does not contain logs for node-39 and looks like someone worked with it and removed some of the files.

What we really need to know is what was the working flow. Afaiu, if you do not install anything and then try ubuntu, it fails (because of LVM), but if you deploy centos and then again ubuntu, it works file. Right?

But we erase every node every time we are going to install OS on it. We do it before reboot, inside bootstrap OS. We write 10M from /dev/zero in the beginning of every partition and every disk. https://github.com/stackforge/fuel-astute/blob/master/mcagents/erase_node.rb#L137-L149

Really need untouched logs.

Revision history for this message
Sam Stoelinga (sammiestoel) wrote :

This is all we have left for now. I have attached the logs that I used. ./remote/10.10.10.24/root.log is interesting to look at.

Changed in fuel:
status: New → Confirmed
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to fuel-library (master)

Fix proposed to branch: master
Review: https://review.openstack.org/135364

Changed in fuel:
status: Confirmed → In Progress
Revision history for this message
Vladimir Kozhukalov (kozhukalov) wrote :

Looks like sometimes when massive /dev changes are expected utilities report "device or resource busy" which is related to udev's inability to handle event queue. Adding udevadm settle can help here. See for example http://permalink.gmane.org/gmane.linux.raid/34027 or http://rwmj.wordpress.com/2012/01/19/udev-unexpectedness/

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

Reviewed: https://review.openstack.org/135364
Committed: https://git.openstack.org/cgit/stackforge/fuel-library/commit/?id=5f39f9d16a3d033ad0273ae3baf8155fab20dddf
Submitter: Jenkins
Branch: master

commit 5f39f9d16a3d033ad0273ae3baf8155fab20dddf
Author: Vladimir Kozhukalov <email address hidden>
Date: Tue Nov 18 20:14:49 2014 +0300

    Added udevadm settle before parted commands

    * udevadm settle waits until udev event queue is handled
      so as to avoid udev race. see for example
      http://rwmj.wordpress.com/2012/01/19/udev-unexpectedness/

    Closes-Bug: 1375481
    Change-Id: I9598f66a8477599959cebf89d1299a30f73a6fbb

Changed in fuel:
status: In Progress → Fix Committed
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.