Bug 481431 - CF card not available to install to
CF card not available to install to
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Jeremy Katz
Fedora Extras Quality Assurance
: 492148 (view as bug list)
Depends On:
Blocks: 483686
  Show dependency treegraph
Reported: 2009-01-24 14:06 EST by Jerry Vonau
Modified: 2009-03-25 15:24 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 483686 519432 (view as bug list)
Last Closed: 2009-02-16 16:09:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
badhack... (1.06 KB, patch)
2009-01-31 10:25 EST, Alexander Larsson
no flags Details | Diff
isys hack for mmc (2.65 KB, patch)
2009-02-01 19:59 EST, Jerry Vonau
no flags Details | Diff

  None (edit)
Description Jerry Vonau 2009-01-24 14:06:57 EST
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:

Steps to Reproduce:
1. boot install with cf card installed 
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
Comment 1 Martin Langhoff 2009-01-26 17:02:02 EST
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...
Comment 2 Martin Langhoff 2009-01-28 15:04:59 EST
Must be noted that this is on XO hw. With some SD card reader anaconda is reported to work.
Comment 3 Alexander Larsson 2009-01-31 09:47:07 EST
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:

is_probably_full_disk(char *name) {
        while (*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.
Comment 4 Alexander Larsson 2009-01-31 10:23:50 EST
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.
Comment 5 Alexander Larsson 2009-01-31 10:25:26 EST
Created attachment 330524 [details]
Comment 6 Alexander Larsson 2009-01-31 13:38:57 EST
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.
Comment 7 Jerry Vonau 2009-02-01 19:58:19 EST
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...

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

  Device /dev/mmcblk0p2 not found (or ignored by filtering).
Comment 8 Jerry Vonau 2009-02-01 19:59:19 EST
Created attachment 330569 [details]
isys hack for mmc
Comment 9 Jeremy Katz 2009-02-02 18:57:51 EST
(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 10 Jeremy Katz 2009-03-25 15:24:51 EDT
*** Bug 492148 has been marked as a duplicate of this bug. ***

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