Bug 894424
Summary: | Fedora 18 installer doesn't recognize LVM partition | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Richard Hunnicutt <rhunnicutt> | ||||||||||||
Component: | lvm2 | Assignee: | Peter Rajnoha <prajnoha> | ||||||||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||
Severity: | high | Docs Contact: | |||||||||||||
Priority: | unspecified | ||||||||||||||
Version: | 18 | CC: | 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
Richard Hunnicutt
2013-01-11 17:31:31 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. Created attachment 677054 [details]
log file from failed install
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 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. 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. > 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). Created attachment 678918 [details]
output of lsblk
Created attachment 678919 [details]
udevadm info log
Created attachment 678928 [details]
systemctl status lvm2-lvmetad.service log
Created attachment 678929 [details]
dmesg output
Also add this because there was an issue recorded within. Not sure if related.
(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... (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). Tried three times and worked each time. Thanks! 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. |