Bug 1323024
| Summary: | Undercloud installation disables LVM activation, which causes boot failure on systems with more than root and swap LVs | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Dan Macpherson <dmacpher> |
| Component: | instack-undercloud | Assignee: | Jeff Peeler <jpeeler> |
| Status: | CLOSED ERRATA | QA Contact: | Shai Revivo <srevivo> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 8.0 (Liberty) | CC: | agk, charcrou, ddomingo, fj-lsoft-ofuku, hjensas, jcoufal, jpeeler, jschluet, mburns, mcornea, ohochman, qguo, rcernin, rhel-osp-director-maint, rhosp-bugs-internal, rnishtal, sasha, shardy, smykhail, tshefi, ykawada |
| Target Milestone: | beta | Keywords: | Triaged |
| Target Release: | 10.0 (Newton) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | instack-undercloud-5.0.0-0.20160907134010.649dc3f | Doc Type: | Known Issue |
| Doc Text: |
A puppet manifest bug incorrectly disables LVM partition automounting during the undercloud installation process. As a result, it is possible for undercloud hosts with partitions other than root and swap (activated on kernel command line) to only boot into an emergency shell.
There are several ways to work around this issue. Choose one from the following:
1. Remove the mountpoints manually from /etc/fstab. Doing so will prevent the issue from manifesting in all future cases. Other partitions could also be removed, and the space added to other partitions (like root or swap).
2. Configure the partitions to be activated in /etc/lvm.conf. Doing so will work until the next update/upgrade, when the undercloud installation is re-run.
3. Restrict initial deployment to only root and swap partitions. This will avoid the issue completely.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-12-14 15:29:31 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1194008, 1274548, 1295530 | ||
Adding jpeeler as he may have more insight into this: https://review.openstack.org/#/c/258139/ This was added as a workaround for kernel panics when using atomic images - Jeff do we know if this is still needed? As far as I know, there wouldn't be anything that would cause this change to be unneeded. But maybe an ironic expert would be able to chime in and confirm. The point was brought up by James that we didn't know how the undercloud might be used with additional logical volumes, but I thought the agreement was that the undercloud isn't expected to be "general use". This bug did not make the OSP 8.0 release. It is being deferred to OSP 10. *** Bug 1327964 has been marked as a duplicate of this bug. *** *** Bug 1333569 has been marked as a duplicate of this bug. *** *** Bug 1340555 has been marked as a duplicate of this bug. *** Mike, remind me how this blocks BZ1194008 again? A more precise fix has been made for this issue here: https://review.openstack.org/#/c/343100/ (In reply to Charles Crouch from comment #15) > Mike, remind me how this blocks BZ1194008 again? Bug 1340555 blocked 1194008. Bug 1340555 was closed as a duplicate of this bug. When a bug gets closed as a duplicate, the "Blocks" field gets copied over to the duplicate bug. Got it! Thanks Mike for the reminder :-) One more fix: https://review.openstack.org/#/c/360790/ (setting back to post as modified should represent committing into RHOS) *** Bug 1374292 has been marked as a duplicate of this bug. *** Verified.
On VM with a 100G disk, following a reboot after installing undercloud I don't hit the usual emergency mode any more, home LV remains active.
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
home rhel -wi-ao---- 39.00g
root rhel -wi-ao---- 50.00g
swap rhel -wi-ao---- 10.00g
Version:
RHEL7.3
instack-undercloud-5.0.0-0.20160907134010.649dc3f.el7ost.noarch
#cat /etc/puppet/manifests/puppet-stack-config.pp
augeas { 'lvm.conf':
require => Package['openstack-nova-compute'],
context => '/files/etc/lvm/lvm.conf/devices/dict/',
changes => 'set global_filter/list/1/str "r|^/dev/disk/by-path/ip.*iscsi.*\.org\.openstack:.*|"'
#cat /etc/lvm/lvm.conf
allow_changes_with_duplicate_pvs = 0
global_filter = ["r|^/dev/disk/by-path/ip.*iscsi.*\.org\.openstack:.*|"]
}
Happened to install today, been following this bug as it would hit me every time, glade it's resolved.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2016-2948.html |
Description of problem: The Undercloud installation includes the following section in its Puppet manifest (/etc/puppet/manifests/puppet-stack-config.pp): # Ensure dm thin-pool is never activated. This avoids an issue # where the instack host (in this case on a VM) was crashing due to # activation of the docker thin-pool associated with the atomic host. augeas { 'lvm.conf': require => Package['openstack-nova-compute'], context => '/files/etc/lvm/lvm.conf/activation/dict/', changes => 'set auto_activation_volume_list/list ""' } This disables auto-activation of volumes. This doesn't affect systems that only have root and swap LVs because these get activated when the kernel starts: linux16 /vmlinuz-3.10.0-327.10.1.el7.x86_64 root=/dev/mapper/rhel_ospd8test-root ro rd.lvm.lv=rhel_ospd8test/root rd.lvm.lv=rhel_ospd8test/swap rhgb quiet LANG=en_AU.UTF-8 However, systems might use additional LVs, especially since the default RHEL installation auto-creates an LV for home if the target installation disk is over a certain size (50 GB according to the RHEL manual). So if these additional LVs don't get activated and you reboot, the boot process will attempt to find and mount the home LV, hang for a minute and half, then timeout and drop you to the emergency shell. If you comment out the line added to /etc/lvm/lvm.conf by puppet-stack-config.pp and reboot, the boot succeeds and the home partition is mounted successfully. Version-Release number of selected component (if applicable): OSPd Puddle from 2016-03-29.3 How reproducible: Always Steps to Reproduce: 1. Install OSPd on a System with additional LVs (e.g. home) 2. Reboot 3. Boot process attempts to mount, fails, then drops to the emergency shell Actual results: Boot process attempts to mount, fails, then drops to the emergency shell Expected results: Boot process succeeds and home LV mounts successfully. Additional info: