Bug 519432 - CF card not available to install to
Summary: CF card not available to install to
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 12
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-08-26 15:30 UTC by Jerry Vonau
Modified: 2010-01-20 18:55 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 481431
Environment:
Last Closed: 2010-01-20 18:55:31 UTC


Attachments (Terms of Use)
tmpfiles (50.00 KB, application/x-tar)
2009-08-26 15:32 UTC, Jerry Vonau
no flags Details

Description Jerry Vonau 2009-08-26 15:30:47 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@laptop.org 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@laptop.org 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@redhat.com 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@redhat.com 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@redhat.com on 2009-01-31 10:25:26 EDT ---

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

--- Additional comment from alexl@redhat.com 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@shaw.ca 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@shaw.ca on 2009-02-01 19:59:19 EDT ---

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

--- Additional comment from katzj@redhat.com 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

--- Additional comment from katzj@redhat.com on 2009-03-25 15:24:51 EDT ---

*** Bug 492148 has been marked as a duplicate of this bug. ***


This bug is back... anaconda 12.16 dated 0823. This was working with F11. Now mmcblk0 doesn't get created in /dev. Files from /tmp attached.

Comment 1 Jerry Vonau 2009-08-26 15:32:22 UTC
Created attachment 358737 [details]
tmpfiles

Comment 2 Joel Andres Granados 2009-09-02 09:09:45 UTC
Jerry:

Maybe we can narrow it down a little.  Lots of things happened from f11 to anaconda-12.16.  Did you have the chance to test with previous versions of anaconda?  12.15 or earlier.  It would be of great help if we can pin-point the version where the bug reapeared.

Comment 3 Bug Zapper 2009-11-16 11:43:01 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping


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