Bug 649530
| Summary: | storage: no LVs listed for VG | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Patrick C. F. Ernzer <pcfe> |
| Component: | udev | Assignee: | Harald Hoyer <harald> |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 14 | CC: | anaconda-maint-list, harald, jonathan, vanmeeuwen+fedora |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-12-01 13:34:55 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: | 494832 | ||
| Attachments: | |||
Created attachment 457597 [details]
anaconda sees no LVs
Created attachment 457598 [details]
storage.log from F14 anaconda
Created attachment 457600 [details]
mdadm --detail, lvs, pvs and vgs all under F13
I think udev is bailing before it gets to completely populate the udev database entry for md1. Here are some suspicious syslog entries, following a few lines of context: 20:44:49,148 INFO kernel:[ 99.064201] md1: detected capacity change from 0 to 999798865920 20:44:49,149 INFO kernel:[ 99.065152] md1: detected capacity change from 0 to 999798865920 20:44:49,150 INFO kernel:[ 99.065158] md1: unknown partition table 20:44:49,188 ERR udevd-work: ressize 4096 too short 20:44:49,189 ERR udevd-work: ressize 4096 too short Created attachment 457954 [details]
exceprt from syslog of currently booted F13 on the affected machine
on F13
the 3 raid member disks are
sd ?:0:0:0: [sd?] 976773168 512-byte logical blocks: (500 GB/465 GiB)
and the assembly plus LV detect are fine
Nov 3 23:04:56 morn kernel: md1: detected capacity change from 0 to 999798865920
Nov 3 23:04:56 morn kernel: dracut: mdadm: /dev/md1 has been started with 3 drives.
Nov 3 23:04:56 morn kernel: md1: unknown partition table
Nov 3 23:04:56 morn kernel: usb 2-5.2: New USB device found, idVendor=05e3, idProduct=0607
Nov 3 23:04:56 morn kernel: usb 2-5.2: New USB device strings: Mfr=0, Product=1, SerialNumber=0
Nov 3 23:04:56 morn kernel: usb 2-5.2: Product: USB2.0 Hub
Nov 3 23:04:56 morn kernel: hub 2-5.2:1.0: USB hub found
Nov 3 23:04:56 morn kernel: hub 2-5.2:1.0: 4 ports detected
Nov 3 23:04:56 morn kernel: dracut: Scanning devices md1 for LVM logical volumes VG_morn/LV_F13_slash VG_morn/LV_swap
Nov 3 23:04:56 morn kernel: dracut: inactive '/dev/VG_morn/LV_F11_slash' [12.00 GiB] inherit
Nov 3 23:04:56 morn kernel: dracut: inactive '/dev/VG_morn/LV_F11_home' [300.00 GiB] inherit
Nov 3 23:04:56 morn kernel: dracut: inactive '/dev/VG_morn/LV_swap' [2.00 GiB] inherit
Nov 3 23:04:56 morn kernel: dracut: inactive '/dev/VG_morn/LV_boinc' [5.00 GiB] inherit
999798865920 comes to the expected PSize of 931.12g and all od /dev/md1 being used as PV for the VG I saw no need for a partition table and had no wish to complicate my calculations for alignment (boy am I happy that these days manual calculation is no longer necessary)
(In reply to comment #5) > I think udev is bailing before it gets to completely populate the udev database > entry for md1. Here are some suspicious syslog entries, following a few lines > of context: > > 20:44:49,148 INFO kernel:[ 99.064201] md1: detected capacity change from 0 to > 999798865920 > 20:44:49,149 INFO kernel:[ 99.065152] md1: detected capacity change from 0 to > 999798865920 > 20:44:49,150 INFO kernel:[ 99.065158] md1: unknown partition table > 20:44:49,188 ERR udevd-work: ressize 4096 too short > 20:44:49,189 ERR udevd-work: ressize 4096 too short hmm, I don't think that udev is the problem... You can see the Volume Group VG_morn just fine in comment 1 (In reply to comment #5) > 20:44:49,188 ERR udevd-work: ressize 4096 too short > 20:44:49,189 ERR udevd-work: ressize 4096 too short This indicates, that a udev rule runs a tool with IMPORT, which outputs more than 4096 bytes. Probably one of the anaconda.rules rules :) Created attachment 459703 [details]
syslog from a rescue boot
this is syslog from booting into rescue mode (via PXE) and then issuing
logger PCFE setting udev logging to level debug
/sbin/udevadm control --log-priority=debug
logger PCFE triggering add
/sbin/udevadm trigger --type=devices --action=add
Does this help you determine what's wrong?
hmm, no "ressize" error in the retrigger... try without " --type=devices": $ /sbin/udevadm trigger --action=add Most of the dm and lvm rules do nothing on "add" events -- only "change". Ignore my last comment -- I forgot this is all triggered by discovery of the PVs, not the LVs. (In reply to comment #10) > hmm, no "ressize" error in the retrigger... try without " --type=devices": > > $ /sbin/udevadm trigger --action=add the "ressize" error might be caused like in bug 652318 by /lib/udev/udisks-lvm-pv-export. $ rpm -qf /lib/udev/udisks-lvm-pv-export udisks-... Created attachment 459867 [details]
syslog from a rescue boot
for this round
logger PCFE adjusting logging
/sbin/udevadm control --log-priority=debug
logger PCFE just add
/sbin/udevadm trigger --action=add
logger PCFE just change for good measure
/sbin/udevadm trigger --action=change
(In reply to comment #13) > the "ressize" error might be caused like in bug 652318 by > /lib/udev/udisks-lvm-pv-export. In F14 x86_64 rescue mode, I have no /lib/udev/udisks-lvm-pv-export find tells me I have nothing matching "*pv-export*" either and the few matches on "*export*" come from /sys, /selinux or /modules. Could the binary have a different name under anaconda? FWIW, an F14 box shows me udisks-1.0.1-4.fc14.x86_64 does have /lib/udev/udisks-lvm-pv-export (In reply to comment #14) > Created attachment 459867 [details] > syslog from a rescue boot > > for this round > > logger PCFE adjusting logging > /sbin/udevadm control --log-priority=debug > logger PCFE just add > /sbin/udevadm trigger --action=add > logger PCFE just change for good measure > /sbin/udevadm trigger --action=change no "ressize" error with the trigger... This would fix the "ressize" bug... not sure how this helps here.. udev-161-6.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/udev-161-6.fc14 Created attachment 460145 [details]
/var/log/messages from F14 x86_64 Live boot
FWIW, F14 x86_64 Live shows my logical volumes just fine
(In reply to comment #17) > This would fix the "ressize" bug... not sure how this helps here.. > > udev-161-6.fc14 has been submitted as an update for Fedora 14. > https://admin.fedoraproject.org/updates/udev-161-6.fc14 It does. Thank you. Steps taken: download src and x86_64 to a temp dir $ createrepo /home/pcfe/tmp/BZ649530 $ scp -r /home/pcfe/tmp/BZ649530 root@qnap:/var/ftp/pub/ $ mock -r fedora-14-x86_64 --init $ mock -r fedora-14-x86_64 --no-clean --install pungi # cp ~pcfe/Desktop/f14-pungi.ks /var/lib/mock/fedora-14-x86_64/root/usr/share/pungi/ $ mock -r fedora-14-x86_64 --chroot "/usr/bin/pungi -c /usr/share/pungi/f14-pungi.ks" booted from /var/lib/mock/fedora-14-x86_64/root/20101130/x86_64/iso/Fedora-20101130-x86_64-netinst.iso could see my LVs. As I did not set the distro flag, I got 20101201. Before I make myslef an ISO with the correct tag and aupdate this box, are there any logs you would like me to post? Created attachment 463845 [details]
ks file used to make the updated installation ISO
*** This bug has been marked as a duplicate of bug 652318 *** |
Description of problem: storage: no LVs listed for VG <VG name> even though under F13 I happily use many LVs of that VG. Version-Release number of selected component (if applicable): INFO loader: anaconda version 14.22 on x86_64 How reproducible: always Steps to Reproduce: 1. Have an existing F13 x86_64 install as follows - sda1, sdb1 and sdc1 are a RAID0 that is used /boot (yes, I tricked earlier versions into this) - sda2, sdb2 and sdc2 are a RAID5 and are used as PV - the single VG on this system has enough free PE - 27 existing LVs in the VG (actually, mdadm tells me that md1 was created in Nov 2008, so I've been carrying it for quote a few Fedora releases) 2. boot into Fedora 14 x86_64 install (I do it via PXE but this should not matter) 3. plan to make a new LV for / and use some of the existing LVs (/home amongst others) and not use a large amount of the LVs (those used by KVM and some others) Actual results: after selecting manual partitioning, anaconda shows me md0 and md1, it shows me the VG, but it considers the VG to be empty. (I'll attach screenshot) rescue mode also fails to detect my LVs (the 'you do not have any linux partitions' dialog) booting back into F13 works just fine, so my VG is at least OK enough for F13 Expected results: anaconda shows me all my LVs and allows me to select which ones I want it to use and create at least one new one Additional info: When anaconda showed the VG to be fully free, I did not press onwards. While I have a backup, restoring from DDS-3 is painfully slow. As I have been carrying the VG for quite a few releases, it might very well be something wonky with the VG and not anacoda, I'll be happy to do all the poking at it that you need under F13) I can defer installation of F14 on this box until the end of November, so feel free to misuse me for testing updates.img as an aside; using updates.img from Bug 627153 or not makes (as expected) no difference to the non-recognition of my LVs