Bug 79920
| Summary: | installer miscomputes existing LVM physical volume size | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Alexandre Oliva <oliva> | ||||||||||||||
| Component: | anaconda | Assignee: | Jeremy Katz <katzj> | ||||||||||||||
| Status: | CLOSED RAWHIDE | QA Contact: | Mike McLean <mikem> | ||||||||||||||
| Severity: | medium | Docs Contact: | |||||||||||||||
| Priority: | medium | ||||||||||||||||
| Version: | rawhide | CC: | ronny-rhbugzilla | ||||||||||||||
| Target Milestone: | --- | ||||||||||||||||
| Target Release: | --- | ||||||||||||||||
| Hardware: | i386 | ||||||||||||||||
| OS: | Linux | ||||||||||||||||
| Whiteboard: | |||||||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||||
| Clone Of: | Environment: | ||||||||||||||||
| Last Closed: | 2004-10-03 15:34:21 UTC | Type: | --- | ||||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||||
| Documentation: | --- | CRM: | |||||||||||||||
| Verified Versions: | Category: | --- | |||||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||
| Embargoed: | |||||||||||||||||
| Bug Depends On: | |||||||||||||||||
| Bug Blocks: | 79579 | ||||||||||||||||
| Attachments: |
|
||||||||||||||||
|
Description
Alexandre Oliva
2002-12-18 01:59:48 UTC
We can't read them from the physical volumes because in the new physical volume case, it hasn't been created to read it from yet :( Which is why I wrote we should do something else for volumes yet to be created :-) We can be more conservative with those, but if the volume already exists, we have to be accurate. Okay, added code that should do this. Still need to test it tomorrow. If you want to try it also, grab me on IRC and I'll make you an update disk that will work with Phoebe for testing it. Ouch! Over the holidays, I had a disk failure on the very disk that exposed the problem, and I ended up having to re-create it all from scratch. Apparently I haven't done so in a way that still triggers the problem :-( Got this again on phoebe2. One of the physical extents has 9308 4 MB extents, for a total of 37232 MB, but the installer says it has only 37228MB. According to parted, the partition extends from 8542.406 to 45788.974. Per fdisk, it goes from cylinder 1090 to 5836, with 16065 * 512 bytes per cylinder. Seems to be fixed in a recent tree, that actually reads LVM info from the kernel. This is back in Fedora Core test2 (as well as current tree). A volume group with two PVs of, respectively, 9060660 and 17518882 blocks (as reported by fdisk), containing 2211 and 4276 4MB extents, are reported by anaconda has containing 8840MB and 17100 MB, respectively. I.e., it's off by 1 extend in each of the PVs. Since I have only 1 PE extend free in the VG, disk druid refuses to proceed. This is not a problem for kickstart installs, only for interactive installs. Created attachment 95273 [details]
update disk
Can you try with the attached update image -- it should add a lot more logging
of the data we get, and then grab /tmp/anaconda.log?
* looking at VG: all * found size: 26570752 * found pesize: 4096 * looking at pv hda4: Existing Part Request -- mountpoint: None uniqueID: 6 type: physical volume (LVM) format: None badblocks: None device: hda4 drive: hda primary: None size: 17108.2836914 grow: 0 maxsize: None start: 23567355 end: 58605119 migrate: None origfstype: physical volume (LVM) * looking at pv hda3: Existing Part Request -- mountpoint: None uniqueID: 5 type: physical volume (LVM) format: None badblocks: None device: hda3 drive: hda primary: None size: 8848.30078125 grow: 0 maxsize: None start: 5446035 end: 23567354 migrate: None origfstype: physical volume (LVM) * looking at LV: all/severn * lvsize is: 16777216 (8192.0 megs) * looking at LV: all/swap * lvsize is: 1048576 (512.0 megs) * looking at LV: all/l * lvsize is: 18530304 (9048.0 megs) * looking at LV: all/shrike * lvsize is: 16777216 (8192.0 megs) Is this better with current fc3 trees? Ugh. Hard to tell. I've since switched to LVM2, and significantly different extent counts. I suppose we could jus close this if the way the sizes are computed changed in a significant way likely to fix the problem. I probably won't be able to recreate the scenario I had above. Feel free to close if you like. I think it should be better now. This problem still exists in current rawhide (2005-04-01) Created attachment 112612 [details]
anaconda.log
Created attachment 112613 [details]
output of fdisk -l /dev/hda
Created attachment 112614 [details]
output of parted /dev/hda print
Created attachment 112615 [details]
output of vgdisplay -v
Created attachment 112616 [details]
anaconda screenshot
|