Hi Paul, First off, please CC the relevant maintainers of the recipes and BSPs you are having trouble with. The README in the cedartrail BSP lists Kishore as the maintainer, now on CC. This will help improve response time to your post as well as getting the right people looking at it.
Kishore, can you please work with Paul to get him booting? Some ideas on things to check/try inline below. On 04/02/2013 02:27 PM, Paul D. DeRocco wrote: > I've successfully built core-image-base-cedartrail-nopvr, with NO > modifications, no meta-oe layer to pull in Samba, no attempt to partition > the flash drive, just the .hddimg file dd'ed to /dev/sdb, to see if I can > get something, anything to boot out of the box. > > I get a kernel panic when it tries to boot on my Intel DN2800MT mobo, with > 1GB of RAM. The error messages, which appear on the attached VGA monitor, > are: > > VFS: Cannot open root device "ram0" or unknown-block(0,0) > Please append a correct "root=" boot option; > here are the available partitions: > VFS: Unable to mount root fs on unknown-block(0,0) > User configuration error - no valid root filesystem found Believe it or not, this is the single most common boot error in the history of boot errors on Linux :-) It is telling you there is no block device called "ram0" to load and there are no other block devices detected. The USB stick doesn't show up here because USB can take a while to enumerate and unless you tell the kernel to wait for it, it doesn't. That shouldn't be your problem here as you are attempting to boot from a ramdisk. 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-standard-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 > > Here is the syslinux.cfg file that is controlling the boot: > > # Automatically created by OE > serial 0 115200 > ALLOWOPTIONS 1 > DEFAULT boot > TIMEOUT 10 > PROMPT 1 > LABEL boot > KERNEL /vmlinuz > APPEND initrd=/initrd LABEL=boot root=/dev/ram0 console=ttyS0,115200 > console=tty0 video=vesafb vga=0x318 > LABEL install > KERNEL /vmlinuz > APPEND initrd=/initrd LABEL=install root=/dev/ram0 console=ttyS0,115200 > console=tty0 video=vesafb vga=0x318 > > This is a live-image boot, and the flash drive contains the usual five > files. As far as I can tell, a live-image boot is a two-stage boot beginning > with a really stripped down vmlinuz and a small RAM-disk read from initrd, > which then reads the big rootfs.img into another RAM-disk and tries to boot > the real kernel from that. I don't know which kernel is panicking, because > it all flies by so fast. 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. > Any ideas, or am I cursed? > 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. 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. Thanks, -- Darren Hart Intel Open Source Technology Center Yocto Project - Technical Lead - Linux Kernel _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
