Bug 483686

Summary: lvm2 doesn't understand mmcblk devs
Product: [Fedora] Fedora Reporter: Jeremy Katz <katzj>
Component: lvm2Assignee: Milan Broz <mbroz>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 10CC: agk, alexl, bmarzins, bmr, dcantrell, dwysocha, heinzm, jvonau3, lvm-team, martin, mbroz, msnitzer, prockai, pvrabec
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: lvm2-2.02.45-4.fc11 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 481431 Environment:
Last Closed: 2009-04-17 11:06:46 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: 481431    
Bug Blocks: 446452    
Attachments:
Description Flags
files from /tmp none

Description Jeremy Katz 2009-02-03 00:09:24 UTC
+++ This bug was initially created as a clone of Bug #481431 +++

Description of problem:
anaconda doesn't not offer to partition a CF card (/dev/mmcblk0) that is seen by stage1

Version-Release number of selected component (if applicable):
F10's installer

How reproducible:
always

Steps to Reproduce:
1. boot install with cf card installed 
2.
3.
  
Actual results:
CF card is not shown to be available to partition and install to. 

Expected results:
install to CF card.

Additional info:
device appears in /dev as mmcblk0

--- Additional comment from martin on 2009-01-26 17:02:02 EDT ---

This fix is specially important for the OLPC School Server - Fedora running from an SD card on an XO is how we run the School Server on XO hardware...

--- Additional comment from martin on 2009-01-28 15:04:59 EDT ---

Must be noted that this is on XO hw. With some SD card reader anaconda is reported to work.

--- Additional comment from alexl on 2009-01-31 09:47:07 EDT ---

I'm seeing this on my acer aspire one with the expansion sdhc slot and i looked a bit at it.

It turns out that the SD card is /dev/mmcblk0 and the partition on it is /dev/mmcblk0p1. This is not visible in system-config-lvm either.

Looking at the system-config-lvm code it uses sfdisk -s to list all devices. This looks in /proc/partitions for the source, but uses some heuristics to find
what are really disks:

int
is_probably_full_disk(char *name) {
        while (*name)
                name++;
        return !isdigit(name[-1]);
}

This clearly doesn't work with the naming scheme for the mmcblk driver, as it ends with a digit for non-partitions.

--- Additional comment from alexl on 2009-01-31 10:23:50 EDT ---

Turns out this is not what is causing anaconda issues.
Instead its the mmcblk0 being storage_type "sd_mmc" and not "disk" in hal.

I'm attaching a badhack i'm using just to get the stuff running on my machine.

--- Additional comment from alexl on 2009-01-31 10:25:26 EDT ---

Created an attachment (id=330524)
badhack...

--- Additional comment from alexl on 2009-01-31 13:38:57 EDT ---

Hmm, i was trying to do a RAID0 on /dev/sda2 and /dev/mmcblk0p1 with this patch, but it seems to fail spectacularly. I'm not really an expert on this stuff, but it seems to become confuser, thinking that sda2 is part of md0 and mmcblk0p1 is part of md_d0, so i'm not able to assemble md0.

I believe this is also due to tools being confused about the mmcblk device naming. Why is it not mmcblka, mmcblkb, mmcblka1, etc.

--- Additional comment from jvonau on 2009-02-01 19:58:19 EDT ---

I used a different path around the isys.py issue(patch later), and the CF card now shows up in the partition screen, then fails when enabling LVM...

lvmout:
Running... ['lvm', 'pvcreate', '-ff', '-y', '-v', '/dev/mmcblk0p2']

  Device /dev/mmcblk0p2 not found (or ignored by filtering).

--- Additional comment from jvonau on 2009-02-01 19:59:19 EDT ---

Created an attachment (id=330569)
isys hack for mmc

--- Additional comment from katzj on 2009-02-02 18:57:51 EDT ---

(In reply to comment #6)
> I believe this is also due to tools being confused about the mmcblk device
> naming. Why is it not mmcblka, mmcblkb, mmcblka1, etc.

Many (many) tools still have assumptions about device naming.  It looks like at least lvm still does, so we'll clone off a bug for that.  mmcblka would actually break things also.  And system-config-lvm's code is apparently broken in lots of other cases since foop1 is used by a number of kernel drivers.

Taking the idea of the patches here, I added something to anaconda that should do the right thing.  And as I said, will then also clone off a bug to get lvm2 fixed

Comment 1 Jesse Keating 2009-04-14 01:11:23 UTC
In the post-storage rewrite world, does this bug still exist?

Comment 2 Jeremy Katz 2009-04-14 02:37:42 UTC
Yes.  We still need the lvm tools to understand the block device names.  This is a trivial patch to lvm based on the several other disk types I've had to add in the past...  not that the package is open to provenpackagers.

Comment 3 Mike Snitzer 2009-04-14 13:43:30 UTC
Jeremy, can you attach your lvm2 patch to this bug?  Not necessary but it would likely move things along quicker for this specific mmcblk.* case.

Comment 4 Milan Broz 2009-04-14 14:02:32 UTC
You mean something like this? (not tested, I have no SD card here...)

--- filter.c.old        2009-02-27 23:47:18.000000000 +0100
+++ filter.c    2009-04-14 16:00:43.000000000 +0200
@@ -78,6 +78,7 @@
        {"vdisk", 8},           /* SUN's LDOM virtual block device */
        {"ps3disk", 16},        /* PlayStation 3 internal disk */
        {"virtblk", 8},         /* VirtIO disk */
+       {"mmcblk", 8},
        {NULL, 0}
 };

Comment 5 Jeremy Katz 2009-04-14 15:58:54 UTC
(In reply to comment #4)
> You mean something like this? (not tested, I have no SD card here...)

Yep.  It's probably worth looking to see what other block devs have been added in kernel land (and/or eventually finding a way that doesn't require constant updates :-)

Comment 6 Jerry Vonau 2009-04-14 16:34:07 UTC
Created attachment 339523 [details]
files from /tmp

LVM is still broken with mmcblk0... I'll retry without LVM as see how that goes.

Comment 7 Jerry Vonau 2009-04-14 17:04:10 UTC
Well, without LVM I get past partitioning, and package selection, using the beta isos on the usbkey(yes!!) but the poor XO displays a kernel opps while installing packages.... :( That I need help with to capture if interested, guess a camera will do that... 
There is much above what scrolled by eye but I can see:
note: mmcqd exited with preempt_count 1
BUG scheduling while atomic: mmcqd/1005/0x10000001

Hope it helps..

Comment 8 Alasdair Kergon 2009-04-15 13:45:28 UTC
(In reply to comment #5)
> Yep.  It's probably worth looking to see what other block devs have been added
> in kernel land (and/or eventually finding a way that doesn't require constant
> updates :-)  

Longer-term, the responsibility for this is likely to be transferred to udev rules.

Comment 9 Milan Broz 2009-04-15 16:41:55 UTC
Tested patch is here
https://www.redhat.com/archives/lvm-devel/2009-April/msg00078.html

I think Alasdair want to do new lvm2 bugfix build for Fedora, if not, I'll rebuild it with just this patch.

Alternatively, you can add
types = [ "mmc", 16 ]

to devices section in /etc/lvm.conf

Comment 10 Milan Broz 2009-04-17 11:06:46 UTC
Fixed in lvm2-2.02.45-4.fc11 / lvm2-2.02.45-4.fc12

Ticket for tagging to F11 final https://fedorahosted.org/rel-eng/ticket/1506