Bug 894424

Summary: Fedora 18 installer doesn't recognize LVM partition
Product: [Fedora] Fedora Reporter: Richard Hunnicutt <rhunnicutt>
Component: lvm2Assignee: Peter Rajnoha <prajnoha>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 18CC: agk, bcl, bmarzins, bmr, dcantrell, dennis, dwysocha, g.kaviyarasu, heinzm, jonathan, lvm-team, mads, msnitzer, patmans, pjones, prajnoha, prl, prockai, tomasek, vanmeeuwen+fedora, zkabelac
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 819604 Environment:
Last Closed: 2013-01-18 08:11:59 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
log file from failed install
none
output of lsblk
none
udevadm info log
none
systemctl status lvm2-lvmetad.service log
none
dmesg output none

Description Richard Hunnicutt 2013-01-11 17:31:31 UTC
+++ This bug was initially created as a clone of Bug #819604 +++

This issue still exists and is not transient. My system had several versions of CentOS 6.2 installed. I created two new logical volumes within an existing vol group to install Fedora 18 beta 32 and 64-bit. The first install went as planned. The installer displayed the logical volumes and allowed installation as expected. When I went to install the next version, I was presented with the actual physical partitions only. It did not recognize the previous installations as it did before.

After trying to resolve with no results, I did a grub-install in the old CentOS 6.2, rebooted the system back into the installer, and presto - I now had my logical volumes listed again and was able to install the second version.


+++ This bug was initially created as a clone of Bug #819604 +++

Description of problem:

Fedora 17 (beta) installer doesn't recognize LVM partitions created with previous Fedora releases (I quess it was done using either Fedora 14 or Fedora 12).

'lvdisplay' (on tty2 root console) recognizes the partitions (i.e. logical volumes) but lists them with status 'inactive'.

Please, make some fix, as this bug makes impossible to install the Fedora 17 on my computer at actually. Thank you!

Versions:

I used the Fedora-17-Beta-i386-netinst.iso (sha256sum=00d9714e0fa60630bd3f1674cfcd8222e434d92808c8dece54bb5da583314750) burnt on bootable CD.

--- Additional comment from Chris Lumens on 2012-05-07 15:18:13 EDT ---

Please attach /tmp/anaconda.log, /tmp/program.log, and /var/log/syslog as individual files to this bug report.

--- Additional comment from Petr Tomasek on 2012-05-08 14:19:57 EDT ---

Created attachment 583051 [details]
/tmp/syslog

--- Additional comment from Petr Tomasek on 2012-05-08 14:20:49 EDT ---

Created attachment 583052 [details]
/tmp/program.log

--- Additional comment from Petr Tomasek on 2012-05-08 14:21:20 EDT ---

Created attachment 583053 [details]
/tmp/anaconda.log

--- Additional comment from Petr Tomasek on 2012-05-08 14:22:15 EDT ---

Created attachment 583054 [details]
/tmp/lvdisplay.log

--- Additional comment from Petr Tomasek on 2012-05-08 14:24:33 EDT ---

Here you are. I added also the output of the lvdisplay command.

--- Additional comment from Chris Lumens on 2012-05-23 10:39:31 EDT ---

They are listed as inactive because you first have to activate them in order to use them.  I don't see anything in your logs that indicated anaconda even attempted to find logical volumes.  If still available, can you please also grab /tmp/storage.log?  Thanks.

--- Additional comment from Petr Tomasek on 2012-05-23 16:55:32 EDT ---

Created attachment 586463 [details]
storage.log

--- Additional comment from Patrick Mansfield on 2012-06-18 13:27:16 EDT ---

I seem to be hitting the same problem, I have the following partitioning and LVM layout:

