From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.13) Gecko/20080325 Fedora/2.0.0.13-1.fc8 Firefox/2.0.0.13 Description of problem: When installing Fedora 9 Beta onto a previous setup Fedora 8, Anaconda/LVM fails to recognize the physical volume. It is marked as "foreign". I'd like to be able to have the installer recognize the previously set up LVM setup, upgrade / (containing /usr and /var), but preserve /home. There are two physical disks, /dev/sda and /dev/sdb. sda3 and sdb3 are a RAID1 as /dev/md1. /dev/md1 is a physical volume with 2 logical volumes, / and /home. I'm using a custom layout. Two disks: partition 1: 100 MB RAID 1 (md0) partition 2: 2 GB swap partition 3: 236 GB (rest) RAID 1 (md1) /dev/md0 has an ext3 FS and is mounted as /boot /dev/md1 is a physical volume, and has two logical volumes, 20 GB for root, and the rest for /home. Version-Release number of selected component (if applicable): 11.4.0.55 How reproducible: Always Steps to Reproduce: 1. Begin with a Fedora 8 with / and /home as 2 logical volumes on a RAID1 2. Attempt to install Fedora 9 3. At the disk partitioning stage, see that all attempts to set up an LVM are met with a dialog box saying "Not enough physical volumes". Actual Results: The dialog box entitled "Not enough physical volumes" prevents me from continuing, unless I blow away the extant physical volume, thus defeating the purpose. Expected Results: Anaconda should have recognized the physical volumes, and allowed me to edit them, just as it does for regular disk partitions. Additional info: I tried switching consoles, and starting the RAIDs with "mdadm --auto-detect" and starting LVM with " vgchange -a y". No change. I understand that its probably a catch-22 issue. At the time the disk partitioning runs, nothing has been written to disk yet. Since /dev/md1 isn't yet started, anaconda can't possibly "see" the physical volume. On the other hand, it DOES see the two logical volumes. They're read-only though.
One final oddity: I'm using an 8 GB USB drive for the install media. That seems to work fine, but I mention it Just In Case....
What's the output of running 'blkid' against the device? This might be bug 442937
"blkid /dev/md1" produces no output. Here is the result of "blkid": /dev/mapper/VolGroup00-LogVol01: UUID="3cd7794b-1f91-4c9f-8e97-a63fd8bdf177" SEC_TYPE="ext2" TYPE="ext3" /dev/mapper/VolGroup00-LogVol00: UUID="55c52f1a-9898-4fdf-9b2a-9b144aec3fed" SEC_TYPE="ext2" TYPE="ext3" /dev/sda1: UUID="76c9855b-ca05-682f-dc0c-38345bd70cca" TYPE="mdraid" /dev/sda2: TYPE="swap" LABEL="SWAP-sda2" UUID="2aaa181d-5b27-4efa-baa0-f7e33d8262b0" /dev/sda3: UUID="b3a7ea8b-03da-900c-3506-52b4b6917830" TYPE="mdraid" /dev/sdb1: UUID="76c9855b-ca05-682f-dc0c-38345bd70cca" TYPE="mdraid" /dev/sdb2: TYPE="swap" LABEL="SWAP-sdb2" UUID="0460eb62-2198-4c94-bf68-d050be237d8c" /dev/sdb3: UUID="b3a7ea8b-03da-900c-3506-52b4b6917830" TYPE="mdraid" /dev/md0: UUID="316b290e-ffa4-4818-95ca-cdd88b2c1ce7" SEC_TYPE="ext2" TYPE="ext3" /dev/VolGroup00/LogVol00: UUID="55c52f1a-9898-4fdf-9b2a-9b144aec3fed" SEC_TYPE="ext2" TYPE="ext3" Please let me know of any additional requests. Thanks!
Could you dd out the first 16k or so of /dev/md1 and attach it? Thanks, -Eric
Created attachment 303377 [details] The frist 20k of /dev/md1 I grabbed 20k. If you need more, please let me know!
hmm. [root@inode ~]# blkid -c /dev/null md1.dump md1.dump: UUID="ohO82H-yqE9-keAm-0Jrt-6rcA-LL1x-TPT6wJ" TYPE="lvm2pv" [root@inode ~]# rpm -q e2fsprogs e2fsprogs-1.40.8-2.fc9.x86_64 seems to me to recognize it just fine... (I suppose you probably ran blkid from an older e2fsprogs in your test) So... Jeremy?
Gonna punt back to anaconda; I don't see any evidence that e2fsprogs is doing the wrong thing here.
Blkid -v says "blkid 1.0.0 (12-Feb-2003)" e2fsprogs rpm is e2fsprogs-1.40.4-2.fc8 I attempted running blkid from another console during the install of Fedora 9 beta, but it didn't exist. Is there anything else I can try for you? Thanks!
Danny, yup, lvm pv detection was only recently added to blkid/e2fsprogs; the F8 versions won't have it. But that's ok, anaconda is using the new stuff. (blkid version is .... funny ....) :)
The full error message goes something like this: # if no PV exist, raise an error message and return if len(self.availlvmparts) < 1: self.intf.messageWindow(_("Not enough physical volumes"), _("At least one unused physical " "volume partition is " "needed to create an LVM Volume Group.\n\n" "Create a partition or RAID array " "of type \"physical volume (LVM)\" and then " "select the \"LVM\" option again."), Is anaconda looking for PVs with no LVs on them yet?
(In reply to comment #9) > Danny, yup, lvm pv detection was only recently added to blkid/e2fsprogs; the F8 > versions won't have it. But that's ok, anaconda is using the new stuff. > > (blkid version is .... funny ....) :) Is there a way I can use blkid during the installation of Fedora 9 beta?
I'm not sure that's the issue. This is out of my realm but it appears that anaconda doesn't want to use your PV because it already has LVs on it? Which seems odd for an upgrade path... *shrug*
(In reply to comment #12) > I'm not sure that's the issue. > > This is out of my realm but it appears that anaconda doesn't want to use your PV > because it already has LVs on it? Which seems odd for an upgrade path... *shrug* So, the fact that the RAID isn't running yet has no bearing on this issue? Thanks!
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Is this still an issue in the final release of F9?
Sorry for the delay in my answer. This is NOT an issue at this time. Thanks for your work and patience with me on this issue. Do I need to change the status of this bug? Thanks!
No worries, I'll take care of it. Good to know this is fixed.