summaryrefslogtreecommitdiff
path: root/meta/recipes-core/initrdscripts
diff options
context:
space:
mode:
authorPatrick Ohly <patrick.ohly@intel.com>2015-09-03 20:42:26 +0200
committerRichard Purdie <richard.purdie@linuxfoundation.org>2015-09-06 15:24:22 +0100
commit37741c539f5d3021e59828b49e968cd42b89a368 (patch)
tree251e38942de1fc16ff6095a8386ac20ebd910f16 /meta/recipes-core/initrdscripts
parent4734ebef1c5259791daba8ce2ce6dd4ddd5d087b (diff)
downloadopenembedded-core-37741c539f5d3021e59828b49e968cd42b89a368.tar.gz
openembedded-core-37741c539f5d3021e59828b49e968cd42b89a368.tar.bz2
openembedded-core-37741c539f5d3021e59828b49e968cd42b89a368.zip
runqemu: support full-disk images
This makes it possible to boot images with multiple partitions (the ones ending in .hddimg or .hdddirect) in several ways: runqemu qemux86 core-image-minimal hddimg runqemu tmp/deploy/images/qemux86/core-image-minimal-qemux86.hddimg VM=tmp-glibc/deploy/images/qemux86/iot-os-image-qemux86.hddimg FSTYPE=hddimg runqemu Same for hdddirect. This is useful for testing initramfs scripts, secure boot (when switching to UEFI), or boot loaders like syslinux. For testing the content of the rootfs, the ext4 image is better because that approach is faster (no need to create another large image during build, rootfs can be read directly instead of reading boot.img through loop device). When booting a live image, the kernel, initramfs (if any) and kernel parameters are taken from the image by the virtual machine's BIOS, so any additional kernel parameters given to runqemu are ignored. This can be avoided (already without this change) in a slightly hacky runqemu setup: ROOTFS=tmp/deploy/images/qemux86/core-image-minimal-qemux86.hddimg \ FSTYPE=ext4 \ KERNEL=tmp/deploy/images/qemux86/bzImage-initramfs-qemux86.bin \ MACHINE=qemux86 \ runqemu serial kvm nographic 'bootparams=root=/dev/ram0' The additional bzImage-initramfs-qemux86.bin kernel here was created by adding this to local.conf: INITRAMFS_IMAGE = "core-image-minimal-initramfs" INITRAMFS_IMAGE_BUNDLE = "1" In the code, the new FSTYPE=hddimg resp. hdddirect behaves almost exactly like the older vmdk FSTYPE. New types were chosen because it seemed cleaner than using FSTYPE=vmdk when the actual image pointed to by VM is not in that format. The downside is that several checks for FSTYPE=vmdk had to be duplicated for FSTYPE=hddimg. The VM variable now gets interpreted as "virtual machine disk image" instead of "vmdk image". Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'meta/recipes-core/initrdscripts')
0 files changed, 0 insertions, 0 deletions