Red Hat Bugzilla – Bug 481431
CF card not available to install to
Last modified: 2009-03-25 15:24:51 EDT
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
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...
Must be noted that this is on XO hw. With some SD card reader anaconda is reported to work.
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.
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.
Created attachment 330524 [details] badhack...
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.
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).
Created attachment 330569 [details] isys hack for mmc
(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
*** Bug 492148 has been marked as a duplicate of this bug. ***