Bug 686

For the BSPs that are in the linux-yocto[-stable] kernels, they represent
a set of tuned configurations. If the options are simple, and they make
sense (as this one probably does) we can add the configuration to the base
BSP. We just have to be wary of adding too many options and creating
kitchen sink BSPs. If the options are too heavy to be in the base BSP, the
solution is equally as simple. We create a 'live boot' kernel configuration
fragment and enable it from the recipes, just like the netfilter options are
enabled.

Reassigning to Bruce, not sure what kernel options are missing to mount ISO rootfs but we probably should have a configuration category for them and include them for the qemu machines.

Confirmed. I'll take this one.

This may have to bump to a point release, I haven't had any cycles to
get in and look at this.

# CONFIG_ISO9660_FS is not set

Guessing that might have something to do with it. That's from the live image for the n450.

We have working USB media installs. Who uses live CDs now? I propose
should be a 1.1 Medium - RP

I'd second this opinion. This is almost definitely a configuration
issue that should be an easy fix, and fixable by a end user
(since we do expect them to reconfigure the kernel). - Bruce

Downgrade to medium based on the above 2 comments

This raises the question of being able to define a kernel feature dependency. We know we need cdrom support, either IDE or SCSI, ISO9660 FS support, maybe squashfs (I'm not sure). Should we consider the livecd to be different from a liveusb?

I've added CONFIG_ISO9660 and the JOILET config options, but live ISO still fails to boot in qemux86. It hangs at:

Waiting for removable media...

Which is displayed from init-live.sh:

echo "Waiting for removable media..."
while true
do
  for i in `ls /media 2>/dev/null`; do
      if [ -f /media/$i/$ROOT_IMAGE ] ; then
          found="yes"
          break
      fi
  done
  if [ "$found" = "yes" ]; then
      break;
  fi
  sleep 1
done

So we appear to be waiting for udevadm to trigger an add action or something like that, but that doesn't appear to be happening with the -cdrom=blah.iso. Haven't been able to test on real hardware.

Did this used to work with init-live.sh? I've never booted a live CD image from this project.

MACHINE=qumu-x86
IMAGE_FSTYPES += " cpio.gz live" (local.conf)
bitbake core-image-minimal

Run:
qemu -m 512 --cdrom core-image-minimal-qemux86-20110812081052.iso
Result:
Hang up at
Waiting for removable media ...

1) "ROOT_IMAGE" in init-live.sh is a wrong path, should be changed into "isolinux/rootfs.img"

http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=jingdonglu/bug686

2) For kernel configuration, we should add the following options into "boot-live.cfg"
CONFIG_BLK_DEV_IDECD=y

Because qemu regard the cdrom as IDE device, we should add CONFIG_BLK_DEV_IDECD=y and it can booted successfully for qemu-x86.

http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=jingdonglu/bug686-v2

I'll grab the kernel part of this and do some testing.

fixed by commit 4f4475f4989c0a3c2dc7ea8d1e9fba3986a37c84

