> From: Darren Hart > > The most obvious question is whether or not the kernel you built has > ramdisk support. You can do this by analyzing the .config file in your > linux-yocto build tree > (build/tmp/work/cedartrail.../linux-yocto*/linux-cedartrail-st > andard-build/.config). > You want to look for: > > $ grep BLK_DEV_RAM .config > CONFIG_BLK_DEV_RAM=y > CONFIG_BLK_DEV_RAM_COUNT=16 > CONFIG_BLK_DEV_RAM_SIZE=4096
That directory (full path is /home/pauld/yocto-atom/build/tmp/work/cedartrail_nopvr-poky-linux/linux-yoct o-3.0.32+git1+a4ac64fe873f08ef718e2849b88914725dc99c1c_1+1e79e03d115ed177882 ab53909a4f3555e434833-r4.1/linux-cedartrail-nopvr-standard-build) is completely empty. Yes, I know it's supposed to be a hidden file. This is right after completing a "successful" build of core-image-sato. > Well, see my comment above, the kernel was about as explicit as it can > be - it didn't find a block device to mount as root. However, when > debugging kernel issues, it is important to be able to record the log. > You have a serial port console configured in your kernel parameters > (console=ttyS0,115200), it would be a good idea to connect to > the serial > console and capture the boot messages to a file using minicom, screen, > or similar. Done. Attached. > Another common problem is the hddimg format itself and conflicts with > certain firmware. You can try the zip image format as described in > poky/README.hardware under the "Intel Atom based PCs and > devices" section. Tried that, same result. > Finally, usb sticks are terrible about just being bad. Many > of them are > literally write once devices. They're fine so long as you don't fill > them up, which works for shuffling small files around, but > writing full > OS images to them tends to kill them in a hurry. Try with a > brand new stick. Tried a fresh one, same results. I'm using a 1GB eUSB SSD, which is basically an industrial grade flash drive that uses SLC memory, on a card that sits on the mobo USB header. The image doesn't come close to filling it up. I've successfully done a live-image boot of full Ubuntu from the 2GB version of the same drive (same vendor). It smells to me like that first problem is the real one. Should I try a clean rebuild? Is there anything I can do short of nuking the entire build tree with its downloads to ensure a clean rebuild? Or would that be like waving a dead chicken over it? -- Ciao, Paul D. DeRocco Paul mailto:pdero...@ix.netcom.com