Bug 496760

Created attachment 340459 [details]
Attached traceback automatically from anaconda.

Created attachment 340462 [details]
Attached traceback automatically from anaconda.

Install is from boot.iso dated 4/20/2009.  Dell Optiplex GX270, 40 GB hard drive.


I'm going to give the "easy" way to recreate this bug, and then the realistic way.  Each has a slightly different expected result, but both have the same actual result.

"Easy Way"

1.  Install from boot.iso (anaconda 11.5.0.46).
2.  When you get to the drive layout screen, select "replace existing Linux system" and "Review and modify partitioning layout",  then click "Next".
3.  Click "New".
4.  Under "Mount Point", enter "/home" (without quotes).
5.  Click "Fill to maximum allowable size" and click "OK".
6.  Click "Next".
7.  After a few seconds, you'll get an error, with the option of filing a bug.  You'll find the traceback above.

You'll notice after step #5 that the size listed for /dev/sda2 and its logical volume group shrink considerably (mine went from 37946 MB to 188 MB), but the logical volumes within the volume group DO NOT shrink, and thus are larger than their group.  I expected it to show a dialogue box indicating "There is no available room on this device", or something to that effect, since I had not created space on the drive before creating a new partition.  Instead, it incorrectly resized another partition.


Now for the "Realistic" way.

1.  Do steps 1-2 above.
2.  Select the "lv_root" logical volume, then click "Edit".
3.  In the "Edit LVM Volume Group" window, select "lv_root" and click "Edit".
4.  Change the size to 10240 MB and click "OK".
5.  Select "lv_swap" and click "Edit"
6.  Change the size to 2048 MB and click "OK". (You can change it to whatever you want... This is the number I was using).
7.  Do steps 3-7 above.

The idea here was to create a separate partition for /home with the space I had removed from the volume group.  Since I didn't have a calculator handy, I figured the "Fill to maximum allowable size" option would use exactly the remaining space.  So, in this case expected result was to create a new partition with a size less than or equal to the remaining space on the drive.  I say "less than" in case the remaining space isn't exactly divisible by the extent size.

Additional info: This bug presents whether "encrypt disk" is selected or not.

This appears to be a real bug, but what you are trying to do will not work even after the bug is fixed. You are trying to reclaim disk space by changing the sizes of LVs, but to reclaim disk space what you need to shrink is the PVs, which will in turn shrink the VG. However, once the PVs are part of a VG you can no longer edit them. What you will need to do is remove the LVs, remove the VG, resize the PV(s), then rebuild the VG and LVs and /home partition.

Oh...  Oops :)  I guess since anaconda automatically shrunk the PV when I calculated everything else myself I thought that that's what was supposed to happen...  So it wasn't a bug, it was a feature! :)

What should have happened when you clicked "OK" on the dialog to create /home is you should have gotten a popup that said "Not enough free space" or similar, and then dropped you back to the partitioning screen. This is because the disks have been fully allocated and, since the /boot request has a fixed size and the PVs are part of a VG, none of the partitions can be altered (resized).

It does not automatically shrink your PVs/VG to match the sizes of your LVs because it cannot know if you are preparing to add another LV, or if you just want to leave some space in the VG for whatever reason.

Sorry, Dave... that was my failed attempt at humor :)  I understand, and will do this properly from now on.  Thanks for your help!