(In reply to comment #12)
> fixed by commit 4f4475f4989c0a3c2dc7ea8d1e9fba3986a37c84

I just rebuilt core-image-sato with

OE Build Configuration:
BB_VERSION        = "1.13.3"
TARGET_ARCH       = "i586"
TARGET_OS         = "linux"
MACHINE           = "atom-pc"
DISTRO            = "poky"
DISTRO_VERSION    = "1.0+snapshot-20110825"
TUNE_FEATURES     = "m32 core2"
TARGET_FPU        = ""
meta              
meta-yocto        = "master:9ca6806de9d9df9d901774c1b23a14f28f10a844"

Sadly, it doesn't work when I run it using VirtualBox
In the attached screen dump, you'll see that I modified init-live.sh
to display the file systems that are being queried.

It looks like it's failing because it can't mount the CD?

How did you test this?

Created attachment 212 [details]
Screenshot of boot failure

What is odd here is that features (240) sounds like ext4 yet we don't build ext4 filesystems, I only merged the commit for that in the last few hours?

It does indeed sound like ext4. The fixes for this case initially targeted qemu, since
there wasn't an atom-pc target available for hardware testing. But that testing would
use ext3 based filesystems.

Gary: can you check if you are using ext4 ?  or something else besides the fs that the
live scripts are looking for (but I'm no live boot expert .. so I'm only guessing).

The failure happened when mounting cdrom. If we use SCSI cdrom in virtualbox, we should add "CONFIG_BLK_DEV_SR=y" for kernel to support SCSI cdrom. If we use IDE cdrom, we should add "CONFIG_BLK_DEV_IDECD=y" for kernel to support IDE cdrom. "CONFIG_ISO9660_FS=y" is also needed by them.

I test it on qemu using IDE cdrom and it works well.

So I think we should add the above items for kernel in "meta/cfg/kernel-cache/bsp/atom-pc/boot-live.cfg" and add "boot-live.cfg" into relevant .scc file for bsp and qemu which have "boot live" feature.

I will commit a patch for this if necessary.

Thanks Jingdong: assuming that CONFIG_BLK_DEV_SR=y can co-exist with the other options in the live boot config fragment, we can definitely add it.

I'd like to hear if it boots on Gary's test as well.

Gary: can you create a <foo>.cfg file, put CONFIG_BLK_DEV_SR=y in it and add it to your SRC_URI and see if your boot works now ?

(In reply to comment #18)
> Thanks Jingdong: assuming that CONFIG_BLK_DEV_SR=y can co-exist with the other
> options in the live boot config fragment, we can definitely add it.
> 
> I'd like to hear if it boots on Gary's test as well.
> 
> Gary: can you create a <foo>.cfg file, put CONFIG_BLK_DEV_SR=y in it and add it
> to your SRC_URI and see if your boot works now ?

If I set both of those options, this image will boot.

However, it's sure not happy with a gazillion messages rolling by about read-only file systems.  I think because of this, it does not start X, only a console.

Sadly, at the moment, I can't test this on my atom hardware (it's refusing to boot from CD) and every other machine I've tried other than VirtualBox is also a hopeless failure.

How did you test qemu booting from the iso image?

I test livecd using qemu:

qemu -m 512 --cdrom core-image-minimal-qemux86.iso

It can work well.

(In reply to comment #20)
> I test livecd using qemu:
> 
> qemu -m 512 --cdrom core-image-minimal-qemux86.iso
> 
> It can work well.

How did you build such an image for qemux86?  I tried this:

diff --git a/meta/conf/machine/include/qemu.inc b/meta/conf/machine/include/qemu.inc
index 9ef242f..6108624 100644
--- a/meta/conf/machine/include/qemu.inc
+++ b/meta/conf/machine/include/qemu.inc
@@ -3,7 +3,7 @@ PREFERRED_PROVIDER_virtual/xserver ?= "xserver-kdrive"
 
 MACHINE_FEATURES = "kernel26 apm alsa pcmcia bluetooth irda usbgadget screen"
 
-IMAGE_FSTYPES ?= "tar.bz2 ext3"
+IMAGE_FSTYPES ?= "tar.bz2 ext3 live"
 
 ROOT_FLASH_SIZE = "280"
 
with no effect - I still only get 'core-image-sato-qemux86.ext3' and
'core-image-sato-qemux86.hddimg'

Also, how can I run this image using 'runqemu'?

Add this in local.conf
IMAGE_FSTYPES += " cpio.gz live" 
and we can get the iso image and hdd image.

I test hdd.img on emenlow using usb disk and it works well. I also test iso image using qemu and it can boot from iso image.

Because we haven't x86 hardware, we can't test on them. If possible we can try to test it on x86-64(sugarbay). But it failed when compiling x86-64 image using latest version.

(In reply to comment #22)
> Add this in local.conf
> IMAGE_FSTYPES += " cpio.gz live" 
> and we can get the iso image and hdd image.
> 
> I test hdd.img on emenlow using usb disk and it works well. I also test iso
> image using qemu and it can boot from iso image.
> 
> Because we haven't x86 hardware, we can't test on them. If possible we can try
> to test it on x86-64(sugarbay). But it failed when compiling x86-64 image using
> latest version.

Interesting note - adding "live" by itself to the FSTYPES does nothing, you have to add "cpio.gz" to get an ISO image.  Perhaps this should be a bug by itself.

That said, I was now able to build an ISO image for qemux86.  When I ran it using the command:
  % tmp/sysroots/i686-linux/usr/bin/qemu -m 512 --cdrom tmp/deploy/images/core-image-sato-qemux8iso 
it fails to come up - it does boot, but does not fully come up, hanging waiting for the root file system to be mounted.  This same image does at least mount on atom-pc.
I'll attach a screen dump of what happened.

When you say that it "ran well", what does that mean?  Does it boot all the way to X running on the device?  Also, how can I run this using the 'runqemu' script?

Created attachment 227 [details]
Screenshot - boot hangs

Boot still hangs when created live image for qemu

(In reply to comment #24)
> Created attachment 227 [details]
> Screenshot - boot hangs
> 
> Boot still hangs when created live image for qemu

Did you add CONFIG_BLK_DEV_IDECD=y into "boot-live.cfg" for kernel and add boot-live.cfg into qemu-ppc32.scc?

(In reply to comment #25)
> (In reply to comment #24)
> > Created attachment 227 [details] [details]
> > Screenshot - boot hangs
> > 
> > Boot still hangs when created live image for qemu
> 
> Did you add CONFIG_BLK_DEV_IDECD=y into "boot-live.cfg" for kernel and add
> boot-live.cfg into qemu-ppc32.scc?

I've no idea how or what you are asking for.  I can't find such files in my tree:
[gthomas@titan pc_poky_full]$ find /local/poky-master -name "qemu*scc"
   ... nothing
[gthomas@titan pc_poky_full]$ find /local/poky-master -name "boot*"
/local/poky-master/scripts/qemuimage-tests/sanity/boot
/local/poky-master/scripts/jhbuild/modulesets/bootstrap.modules
/local/poky-master/meta/recipes-core/sysvinit/sysvinit/bootlogd.init
/local/poky-master/meta/recipes-core/initscripts/initscripts-1.0/bootmisc.sh
/local/poky-master/meta/classes/bootimg.bbclass
/local/poky-master/meta/classes/boot-directdisk.bbclass

The whole point of this bug is that purportedly one can build and boot from an ISO image (from the documentation), but I have been 100% unable to do so.  Also, it's not much good if abnormal operations (like add some option to some obscure config file) have to be done by the user, even if it does work.

There's just a minor workflow/terminology mismatch here.

Jingdong is really just trying to find out if those options are in your final .config that
you've been trying to boot.

Getting them into the config can be done via a config fragment on the SRC_URI, menuconfig or by modifying the in tree configs (what he has suggested). You can pick the poison, but as a first step, if we get an updated .config from your build, we can see what options actually made it into the build.

Verified - CONFIG_BLK_DEV_IDECD=y is set (by default I believe as I did not run menuconfig or any other such step)

Perhaps you could provide the ISO image (and kernel config) that you used to test this on QEMUx86 so I can compare?

Thanks Gary.

Jingdong, is there a way you can make what you've been booting available ?

Created attachment 230 [details]
kernel configure file for qemux86

(In reply to comment #28)
> Verified - CONFIG_BLK_DEV_IDECD=y is set (by default I believe as I did not run
> menuconfig or any other such step)
> 
> Perhaps you could provide the ISO image (and kernel config) that you used to
> test this on QEMUx86 so I can compare?

I post .config of QEMUx86 kernel and I hope it can help you. I think the following options should be configured for kernel to boot from liveCD.
CONFIG_ISO9660_FS=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_LOOP=y

(In reply to comment #31)
> (In reply to comment #28)
> > Verified - CONFIG_BLK_DEV_IDECD=y is set (by default I believe as I did not run
> > menuconfig or any other such step)
> > 
> > Perhaps you could provide the ISO image (and kernel config) that you used to
> > test this on QEMUx86 so I can compare?
> 
> I post .config of QEMUx86 kernel and I hope it can help you. I think the
> following options should be configured for kernel to boot from liveCD.
> CONFIG_ISO9660_FS=y
> CONFIG_BLK_DEV_IDECD=y
> CONFIG_BLK_DEV_LOOP=y

I don't see how we can make any progress on this if you and I aren't using the same sources.  Comparing the kernel config you sent with what I get, I can see that you are still using kernel 2.6.37.6 whereas master has moved on to 3.0.4

Also, there are a lot more things that need to be set other than the list above.  I'll attach my config file for comparison.

Finally, even with all these changes, it still does not come up :-(  It hangs late in the boot process, but is not functional (screenshot attachment)

Created attachment 231 [details]
Boot from CD still hangs, late in boot

Created attachment 232 [details]
Kernel config file

I'd still like access to the ISO image that works for you (Jingdong) and the _exact_ command line you use to run it.  Thanks

Sorry Gary, I used older kernel and minimal image to test it. In order to test new kernel and X, I compiled a new iso image with the new version.

1. Compile iso image
(1) Branch: master
    Commit: bb4a5c44da23a1bb363f1f081cf1644fd7975957
(2) also need to add IMAGE_FSTYPES += " cpio.gz live" into local.conf
(3) bitbake core-image-sato
(4) generate iso image: core-image-sato-qemux86-20110916014455.iso
(5) run: qemu -m 512 --cdrom core-image-sato-qemux86-20110916014455.iso
    result: Hang at
            "Waiting for removable media..."

2. Modify the kernel configuration and re-compile iso image
(1) The difference between the two configure files.
--- .config 2011-09-16 16:28:04.655327083 +0800
+++ /tmp/.config    2011-09-16 16:25:06.615325761 +0800
@@ -919,8 +919,8 @@
 # CONFIG_BLK_DEV_DAC960 is not set
 # CONFIG_BLK_DEV_UMEM is not set
 # CONFIG_BLK_DEV_COW_COMMON is not set
-CONFIG_BLK_DEV_LOOP=m
-CONFIG_BLK_DEV_CRYPTOLOOP=m
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_CRYPTOLOOP=y
 # CONFIG_BLK_DEV_DRBD is not set
 CONFIG_BLK_DEV_NBD=m
 # CONFIG_BLK_DEV_SX8 is not set
@@ -2521,7 +2521,9 @@
 #
 # CD-ROM/DVD Filesystems
 #
-# CONFIG_ISO9660_FS is not set
+CONFIG_ISO9660_FS=y
+# CONFIG_JOLIET is not set
+# CONFIG_ZISOFS is not set
 # CONFIG_UDF_FS is not set

(2) Re-compile kernel and iso image
(3) run: qemu -m 512 --cdrom core-image-sato-qemux86-20110916072717.iso
    result: Hang at the yocto interface, enter the text console, I find it hang because the following commands.
mv: overwrite '/etc/nsswitch.conf'?

If we press "enter" or 'n','y', many messages display on the screen and it will be loaded on text mode. We can login in on text mode.

I think some scripts which run on booting-up time cause hang up and failure to start X. I also posted some screenshots to help to fix this bug.

Created attachment 234 [details]
qemu booted from livecd using master branch iso image

Using master branch to compile kernel and iso image, qemu will hang at this point.

Created attachment 235 [details]
qemu booted from livecd using modified kernel configuration

Modified kernel configuration according to the above patch and re-compiled kernel and iso image. Qemu can be booted from livecd, but hang at the yocto interface.

Created attachment 236 [details]
enter text mode to find which point it hangs

Enter text-mode when qemu hang at yocto interface and try to find why it hang.

Created attachment 237 [details]
Press "enter" and qemu can login on text mode

Press "enter" when qemu hang at yocto interface and we can get the login interface on text mode.

So I think the bug should be divided into two parts.
1. Qemu can't be booted using livecd
   Fix:
  (1) Modify the init-live.sh to fix the correct directory of rootfs.img
      Branch: master
      commit: 4f4475f4989c0a3c2dc7ea8d1e9fba3986a37c84
  (2) For kernel configuration, we should add the related items.
      CONFIG_BLK_DEV_LOOP=y
      CONFIG_ISO9660_FS=y
      They are already exited in "boot-live.cfg".

2. Qemu can't start X using livecd
   I think we should change some init scripts for livecd(read-only system). If necessary, we should open a new bug to trace this failure.

(In reply to comment #41)
> So I think the bug should be divided into two parts.
> 1. Qemu can't be booted using livecd
>    Fix:
>   (1) Modify the init-live.sh to fix the correct directory of rootfs.img
>       Branch: master
>       commit: 4f4475f4989c0a3c2dc7ea8d1e9fba3986a37c84
>   (2) For kernel configuration, we should add the related items.
>       CONFIG_BLK_DEV_LOOP=y
>       CONFIG_ISO9660_FS=y
>       They are already exited in "boot-live.cfg".
> 
> 2. Qemu can't start X using livecd
>    I think we should change some init scripts for livecd(read-only system). If
> necessary, we should open a new bug to trace this failure.

Agreed. Nice analysis. In the future, consider using the "-serial stdio" options to qemu to get the kernel output to your console so you can just copy the text rather than having to resort to screenshots.

(In reply to comment #42)
> (In reply to comment #41)
> > So I think the bug should be divided into two parts.
> > 1. Qemu can't be booted using livecd
> >    Fix:
> >   (1) Modify the init-live.sh to fix the correct directory of rootfs.img
> >       Branch: master
> >       commit: 4f4475f4989c0a3c2dc7ea8d1e9fba3986a37c84
> >   (2) For kernel configuration, we should add the related items.
> >       CONFIG_BLK_DEV_LOOP=y
> >       CONFIG_ISO9660_FS=y
> >       They are already exited in "boot-live.cfg".
> > 
> > 2. Qemu can't start X using livecd
> >    I think we should change some init scripts for livecd(read-only system). If
> > necessary, we should open a new bug to trace this failure.
> 
> Agreed. Nice analysis. In the future, consider using the "-serial stdio"
> options to qemu to get the kernel output to your console so you can just copy
> the text rather than having to resort to screenshots.

How can one pass such options to the runqemu script (my attempts to follow the scant help have been fruitless)?

Is there a way to boot the ISO image using runqemu? (same question, posed differently :-)

Does anyone have a suggestion for Gary ? I always just modify the scripts to suit my needs, so I'm not a lot of help here.

I just don't want the question to be lost, since I'm going to create a new bug for the X based issues, and mark this one as resolved.

marking this as resolved from the point of view of live booting. Another bug will track the X startup issues.

(In reply to comment #45)
> marking this as resolved from the point of view of live booting. Another bug
> will track the X startup issues.

Should this really be marked as resolved/closed before the actual changes make into the master tree?

The two parts that this bug continues to cover are already in master.

   (1) Modify the init-live.sh to fix the correct directory of rootfs.img
       Branch: master
       commit: 4f4475f4989c0a3c2dc7ea8d1e9fba3986a37c84
   (2) For kernel configuration, we should add the related items.
       CONFIG_BLK_DEV_LOOP=y
       CONFIG_ISO9660_FS=y
       They are already exited in "boot-live.cfg".

(In reply to comment #47)
> The two parts that this bug continues to cover are already in master.
> 
>    (1) Modify the init-live.sh to fix the correct directory of rootfs.img
>        Branch: master
>        commit: 4f4475f4989c0a3c2dc7ea8d1e9fba3986a37c84
>    (2) For kernel configuration, we should add the related items.
>        CONFIG_BLK_DEV_LOOP=y
>        CONFIG_ISO9660_FS=y
>        They are already exited in "boot-live.cfg".

But that seems to only be for atom-pc, not qemux86

[gthomas@titan pc_poky_full]$ find tmp/work/qemux86-poky-linux/linux-yocto-3.0.4+git3+12574e5a77597f6938315ef82d18fc5e229fb79c_2+72671808fdbe69a9fe03fd8f094e7c59da04a28c-r2/ -name "boot*.cfg"
tmp/work/qemux86-poky-linux/linux-yocto-3.0.4+git3+12574e5a77597f6938315ef82d18fc5e229fb79c_2+72671808fdbe69a9fe03fd8f094e7c59da04a28c-r2/sysroot-destdir/kernel/meta/cfg/kernel-cache/bsp/atom-pc/boot-live.cfg
tmp/work/qemux86-poky-linux/linux-yocto-3.0.4+git3+12574e5a77597f6938315ef82d18fc5e229fb79c_2+72671808fdbe69a9fe03fd8f094e7c59da04a28c-r2/image/kernel/meta/cfg/kernel-cache/bsp/atom-pc/boot-live.cfg
tmp/work/qemux86-poky-linux/linux-yocto-3.0.4+git3+12574e5a77597f6938315ef82d18fc5e229fb79c_2+72671808fdbe69a9fe03fd8f094e7c59da04a28c-r2/linux/meta/cfg/kernel-cache/bsp/atom-pc/boot-live.cfg

So, out of the box (from master ce2b383d045db5bbdbccdce2d9d1eae8b0d061a1), the configuration is still wrong:

[gthomas@titan pc_poky_full]$ grep CONFIG_BLK_DEV_LOOP tmp/work/qemux86-poky-linux/linux-yocto-3.0.4+git3+12574e5a77597f6938315ef82d18fc5e229fb79c_2+72671808fdbe69a9fe03fd8f094e7c59da04a28c-r2/linux-qemux86-standard-build/.config
CONFIG_BLK_DEV_LOOP=m
[gthomas@titan pc_poky_full]$ grep CONFIG_ISO9660_FS tmp/work/qemux86-poky-linux/linux-yocto-3.0.4+git3+12574e5a77597f6938315ef82d18fc5e229fb79c_2+72671808fdbe69a9fe03fd8f094e7c59da04a28c-r2/linux-qemux86-standard-build/.config
# CONFIG_ISO9660_FS is not set

ok. I'll buy that. Jingdong, can you include the relevant fragments in qemu and qemu_x86-64 as well ? I don't want to go much more general than that at the moment.

I update boot live config(boot-live.cfg), add boot-live.scc and move them into directory 'kernel-cache/cfg'.  
Including cfg/boot-live.scc for atom-pc, common-pc and common-pc-64 to enable live booting.

http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=4833772c5fed1905404b50a832303f579c316d21