Thanks Darren, will follow up on this. Hi Paul, Please try out what Darren has suggested.
-Kishore. >-----Original Message----- >From: Darren Hart [mailto:dvh...@linux.intel.com] >Sent: Wednesday, April 03, 2013 8:39 AM >To: Paul D. DeRocco >Cc: yocto@yoctoproject.org; Bodke, Kishore K >Subject: Re: [yocto] This one can't be me... > >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