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.
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.
Can you reproduce the bug on F13, Larry? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
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?
Created attachment 443029 [details] Anaconda error when attempting to use "All Space" option with pv.01 set to --size=1 --grow
Created attachment 443030 [details] Anaconda error after Finding Storage Devices... with no --size for pv.01
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.
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.