Bug 2138

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.

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?

.

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

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

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.

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.

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

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

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).

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.

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).

(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.

(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.

(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.

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.

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?

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?

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.

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?

(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.

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.

(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.

Yes, a backport may be necessary, but I'd like to first confirm that it works.

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.

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?

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.

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

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.

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?

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 :(

(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.

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

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.

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.

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.

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.

Josh, added you to CC as this is an edison bug with patches ready for merge.

Patches merged into edison: http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=edison&id=4274ebdd009163bd199f6cb08df373fdfeb67178

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

Sorry, not ignoring this, just swamped with some other things at the moment. It is on my list...

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?

(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.

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).

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.

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.

(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.

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!"

(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.

(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.

> What hardware did you attempt to build this on?

s/build/boot/

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?

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)

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.

> 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

$ 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.

Patch submitted to oe-core.

(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?

(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.

That's a relief!

Merged to master:
commit 722430a488f39bf583e4a557a254fb84fae4d0a7

Verified in 1.4_M3:3ae1a4ba972cfc17ff3f2fda632da8ecc3414885

with:

core-image-lsb-sdk-jasperforest.hddimg   01-Feb-2013 04:55  2.3G