Recently, BIOS vendors have been starting to implement a 'boot from SD card' feature, much like they have added 'boot from USB memory stick' some years ago.
The only SD-card host controller that I've seen this implemented for is SDHCI compliant host controllers.
While this is a nice feature to support, for most systems it is just a gimmick and not something neccessarry.
However, there are hand-held devices such as netbooks in the pipeline which do not have any other mass storage device. No hard disk and no IDE-attached flash disk or the like. They just have one (more likely two or more) SD card slots and you install and store not only your data but the entire operating system on that SD card.
Furthermore, there are products like Samsung moviNAND which are basically a SDcard in a BGA package that can be soldered onto a PCB. So from a protocol and software point of view it is a SD card, but it is mechanically soldered onto the board. Such device have gained some popularity in ARM-based designs, but we'll likely see them in the x86 world, too.
I've tried to install Fedora 10 Alpha i386 on such a system, and it failed, since:
The distribution installation initrd needs to
1. include and auto-load the sdhc.ko and sdhci_pci.ko kernel modules
2. create the /dev/mmcblk* device nodes as per udev/hotplug events
The actual distribution installation program needs to
1. recognize /dev/mmcblk* as block devices that can be used as target device
2. use a grub-install or similar program that can discover the bios drive number to /dev/mmcblk* device name mapping
I have a patch for this in my local tree that I'll push post beta.
Not MODIFIED as the patch hasn't actually been pushed yet
I have tested the FC10.beta version, and found that it remain false.
I check the changlog about grub fount that the last modify is "* Wed Jun 25 2008 Peter Jones <firstname.lastname@example.org> - 0.97-34"
So are you sure that you have pushed your patch ?
Can you give me a account of svn or cvs ,and so on. I want to join in this tast.
I have a patch to grub on fc8, and it could be installed to SD card. The patch is about lib/device.c . But It is not fix this bug fully. It could not embedded staged1.5 to SD(although, it is not important). Of course ,the command grub-install is same.
I have tested other version grub on fc with new patch, and it is ok also.
I have the env about boot from SD.
If you not , I can tester for you .
This patch wasn't to grub, it was to anaconda for allowing the device as a selectable install method. What issues are you specifically seeing with the beta?
grub should handle it fine, as long as the BIOS can.
The SD device is found as /dev/sdX(X=a,b,c...) or /dev/mmcblkY(Y=0,1,2...) in Linux OS.
If it is /dev/sdX , everything is ok.
If it is /dev/mmcblkY, the grub could not be installed to SD(FC have this problem all). You can do following :
mount /dev/mmcblk0p1 /mnt/sd
echo "(hd0) /dev/mmcblk0" >/mnt/sd/boot/grub/device.map
grub --device-map=/mnt/sd/boot/grub/device.map <<EOF
You will found that install error.
What is the actual error given by grub?
grub> root (hd0,0)
Filesystem type is ext2fs, partition type 0x83
grub> setup (hd0)
Checking if "/boot/grub/stage1" exists... yes
Checking if "/boot/grub/stage2" exists... yes
Checking if "/boot/grub/e2fs_stage1_5" exists... yes
Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... failed (this is not fatal)
Running "embed /boot/grub/e2fs_stage1_5 (hd0,0)"... failed (this is not
Running "install /boot/grub/stage1 (hd0) /boot/grub/stage2 p
onf "... failed
Error 22: No such partition
you can modify lib/device.c
"sprintf (dev + strlen(dev), "%s%d",
/* Compaq smart and others */
(strncmp(dev, "/dev/ida/", 9) == 0 ||
strncmp(dev, "/dev/ataraid/", 13) == 0 ||
strncmp(dev, "/dev/mapper/", 12) == 0 ||
strncmp(dev, "/dev/cciss/", 11) == 0 ||
strncmp(dev, "/dev/rd/", 8) == 0) ? "p" : "",
((partition >> 16) & 0xFF) + 1);
add "strncmp(dev, "/dev/mmcblk", 11) == 0) ? "p" : ""," in it
Now ,it new grub could be installed to SD. But It is not fix this bug fully. It could not embedded staged1.5 to SD(although, it is not important). Of
course ,the command grub-install is same.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.
More information and reason for this action is here:
I think this is still valid for F11. I'm not sure if the grub side has been fixed but mkinitrd doesn't see the sdhci driver as a valid so in the case of the OLPC when booting it can't find the rootfs when using as SD card as the bootfs.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.
More information and reason for this action is here:
Is this now resolved in F-12?
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '11'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 11's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 11 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.