(In reply to comment #4)
> This appears to be a real bug, but what you are trying to do will not work even
> after the bug is fixed. You are trying to reclaim disk space by changing the
> sizes of LVs, but to reclaim disk space what you need to shrink is the PVs,
> which will in turn shrink the VG. However, once the PVs are part of a VG you
> can no longer edit them. What you will need to do is remove the LVs, remove the
> VG, resize the PV(s), then rebuild the VG and LVs and /home partition.  

For VGs on growing PVs (which are in comment #3 i think), you don't have to
take these steps necessarily. But Mike's steps probably wouldn't work even after
the bug is fixed. (I am working on patch to check that there is enough space for
allocated LVs when adding a partition that would make their PVs(VGs) grow less)
because he wanted to create /home with "Fill to maximum allowable
size" which wouldn't work as he expected. But there is a way to create /home
without removing VG if the VG lies on growing PV (e.g. default PV holding
/ and swap):

Reduce sizes of LVs (e.g. of '/') by amount sufficient to satisfy
added partition request. The thing is that the sufficient amount is not obvious:
In simple case with one growing PV, the amount is the size specified
for new partition (/home). If the new partition is growing ("Fill
to maximum allowable size"), or if more growing PVs come into play,
the sufficient amount depends on how partition growing algorithm
distributes free space between all growing partitions
(including the new one) - that is, how much growing PVs will get
shrinked by added partition.

(In reply to comment #8)
> (In reply to comment #4)

> > This appears to be a real bug, but what you are trying to do will not work even
> > after the bug is fixed. You are trying to reclaim disk space by changing the
> > sizes of LVs, but to reclaim disk space what you need to shrink is the PVs,
> > which will in turn shrink the VG. However, once the PVs are part of a VG you
> > can no longer edit them. What you will need to do is remove the LVs, remove the
> > VG, resize the PV(s), then rebuild the VG and LVs and /home partition.  
> 
> For VGs on growing PVs (which are in comment #3 i think), you don't have to
> take these steps necessarily.

OK, as I learned you will have to, Dave has a patch which will ensure
this more sensible behavior wrt growing PVs.

Created attachment 340964 [details]
Attached traceback automatically from anaconda.

Created attachment 341002 [details]
Attached traceback automatically from anaconda.

Created attachment 341734 [details]
Attached traceback automatically from anaconda.

Comment #12 was F11 Preview on a FSC PRIMERGY Econel 230R S1

*** Bug 498234 has been marked as a duplicate of this bug. ***

Created attachment 341767 [details]
Anaconda dump log

Created attachment 342190 [details]
Attached traceback automatically from anaconda.

This should be fixed in the next build of anaconda.  Thanks for the bug report.

There is a very similar bug in Anaconda in F11 Preview. If you try to resize /boot (to make room for testing kernels) then Anaconda will happily accept the resized volume during partitioning, but will then end up with a volume group containing volumes that exceed the new size of the group - common failure is resizing /boot leads to last volume "swap" being too big within the group.

I think this is a fairly annoying bug, though there is a workaround of going into the groups each time and resizing their members manually.

A fix for this issue is available in the latest Rawhide build.  

Can you confirm that this issue is no longer present?  For information on downloading and installing rawhide, see https://fedoraproject.org/wiki/Releases/Rawhide#Direct_Rawhide_install.

------- Comment From pavan.naregundi.com 2009-05-12 07:30 EDT-------
(In reply to comment #17)
> A fix for this issue is available in the latest Rawhide build.
>
> Can you confirm that this issue is no longer present?  For information on
> downloading and installing rawhide, see
> https://fedoraproject.org/wiki/Releases/Rawhide#Direct_Rawhide_install.
>

I could still reproduce this in latest rawhide build. Not sure latest build has issue this fixed.

Thanks
Pavan

Created attachment 343569 [details]
Anaconda dump log


------- Comment (attachment only) From pavan.naregundi.com 2009-05-12 07:31 EDT-------

Created attachment 343620 [details]
Attached traceback automatically from anaconda.

Created attachment 343900 [details]
Attached traceback automatically from anaconda.

Comment #23 is from an install using boot.iso dated 2009-05-08.  When I check the i386 mirrors (like Virginia Tech), the latest package of anaconda available was last updated 2009-05-08 (version 11.5.0.51-1), so I'm making the assumption that this package was on the 2009-05-08 boot.iso, and that no later version of anaconda is available in a later boot.iso.  If I am incorrect, please let me know.  If not -- it's still broken.  I used the "Easy Method" of recreating the error, as described in Comment #3.

This required a fix to parted, which made it into version 1.8.8-17. This parted package seems to have been built on 08 May, so it would not be in the rawhide trees for that day.

When I get a chance I'll try to reproduce this on my own here.

I retested and got past this problem, but then ran into bug 499459. I am working on a fix for that issue now.

I just retested with boot.iso 2009-05-14 with anaconda 11.5.0.52, and the bug has been fixed.  Thanks!

Mike

------- Comment From pavan.naregundi.com 2009-05-18 02:27 EDT-------
Retested with latest rawhide(anaconda 11.5.0.52). This issue seems to be fixed now.

Thanks for the feedback Mike and Pavan.

Created attachment 344624 [details]
Attached traceback automatically from anaconda.

Reproduced this bug on an IBM Power5 with rawhide-20090519 (includes anaconda-11.5.0.52 and pyparted-2.0.12-1).

Is there another exposure window for this issue (see attached traceback in comment#30)?

Tried to reproduce this on i586 with anaconda-11.5.0.53, following the "Realistic" reproducer from comment #3. Install completed successfully.

Okay, moving this back to CLOSED RAWHIDE.  SaveToBugzilla definitely found this issue and logged it against anaconda-11.5.0.52, but perhaps something else is lurking.  I'll continue testing on that platform to trigger this issue.

Based on Mike, Pavan and Will's feedback, moving back to CLOSED RAWHIDE.

Thanks!

Created attachment 344908 [details]
Attached traceback automatically from anaconda.

Created attachment 345243 [details]
Attached traceback automatically from anaconda.

  I've burned the same .iso at least twice, with K3B and iirc Brasero; it had been downloaded from http://mirrors.kernel.org/fedora/releases/test/11-Preview/Live/i686/F11-Preview-i686-Live.iso on or shortly before 5/23/09. Length 644.7 MB (675987456 bytes)

  I did fiddle with trying to create a /home, around 1/4 - 1/2 the size of the hard drive. Will try again with no fiddling. (I told it "review & modify," but only looked; it appeared to intend putting almost all space into /root.

  I've burned the same .iso at least twice, with K3B and iirc Brasero; it had been downloaded from http://mirrors.kernel.org/fedora/releases/test/11-Preview/Live/i686/F11-Preview-i686-Live.iso on or shortly before 5/23/09. Length 644.7 MB (675987456 bytes)

  I did fiddle with trying to create a /home, around 1/4 - 1/2 the size of the hard drive. Will try again with no fiddling. (I told it "review & modify," but only looked; it appeared to intend putting almost all space into /root.

  Without fiddling, it did install. Rebooting was odd -- it failed to eject the medium, *and* to finish shutting down. I had to use the shutdown button, *and* the three-finger salute, *and* finally the power button (but not remove the electric cord nor the battery). Then I got the medium out with a paper clip. 

   After that, however, it booted into Firstboot, and completed normally. I'm now adding and removing software before doing an update.

Beartooth,

While you downloaded the file on May 23, the F11-Preview iso was created on April 24.  This bug was fixed in early May, and the Preview disk does not get updated.  If you want to retest, you'll need to download the latest rawhide from:

http://mirrors.kernel.org/fedora/development/i386/os/images/

Download the file labeled "boot.iso".  This image basically only includes the installer, so it will download all other packages from the repo when you do the install.

Mike

------- Comment From pavan.naregundi.com 2009-06-01 02:50 EDT-------
This issue is again seen on latest Fedora 11 Rawhide.

Machine: P550
CPU Type: power 5

Steps:
1. Start the f11 rawhide installation.
2. Choose "Use Entire Disk" at partition stage. Anaconda trace gets generated

Attaching the anaconda dump log in next comment.

Thanks
Pavan

Created attachment 346058 [details]
Anaconda dump log


------- Comment (attachment only) From pavan.naregundi.com 2009-06-01 02:52 EDT-------

Created attachment 347466 [details]
Attached traceback automatically from anaconda.

Created attachment 347788 [details]
Attached traceback automatically from anaconda.

Created attachment 347841 [details]
Attached traceback automatically from anaconda.

Created attachment 347986 [details]
Attached traceback automatically from anaconda.

Created attachment 348026 [details]
Attached traceback automatically from anaconda.

Created attachment 348422 [details]
Attached traceback automatically from anaconda.

Created attachment 348587 [details]
Attached traceback automatically from anaconda.

Hi, to me it seems like the options presented at installation does not suit all user cases. Perhaps the menuoptions presented at installation needs to be updated to the "LVM-world" realities. I mean that since a linux LVM system can be on two HD:s, the installation options get a bit confusing. For me at least "use entire disc" sound like a bigger thing than "replace a linux system"(forgot the exact phrase). Could it be some very high level logical error hidden here somewhere?

Probably I am very far out in the blue about this, but I got this feeling and wanted to put some attention to the possibility.

Keep up the good work. Fedora11 is really quick on my old computer :-)

I'm reopening, due to the number of people who are still having this issue with what appears to be the release version of anaconda (ver. 11.5.0.59).  I'm also changing to F11 instead of rawhide.  Please correct if this is wrong.

Could somebody please report how to recreate this error using the release install media?

Mike

When I installed F11 (release) I had to try it a few times before success. I got different fault messages (This LVM-error where among them, i don't remember the other(s)). So comment #51 about lingering metadata make sense to me.

comment #52
"Could somebody please report how to recreate this error using the release
install media?"

I had Ubuntu 9.04 (lvm-installation) on one HD, and fedora on the other HD when I tried to install F11-release version and got a lvm-error.

Created attachment 350132 [details]
Attached traceback automatically from anaconda.

Created attachment 351122 [details]
Attached traceback automatically from anaconda.

Created attachment 351249 [details]
Attached traceback automatically from anaconda.

Created attachment 355226 [details]
Attached traceback automatically from anaconda.

Comment on attachment 355226 [details]
Attached traceback automatically from anaconda.

Re-Install on Dell Optiplex 745.  Base 232GB Sata0 disk contained WinXP is target install/boot drive.

WD 2TB disk attached to Silicon Image Sata controller.

Successfully installed Fedora 11 to WD disk.  Now switching to 250GB disk for base/boot, and it is failing.

Any workarounds?  My first Bugzilla report.  Will keep searching.

anaconda 11.5.0.59

I bypassed the error by:
1. eliminating second 2TB disk from the install
2. Switching from "replace linux" to "use entire disk"
   on the Sata0 250BGB disk.

I'll add the second disk in as a filesystem later.

Created attachment 355339 [details]
Attached traceback automatically from anaconda.

Created attachment 357174 [details]
Attached traceback automatically from anaconda.

Created attachment 357508 [details]
Attached traceback automatically from anaconda.

Created attachment 358623 [details]
Attached traceback automatically from anaconda.

Created attachment 358824 [details]
F12 alpha: anaconda log file


------- Comment on attachment From pavan.naregundi.com 2009-08-27 04:28 EDT-------


This bug still exists in F12 Alpha(anconda 12.15).

Steps where I got this issue:

1. Start the installation in GUI mode
2. select custom partiition
3. partition layout looks similar to below
        * /dev/sda1 prep - 10M
        * /dev/sda2 / (ext4) - 30G
        * /dev/sda3 LVM - 32G
            (physical Extent  - 16M)
                * LogVol00 /ext4  (ext4) - 2G
                * LogVol01 /ext3  (ext3) - 17G
                * LogVol02 /xfs     (xfs)  - ~13G
        * /dev/sda4 Extended partition ~4541M
                * /dev/sda5 swap - 4G
                * free space 541M

After a retry, I did not face this issue with the same configuration. Looks like it is not easily reproducible.

*** Bug 520624 has been marked as a duplicate of this bug. ***

*** Bug 519529 has been marked as a duplicate of this bug. ***

*** Bug 517537 has been marked as a duplicate of this bug. ***

------- Comment From pavan.naregundi.com 2009-09-03 02:18 EDT-------
Redhat, Any updates on this bug?

Next time you hit this, please leave the system in the failure state so I can look around on it. If you want to start collecting information yourself, the output of the following commands would be useful:

  cat /proc/partitions
  for disk in /dev/sd[a-z] ; do parted $disk print ; done
  lvm pvs
  lvm vgs
  lvm lvs

Hi Dave,

I'm not able to reproduce this on RHEL6.0-20091006.0 with anaconda 12.34. If I found that error again, I'll get the requested info for you.

Created attachment 366890 [details]
Attached traceback automatically from anaconda.

------- Comment From emachado.ibm.com 2010-01-15 09:41 EDT-------
Thanks Pavan for retesting this. I'm closing this issue as unreproducible on Fedora 12.

Closing this on the basis of comment 74 along with the fact that nobody has reported seeing this problem on Fedora 12.

Created attachment 390499 [details]
Attached traceback automatically from anaconda.

Created attachment 484258 [details]
Attached traceback automatically from anaconda.