This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 649530 - storage: no LVs listed for VG
storage: no LVs listed for VG
Status: CLOSED DUPLICATE of bug 652318
Product: Fedora
Classification: Fedora
Component: udev (Show other bugs)
14
Unspecified Unspecified
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 494832
  Show dependency treegraph
 
Reported: 2010-11-03 17:52 EDT by Patrick C. F. Ernzer
Modified: 2010-12-01 08:34 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-01 08:34:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
anaconda sees no LVs (58.36 KB, image/png)
2010-11-03 17:53 EDT, Patrick C. F. Ernzer
no flags Details
storage.log from F14 anaconda (244.51 KB, text/plain)
2010-11-03 17:54 EDT, Patrick C. F. Ernzer
no flags Details
mdadm --detail, lvs, pvs and vgs all under F13 (4.32 KB, text/plain)
2010-11-03 17:59 EDT, Patrick C. F. Ernzer
no flags Details
exceprt from syslog of currently booted F13 on the affected machine (12.54 KB, text/plain)
2010-11-04 18:11 EDT, Patrick C. F. Ernzer
no flags Details
syslog from a rescue boot (858.80 KB, text/plain)
2010-11-11 04:21 EST, Patrick C. F. Ernzer
no flags Details
syslog from a rescue boot (1.64 MB, text/plain)
2010-11-11 17:34 EST, Patrick C. F. Ernzer
no flags Details
/var/log/messages from F14 x86_64 Live boot (98.21 KB, application/octet-stream)
2010-11-12 15:34 EST, Patrick C. F. Ernzer
no flags Details
ks file used to make the updated installation ISO (1.07 KB, application/octet-stream)
2010-11-30 18:02 EST, Patrick C. F. Ernzer
no flags Details

  None (edit)
Description Patrick C. F. Ernzer 2010-11-03 17:52:56 EDT
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
Comment 1 Patrick C. F. Ernzer 2010-11-03 17:53:39 EDT
Created attachment 457597 [details]
anaconda sees no LVs
Comment 2 Patrick C. F. Ernzer 2010-11-03 17:54:27 EDT
Created attachment 457598 [details]
storage.log from F14 anaconda
Comment 4 Patrick C. F. Ernzer 2010-11-03 17:59:20 EDT
Created attachment 457600 [details]
mdadm --detail, lvs, pvs and vgs all under F13
Comment 5 David Lehman 2010-11-04 17:53:12 EDT
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
Comment 6 Patrick C. F. Ernzer 2010-11-04 18:11:32 EDT
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)
Comment 7 Harald Hoyer 2010-11-10 08:32:18 EST
(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
Comment 8 Harald Hoyer 2010-11-10 09:40:43 EST
(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 :)
Comment 9 Patrick C. F. Ernzer 2010-11-11 04:21:33 EST
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?
Comment 10 Harald Hoyer 2010-11-11 08:23:28 EST
hmm, no "ressize" error in the retrigger... try without " --type=devices":

$ /sbin/udevadm trigger --action=add
Comment 11 David Lehman 2010-11-11 12:11:24 EST
Most of the dm and lvm rules do nothing on "add" events -- only "change".
Comment 12 David Lehman 2010-11-11 12:19:30 EST
Ignore my last comment -- I forgot this is all triggered by discovery of the PVs, not the LVs.
Comment 13 Harald Hoyer 2010-11-11 12:39:51 EST
(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-...
Comment 14 Patrick C. F. Ernzer 2010-11-11 17:34:29 EST
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
Comment 15 Patrick C. F. Ernzer 2010-11-11 17:40:39 EST
(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
Comment 16 Harald Hoyer 2010-11-12 05:25:42 EST
(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...
Comment 17 Harald Hoyer 2010-11-12 10:00:17 EST
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
Comment 19 Patrick C. F. Ernzer 2010-11-12 15:34:48 EST
Created attachment 460145 [details]
/var/log/messages from F14 x86_64 Live boot

FWIW, F14 x86_64 Live shows my logical volumes just fine
Comment 20 Patrick C. F. Ernzer 2010-11-30 17:59:10 EST
(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?
Comment 21 Patrick C. F. Ernzer 2010-11-30 18:02:47 EST
Created attachment 463845 [details]
ks file used to make the updated installation ISO
Comment 22 Harald Hoyer 2010-12-01 08:34:55 EST

*** This bug has been marked as a duplicate of bug 652318 ***

Note You need to log in before you can comment on or make changes to this bug.