Bug 782238

If you can pinpoint the kernel module responsible for your internal card reader, we can include that kernel module in the initramfs.

(In reply to comment #1)
> If you can pinpoint the kernel module responsible for your internal card
> reader, we can include that kernel module in the initramfs.

Okay, I'll see what I can find.  I'd hoped to include that info with the bug report but alas the rd shell didn't have lsmod.  What's the easiest way to get that info?  (It seems I have to go dredging around initramfs only often enough that I forget most of the tricks.)

Created attachment 556034 [details]
lsmod output from F13 system which can boot from internal SD reader

Maybe something here will jump out at you as likely responsible AND missing in the initramfs produced currently under F16.

My best hunch is eeepc_laptop.  It appears that this module causes /sys/devices/platform/eeepc/cardr to exist, which sure sounds promising.  I should note that this attachment was indeed generated on a Asus Eee Box (model B202).  However, not all of the internal SD readers I'm testing against are B202s.  They are all nettop type of devices though.

My 2nd best guess would be usb_storage as I see that here, but not on a F16 spin that booted from CF.  I thought both the internal SD and CF readers are typically USB based so I'm not sure how a CF system could boot without this module, unless the BIOS is <sarcasm>"helping"</sarcasm> with some sort of floppy-disk emulation for legacy reasons.

Provided my testing procedure is correct, I'm not seeing any difference in the kernel modules that would explain this problem.

Booted an older F13-based spin from SD and added 'rdbreak' to the kernel command-line.  Once in the dracut shell I did 'cat /proc/modules' where it listed the following modules:

drm
drm_kms_helper
i2c_algo_bit
i2c_core
i915
output
squashfs
usb_storage
video

I then booted a newer F16-based spin from SD and added 'rd.break' to the kernel command-line.  Once in the dracut shell I did 'cat /proc/modules' where it listed the following modules:

drm
drm_kms_helper
i2c_algo_bit
i2c_core
i915
output
usb_storage

Upon noticing that squashfs wasn't listed, I was quite sure I'd discovered the problem as a sping created using livecd-tools places the whole rootfs into a squashfs image.  Reviewing dracut.kernel(7) I then appended 'rd.driver.pre=squashfs' and ' rd.driver.pre=output' (just for good measure although it looked irrelevant) and crossed my fingers.

This did affect the output of 'cat /proc/modules' in the expected way, but alas the system still cannot boot as it fails with:

dracut: Warning: No root device "live:/dev/disk/by-uuid/bla-bla-bla" found


I'd blame livecd-tools instead, but this same SD card boots perfectly fine on the same computer provided that I use an external SD card reader instead of the built in one.

FOUND IT !!!

If I tell python-imgcreate to include 'ums_realtek' (Universal Mass Storage?) as an extra driver to be included by dracut in the initramfs these systems will once again boot from their internal SD reader.  I've confirmed before/after results on the following hardware:

 * Asus EeeBox B202
 * Foxconn NT-535
 * Zotac ZBox HD-ID11

While Googling for clues, I also found countless complaints in the Fedora forums about similar problems encountered by people trying to first install F16 using SD cards.  Most wound up with a work-around of using an external reader, much as I was doing to prove to myself there was nothing wrong with my SD images.  I suspect this missing driver is at the core of most all those complaints.

I should note that while investigating this, I noticed that Fedora 16 first shipped with another driver named 'uas' (USB Attached SCSI) but that one disappeared with one of the kernel updates and 'ums_realtek' later appeared.  I suspect the latter replaces the former, but can't say for certain.

So ... can we please get this driver included with dracut images by default?  Ideally we could also get an updated dracut for F16 -- it won't help installing the mainstream F16 images, but it would resolve problems for custom spins such as those made by livecd-tools.

It's in dracut in F17/rawhide

Thanks Harald.

I know it's almost pointless, but would it be too much to ask for an update to F16 as well?  It certainly wouldn't fix the F16 Release proper, but for those of us who make custom spins on a daily basis, it would be welcomed.  I know my employer would much prefer that our deployed custom spins be something that can be made out of the box without requiring temporary patches.

(In reply to comment #7)
> Thanks Harald.
> 
> I know it's almost pointless, but would it be too much to ask for an update to
> F16 as well?  It certainly wouldn't fix the F16 Release proper, but for those
> of us who make custom spins on a daily basis, it would be welcomed.  I know my
> employer would much prefer that our deployed custom spins be something that can
> be made out of the box without requiring temporary patches.

you could probably modify the kickstart for the livecd creation and add:

device ums_realtek

(In reply to comment #8)

> you could probably modify the kickstart for the livecd creation and add:
> 
> device ums_realtek

Clever!  I wasn't aware of that KS option.  I'll give it a try as soon as time permits.  Thanks so much for the pointer.

hi guys, I had this same error on a CentOS 6.2 copy I made on an SD card.

Upon further inspection I found that the SD card was being detected fine but the UUID was not being found due to it being case sensitive. The UUID in the /dev/disk/by-uuid folder was in lowercase, though the UUID in the syslinux/extlinux config was in uppercase. disktype & blkid also present UUID's in uppercase.

I hope that helps someone, though RFC4122 says UUID's should be in lower case. There could be a few places that need editing to enforce lower case UUIDs.