Bug 581218 - partition config in interactive kickstart results in extra LVM VolGroup
partition config in interactive kickstart results in extra LVM VolGroup
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-11 03:23 EDT by Larry O'Leary
Modified: 2010-09-09 09:36 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-09-09 09:36:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
A kickstart configuration file that can be used to demonstrate the bug (2.22 KB, text/plain)
2010-04-11 03:23 EDT, Larry O'Leary
no flags Details
Anaconda error when attempting to use "All Space" option with pv.01 set to --size=1 --grow (21.91 KB, application/x-gzip)
2010-09-04 02:39 EDT, Larry O'Leary
no flags Details
Anaconda error after Finding Storage Devices... with no --size for pv.01 (17.74 KB, application/x-gzip)
2010-09-04 02:41 EDT, Larry O'Leary
no flags Details

  None (edit)
Description Larry O'Leary 2010-04-11 03:23:12 EDT
Created attachment 405786 [details]
A kickstart configuration file that can be used to demonstrate the bug

Description of problem:
I performed an interactive kickstart install of Fedora 12 on an i386 with the intent that my partitions would be setup to my liking.  Here is the partition information in my kickstart file:

clearpart --all --drives=sda
part /boot --fstype=ext4 --size=200
part pv.01 --grow --size=1
volgroup vg_default --pesize=4096 pv.01
logvol / --fstype=ext4 --name=lv_root --vgname=vg_default --grow --size=1024 --maxsize=10240
logvol swap --name=lv_swap --vgname=vg_default --recommended
logvol /home --fstype=ext4 --name=lv_home --vgname=vg_default --grow --size=5120 --maxsize=40960
logvol /var --fstype=ext4 --name=lv_var --vgname=vg_default --grow --size=1024 --maxsize=5120
logvol /opt --fstype=ext4 --name=lv_opt --vgname=vg_default --grow --size=1024 --maxsize=10240
logvol /tmp --fstype=ext4 --name=lv_tmp --vgname=vg_default --grow --size=1024 --maxsize=6144

The key here is that the "interactive" option was in the kickstart configuration file.  The intent was to allow the user to modify the "default" settings provided by the kickstart file.  

After the installation finished, boot failed because the root file system could not be mounted.  According to mtab it was already mounted.  After looking at what occurred I noticed that my new system contained an extra LVM Volume Group named VolGroup whith to Logical Volumes.  One named lv_root and one named lv_swap.  It appears that VolGroup and its logical volumes where the default volumes created when no partition information is given.  The strange thing is that it appears that everything ended up getting installed where it was supposed to.  vg_default-lv_root instead of VolGroup-lv_root but Grub uses VolGroup-lv_root as the root filesystem to the kernel.  I am guessing that the boot failure is due to VolGroup-lv_root being mounted at / and then vg_default-lv_root can not be mounted at /.  

I have attached a sample kickstart config file that can be used to demonstrate the issue.  


How reproducible:
Every if the interactive kickstart is performed

Steps to Reproduce:
1. Boot target machine using F12 install CD/DVD
2. Highlight "Install or upgrade an existing system" option
3. Press Tab
4. Append: ks=http://anhttpserver/hosting/kickstart/file.ks
5. Click Next on each page of the installer where possible.
6. Finish installation and reboot machine
  
Actual results:
Machine fails to boot due to inability to mount root file system.  There are two LVM Volume Groups; VolGroup and vg_default each containing a lv_root partition.  VolGroup is on sda2 and vg_default is on sda5.

Expected results:
Machine should have booted normally with no incidents and should have had a single LVM Volume Group named vg_default on sda2

Additional info:
I have attached a sample kickstart config file that can be used to demonstrate the issue.  

It appears that "interactive" continues to create the default partitioning layout resulting in extra partitions being created.  Normally, sda1 and sda2 are created.  sda1 hold the /boot partition and sda2 holds the LVM partition named VolGroup with lv_swap and lv_root.  In the case of partitioning information being provided in the kickstart file, what ends up happening is that the partition configuration is added to the default partition configuration.  This resulting in sda3 containing a /boot partition and sda4 containing and extend partition which contain sda5 which has the LVM for vg_default with all the logical volumes defined from kickstart file.

Also, this is evident during the interactive install if you check the option to review and modify the partition layout.  It also is not possible to delete/correct the partitioning issue due to strange behaviour with the Delete partition action in where the partition gets deleted by the Free space can not be reallocated to one of the other partitions without recreating all of them.
Comment 1 Chris Lumens 2010-06-03 11:29:30 EDT
This sounds very familiar to me, though I'm not able to find a specific commit or bug report offhand.  I know we've had interactive kickstart partitioning bugs before and I know I've fixed several.  Can you please give F13 a quick test with the same setup and verify whether or not you're still seeing this problem?  If you are, I'll take a look at it again.  Thanks.
Comment 2 Manuel Faux 2010-08-19 17:19:02 EDT
Can you reproduce the bug on F13, Larry?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 3 Larry O'Leary 2010-09-04 00:57:36 EDT
Sorry for the delay... Attempting my previous test now fails during interactive configuration.  I am asked what storage layout I would like to us but I simply click next (leaving the default of Use entire disk).  Next, I get the following error:

Could not allocate requested partitions:

not enough space for LVM requests.

Press 'OK' to exit the installer.


