2138 2012-03-19 14:32:06 +0000 live image fails to boot if size exceeds 1 GB 2013-02-08 09:10:56 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core unspecified x86 Multiple VERIFIED FIXED Medium normal 1.4 M2 1 josh dvhart corneliux.stoicescu dexuan.cui dvhart jessica.zhang josh meta.mr.watcher meta.watcher przemyslawx.czesnowicz richard.purdie steve --- Regression (Used to work) --- oldest_to_newest 19219 0 josh 2012-03-19 14:32:06 +0000 19220 1 josh 2012-03-19 14:43:54 +0000 When building a live image (.hddimg), the generated image fails to boot if the image size exceeds 1GB. This is due to the limitation set in the syslinux. This can be verified easily by overriding the bootimg.bbclass and copy any large enough file (so as to exceed the 1GB) into ${HDDDIR} before doing the mkdosfs. The generated image can be dd'ed into a usb stick and be checked for its boot ability. This will fail with syslinux stating "No DEFAULT or UI configuration directive found". To fix this, either we have to patch syslinux or use some other bootloader. 19224 2 dvhart 2012-03-19 16:34:54 +0000 I'll copy my question to the mailing list here. Where are you getting this information? From what I can gather, syslinux 2.xx didn't support FAT32, which limited the maximum filesystem size purely due to limitations of FAT16. Syslinux 3.xx supports FAT32. We are building syslinux 4.xx in Yocto. I'm fairly certain I've built syslinux images larger than 1GB without an issue. Can you provide a failure case? 19225 3 dvhart 2012-03-19 16:35:09 +0000 . 19242 4 sgw 2012-03-20 00:32:10 +0000 I just build a live image for the Build appliance with a rootfs of 3G, so I am pretty sure this is working, I would need more details but as I have a working version I am going to lower the priority of this bug 19275 5 josh 2012-03-21 07:34:34 +0000 Darren, Do the following quick hack in order to reproduce the problem In bootimg.bbclass add the following line before calculating the BLOCKS in 'build_boot_bin' function dd if=/dev/zero of=${HDDDIR}/zero.img count=2097152 Then on the command line do the following $ bitbake core-image-minimal Then dd the image on to the USB disk $ dd if=tmp/deploy/images/core-image-minimal-<machine>.hddimg of=/dev/sdb $ sync Now try booting the machine via USB. You will get the following error message on the syslinux boot prompt "No DEFAULT or UI configuration directive found!" For further information we can see this thread (though the thread is from 2006 but it is still applicable) http://www.syslinux.org/archives/2006-October/007535.html 19276 6 josh 2012-03-21 08:15:47 +0000 If we try to boot the image by specifying the command options directly in the syslinux boot prompt like this > SYSLINUX 4.03 ... > No DEFAULT or UI configuration directive found! > boot: vmlinuz initrd=initrd then I get the kernel panic like this > Kernel panic - not syncing: Attempted to kill init! If I try to dd the image (hddimg) on to the compact flash card and boot it on my Intel Atom N270 eKino board (www.comp-mall.de/datenblatt/eKINO-ATOM.pdf) I get the "Boot error" message, as there are no boot flag marked partitions in it. So, the problem do exist. 19284 7 dvhart 2012-03-21 14:31:02 +0000 How much freespace do you have on the image after you have added the 2 MB zero file? Try mounting the image on your host machine and reporting the output of "df" here. 19327 8 josh 2012-03-22 06:14:52 +0000 Darren, The size of the zero.img is 1073741824 bytes. The size of core-image-minimal-<machine>.hddimg is 1099686912 bytes. The df output for the mounted core-image-minimal is Filesystem 1K-blocks Used Available Use% Mounted on /dev/loop0 1073760 1073536 224 100% /tmp/img 19328 9 josh 2012-03-22 06:58:54 +0000 The below link also suggests that the 1GB limit of syslinux is still in place even in FAT32 http://www.damnsmalllinux.org/f/topic-3-17-17659-0.html 19336 10 dvhart 2012-03-22 15:00:45 +0000 Try boosting the the BOOTIMG_EXTRA_SPACE count (units in 512b blocks) up to account for the dd you add and ensure you have 1MB or so of free space. Regarding the Boot Error, there are other reasons that can happen, including broken BIOSs. See the poky README.hardware and see the section on USB ZIP format (this is also documented in the syslinux documentation). 19340 11 dvhart 2012-03-22 15:14:31 +0000 Consider the following example of syslinux working on a larger than 1GB image: dvhart@envy:~/projects/bug2138 $ mkdosfs -n boot -S 512 -C boot.img $(expr 1099686912 / 512) mkdosfs 3.0.11 (24 Dec 2010) dvhart@envy:~/projects/bug2138 $ syslinux boot.img dvhart@envy:~/projects/bug2138 $ echo "serial 0" > syslinux.cfg dvhart@envy:~/projects/bug2138 $ mcopy -i boot.img -s syslinux.cfg ::/ dvhart@envy:~/projects/bug2138 dvhart@envy:~/projects/bug2138 $ ls -lah boot.img -rw-rw-r--. 1 dvhart dvhart 2.1G Mar 22 08:08 boot.img dvhart@envy:~/projects/bug2138 $ mkdir mnt dvhart@envy:~/projects/bug2138 $ sudo mount -o loop boot.img mnt dvhart@envy:~/projects/bug2138 $ df -h mnt Filesystem Size Used Avail Use% Mounted on /dev/loop0 2.1G 40K 2.1G 1% /home/dvhart/projects/bug2138/mnt $ qemu -nographic -hda boot.img Could not initialize KVM, will disable KVM support SYSLINUX 4.02 2010-07-21 Copyright (C) 1994-2010 H. Peter Anvin et al No DEFAULT or UI configuration directive found! boot: QEMU: Terminated Syslinux does work with larger than 1GB images. I suspect you are suffering from either a buggy BIOS (very common) or from a failed image creation due to lack of free space, although I would have expected an error during image creation for the latter. 19342 12 dvhart 2012-03-22 15:32:44 +0000 Another couple thoughts. If you mount the image, does syslinux.cfg exist? What are its contents? If this is missing, it accounts for the: No DEFAULT or UI configuration directive found! As for the kernel panic: Kernel panic - not syncing: Attempted to kill init! You booted it without a default append line (since there was no config found) and did not specify a rootfs, so this is what I would expect the kernel to do. boot: vmlinuz initrd=initrd Try adding a root=... parameter (whatever is appropriate for your image). 19343 13 josh 2012-03-22 17:26:11 +0000 (In reply to comment #11) > $ qemu -nographic -hda boot.img > Could not initialize KVM, will disable KVM support > > SYSLINUX 4.02 2010-07-21 Copyright (C) 1994-2010 H. Peter Anvin et al > No DEFAULT or UI configuration directive found! > boot: QEMU: Terminated As per the above line, I find that you too get the "No DEFAULT or UI configuration directive found!" error message in the syslinux boot prompt. > Syslinux does work with larger than 1GB images. I suspect you are suffering > from either a buggy BIOS (very common) or from a failed image creation due to > lack of free space, although I would have expected an error during image > creation for the latter. As per the bootimg.bbclass file, the hddimage size is calculated as BLOCKS=`du -bks ${HDDDIR} | cut -f 1` SIZE=`expr $BLOCKS + ${BOOTIMG_EXTRA_SPACE}` Here the BOOTIMG_EXTRA_SPACE is 512. So, the SIZE will always be the size of the entire HDDDIR folder + 512 If I reduce the zero.img file size so that the entire hddimg size is less than 1GB then I have no problem in booting that image. IMHO, I think there is a 1GB limitation with syslinux. 19344 14 josh 2012-03-22 17:32:09 +0000 (In reply to comment #12) > Another couple thoughts. If you mount the image, does syslinux.cfg exist? What > are its contents? If this is missing, it accounts for the: > > No DEFAULT or UI configuration directive found! > Yes. the syslinux.cfg file exists. It has the default contents # Automatically created by OE ALLOWOPTIONS 1 DEFAULT boot TIMEOUT 50 PROMPT 1 LABEL boot KERNEL vmlinuz APPEND initrd=initrd LABEL=boot usbcore.autosuspend=1 root=/dev/ram0 LABEL install KERNEL vmlinuz APPEND initrd=initrd LABEL=install usbcore.autosuspend=1 root=/dev/ram0 > As for the kernel panic: > > Kernel panic - not syncing: Attempted to kill init! > > You booted it without a default append line (since there was no config found) > and did not specify a rootfs, so this is what I would expect the kernel to do. > > boot: vmlinuz initrd=initrd > > Try adding a root=... parameter (whatever is appropriate for your image). I can't try this right now as I am away from the eKino board. Moreover its 23:00 hrs localtime (GMT+5:30) now. Will try this tomorrow and let you know. 19349 15 dvhart 2012-03-22 17:47:18 +0000 (In reply to comment #13) > (In reply to comment #11) > > $ qemu -nographic -hda boot.img > > Could not initialize KVM, will disable KVM support > > > > SYSLINUX 4.02 2010-07-21 Copyright (C) 1994-2010 H. Peter Anvin et al > > No DEFAULT or UI configuration directive found! > > boot: QEMU: Terminated > > As per the above line, I find that you too get the "No DEFAULT or UI > configuration directive found!" error message in the syslinux boot prompt. > In my case it is expected as I didn't provide a DEFAULT directive in the syslinux.cfg. > > Syslinux does work with larger than 1GB images. I suspect you are suffering > > from either a buggy BIOS (very common) or from a failed image creation due to > > lack of free space, although I would have expected an error during image > > creation for the latter. > > As per the bootimg.bbclass file, the hddimage size is calculated as > BLOCKS=`du -bks ${HDDDIR} | cut -f 1` > SIZE=`expr $BLOCKS + ${BOOTIMG_EXTRA_SPACE}` > > Here the BOOTIMG_EXTRA_SPACE is 512. So, the SIZE will always be the size of > the entire HDDDIR folder + 512 But it wasn't quite, per your df listing, perhaps due to some additional filesystem overhead we're not accounting for. 19353 16 dvhart 2012-03-22 18:36:53 +0000 I thought there might be something about the order files are placed on the filesystem, so I did a little experiment: dvhart@envy:~/projects/bug2138 $ ls -lah boot.img -rw-rw-r--. 1 dvhart dvhart 2.1G Mar 22 11:14 boot.img dvhart@envy:~/projects/bug2138 $ ls -lah mnt/ total 1.1G drwxr-xr-x. 2 root root 4.0K Mar 22 11:13 . drwxrwxr-x. 4 dvhart dvhart 4.0K Mar 22 11:05 .. -rwxr-xr-x. 1 root root 1.0G Mar 22 11:06 bigfile -rwxr-xr-x. 1 root root 5.4M Mar 22 11:13 initrd -r-xr-xr-x. 1 root root 32K Mar 22 09:05 ldlinux.sys -rwxr-xr-x. 1 root root 16M Mar 22 11:13 rootfs.img -rwxr-xr-x. 1 root root 286 Mar 22 11:02 syslinux.cfg -rwxr-xr-x. 1 root root 4.1M Mar 22 11:13 vmlinuz dvhart@envy:~/projects/bug2138 $ df -h mnt Filesystem Size Used Avail Use% Mounted on /dev/loop0 2.1G 1.1G 1.1G 51% /home/dvhart/projects/bug2138/mnt dvhart@envy:~/projects/bug2138 $ qemu -hda boot.img -nographic Could not initialize KVM, will disable KVM support SYSLINUX 4.02 2010-07-21 Copyright (C) 1994-2010 H. Peter Anvin et al boot: # Using your syslinux.cfg with an additional "serial 0" added. # Boot with: boot: boot console=ttyS0 Boots all the way to: ... Freeing unused kernel memory: 508k freed input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input2 udev[38]: starting version 164 Refined TSC clocksource calibration: 2659.999 MHz. Switching to clocksource tsc Waiting for removable media... (It won't get past here as I passed the image as hda, not a usb stick, so the udev trigger what fire). I then tested this on an Intel Atom E6xx development system and it booted all the way to the login prompt. This uses the crownbay BSP vmlinuz, rootfs.img, and initrd files from a core-image-minimal build. This is pretty conclusive evidence that syslinux.cfg does support > 1GB images. Whatever problem you are encountering appears to be either a configuration issue or a firmware bug. 19382 17 josh 2012-03-23 07:17:48 +0000 Darren, Thanks for your patience. As per your suggestion, I added some extra space for the hddimg in the bootimg.bbclass SIZE=`expr $BLOCKS + ${BOOTIMG_EXTRA_SPACE} + 983040` The size of core-image-minimal is now 2106318848 bytes and the df reports the following when it is loop mounted Filesystem 1K-blocks Used Available Use% Mounted on /dev/loop0 2056672 1073504 983168 53% /tmp/img I dd'ed this hddimg on to the USB stick and tried booting on the eKino board. Still I get the "No DEFAULT or UI configuration directive found!" error message. I even tried giving the root option as you suggested > SYSLINUX 4.03 ... > No DEFAULT or UI configuration directive found! > boot: vmlinuz initrd=initrd root=/dev/ram0 I still get the kernel panic > Kernel panic - not syncing: Attempted to kill init! I then tried booting the image in the qemu (to check whether it is a BIOS problem) $ qemu -hda core-image-minimal-ekino.hddimg I get the following error > Booting from Hard Disk... > Boot error So, how to debug this error further? 19383 18 josh 2012-03-23 07:35:06 +0000 One more update on this. In the syslinux boot prompt I included the LABEL option too like this > SYSLINUX 4.03 ... > No DEFAULT or UI configuration directive found! > boot: vmlinuz initrd=initrd root=/dev/ram0 LABEL=boot This booted all the way to the root prompt. There was no kernel panic error. But, we can't expect an user to type in all these values at boot prompt every time he/she wants to boot the image. This defeats the embedded application purpose. How to fix this problem? 19407 19 josh 2012-03-23 13:31:21 +0000 Darren, One more update: I followed your steps for creating a boot.img file $ mkdosfs -n boot -S 512 -C boot.img $(expr 1099686912 / 512) $ syslinux boot.img Then I loop mounted this boot.img and also loop mounted the core-image-minimal.hddimg and copied the files from core-image-minimal into the boot.img mounted location. Now boot.img contains the following files: total 1073404 -rwxr-xr-x 1 root root 7207777 Mar 23 17:57 initrd -r-xr-xr-x 1 root root 32256 Mar 23 2012 ldlinux.sys -rwxr-xr-x 1 root root 13508608 Mar 23 17:57 rootfs.img -rwxr-xr-x 1 root root 278 Mar 23 17:57 syslinux.cfg -rwxr-xr-x 1 root root 4666560 Mar 23 17:57 vmlinuz -rwxr-xr-x 1 root root 1073741824 Mar 23 17:58 zero.img I dd'ed this boot.img on to the USB stick and tried booting this on my eKino board. To my surprise there were no errors. I was able to get the login prompt. This concludes that 1. There is no issue with the free space in the created image 2. There is no issue with the BIOS But, still that core-image-minimal hddimg is not bootable via USB stick. I'll debug more on this and keep you posted. 19408 20 dvhart 2012-03-23 14:33:30 +0000 Joshua, aha, great, now we're getting somewhere. So the differences between the failing image and the good image are: o different version of mkdosfs (host vs. build env) There are some known issues with large images (over 4GB) with the 2.* version we have in poky for licensing reasons. Perhaps there are other limitations. o different version of syslinux (host vs. build env) o different order of writing files to the image (so they appear in the FAT differently) Which version of poky are you building from? My guess is mkdosfs is to blame. Saul, I know you were looking at bringing in a newer version of mkdosfs for testing, how is that coming? I think a good next step for Joshua would be try using that. Also, is there a way to force it to use the host dosfstools? Maybe clean them and drop the dosfstools dependency from the image he's building? 19418 21 josh 2012-03-23 15:24:03 +0000 (In reply to comment #20) > Joshua, aha, great, now we're getting somewhere. So the differences between the > failing image and the good image are: > > o different version of mkdosfs (host vs. build env) > There are some known issues with large images (over 4GB) with the 2.* version > we have in poky for licensing reasons. Perhaps there are other limitations. > o different version of syslinux (host vs. build env) > o different order of writing files to the image (so they appear in the FAT > differently) > > Which version of poky are you building from? I am using poky edison branch. My host mkdosfs version is 3.0.12 and my build version is 2.10 My host syslinux version is 4.05 and my build version is 4.03 I did one more change to the bootimg.bbclass like this mkdosfs -n ${BOOTIMG_VOLUME_ID} -S 512 \ -C ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hddimg $SIZE syslinux ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hddimg chmod 644 ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hddimg mcopy -i ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hddimg -s ${HDDDIR}/* ::/ Instead of specifying the -d ${HDDDIR} to mkdosfs I created an empty image and then tried to mcopy the files from the ${HDDDIR} on to the image. But the mcopy operation *never* completes. It takes infinite time. So the bitbake task do_bootimg never completes. I don't know whats the reason behind it. The build mkdosfs tool is patched in order to accept -d option to convert the contents of an directory into an image. Obviously the host mkdosfs lacks this. So, even if we use the host mkdosfs to generate the image it will not accept the directory (-d) option. Then we should be adding the files into the hddimg only by using mcopy. But I can't figure out why this mcopy is taking infinite time. May be some silly issue :( Help needed in debugging. 19421 22 dvhart 2012-03-23 15:58:13 +0000 The -d option to mkdosfs had a lot of issues and was quite poorly implemented. I have removed the -d patch from dosfstools and rewritten the bootimg code to use mcopy similarly to what you have done. However, there were a number of tweaks necessary to properly account for filesystem usage as well as ensure a format that mcopy didn't complain about (integral number of sectors per track iirc). It would be worth testing your build against the current poky master branch (we are nearing a release for 1.2, so things should be in pretty good shape). Is that something you can try? Failing that, we can try to backport the bootimg changes to edison, but I think that will be more work and it would be nice to verify things work on master before going through that. 19428 23 josh 2012-03-23 16:47:41 +0000 (In reply to comment #22) > The -d option to mkdosfs had a lot of issues and was quite poorly implemented. > I have removed the -d patch from dosfstools and rewritten the bootimg code to > use mcopy similarly to what you have done. However, there were a number of > tweaks necessary to properly account for filesystem usage as well as ensure a > format that mcopy didn't complain about (integral number of sectors per track > iirc). > > It would be worth testing your build against the current poky master branch (we > are nearing a release for 1.2, so things should be in pretty good shape). Is > that something you can try? Sure. Will try this tomorrow (as it is already 22:17 hrs localtime and moreover I don't have the eKino board at home) and let you know. > Failing that, we can try to backport the bootimg changes to edison, but I think > that will be more work and it would be nice to verify things work on master > before going through that. But, as the poky edison branch is supposed to be a stable branch I guess we should backport them here too if the issue is sorted out. 19431 24 dvhart 2012-03-23 16:57:44 +0000 Yes, a backport may be necessary, but I'd like to first confirm that it works. 19449 25 josh 2012-03-24 12:18:49 +0000 Darren, I did the following in the poky master 1. Added a line in bootimg.bbclass in build_hddimg function as follows (after populate ${HDDDIR}) dd if=/dev/zero of=${HDDDIR}/zero.img count=3145728 2. Built a core-image-minimal $ bitbake core-image-minimal The generated core-image-minimal size was 1655554048 bytes. Loop mounting this and running ls -l gave this output total 1591456 -rwxr-xr-x 1 root root 5682881 Mar 24 2012 initrd -r-xr-xr-x 1 root root 32768 Mar 24 2012 ldlinux.sys -rwxr-xr-x 1 root root 8439808 Mar 24 2012 rootfs.img -rwxr-xr-x 1 root root 284 Mar 24 2012 syslinux.cfg -rwxr-xr-x 1 root root 4785632 Mar 24 2012 vmlinuz -rwxr-xr-x 1 root root 1610612736 Mar 24 2012 zero.img 3. I dd'ed this image on to the USB stick $ dd if=core-image-minimal-atom-pc.hddimg of=/dev/sdb $ sync 4. Tried booting this stick in Intel Atom N270 eKINO board. Voila! Everything worked perfectly. There were no errors and I was able to get the login prompt. Earlier, when I tried booting the hddimg (generated from edison branch) in qemu I always used to get the "Boot error". But this image (generated from master branch) boots all the way to login prompt in qemu (via -hda option). I guess we have to backport this to edison branch. Darren, thanks for all the help. 19472 26 josh 2012-03-26 07:37:07 +0000 In order to be sure that the problem exists with poky edison's mkdosfs I did the following $ tmp/sysroots/i686-linux/usr/sbin/mkdosfs -n boot -S 512 -C boot.img $(expr 1099686912 / 512) This gave out the following error. > mkdosfs 2.10 (22 Sep 2003) > mkdosfs: seek failed I guess we have to use the newer version of mkdosfs. If 1.2 is released, will that be a new poky edison? 19960 27 dvhart 2012-04-05 17:58:39 +0000 Poky Edison will see at least one more point release, 1.1.2. We need to backport this fix to that. That's on me. 19971 28 dvhart 2012-04-05 21:36:20 +0000 Patches available on yocto list. Joshua I. would you consider testing? https://lists.yoctoproject.org/pipermail/yocto/2012-April/008077.html You can pull them from here: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dvhart/edison/bug/2138 20049 29 josh 2012-04-09 07:11:11 +0000 To test the new bootimg.bbclass I added the following line in the build_boot_bin function after the install command of ldlinux.sys on to the ${HDDDIR} > dd if=/dev/zero of=${HDDDIR}/zero.img count=3145728 Now my hddimg size of core-image-minimal is 1662124032 bytes. The contents of this loop mounted image is as follows total 1597760 -rwxr-xr-x 1 root root 7208314 Apr 9 2012 initrd -r-xr-xr-x 1 root root 32768 Apr 9 2012 ldlinux.sys -rwxr-xr-x 1 root root 13508608 Apr 9 2012 rootfs.img -rwxr-xr-x 1 root root 278 Apr 9 2012 syslinux.cfg -rwxr-xr-x 1 root root 4666560 Apr 9 2012 vmlinuz -rwxr-xr-x 1 root root 1610612736 Apr 9 2012 zero.img I tried booting this image via qemu $ qemu -hda tmp/deploy/images/core-image-minimal-ekino.hddimg It gave the following output. > Booting from Hard Disk... > Boot error Then I dd'ed this image on to the USB stick and tried booting this on my eKINO board. This booted all the way to the login prompt. There were no errors. 20068 30 dvhart 2012-04-09 16:11:46 +0000 Joshua, which MACHINE are you building for? If you build for qemux86 with the same dd line added to bootimg.bbclass, do you still see the boot failure for qemu? 20120 31 josh 2012-04-10 11:14:45 +0000 Darren, I was building the image for Intel Atom N270 eKINO SBC. Its config is similar to atom-pc.conf. The hddimg that I built from poky master branch for the MACHINE 'atom-pc' was booting in qemu without any issues. Moreover, qemux86.conf file doesn't declare the IMAGE_FSTYPES variable to include 'live' image for generation. For some weird reason, adding this variable to qemux86.conf doesn't generate 'live' image (hddimg). So, I am not able to check the hddimg for qemux86 MACHINE :( 20121 32 josh 2012-04-10 11:23:15 +0000 (In reply to comment #31) > Moreover, qemux86.conf file doesn't declare the IMAGE_FSTYPES variable to > include 'live' image for generation. For some weird reason, adding this > variable to qemux86.conf doesn't generate 'live' image (hddimg). So, I am not > able to check the hddimg for qemux86 MACHINE :( Sorry, IMAGE_FSTYPES is declared in 'conf/machine/include/qemu.inc' file. I'll test and update you on this shortly. 20122 33 josh 2012-04-10 11:55:46 +0000 Darren, I still get the same error when I try to boot the core-image-minimal hddimg for the MACHINE qemux86 $ qemu -hda tmp/deploy/images/core-image-minimal-qemux86.hddimg > Booting from Hard Disk... > Boot error 20165 34 dvhart 2012-04-11 05:14:27 +0000 The problem appears to be with mkdosfs. If I use my system mkdosfs (3.0.9), the image is bootable. If I use the one from sysroots (2.10), it is not (in qemu). The master has dosfstools 2.11, with the following relevant commits since edison: 995a09e dosfstools: Add patch to disable fat32 autoselection and behave as 2.10 0c45ecb dosfstools: update native to 2.11 6979190 dosfstools: add Upstream-Status to patches 9c92435 dosfstools: Add SRC_URI Checksum Others follow but they fix things like the -d option, which we've stopped using, so we don't need to pull that back into an edison point release in my opinion. With these 4 patches cherry-picked, the edison generated image boots in qemu. Joshua I, could you kindly test using my latest branch: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=dvhart/edison/bug/2138 Joshua L, I shall send another pull request for this branch once Joshua I confirms it works for him. 20175 35 josh 2012-04-11 12:31:17 +0000 Darren, I generated the core-image-minimal image for atom-pc MACHINE from your latest branch HEAD (with the 'dd' line included in bootimg.bbclass). This image boots all the way to the login prompt in the eKINO board. And in the qemu, it boots till this location and stays there forever. > VFS: Disk quotas dquot_6.5.2 > Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) > msgmni has been set to 233 > Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) > io scheduler noop registered > io scheduler deadline registered > io scheduler cfq registered (default) > input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0 > ACPI: Power Button [PWRF] > Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled > serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A But, the core-image-minimal-atom-pc image generated from poky master boots all the way to the login prompt in qemu. 20183 36 dvhart 2012-04-11 14:43:04 +0000 So the syslinux issue is taken care of. We should be able to address the boot issue independently. Note that it works for me. This looks like it might just be kernel parameter related. Try adding "console=tty0" to the syslinux boot prompt, eg: boot: boot console=tty0 Also, check that you are not changing the APPPEND variable from the default. Just to confirm. Are you booting with the qemu graphical console? The atom-pc build doesn't put a getty on a serial port. 20198 37 josh 2012-04-11 17:39:33 +0000 Darren, (In reply to comment #36) > So the syslinux issue is taken care of. Yes. > We should be able to address the boot > issue independently. Note that it works for me. This looks like it might just > be kernel parameter related. Try adding "console=tty0" to the syslinux boot > prompt, eg: > > boot: boot console=tty0 > I tried adding the console parameter as you mentioned above. The booting gets stuck at the same place as before. Then I tried adding the console as ttyS0, for this I get the following output. > Booting from Hard Disk... > SYSLINUX 4.03 ... > boot: boot console=ttyS0 > Loading vmlinuz....... > Loading initrd.........ready > Decompressing Linux... Parsing ELF... done. > Booting the kernel. It doesn't go beyond this. > Also, check that you are not changing the APPPEND variable from the default. > I didn't change the APPEND variable. > Just to confirm. Are you booting with the qemu graphical console? The atom-pc > build doesn't put a getty on a serial port. Yes I am using the graphical console. qemu -nographic option doesn't work for me. In order to check whether this was due to the init-live.sh (from initrdscripts recipe) I even tried porting that script from master branch. Still I couldn't get it booted till the login prompt. I invoke qemu like this $ qemu -hda tmp/deploy/images/core-image-minimal-atom-pc.hddimg I'll debug this further and let you know tomorrow. 20319 38 dvhart 2012-04-13 14:49:40 +0000 Josh, added you to CC as this is an edison bug with patches ready for merge. 20387 39 richard.purdie 2012-04-14 22:13:18 +0000 Patches merged into edison: http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=edison&id=4274ebdd009163bd199f6cb08df373fdfeb67178 20422 40 josh 2012-04-16 05:35:39 +0000 Darren, (In reply to comment #36) > So the syslinux issue is taken care of. We should be able to address the boot > issue independently. Note that it works for me. This looks like it might just > be kernel parameter related. In the comment #16 you have mentioned the following, > Waiting for removable media... > (It won't get past here as I passed the image as hda, not a usb stick, so the > udev trigger what fire). As per this comment, in qemu we won't get till the login prompt. Were you able to boot the core-image-minimal image till the login prompt (in qemu) using the hdd image generated from the latest? As I said earlier, the hddimg generated from master branch boots till the login prompt in qemu via -hda option. But the hddimg from edison branch stays at this point while booting in qemu > VFS: Disk quotas dquot_6.5.2 > Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) > msgmni has been set to 233 > Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) > io scheduler noop registered > io scheduler deadline registered > io scheduler cfq registered (default) > input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0 > ACPI: Power Button [PWRF] > Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled > serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A 20656 41 dvhart 2012-04-18 16:09:09 +0000 Sorry, not ignoring this, just swamped with some other things at the moment. It is on my list... 20657 42 dvhart 2012-04-18 16:11:04 +0000 But to answer your question, No, I did not get the live image from the latest of the edison branch to boot to the login prompt. Your testing of images built from master successfully boots live image to a login prompt in qemu? 20702 43 josh 2012-04-19 06:17:07 +0000 (In reply to comment #42) > But to answer your question, No, I did not get the live image from the latest > of the edison branch to boot to the login prompt. > > Your testing of images built from master successfully boots live image to a > login prompt in qemu? Yes. The core-image-minimal from master branch boots till the login prompt in qemu but not the one from the edison branch. When you have time please let me know the outcome so that I could debug further. Thank you. 21884 44 josh 2012-06-06 10:46:27 +0000 This bug still seems to exist under certain conditions. I'll post the detailed report of it and re-open the bug once I get back home (probably next week). 23118 45 josh 2012-07-16 12:46:24 +0000 Darren, Sorry for the late response. As I mentioned in my previous comment that the live image fails to boot under certain conditions. Here is the scenario In poky edison, in bootimg.bbclass under build_boot_bin function before calculation of SECTORS I added the following line > dd if=/dev/zero of=${HDDDIR}/zero.img count=3145728 then I dd'ed the core-image-minimal image on to the usb stick. This image booted all the way till login prompt. So, considering this case, this bug was closed. But, when I changed the 'zero.img' filename to 'abc.img' (in bootimg.bbclass) like this: > dd if=/dev/zero of=${HDDDIR}/abc.img count=3145728 The core-image-minimal image dd'ed on to the usb stick fails to boot. It gives out the following error (syslinux boot prompt doesn't show up) > Boot error The size of core-image-minimal generated was 1662124032 bytes But, both the images were bootable via qemu till login prompt > $ kvm -hda core-image-minimal-ekino.hddimg In order to debug further, I added the following lines in image_types.bbclass to make the rootfs.img size bigger. In 'runimagecmd' function before calculation of ROOTFS_SIZE these lines were added if [ "${IMAGE_BASENAME}" == "core-image-minimal" ] && [ "${type}" == "ext3" ] then mkdir -p ${IMAGE_ROOTFS}/opt dd if=/dev/zero of=${IMAGE_ROOTFS}/opt/zero.img count=3145728 fi This gave out the following error while building > | Size before prelinking 9972. > | Size after prelinking 10148. > | 3145728+0 records in > | 3145728+0 records out > | 1610612736 bytes (1.6 GB) copied, 21.5073 s, 74.9 MB/s > | genext2fs: not enough mem to read file 'zero.img' > | ERROR: Function 'do_rootfs' failed So, split the 'zero.img' into 10 separate files like this: if [ "${IMAGE_BASENAME}" == "core-image-minimal" ] && [ "${type}" == "ext3" ] then mkdir -p ${IMAGE_ROOTFS}/opt dd if=/dev/zero of=${IMAGE_ROOTFS}/opt/1.img count=314572 dd if=/dev/zero of=${IMAGE_ROOTFS}/opt/2.img count=314572 dd if=/dev/zero of=${IMAGE_ROOTFS}/opt/3.img count=314572 dd if=/dev/zero of=${IMAGE_ROOTFS}/opt/4.img count=314572 dd if=/dev/zero of=${IMAGE_ROOTFS}/opt/5.img count=314572 dd if=/dev/zero of=${IMAGE_ROOTFS}/opt/6.img count=314572 dd if=/dev/zero of=${IMAGE_ROOTFS}/opt/7.img count=314572 dd if=/dev/zero of=${IMAGE_ROOTFS}/opt/8.img count=314572 dd if=/dev/zero of=${IMAGE_ROOTFS}/opt/9.img count=314572 dd if=/dev/zero of=${IMAGE_ROOTFS}/opt/10.img count=314572 fi This gave out the following error while building | mkdosfs: seek failed | mkdosfs 2.11 (12 Mar 2005) | ERROR: Function 'build_boot_bin' failed I am re-opening this bug. 23137 46 dvhart 2012-07-17 00:34:33 +0000 I can't tell what you are reporting as the failure. Is it that it doesn't boot on the hardware? Is it that you see a failure while building? Is it the same bug that this bug was opened for initially? If not, please open a new bug. 23151 47 josh 2012-07-17 05:30:24 +0000 (In reply to comment #46) > I can't tell what you are reporting as the failure. Is it that it doesn't > boot on the hardware? Yes. It doesn't boot on the hardware when the name of the zero.img file changed to abc.img. > Is it that you see a failure while building? The whole purpose of adding the zero.img is to make the size of the final image go beyond 1GiB in a simpler way (rather than adding more packages on to the image). First, I added them in the hddimg (dos filesystem) by adding the 'dd' line in the bootimg.bbclass. Then I tried to increase the size of rootfs image to check that whether the same thing (boot failure) occurs. In order to increase the rootfs image size I tried adding the zero image in image_types.bbclass, thats when I encountered the build failure. (So, I reported them too) > Is it the same bug that this bug was opened for initially? If not, please open > new bug. Yes. It is the same bug. 25247 48 przemyslawx.czesnowicz 2012-09-14 11:10:47 +0000 This bug is still present in 1.3 beta. For example booting this image : http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-1.3-beta/machines/atom-pc/core-image-lsb-sdk-atom-pc-20120905071457.hddimg fails with "No DEFAULT or UI configuration directive found!" 25249 49 josh 2012-09-14 12:17:46 +0000 (In reply to comment #48) > This bug is still present in 1.3 beta. For example booting this image : > > http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-1.3-beta/ > machines/atom-pc/core-image-lsb-sdk-atom-pc-20120905071457.hddimg > > fails with > > "No DEFAULT or UI configuration directive found!" I reported this bug for edison branch. But, it exists even in denzil branch. 25385 50 dvhart 2012-09-19 03:11:24 +0000 (In reply to comment #48) > This bug is still present in 1.3 beta. For example booting this image : > > http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-1.3-beta/ > machines/atom-pc/core-image-lsb-sdk-atom-pc-20120905071457.hddimg > > fails with > > "No DEFAULT or UI configuration directive found!" What hardware did you attempt to build this on? I have yet to observer a failure that I can directly attribute to image size, so I'd like some clarity on this. 25386 51 dvhart 2012-09-19 03:12:06 +0000 > What hardware did you attempt to build this on? s/build/boot/ 25394 52 przemyslawx.czesnowicz 2012-09-19 09:46:11 +0000 I've tried to boot it on at least 4 hardware platforms a Mooncreek board, Valleyfalls board, SNB laptop, piketon board. It always fails in the same way. Every hddimg that is bigger than 1GB fails for me in the same way, smaller images are fine. Were You able to boot the image from the link? 26986 53 steve 2012-10-27 04:11:09 +0000 I am seeing a similar issue on FRI2 with builds from the danny branch. Smaller images work properly (i.e. core-image-minimal, core-image-rt, core-image-sato), larger images fail with "No DEFAULT or UI configuration directive found" (like core-image-rt-sdk, suspiciously 1.1GB in size) 26987 54 dvhart 2012-10-27 04:30:40 +0000 Next steps would be to try and duplicate the steps performed in bootimg.bbclass manually using the crrent versions of the tools installed on your host. The dosfstools we build are old and stale in order to avoid GPL V3 in later versions. It would be worth seeing if the current versions of the tools create images that work. Alternatively, you could just replace the dosfstools in the host sysroot with the ones from your host filesystem (I think that should work) and re-run the last step of creating the large images. 26989 55 steve 2012-10-27 14:19:54 +0000 > Alternatively, you could just replace the dosfstools in the host sysroot > with the ones from your host filesystem I did this experiment. The image build completed without error, and the image is the same size as that made with the original sysroot tools. The boot fails in a different manner now: Boot error Rather than: No DEFAULT or UI configuration directive found 28205 56 dvhart 2012-12-12 20:52:58 +0000 $ file core-image-lsb-sdk-atom-pc-20121010233936.hddimg core-image-lsb-sdk-atom-pc-20121010233936.hddimg: x86 boot sector, code offset 0x58, OEM-ID "SYSLINUX", sectors/cluster 128, root entries 512, Media descriptor 0xf8, sectors/FAT 138, heads 64, sectors 4502496 (volumes > 32 MB) , serial number 0x50761926, label: "boot ", FAT (16 bit) This indicates a FAT16 filessytem was created, despite the file being 2.2GB. FAT16 only supports sizes up to 2048MB. SYSLINUX is very strict on adhering to the FAT specification. This doesn't explain why it would fail over 1GB. Making progress, I suspect some fixes to the calculations in bootimg.bbclass are in order. 28207 57 dvhart 2012-12-12 22:39:38 +0000 Patch submitted to oe-core. 28356 58 przemyslawx.czesnowicz 2012-12-18 14:59:09 +0000 (In reply to comment #57) > Patch submitted to oe-core. I tested Your patch and booting still fails with hddimg grater than 1GB or 2GB. The error message is different : Boot error Rather than: No DEFAULT or UI configuration directive found On what machine were You able to boot Your 2GB image? 28359 59 przemyslawx.czesnowicz 2012-12-18 17:33:08 +0000 (In reply to comment #58) > (In reply to comment #57) > > Patch submitted to oe-core. > > I tested Your patch and booting still fails with hddimg grater than 1GB or > 2GB. > The error message is different : > Boot error > > Rather than: > > No DEFAULT or UI configuration directive found > > On what machine were You able to boot Your 2GB image? That was my error. The patch works fine. I can boot 2GB images. Sorry. 28507 60 dvhart 2013-01-02 22:19:36 +0000 That's a relief! Merged to master: commit 722430a488f39bf583e4a557a254fb84fae4d0a7 29666 61 corneliux.stoicescu 2013-02-08 09:10:56 +0000 Verified in 1.4_M3:3ae1a4ba972cfc17ff3f2fda632da8ecc3414885 with: core-image-lsb-sdk-jasperforest.hddimg 01-Feb-2013 04:55 2.3G