Bug 1157990

Summary: Anaconda F21B-RC1 forces "/", swap, "/var" to the same vg and physical device target
Product: [Fedora] Fedora Reporter: bob <redzilla.coralnut>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 21CC: anaconda-maint-list, g.kaviyarasu, jonathan, redzilla.coralnut, vanmeeuwen+fedora
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-11-03 21:22:21 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:
Attachments:
Description Flags
new volume group
none
partition layout none

Description bob 2014-10-28 08:24:30 UTC 
Description of problem:

Anaconda installer in F21Beta RC1 forces "/", swap and "/var" all onto the same vg target on the same physical device.  

I am attempting to perform a multiple device install, placing /boot, /boot/efi and / onto a vg named "ssd" on an SSD physical device.  I am attempting to put /var, swap and /home onto a vg named "hdd" on an HDD physical device.  I am able to complete the partition assignments successfully when the partition type is selected as a regular partition, but the partitioning scheme fails when LVM is selected.  

It fails because anaconda mistakenly applies updates to partitions that are not being actively edited.

If LVM is selected, it is possible to assign "/" to a vg named "ssd" that is targeted to the physical SSD.  I am able to create a new vg named "hdd" on the HDD target to hold "swap".  When I attempt to save the changes that I have made to the configuration for the "swap" partition, anaconda erroneously updates the value of the vg name for the "/" partition, such that "/" and "swap" are forced onto the same volume group on the same physical device.  

Upon attempting to install "/var" onto a separate vg and physical device, assignment to that target also fails when the update button is clicked.  Instead of just updating the values for the partition being edited, anaconda updates the targets "/", "swap" and "/var", even though the partitions are not being edited.  The net result is that all three partitions are forced onto the same vg on the same physical device.  

Anaconda is not honoring instructions to break up the grouping of these partitions so that they can be assigned to different vg on different physical targets.


Version-Release number of selected component (if applicable):

F21 Beta RC1 installation media

How reproducible:

Always

Steps to Reproduce:
1. attempt to assign "/", "/var" and swap to different vg on different physical targets.
2.
3.

Actual results:

root, var and swap are clustered into the same vg on the same physical target.

Expected results:

user-defined assignment of partitions to desired vg and to desired physical targets.

Additional info:

Please understand that the problem is not that I am failing to properly select the appropriate physical target in the pull down menus, or that I am failing to create different vgs with different names.  the problem is that when one of the aforementioned partitions is being edited and the update button is pressed, the update is also being applied erroneously to those partitions that are not actively being edited.
Comment 1 David Shea 2014-10-28 13:42:19 UTC 
Created attachment 951405 [details]
new volume group

In the dropdown with the volume group name, choose "Create a new volume group."
Comment 2 bob 2014-10-28 19:10:11 UTC 
Your closure of this bug was inappropriate.
Your attachment is not related to the problem.

It would appear that you never read the last paragraph in the bug report.  I know how to create a new volume group.  I did it.  That is not what this bug report is about.

This bug is about anaconda applying updates to existing volume group "A" after a commit is made to existing volume group "B".  The application of vg "B" modifications to vg "A" configuration is causing the error of mis-allocation of partitions.

Please don't go closing bugs without bothering to read them.
Comment 3 bob 2014-10-28 19:17:40 UTC 
http://bugzilla.redhat.com/show_bug.cgi?id=1154443

^ Same problem, previously reported, improperly closed due to failure to understand the problem.
Comment 4 David Shea 2014-10-28 19:55:19 UTC 
Then attach some logs. Provide actual steps to reproduce. Stop hiding problems in novels that you accidentally submitted as bug reports.
Comment 5 bob 2014-10-28 21:19:55 UTC 
> Stop hiding problems in novels that you accidentally submitted as bug reports.

There is no "novel" in this bug report, so I don't understand the basis for rude nature of your response.  

Ignoring your angry tone, I am only here to help.  Please specify exactly which logs you would like to see, and the paths to the specific files requested and I'll do what I can to provide the requested information.
Comment 6 David Shea 2014-10-29 13:33:02 UTC 
/tmp/storage.log
/tmp/program.log
/tmp/anaconda.log
Detailed steps to reproduce the problem.
Comment 7 bob 2014-10-29 20:47:11 UTC 
Yesterday I closed Bug 1154347 because the F21BRC1 installer recognized the Standard Local Disk Drives, and opened this bug because LVM was acting like there weren't enough variables assigned to accomodate my LVM paritioning scheme across multiple drives.

Today I tried to collect the data requested in Comment 6.  The result was that the F21BRC1 Installer would not recognize any of the Standard Local Disk Drives on a working F21Beta RC1 system as standard local disks.  Instead, it either fails to recognize them or it errantly reports them as multipath devices.  See Bug 1154347.

The installed F21BRC1 system that I built yesterday works fine.

Sorry, but with the intermittent problem of the installer failing to recognize local standard disk drives it's not possible to collect the requested data.  It appears that htis bug is being blocked by 1154347.  

Bug 1154347 reopened.
Comment 8 David Shea 2014-11-03 21:21:58 UTC 
Created attachment 953277 [details]
partition layout

I created a layout like you described, putting /boot and / in a volume group on one device (and /boot/efi as a regular partition on the same device since you can't have an EFI system partition in LVM), and /home, /var and swap in a volume group on the other device. I did not have any problems. Logs may help to decipher your problems. A list of the steps you took would also be valuable.