The installation will not proceed.  I also tried checking the "View/Modify Layout" checkbox in the hopes that I could see what was actually going on but to no avail.

The disk size in 80GB so it should be sufficient to hold the partition information in the Kickstart file.  Additionally, the partition configuration specifies minimum and maximum sizes that I would expect to fit on even a 30GB disk.

Thoughts?
Comment 4 Larry O'Leary 2010-09-04 02:39:19 EDT
Created attachment 443029 [details]
Anaconda error when attempting to use "All Space" option with pv.01 set to --size=1 --grow
Comment 5 Larry O'Leary 2010-09-04 02:41:05 EDT
Created attachment 443030 [details]
Anaconda error after Finding Storage Devices... with no --size for pv.01
Comment 6 Larry O'Leary 2010-09-04 02:48:23 EDT
Also re-tested using 160GB disk with same result.

I then re-tested using the 160GB disk but this time I selected the "Create Custom Layout" option.  I could now see my disk layout, however all the minimum sizes were used (in other words, they did not grow to the --maxsize setting).  Additionally, when I clicked on one of the partitions (lv_root for example) an uncaught exception occurred (anaconda-exception-001.txt) and the installer terminated.  I believe the uncaught exception was due to the vg_default Volume Group having a size of 0 while the Logical Volumes had sizes greater than 0.  It appears that the --grow argument was ignored for part pv.01 which is where vg_default was being placed.

I then reattempted the install with an updated layout in the Kickstart file of:

clearpart --all --drives=sda
part /boot --fstype=ext4 --size=200
part pv.01 --grow
volgroup vg_default --pesize=4096 pv.01
logvol / --fstype=ext4 --name=lv_root --vgname=vg_default --grow --maxsize=10240
logvol swap --name=lv_swap --vgname=vg_default --recommended
logvol /var --fstype=ext4 --name=lv_var --vgname=vg_default --grow --maxsize=5120
logvol /home --fstype=ext4 --name=lv_home --vgname=vg_default --grow --maxsize=40960
logvol /tmp --fstype=ext4 --name=lv_tmp --vgname=vg_default --grow --maxsize=6144
logvol /opt --fstype=ext4 --name=lv_opt --vgname=vg_default --grow --maxsize=10240


Essentially, all the size options have been removed in the hope to cause maxsize and grow to work.  But still no success.  Now, Anaconda fails shortly after the GUI is started -- after the Finding Storage Devices message -- with an uncaught exception (anaconda-exception-002.txt). From the looks of the debug log, size is required for the part command in the Kickstart file.  I even tried to simply use the --recommended option for the part but same error. --size seems to be required.

So, I gave up on the idea that Kickstart and Anaconda could be smart enough to figure out what I am really wanting.  So, I have now hard-coded the --size for part and all logvol:

clearpart --all --drives=sda --initlabel
part /boot --fstype=ext4 --size=200
part pv.01 --grow --size=9216
volgroup vg_default --pesize=4096 pv.01
logvol / --fstype=ext4 --name=lv_root --vgname=vg_default --size=1024 --grow --maxsize=10240
logvol swap --name=lv_swap --vgname=vg_default --recommended
logvol /var --fstype=ext4 --name=lv_var --vgname=vg_default --size=1024 --grow --maxsize=5120
logvol /home --fstype=ext4 --name=lv_home --vgname=vg_default --size=5120 --grow --maxsize=40960
logvol /tmp --fstype=ext4 --name=lv_tmp --vgname=vg_default --size=1024 --grow --maxsize=6144
logvol /opt --fstype=ext4 --name=lv_opt --vgname=vg_default --size=1024 --grow --maxsize=10240


But, this has still not given me what I need. It does seem to prevent the uncaught exceptions from occurring but I can see the vg_default is actually still too large to fit onto pv.01.  Furthermore, pv.01 (sda2) doesn't show up under the Hard Drives list for sda.  The only thing I see there is a bunch of unallocated space.  However, it gets even stranger.  Clicking Create on the unallocated space and setting it to LVM and "all available space" creates a third partion sda3 which suddenly results in sda1, sda2, and sda3 showing up under Hard Drives.  Furthermore, vg_default on pv.01 has now grown to all available space.  Of course, the Logical Volumes are still very tiny.


I then re-attempted my original test with the new partition layout in my Kickstart file.  This was to simply select the "Use All Space" option rather then the "Create Custom Layout" option.  I also checked the View/Modify checkbox so I could see the layout.  And I am now seeing the same thing I saw in Fedora 12.  The default layout is used VolGroup -- lv_root and lv_swap and then my layout appears on sda5 with vg_default and my lvs.  


So, it would seem at the moment, that one can get around these strange glitches by simply selecting the "Create Custom Layout" and then tweaking the settings from the Kickstart file but this does defeat the purpose of providing a default layout/setup that a user might want to tweak.  I could get around the hard-coding by using post-install scripts and includes to dynamically build the partition layout based on the machine but it would be nice for this simple use case to work.
Comment 7 Chris Lumens 2010-09-09 09:36:46 EDT
Interactive kickstart installs have been deprecated, given this and other similar difficulties.  Note that this only applies to use of the "interactive" command.  Omitting information from a kickstart file will still cause anaconda to stop and prompt for it.

Note You need to log in before you can comment on or make changes to this bug.