# lsblk /dev/sda
NAME                                                 MAJ:MIN RM   SIZE RO MOUNTPOINT
sda                                                    8:0    0 298.1G  0 
├─sda1                                                 8:1    0 245.9G  0 
│ └─luks-f1191002-0333-4759-ac9f-161507f8191b (dm-0) 253:0    0 245.9G  0 
│   ├─vgwd300-LogVol01 (dm-1)                        253:1    0  14.7G  0 /
│   ├─vgwd300-LogVol02 (dm-2)                        253:2    0     1G  0 [SWAP]
│   ├─vgwd300-LogVol00 (dm-3)                        253:3    0  14.7G  0 /f13root
│   └─vgwd300-LogVol03 (dm-4)                        253:4    0 215.6G  0 /home
├─sda2                                                 8:2    0    50G  0 /windows
├─sda3                                                 8:3    0     1K  0 
├─sda5                                                 8:5    0   251M  0 /boot
└─sda6                                                 8:6    0     2G  0 

Installing with Fedora 17, the partition tool does not show any of the logical volumes for vgwd300, so I can't install to vgwd300-LogVol00 (currently /f13root), and leave the other partitions (my current "/", swap, and /home) as-is.

This worked fine when installing Fedora 15, and it works fine with CentOS 6.2 - with those, I can see and select vgwd300-LogVol00 for "/" root file system.

Any suggested (and of course safe) workarounds are very much appreciated ...

--- Additional comment from David Lehman on 2012-06-18 13:48:58 EDT ---

