Hide Forgot
Description of problem: I've transferred a custom F16 Live spin to both CF and SD memory cards. While I can boot the CF images without problems, I cannot boot the SD images using the built-in SD card slot (on several different hardware models). The SD images will boot fine however, if a an external, USB attached SD card reader is employed. These same hardware models have been successfully booting similar images that had been based on F13. Version-Release number of selected component (if applicable): dracut-013-20.fc16.noarch How reproducible: always Steps to Reproduce: 1. Transfer a Live F16 image to an SD card, using livecd-tools' livecd-iso-to-disk. 2. Attempt to boot from the SD card using a built-in SD reader device. Observe failure that terminates with: dracut: Warning: No root device "live:/dev/disk/by-uuid/UUID" found 3. Attempt to boot using same SD card, but now with an external SD card reader attached via USB. Additional info: It seems that the dracut rd image is missing support for built-in SD reader support. If I boot the device using the external USB reader and then insert/remove another imaged SD card at the built-in reader, I'll see kernel messages to the effect that a new device has been discovered/removed respectively. However, if I try to boot from the built-in reader, which drops me to an rd shell and then repeat the insert/remove process (with the built-in reader's SD card), I see no such kernel messages. Further, in the failed mode, I see no /dev/disk, neither the directory nor anything below it (of course). These custom spins are freshly produced on a fully updated F16 system. I do not see any problems with the same images transferred to CompactFlash cards using either built-in or external readers.
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.