+++ 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
In the post-storage rewrite world, does this bug still exist?
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.
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.
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} };
(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 :-)
Created attachment 339523 [details] files from /tmp LVM is still broken with mmcblk0... I'll retry without LVM as see how that goes.
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..
(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.
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
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