(In reply to comment #8)
> Created attachment 586463 [details]
> storage.log

For some reason udev is not reporting your PV (sda4) as having any recognizable formatting of any kind. Something is wrong either in udev or blkid if that device is indeed an LVM PV.

--- Additional comment from David Lehman on 2012-06-18 13:51:40 EDT ---

(In reply to comment #9)
<snip>
> Installing with Fedora 17, the partition tool does not show any of the
> logical volumes for vgwd300, 
<snip>

Please attach /tmp/storage.log (as an attachment of type text/plain) so we can get an initial idea of what is happening.

--- Additional comment from Patrick Mansfield on 2012-06-23 21:23:59 EDT ---

Created attachment 593961 [details]
f17 install storage.log

My /tmp/storage.log created while trying to install Fedora 17.

--- Additional comment from David Lehman on 2012-06-25 10:26:33 EDT ---

(In reply to comment #12)
> Created attachment 593961 [details]
> f17 install storage.log
> 
> My /tmp/storage.log created while trying to install Fedora 17.

Everything looks normal in there. Your lvs are correctly recognized by the installer. Please attach /tmp/anaconda.log so we can investigate further. If you want to go ahead and attach /tmp/program.log and /tmp/syslog now as well, feel free -- we may need them at some point. Please do attach them individually, though -- no archives.

--- Additional comment from Patrick Mansfield on 2012-06-30 15:43:10 EDT ---

Created attachment 595471 [details]
fedora 17 /tmp/anaconda.log for failed LVM partition non-usage

--- Additional comment from Patrick Mansfield on 2012-06-30 15:43:57 EDT ---

Created attachment 595472 [details]
fedora 17 /tmp/program.log for failed LVM partition non-usage

--- Additional comment from Patrick Mansfield on 2012-06-30 15:44:41 EDT ---

Created attachment 595473 [details]
fedora 17 /tmp/syslog for failed LVM partition non-usage

--- Additional comment from David Lehman on 2012-07-02 10:07:47 EDT ---

(In reply to comment #16)
> Created attachment 595473 [details]
> fedora 17 /tmp/syslog for failed LVM partition non-usage

How about attaching a screenshot of the main partitioning screen so I can see exactly what you are talking about.

--- Additional comment from Patrick Mansfield on 2012-07-02 17:31:20 EDT ---

(In reply to comment #17)
> (In reply to comment #16)
> > Created attachment 595473 [details]
> > fedora 17 /tmp/syslog for failed LVM partition non-usage
> 
> How about attaching a screenshot of the main partitioning screen so I can
> see exactly what you are talking about.

It'll be another week or two before I can try to install again.

This problem is a show-stopper for me, I'll probably have to switch to CentOS or something that is still supported.

Have you tried to reproduce the problem?

Create or use an encrypted LUKS partition, create a file system on it.

Install, and try to access the file system.

--- Additional comment from David Lehman on 2012-07-12 11:56:55 EDT ---

(In reply to comment #18)
> Have you tried to reproduce the problem?

Yes. See below.

> 
> Create or use an encrypted LUKS partition, create a file system on it.
> 
> Install, and try to access the file system.

I did exactly that. I installed an lvm-on-encrypted-pv setup using the F17 installer, rebooted, then provided the luks passphrase when asked. The custom partitioning screen correctly showed the lvs.

--- Additional comment from Patrick Mansfield on 2012-07-15 16:18:55 EDT ---

(In reply to comment #17)
> (In reply to comment #16)
> > Created attachment 595473 [details]
> > fedora 17 /tmp/syslog for failed LVM partition non-usage
> 
> How about attaching a screenshot of the main partitioning screen so I can
> see exactly what you are talking about.

I re-ran the install today, and the partitions showed up as expected, and I was able to install Fedora 17.

I don't *think* I did anything different, given I tried this 3 times before, and that I was also able install CentOS 6.3. 

I have the log files, and can upload them if you want.

--- Additional comment from David Lehman on 2012-07-16 09:49:08 EDT ---

The log files from a successful install won't tell me anything about the previous failure in this case. I'm going to close this bug since it appears to have been a transient failure.

Comment 1 David Lehman 2013-01-11 18:11:37 UTC
Please attach the full set of logs from the run in which your lvm was not visible. This is absolutely critical to keeping this bug open.

Comment 2 Richard Hunnicutt 2013-01-11 19:14:17 UTC
Created attachment 677054 [details]
log file from failed install

Comment 3 Richard Hunnicutt 2013-01-11 19:23:11 UTC
If this helps:

[root@localhost ~]# lsblk /dev/sda
NAME                                 MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda                                    8:0    0 465.8G  0 disk 
├─sda1                                 8:1    0 232.9G  0 part 
│ ├─vg_centos6-Fedora18--64 (dm-0)   253:0    0    30G  0 lvm  /
│ ├─vg_centos6-Fedora18--32 (dm-4)   253:4    0    20G  0 lvm  
│ └─vg_centos6-Fedora18--test (dm-5) 253:5    0    20G  0 lvm  
├─sda2                                 8:2    0   200M  0 part 
├─sda3                                 8:3    0  73.2G  0 part 
│ └─vg_centos6-LogVol00 (dm-3)       253:3    0  73.2G  0 lvm  
├─sda4                                 8:4    0     1K  0 part 
├─sda5                                 8:5    0     2G  0 part [SWAP]
├─sda6                                 8:6    0   9.8G  0 part 
└─sda7                                 8:7    0 147.7G  0 part 
  └─vg_centoos32bit-LogVol00 (dm-2)  253:2    0 147.7G  0 lvm

Comment 4 David Lehman 2013-01-11 19:53:40 UTC
19:03:33,063 ERR systemd-udevd: timeout: killing '/usr/sbin/lvm pvscan --cache --activate ay --major 8 --minor 19' [611]
19:03:33,066 ERR systemd-udevd: timeout: killing '/usr/sbin/lvm pvscan --cache --activate ay --major 8 --minor 3' [614]
19:03:33,066 ERR systemd-udevd: timeout: killing '/usr/sbin/lvm pvscan --cache --activate ay --major 8 --minor 1' [612]
19:03:33,066 ERR systemd-udevd: timeout: killing '/usr/sbin/lvm pvscan --cache --activate ay --major 8 --minor 7' [613]
19:03:33,066 ERR systemd-udevd: '/usr/sbin/lvm pvscan --cache --activate ay --major 8 --minor 1' [612] terminated by signal 9 (Killed)
19:03:33,066 ERR systemd-udevd: '/usr/sbin/lvm pvscan --cache --activate ay --major 8 --minor 3' [614] terminated by signal 9 (Killed)
19:03:33,066 ERR systemd-udevd: '/usr/sbin/lvm pvscan --cache --activate ay --major 8 --minor 19' [611] terminated by signal 9 (Killed)
19:03:33,066 ERR systemd-udevd: '/usr/sbin/lvm pvscan --cache --activate ay --major 8 --minor 7' [613] terminated by signal 9 (Killed)

All lvm commands appear to be hanging, causing udev (which spawned them) to timeout and terminate them. Since they did not do their job there is no lvm data in the udev database, which the installer relies on.



I don't see any evidence that this is related to grub2. It may end up being a problem with udev or systemd or the kernel, but the next link in the chain is lvm2 so I'm reassigning there.

Comment 5 Peter Rajnoha 2013-01-15 11:14:53 UTC
Please, try to switch to the console and try to get the "lsblk" output as well as the output of "udevadm info --export-db" when the problem occurs during installation. Also the output of pvs, vgs and lvs would help. Thanks.

Comment 6 Peter Rajnoha 2013-01-15 12:54:15 UTC
> 19:03:33,063 ERR systemd-udevd: timeout: killing '/usr/sbin/lvm pvscan
> --cache --activate ay --major 8 --minor 19' [611]

..this is a bit odd since pvscan --cache is NOP in F18 as it requires lvmetad to be used, which is not by default in F18. So even if pvscan --cache is run from within udev rule, it should exit very quickly and practically do nothing. So the timeout must be there either because of huge events being processed but that clearly does not seem to be the case here. Or there's some problematic part in the (lvm command initialization) code that hangs or takes a very long time for some reasone.

But for starters, let's see the output requested in comment #5.

Maybe also add the output of "systemctl status lvm2-lvmetad.service" (the service should be disabled and not running).

Comment 7 Richard Hunnicutt 2013-01-15 17:35:18 UTC
Created attachment 678918 [details]
output of lsblk

Comment 8 Richard Hunnicutt 2013-01-15 17:36:26 UTC
Created attachment 678919 [details]
udevadm info log

Comment 9 Richard Hunnicutt 2013-01-15 17:37:52 UTC
Created attachment 678928 [details]
systemctl status lvm2-lvmetad.service log

Comment 10 Richard Hunnicutt 2013-01-15 17:41:21 UTC
Created attachment 678929 [details]
dmesg output

Also add this because there was an issue recorded within. Not sure if related.

Comment 11 Peter Rajnoha 2013-01-16 13:13:11 UTC
(In reply to comment #9)
> Created attachment 678928 [details]
> systemctl status lvm2-lvmetad.service log

lvm2-lvmetad.service - LVM2 metadata daemon
          Loaded: loaded (/usr/lib/systemd/system/lvm2-lvmetad.service; disabled)
          Active: active (running) since Tue, 2013-01-15 17:16:58 UTC; 15min ago 
            Docs: man:lvmetad(8)
         Process: 653 ExecStart=/usr/sbin/lvmetad (code=exited, status=0/SUCCESS)
        Main PID: 654 (lvmetad)
          CGroup: name=systemd:/system/lvm2-lvmetad.service
                  └ 654 n/a 

Jan 15 17:16:58 localhost systemd[1]: Started LVM2 metadata daemon.

--> this should not be activated by default (as anaconda does not define an lvm.conf and by default, lvmetad is not enabled and used in F18 yet).

But if it is activated by any means (we have to find out why it got activated - but that's another thing to look at), we're then getting into the same problem as already reported in bug #816724. This one is still under an inspection at the moment...

Comment 12 Peter Rajnoha 2013-01-17 09:13:02 UTC
(In reply to comment #11)
> Jan 15 17:16:58 localhost systemd[1]: Started LVM2 metadata daemon.
> 
> --> this should not be activated by default (as anaconda does not define an
> lvm.conf and by default, lvmetad is not enabled and used in F18 yet).

Well, F18 beta still used lvm2-2.02.98-2.fc18 package which had a bug that used lvmetad by default if there was no lvm.conf setting. This was fixed later with lvm2-2.02.98-3.fc18. Could you please try the latest F18 release and see if you can still hit the problem? (the final and official F18 released on Tue Jan 15 2013).

Comment 13 Richard Hunnicutt 2013-01-17 18:47:43 UTC
Tried three times and worked each time.

Thanks!

Comment 14 Peter Rajnoha 2013-01-18 08:11:59 UTC
OK, thanks for testing. I'll mark this one as CLOSED/CURRENTRELEASE (as this bug was seen in the installer only and lvmetad is not used by default in F18 yet anyway). 

We're still tracking the problem with lvmetad in bug #816724.