Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1157990 - Anaconda F21B-RC1 forces "/", swap, "/var" to the same vg and physical device target
Summary: Anaconda F21B-RC1 forces "/", swap, "/var" to the same vg and physical device...
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 21
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-28 08:24 UTC by bob
Modified: 2014-11-03 21:22 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-11-03 21:22:21 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)
new volume group (94.85 KB, image/png)
2014-10-28 13:42 UTC, David Shea 		no flags Details
partition layout (93.62 KB, image/png)
2014-11-03 21:21 UTC, David Shea 		no flags Details
Show Obsolete (1) View All

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.
Note You need to log in before you can comment on or make changes to this bug.