* [PATCH 01/10] runqemu: support full-disk images
2015-09-02 15:48 [PATCH 00/10] enhancing images, booting and runqemu Patrick Ohly
@ 2015-09-02 15:48 ` Patrick Ohly
2015-09-02 15:48 ` [PATCH 02/10] initrdscripts: create /dev/console Patrick Ohly
` (10 subsequent siblings)
11 siblings, 0 replies; 32+ messages in thread
From: Patrick Ohly @ 2015-09-02 15:48 UTC (permalink / raw)
To: openembedded-core
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".
---
scripts/runqemu | 24 ++++++++++++++----------
scripts/runqemu-internal | 10 +++++-----
2 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/scripts/runqemu b/scripts/runqemu
index 8271160..a4d9a23 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -28,7 +28,7 @@ usage() {
echo " MACHINE - the machine name (optional, autodetected from KERNEL filename if unspecified)"
echo " RAMFS - boot a ramfs-based image"
echo " ISO - boot an ISO image"
- echo " VM - boot a vmdk image"
+ echo " VM - boot a virtual machine image (= a file representing a full disk with boot loader)"
echo " Simplified QEMU command-line options can be passed with:"
echo " nographic - disables video console"
echo " serial - enables a serial console on /dev/ttyS0"
@@ -94,7 +94,7 @@ process_filename() {
error "conflicting FSTYPE types [$FSTYPE] and [$EXT]"
fi
;;
- /vmdk/)
+ /hddimg/|/hdddirect/|/vmdk/)
FSTYPE=$EXT
VM=$filename
;;
@@ -114,7 +114,7 @@ while true; do
[ -z "$MACHINE" ] && MACHINE=$arg || \
error "conflicting MACHINE types [$MACHINE] and [$arg]"
;;
- "ext2" | "ext3" | "ext4" | "jffs2" | "nfs" | "btrfs")
+ "ext2" | "ext3" | "ext4" | "jffs2" | "nfs" | "btrfs" | "hddimg" | "hdddirect" )
[ -z "$FSTYPE" -o "$FSTYPE" = "$arg" ] && FSTYPE=$arg || \
error "conflicting FSTYPE types [$FSTYPE] and [$arg]"
;;
@@ -235,12 +235,12 @@ if [ "$FSTYPE" = "nfs" -a -z "$ROOTFS" ]; then
fi
if [ -z "$MACHINE" ]; then
- if [ "x$FSTYPE" = "xvmdk" ]; then
+ if [ "x$FSTYPE" = "xvmdk" ] || [ "x$FSTYPE" = "xhddimg" ] || [ "x$FSTYPE" = "xhdddirect" ]; then
MACHINE=`basename $VM | sed -n 's/.*\(qemux86-64\|qemux86\|qemuarm64\|qemuarm\|qemumips64\|qemumips\|qemuppc\|qemush4\).*/\1/p'`
if [ -z "$MACHINE" ]; then
- error "Unable to set MACHINE from vmdk filename [$VM]"
+ error "Unable to set MACHINE from image filename [$VM]"
fi
- echo "Set MACHINE to [$MACHINE] based on vmdk [$VM]"
+ echo "Set MACHINE to [$MACHINE] based on image [$VM]"
else
MACHINE=`basename $KERNEL | sed -n 's/.*\(qemux86-64\|qemux86\|qemuarm64\|qemuarm\|qemumips64\|qemumips\|qemuppc\|qemush4\).*/\1/p'`
if [ -z "$MACHINE" ]; then
@@ -436,7 +436,7 @@ if [ -e "$ROOTFS" -a -z "$FSTYPE" ]; then
fi
fi
-if [ -z "$KERNEL" -a "x$FSTYPE" != "xvmdk" ]; then
+if [ -z "$KERNEL" -a "x$FSTYPE" != "xvmdk" -a "x$FSTYPE" != "xhddimg" -a "x$FSTYPE" != "xhdddirect" ]; then
setup_path_vars 1
eval kernel_file=\$${machine2}_DEFAULT_KERNEL
KERNEL=$DEPLOY_DIR_IMAGE/$kernel_file
@@ -462,10 +462,14 @@ fi
if [ "$LAZY_ROOTFS" = "true" ]; then
setup_path_vars 1
echo "Assuming $ROOTFS really means $DEPLOY_DIR_IMAGE/$ROOTFS-$MACHINE.$FSTYPE"
- ROOTFS=$DEPLOY_DIR_IMAGE/$ROOTFS-$MACHINE.$FSTYPE
+ if [ "$FSTYPE" = "hddimg" -o "x$FSTYPE" = "xhdddirect" ]; then
+ VM=$DEPLOY_DIR_IMAGE/$ROOTFS-$MACHINE.$FSTYPE
+ else
+ ROOTFS=$DEPLOY_DIR_IMAGE/$ROOTFS-$MACHINE.$FSTYPE
+ fi
fi
-if [ -z "$ROOTFS" -a "x$FSTYPE" != "xvmdk" ]; then
+if [ -z "$ROOTFS" -a "x$FSTYPE" != "xvmdk" -a "x$FSTYPE" != "xhddimg" -a "x$FSTYPE" != "xhdddirect" ]; then
setup_path_vars 1
T=$DEPLOY_DIR_IMAGE
eval rootfs_list=\$${machine2}_DEFAULT_ROOTFS
@@ -481,7 +485,7 @@ ROOTFS=`readlink -f $ROOTFS`
echo ""
echo "Continuing with the following parameters:"
-if [ "x$FSTYPE" != "xvmdk" ]; then
+if [ "x$FSTYPE" != "xvmdk" -a "x$FSTYPE" != "xhddimg" -a "x$FSTYPE" != "xhdddirect" ]; then
echo "KERNEL: [$KERNEL]"
echo "ROOTFS: [$ROOTFS]"
else
diff --git a/scripts/runqemu-internal b/scripts/runqemu-internal
index a691a80..1527268 100755
--- a/scripts/runqemu-internal
+++ b/scripts/runqemu-internal
@@ -315,13 +315,13 @@ case "$MACHINE" in
;;
esac
-if [ ! -f "$KERNEL" -a "x$FSTYPE" != "xvmdk" ]; then
+if [ ! -f "$KERNEL" -a "x$FSTYPE" != "xvmdk" -a "x$FSTYPE" != "xhddimg" -a "x$FSTYPE" != "xhdddirect" ]; then
echo "Error: Kernel image file $KERNEL doesn't exist"
cleanup
return 1
fi
-if [ "$FSTYPE" != "nfs" -a "$FSTYPE" != "vmdk" -a ! -f "$ROOTFS" ]; then
+if [ "$FSTYPE" != "nfs" -a "$FSTYPE" != "vmdk" -a "$FSTYPE" != "hddimg" -a "$FSTYPE" != "hdddirect" -a ! -f "$ROOTFS" ]; then
echo "Error: Image file $ROOTFS doesn't exist"
cleanup
return 1
@@ -440,7 +440,7 @@ if [ "$MACHINE" = "qemux86" ]; then
KERNCMDLINE="root=/dev/nfs nfsroot=$NFS_SERVER:$NFS_DIR,$UNFS_OPTS rw $KERNEL_NETWORK_CMD mem=$QEMU_MEMORY"
QEMUOPTIONS="$QEMU_NETWORK_CMD $QEMU_UI_OPTIONS"
fi
- if [ "$FSTYPE" = "vmdk" ]; then
+ if [ "$FSTYPE" = "vmdk" -o "$FSTYPE" = "hddimg" -o "$FSTYPE" = "hdddirect" ]; then
QEMUOPTIONS="$QEMU_NETWORK_CMD $QEMU_UI_OPTIONS"
fi
# Currently oprofile's event based interrupt mode doesn't work(Bug #828) in
@@ -476,7 +476,7 @@ if [ "$MACHINE" = "qemux86-64" ]; then
KERNCMDLINE="root=/dev/nfs nfsroot=$NFS_SERVER:$NFS_DIR,$UNFS_OPTS rw $KERNEL_NETWORK_CMD mem=$QEMU_MEMORY"
QEMUOPTIONS="$QEMU_NETWORK_CMD -cpu $CPU_SUBTYPE $QEMU_UI_OPTIONS"
fi
- if [ "$FSTYPE" = "vmdk" ]; then
+ if [ "$FSTYPE" = "vmdk" -o "$FSTYPE" = "hddimg" -o "$FSTYPE" = "hdddirect" ]; then
QEMUOPTIONS="$QEMU_NETWORK_CMD -cpu $CPU_SUBTYPE $QEMU_UI_OPTIONS"
fi
# Currently oprofile's event based interrupt mode doesn't work(Bug #828) in
@@ -702,7 +702,7 @@ fi
echo "Running $QEMU..."
# -no-reboot is a mandatory option - see bug #100
-if [ "$FSTYPE" = "vmdk" ]; then
+if [ "$FSTYPE" = "vmdk" -o "$FSTYPE" = "hddimg" -o "$FSTYPE" = "hdddirect" ]; then
echo $QEMUBIN $VM $QEMUOPTIONS $SERIALOPTS -no-reboot $SCRIPT_QEMU_OPT $SCRIPT_QEMU_EXTRA_OPT
LD_PRELOAD="$GL_LD_PRELOAD" $QEMUBIN $VM $QEMUOPTIONS $SERIALOPTS -no-reboot $SCRIPT_QEMU_OPT $SCRIPT_QEMU_EXTRA_OPT
elif [ "$FSTYPE" = "iso" ]; then
--
2.1.4
^ permalink raw reply related [flat|nested] 32+ messages in thread* [PATCH 02/10] initrdscripts: create /dev/console
2015-09-02 15:48 [PATCH 00/10] enhancing images, booting and runqemu Patrick Ohly
2015-09-02 15:48 ` [PATCH 01/10] runqemu: support full-disk images Patrick Ohly
@ 2015-09-02 15:48 ` Patrick Ohly
2015-09-02 16:08 ` Otavio Salvador
2015-09-02 15:48 ` [PATCH 03/10] initramfs-framework: handle kernel parameters with . inside Patrick Ohly
` (9 subsequent siblings)
11 siblings, 1 reply; 32+ messages in thread
From: Patrick Ohly @ 2015-09-02 15:48 UTC (permalink / raw)
To: openembedded-core
Some kernels, for example linux-yocto 3.19 for qemux86, fail to
execute /init in an initramfs unless there is already a /dev/console
char device in the initramfs. Booting then fails with:
Kernel panic - not syncing: /dev/console is missing or not a character device!
Please ensure your rootfs is properly configured
The panic itself comes from a linux-yocto specific patch to
kernel_init_freeable in init/main.c, but even without it, that
function will print an error when /dev/console is missing. The
kernel's Documentation/initrd.txt also mentions creating that device.
It remained unclear why this is not a problem on other machines. On
intel-corei7-64 from meta-intel, something (the kernel?) creates
/dev/console and /dev/[012] before transfering control to the init
script. In that case, creating /dev/console in advance is not
necessary, but does not cause any problem either.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
---
meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb | 7 ++++++-
meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb | 4 +++-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb b/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb
index 89b900d..6c37b9a 100644
--- a/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb
+++ b/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb
@@ -34,6 +34,11 @@ do_install() {
# debug
install -m 0755 ${WORKDIR}/debug ${D}/init.d/00-debug
+
+ # Create device nodes expected by some kernels in initramfs
+ # before even executing /init.
+ install -d ${D}/dev
+ mknod -m 622 ${D}/dev/console c 5 1
}
PACKAGES = "${PN}-base \
@@ -42,7 +47,7 @@ PACKAGES = "${PN}-base \
initramfs-module-e2fs \
initramfs-module-debug"
-FILES_${PN}-base = "/init /init.d/99-finish"
+FILES_${PN}-base = "/init /init.d/99-finish /dev"
SUMMARY_initramfs-module-mdev = "initramfs support for mdev"
RDEPENDS_initramfs-module-mdev = "${PN}-base"
diff --git a/meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb b/meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb
index b54cb61..57b3025 100644
--- a/meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb
+++ b/meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb
@@ -11,9 +11,11 @@ S = "${WORKDIR}"
do_install() {
install -m 0755 ${WORKDIR}/init-live.sh ${D}/init
+ install -d ${D}/dev
+ mknod -m 622 ${D}/dev/console c 5 1
}
-FILES_${PN} += " /init "
+FILES_${PN} += " /init /dev "
# Due to kernel dependency
PACKAGE_ARCH = "${MACHINE_ARCH}"
--
2.1.4
^ permalink raw reply related [flat|nested] 32+ messages in thread* Re: [PATCH 02/10] initrdscripts: create /dev/console
2015-09-02 15:48 ` [PATCH 02/10] initrdscripts: create /dev/console Patrick Ohly
@ 2015-09-02 16:08 ` Otavio Salvador
0 siblings, 0 replies; 32+ messages in thread
From: Otavio Salvador @ 2015-09-02 16:08 UTC (permalink / raw)
To: Patrick Ohly; +Cc: Patches and discussions about the oe-core layer
On Wed, Sep 2, 2015 at 12:48 PM, Patrick Ohly <patrick.ohly@intel.com> wrote:
> Some kernels, for example linux-yocto 3.19 for qemux86, fail to
> execute /init in an initramfs unless there is already a /dev/console
> char device in the initramfs. Booting then fails with:
> Kernel panic - not syncing: /dev/console is missing or not a character device!
> Please ensure your rootfs is properly configured
>
> The panic itself comes from a linux-yocto specific patch to
> kernel_init_freeable in init/main.c, but even without it, that
> function will print an error when /dev/console is missing. The
> kernel's Documentation/initrd.txt also mentions creating that device.
>
> It remained unclear why this is not a problem on other machines. On
> intel-corei7-64 from meta-intel, something (the kernel?) creates
> /dev/console and /dev/[012] before transfering control to the init
> script. In that case, creating /dev/console in advance is not
> necessary, but does not cause any problem either.
>
> Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
I fully agree with the patch but it would be better to split the patch
for both recipes.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH 03/10] initramfs-framework: handle kernel parameters with . inside
2015-09-02 15:48 [PATCH 00/10] enhancing images, booting and runqemu Patrick Ohly
2015-09-02 15:48 ` [PATCH 01/10] runqemu: support full-disk images Patrick Ohly
2015-09-02 15:48 ` [PATCH 02/10] initrdscripts: create /dev/console Patrick Ohly
@ 2015-09-02 15:48 ` Patrick Ohly
2015-09-02 16:09 ` Otavio Salvador
2015-09-02 15:48 ` [PATCH 04/10] initramfs-framework: add separate init_verbose log level parameter Patrick Ohly
` (8 subsequent siblings)
11 siblings, 1 reply; 32+ messages in thread
From: Patrick Ohly @ 2015-09-02 15:48 UTC (permalink / raw)
To: openembedded-core
Kernel parameters like "uvesafb.mode_option=640x480-32" were turned
into shell variables named "bootparam_uvesafb.mode_option", which
triggered errors from the shell because the name is not valid. Now
points get replaced with underscores, leading to
bootparam_uvesafb_mode_option in this example.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
---
meta/recipes-core/initrdscripts/initramfs-framework/init | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-core/initrdscripts/initramfs-framework/init b/meta/recipes-core/initrdscripts/initramfs-framework/init
index 95fa9fb..e8f4713 100755
--- a/meta/recipes-core/initrdscripts/initramfs-framework/init
+++ b/meta/recipes-core/initrdscripts/initramfs-framework/init
@@ -13,6 +13,7 @@
#
# 'foo=value' as 'bootparam_foo=value'
# 'foo' as 'bootparam_foo=true'
+# 'foo.bar[=value] as 'foo_bar=[value|true]'
# Register a function to be called before running a module
# The hook is called as:
@@ -79,7 +80,7 @@ mount -t sysfs sysfs /sys
# populate bootparam environment
for p in `cat /proc/cmdline`; do
opt=`echo $p | cut -d'=' -f1`
- opt=`echo $opt | sed -e 's/-/_/'`
+ opt=`echo $opt | tr '.-' '__'`
if [ "`echo $p | cut -d'=' -f1`" = "$p" ]; then
eval "bootparam_${opt}=true"
else
--
2.1.4
^ permalink raw reply related [flat|nested] 32+ messages in thread* [PATCH 04/10] initramfs-framework: add separate init_verbose log level parameter
2015-09-02 15:48 [PATCH 00/10] enhancing images, booting and runqemu Patrick Ohly
` (2 preceding siblings ...)
2015-09-02 15:48 ` [PATCH 03/10] initramfs-framework: handle kernel parameters with . inside Patrick Ohly
@ 2015-09-02 15:48 ` Patrick Ohly
2015-09-02 16:16 ` Otavio Salvador
2015-09-02 15:48 ` [PATCH 05/10] initramfs-framework: support mounting rootfs in modules Patrick Ohly
` (7 subsequent siblings)
11 siblings, 1 reply; 32+ messages in thread
From: Patrick Ohly @ 2015-09-02 15:48 UTC (permalink / raw)
To: openembedded-core
Using the general purpose "debug" and "verbose" kernel parameters to
increase logging in the init script has the disadvantage that it
also increases logging in other components, making the output hard
to read (in particular with "debug").
The new init_verbose parameter only affects the init script:
init_verbose, init_verbose=1, init_verbose=true: enable just some info messages
init_verbose=2: debug messages
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
---
meta/recipes-core/initrdscripts/initramfs-framework/init | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/initrdscripts/initramfs-framework/init b/meta/recipes-core/initrdscripts/initramfs-framework/init
index e8f4713..cd55ee2 100755
--- a/meta/recipes-core/initrdscripts/initramfs-framework/init
+++ b/meta/recipes-core/initrdscripts/initramfs-framework/init
@@ -14,6 +14,13 @@
# 'foo=value' as 'bootparam_foo=value'
# 'foo' as 'bootparam_foo=true'
# 'foo.bar[=value] as 'foo_bar=[value|true]'
+#
+# Special boot parameters always recognized by initramfs-framework (see modules
+# like "debug" for additional ones):
+# debug: enable debug logging (beware, also enables debug output in other system components)
+# verbose: similar do debug, just less output
+# init_verbose[=true|1|2]: same output as for verbose when no value or true/1 are given,
+# same as debug for 2 - only affects logging in initramfs-framework
# Register a function to be called before running a module
# The hook is called as:
@@ -45,12 +52,12 @@ msg() {
# Prints information if verbose bootparam is used
info() {
- [ -n "$bootparam_verbose" ] && echo "$@" >/dev/console
+ ( [ -n "$bootparam_verbose" ] || [ "${bootparam_init_verbose:-0}" -gt 0 ] ) && echo "$@" >/dev/console
}
# Prints information if debug bootparam is used
debug() {
- [ -n "$bootparam_debug" ] && echo "DEBUG: $@" >/dev/console
+ ( [ -n "$bootparam_debug" ] || [ "${bootparam_init_verbose:-0}" -gt 1 ] ) && echo "DEBUG: $@" >/dev/console
}
# Prints a message and start a endless loop
@@ -89,6 +96,11 @@ for p in `cat /proc/cmdline`; do
fi
done
+# Simplify log level check in debug() and info().
+if [ "x$bootparam_init_verbose" = "xtrue" ]; then
+ bootparam_init_verbose=1
+fi
+
# use /dev with devtmpfs
if grep -q devtmpfs /proc/filesystems; then
mkdir -p /dev
--
2.1.4
^ permalink raw reply related [flat|nested] 32+ messages in thread* Re: [PATCH 04/10] initramfs-framework: add separate init_verbose log level parameter
2015-09-02 15:48 ` [PATCH 04/10] initramfs-framework: add separate init_verbose log level parameter Patrick Ohly
@ 2015-09-02 16:16 ` Otavio Salvador
2015-09-03 6:36 ` Patrick Ohly
0 siblings, 1 reply; 32+ messages in thread
From: Otavio Salvador @ 2015-09-02 16:16 UTC (permalink / raw)
To: Patrick Ohly; +Cc: Patches and discussions about the oe-core layer
On Wed, Sep 2, 2015 at 12:48 PM, Patrick Ohly <patrick.ohly@intel.com> wrote:
> Using the general purpose "debug" and "verbose" kernel parameters to
> increase logging in the init script has the disadvantage that it
> also increases logging in other components, making the output hard
> to read (in particular with "debug").
>
> The new init_verbose parameter only affects the init script:
> init_verbose, init_verbose=1, init_verbose=true: enable just some info messages
> init_verbose=2: debug messages
>
> Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
> ---
> meta/recipes-core/initrdscripts/initramfs-framework/init | 16 ++++++++++++++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-core/initrdscripts/initramfs-framework/init b/meta/recipes-core/initrdscripts/initramfs-framework/init
> index e8f4713..cd55ee2 100755
> --- a/meta/recipes-core/initrdscripts/initramfs-framework/init
> +++ b/meta/recipes-core/initrdscripts/initramfs-framework/init
> @@ -14,6 +14,13 @@
> # 'foo=value' as 'bootparam_foo=value'
> # 'foo' as 'bootparam_foo=true'
> # 'foo.bar[=value] as 'foo_bar=[value|true]'
> +#
> +# Special boot parameters always recognized by initramfs-framework (see modules
> +# like "debug" for additional ones):
> +# debug: enable debug logging (beware, also enables debug output in other system components)
> +# verbose: similar do debug, just less output
> +# init_verbose[=true|1|2]: same output as for verbose when no value or true/1 are given,
> +# same as debug for 2 - only affects logging in initramfs-framework
I personally don't see much benefit on this. The debug module is the
one used to debug the initramfs-framework script. If we ought to add
support for something like this, this should be done there.
A possible way to do so is adding in the module the init-verbose and
init-debug params and this to set bootparam_verbose and
bootparam_debug accordingly. This avoids changing the common code and
move this where it belongs.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 04/10] initramfs-framework: add separate init_verbose log level parameter
2015-09-02 16:16 ` Otavio Salvador
@ 2015-09-03 6:36 ` Patrick Ohly
2015-09-03 11:50 ` Otavio Salvador
0 siblings, 1 reply; 32+ messages in thread
From: Patrick Ohly @ 2015-09-03 6:36 UTC (permalink / raw)
To: Otavio Salvador; +Cc: Patches and discussions about the oe-core layer
On Wed, 2015-09-02 at 13:16 -0300, Otavio Salvador wrote:
> On Wed, Sep 2, 2015 at 12:48 PM, Patrick Ohly <patrick.ohly@intel.com> wrote:
> > Using the general purpose "debug" and "verbose" kernel parameters to
> > increase logging in the init script has the disadvantage that it
> > also increases logging in other components, making the output hard
> > to read (in particular with "debug").
> >
> > The new init_verbose parameter only affects the init script:
> > init_verbose, init_verbose=1, init_verbose=true: enable just some info messages
> > init_verbose=2: debug messages
> >
> > Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
> > ---
> > meta/recipes-core/initrdscripts/initramfs-framework/init | 16 ++++++++++++++--
> > 1 file changed, 14 insertions(+), 2 deletions(-)
> >
> > diff --git a/meta/recipes-core/initrdscripts/initramfs-framework/init b/meta/recipes-core/initrdscripts/initramfs-framework/init
> > index e8f4713..cd55ee2 100755
> > --- a/meta/recipes-core/initrdscripts/initramfs-framework/init
> > +++ b/meta/recipes-core/initrdscripts/initramfs-framework/init
> > @@ -14,6 +14,13 @@
> > # 'foo=value' as 'bootparam_foo=value'
> > # 'foo' as 'bootparam_foo=true'
> > # 'foo.bar[=value] as 'foo_bar=[value|true]'
> > +#
> > +# Special boot parameters always recognized by initramfs-framework (see modules
> > +# like "debug" for additional ones):
> > +# debug: enable debug logging (beware, also enables debug output in other system components)
> > +# verbose: similar do debug, just less output
> > +# init_verbose[=true|1|2]: same output as for verbose when no value or true/1 are given,
> > +# same as debug for 2 - only affects logging in initramfs-framework
>
> I personally don't see much benefit on this. The debug module is the
> one used to debug the initramfs-framework script. If we ought to add
> support for something like this, this should be done there.
So you are saying that the msg/info/debug/fatal functions should be in
the "debug" module? Or should they be present, but changing the logging
level should be done by the "debug" module? How would logging work
before the "debug" module is loaded or when it is not installed at all
(as in a production image)?
I guess one could have empty stubs in the main "init" and only do
logging after loading the debug module - that should work, at the loss
of early log output.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 04/10] initramfs-framework: add separate init_verbose log level parameter
2015-09-03 6:36 ` Patrick Ohly
@ 2015-09-03 11:50 ` Otavio Salvador
0 siblings, 0 replies; 32+ messages in thread
From: Otavio Salvador @ 2015-09-03 11:50 UTC (permalink / raw)
To: Patrick Ohly; +Cc: Patches and discussions about the oe-core layer
On Thu, Sep 3, 2015 at 3:36 AM, Patrick Ohly <patrick.ohly@intel.com> wrote:
> On Wed, 2015-09-02 at 13:16 -0300, Otavio Salvador wrote:
>> On Wed, Sep 2, 2015 at 12:48 PM, Patrick Ohly <patrick.ohly@intel.com> wrote:
>> > Using the general purpose "debug" and "verbose" kernel parameters to
>> > increase logging in the init script has the disadvantage that it
>> > also increases logging in other components, making the output hard
>> > to read (in particular with "debug").
>> >
>> > The new init_verbose parameter only affects the init script:
>> > init_verbose, init_verbose=1, init_verbose=true: enable just some info messages
>> > init_verbose=2: debug messages
>> >
>> > Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
>> > ---
>> > meta/recipes-core/initrdscripts/initramfs-framework/init | 16 ++++++++++++++--
>> > 1 file changed, 14 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/meta/recipes-core/initrdscripts/initramfs-framework/init b/meta/recipes-core/initrdscripts/initramfs-framework/init
>> > index e8f4713..cd55ee2 100755
>> > --- a/meta/recipes-core/initrdscripts/initramfs-framework/init
>> > +++ b/meta/recipes-core/initrdscripts/initramfs-framework/init
>> > @@ -14,6 +14,13 @@
>> > # 'foo=value' as 'bootparam_foo=value'
>> > # 'foo' as 'bootparam_foo=true'
>> > # 'foo.bar[=value] as 'foo_bar=[value|true]'
>> > +#
>> > +# Special boot parameters always recognized by initramfs-framework (see modules
>> > +# like "debug" for additional ones):
>> > +# debug: enable debug logging (beware, also enables debug output in other system components)
>> > +# verbose: similar do debug, just less output
>> > +# init_verbose[=true|1|2]: same output as for verbose when no value or true/1 are given,
>> > +# same as debug for 2 - only affects logging in initramfs-framework
>>
>> I personally don't see much benefit on this. The debug module is the
>> one used to debug the initramfs-framework script. If we ought to add
>> support for something like this, this should be done there.
>
> So you are saying that the msg/info/debug/fatal functions should be in
> the "debug" module? Or should they be present, but changing the logging
> level should be done by the "debug" module? How would logging work
> before the "debug" module is loaded or when it is not installed at all
> (as in a production image)?
>
> I guess one could have empty stubs in the main "init" and only do
> logging after loading the debug module - that should work, at the loss
> of early log output.
I think we can use the init-verbose and init-debug params but I would
like to see them setting the bootparam_verbose and bootparam_debug so
the init module handles it.
I am not sure if we ought to have this outside of debug module though...
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH 05/10] initramfs-framework: support mounting rootfs in modules
2015-09-02 15:48 [PATCH 00/10] enhancing images, booting and runqemu Patrick Ohly
` (3 preceding siblings ...)
2015-09-02 15:48 ` [PATCH 04/10] initramfs-framework: add separate init_verbose log level parameter Patrick Ohly
@ 2015-09-02 15:48 ` Patrick Ohly
2015-09-02 16:19 ` Otavio Salvador
2015-09-02 15:48 ` [PATCH 06/10] initramfs-framework: support live images Patrick Ohly
` (6 subsequent siblings)
11 siblings, 1 reply; 32+ messages in thread
From: Patrick Ohly @ 2015-09-02 15:48 UTC (permalink / raw)
To: openembedded-core
The "finish" script always expected to mount the rootfs itself if the
"root" parameter was set. Now it checks first whether the rootfs
directory is still empty (using /dev as indicator, because that was
already expected to be present in a supported rootfs) and skips that
step if non-empty.
This allows modules to implement their own rootfs handling.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
---
.../initrdscripts/initramfs-framework/finish | 33 +++++++++++++---------
1 file changed, 19 insertions(+), 14 deletions(-)
diff --git a/meta/recipes-core/initrdscripts/initramfs-framework/finish b/meta/recipes-core/initrdscripts/initramfs-framework/finish
index 325f47b..fa566b1 100755
--- a/meta/recipes-core/initrdscripts/initramfs-framework/finish
+++ b/meta/recipes-core/initrdscripts/initramfs-framework/finish
@@ -8,23 +8,28 @@ finish_enabled() {
finish_run() {
if [ -n "$ROOTFS_DIR" ]; then
- if [ -n "$bootparam_rootdelay" ]; then
- debug "Sleeping for $rootdelay second(s) to wait root to settle..."
- sleep $bootparam_rootdelay
- fi
+ # If $ROOTFS_DIR is non-empty, then some other module has already found
+ # the rootfs. We check for /dev because that was already expected to be
+ # in the rootfs.
+ if [ ! -d $ROOTFS_DIR/dev ]; then
+ if [ -n "$bootparam_rootdelay" ]; then
+ debug "Sleeping for $rootdelay second(s) to wait root to settle..."
+ sleep $bootparam_rootdelay
+ fi
- if [ -n "$bootparam_root" ]; then
- debug "No e2fs compatible filesystem has been mounted, mounting $bootparam_root..."
+ if [ -n "$bootparam_root" ]; then
+ debug "No e2fs compatible filesystem has been mounted, mounting $bootparam_root..."
- if [ "`echo ${bootparam_root} | cut -c1-5`" = "UUID=" ]; then
- root_uuid=`echo $bootparam_root | cut -c6-`
- bootparam_root="/dev/disk/by-uuid/$root_uuid"
- fi
+ if [ "`echo ${bootparam_root} | cut -c1-5`" = "UUID=" ]; then
+ root_uuid=`echo $bootparam_root | cut -c6-`
+ bootparam_root="/dev/disk/by-uuid/$root_uuid"
+ fi
- if [ -e "$bootparam_root" ]; then
- mount $bootparam_root $ROOTFS_DIR
- else
- debug "root '$bootparam_root' doesn't exist."
+ if [ -e "$bootparam_root" ]; then
+ mount $bootparam_root $ROOTFS_DIR
+ else
+ debug "root '$bootparam_root' doesn't exist."
+ fi
fi
fi
--
2.1.4
^ permalink raw reply related [flat|nested] 32+ messages in thread* Re: [PATCH 05/10] initramfs-framework: support mounting rootfs in modules
2015-09-02 15:48 ` [PATCH 05/10] initramfs-framework: support mounting rootfs in modules Patrick Ohly
@ 2015-09-02 16:19 ` Otavio Salvador
2015-09-02 16:24 ` Otavio Salvador
0 siblings, 1 reply; 32+ messages in thread
From: Otavio Salvador @ 2015-09-02 16:19 UTC (permalink / raw)
To: Patrick Ohly; +Cc: Patches and discussions about the oe-core layer
On Wed, Sep 2, 2015 at 12:48 PM, Patrick Ohly <patrick.ohly@intel.com> wrote:
> The "finish" script always expected to mount the rootfs itself if the
> "root" parameter was set. Now it checks first whether the rootfs
> directory is still empty (using /dev as indicator, because that was
> already expected to be present in a supported rootfs) and skips that
> step if non-empty.
>
> This allows modules to implement their own rootfs handling.
>
> Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
I think this should not be applied as is. Anything doing the rootfs
mapping should set the proper parameters so we don't have multiple
rootfs mounting code duplicated.
If there is any limitation please share the use case so we can
understand the need for it.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 05/10] initramfs-framework: support mounting rootfs in modules
2015-09-02 16:19 ` Otavio Salvador
@ 2015-09-02 16:24 ` Otavio Salvador
2015-09-03 6:29 ` Patrick Ohly
0 siblings, 1 reply; 32+ messages in thread
From: Otavio Salvador @ 2015-09-02 16:24 UTC (permalink / raw)
To: Otavio Salvador; +Cc: Patches and discussions about the oe-core layer
On Wed, Sep 2, 2015 at 1:19 PM, Otavio Salvador <otavio@ossystems.com.br> wrote:
> If there is any limitation please share the use case so we can
> understand the need for it.
I found the live module and understood why you want to do this.
Instead you could use:
- live as 99-live
- move finish for 99-rootfs-mount and split as a package
- put RCONFLICTS and RPROVIDES initramfs-module-rootfs-mount.
We can than do the choice in the image and avoid both to exist in same
initramfs.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 05/10] initramfs-framework: support mounting rootfs in modules
2015-09-02 16:24 ` Otavio Salvador
@ 2015-09-03 6:29 ` Patrick Ohly
2015-09-03 11:55 ` Otavio Salvador
0 siblings, 1 reply; 32+ messages in thread
From: Patrick Ohly @ 2015-09-03 6:29 UTC (permalink / raw)
To: Otavio Salvador; +Cc: Patches and discussions about the oe-core layer
On Wed, 2015-09-02 at 13:24 -0300, Otavio Salvador wrote:
> On Wed, Sep 2, 2015 at 1:19 PM, Otavio Salvador <otavio@ossystems.com.br> wrote:
> > If there is any limitation please share the use case so we can
> > understand the need for it.
>
> I found the live module and understood why you want to do this.
> Instead you could use:
>
> - live as 99-live
> - move finish for 99-rootfs-mount and split as a package
> - put RCONFLICTS and RPROVIDES initramfs-module-rootfs-mount.
So you are suggesting that either "live" or "finish" do the final step
of mounting the rootfs and switching to the rootfs? I actually wanted to
have an initramfs which can be used in the live image *and* on a real
disk and thus would need both, with the "live" module doing nothing
unless booting from the live image.
That's because the initramfs would also contain IMA initialization, and
that is needed in both cases. Maintaining two different initramfs
versions would be an alternative, but then the user and/or script which
does the installation must be aware of the difference. It would also
prevent embedding the initramfs inside the kernel
(INITRAMFS_IMAGE_BUNDLE).
But I'm fine with dropping these two patches for now and revisit the
topic at a later time. I'll remove them from V2 of the patch series.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 05/10] initramfs-framework: support mounting rootfs in modules
2015-09-03 6:29 ` Patrick Ohly
@ 2015-09-03 11:55 ` Otavio Salvador
0 siblings, 0 replies; 32+ messages in thread
From: Otavio Salvador @ 2015-09-03 11:55 UTC (permalink / raw)
To: Patrick Ohly; +Cc: Patches and discussions about the oe-core layer
On Thu, Sep 3, 2015 at 3:29 AM, Patrick Ohly <patrick.ohly@intel.com> wrote:
> On Wed, 2015-09-02 at 13:24 -0300, Otavio Salvador wrote:
>> On Wed, Sep 2, 2015 at 1:19 PM, Otavio Salvador <otavio@ossystems.com.br> wrote:
>> > If there is any limitation please share the use case so we can
>> > understand the need for it.
>>
>> I found the live module and understood why you want to do this.
>> Instead you could use:
>>
>> - live as 99-live
>> - move finish for 99-rootfs-mount and split as a package
>> - put RCONFLICTS and RPROVIDES initramfs-module-rootfs-mount.
>
> So you are suggesting that either "live" or "finish" do the final step
> of mounting the rootfs and switching to the rootfs? I actually wanted to
> have an initramfs which can be used in the live image *and* on a real
> disk and thus would need both, with the "live" module doing nothing
> unless booting from the live image.
>
> That's because the initramfs would also contain IMA initialization, and
> that is needed in both cases. Maintaining two different initramfs
> versions would be an alternative, but then the user and/or script which
> does the installation must be aware of the difference. It would also
> prevent embedding the initramfs inside the kernel
> (INITRAMFS_IMAGE_BUNDLE).
I see your point and it is a valid one.
However in this case, the finish change needs to be reworked to avoid
too much indenting change for no reason, the finish_enabled function
can be used for this.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH 06/10] initramfs-framework: support live images
2015-09-02 15:48 [PATCH 00/10] enhancing images, booting and runqemu Patrick Ohly
` (4 preceding siblings ...)
2015-09-02 15:48 ` [PATCH 05/10] initramfs-framework: support mounting rootfs in modules Patrick Ohly
@ 2015-09-02 15:48 ` Patrick Ohly
2015-09-02 15:48 ` [PATCH 07/10] image-vm.bbclass: avoid duplicating syslinux default values Patrick Ohly
` (5 subsequent siblings)
11 siblings, 0 replies; 32+ messages in thread
From: Patrick Ohly @ 2015-09-02 15:48 UTC (permalink / raw)
To: openembedded-core
Now initramfs-framework can be used as a replacement for
initramfs-live-boot. The "live" module was copied from init-live.sh
and adapted to the framework.
The intended usage is like this:
INITRAMFS_IMAGE = "core-image-minimal-initramfs"
PACKAGE_INSTALL_remove_pn-core-image-minimal-initramfs = "initramfs-live-boot initramfs-live-install initramfs-live-install-efi"
PACKAGE_INSTALL_append_pn-core-image-minimal-initramfs = " \
initramfs-module-udev \
initramfs-module-e2fs \
initramfs-module-debug \
initramfs-module-live \
udev-extraconf \
"
SYSLINUX_LABELS_remove = "install"
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
---
.../initrdscripts/initramfs-framework/live | 131 +++++++++++++++++++++
.../initrdscripts/initramfs-framework_1.0.bb | 9 ++
2 files changed, 140 insertions(+)
create mode 100644 meta/recipes-core/initrdscripts/initramfs-framework/live
diff --git a/meta/recipes-core/initrdscripts/initramfs-framework/live b/meta/recipes-core/initrdscripts/initramfs-framework/live
new file mode 100644
index 0000000..42125f7
--- /dev/null
+++ b/meta/recipes-core/initrdscripts/initramfs-framework/live
@@ -0,0 +1,131 @@
+#!/bin/sh
+#
+# Corresponds to and derived from initramfs-live-boot's "live" init-live.
+#
+# It will wait until a (potentially removable) disk with
+# a "rootfs.img" file on it shows up, then loop-mount that
+# file as rootfs.
+#
+# Relies on "udev" or "mdev" having run already.
+#
+# To skip this module in an initramfs which needs to support live
+# images as well as regular partitions, boot with "root" kernel
+# parameter set to something other than /dev/ram0 (the value set
+# by image-live.bbclass for SYSLINUX_ROOT, which then becomes the root
+# kernel parameter).
+
+LIVE_ROOT_IMAGE="rootfs.img"
+LIVE_ISOLINUX=""
+LIVE_ROOT_DISK=""
+LIVE_FAILURE_TIMEOUT=5
+
+live_enabled() {
+ if [ -n "$bootparam_root" ] && [ "$bootparam_root" != "/dev/ram0" ]; then
+ return 1
+ fi
+}
+
+live_run() {
+ if [ -n "$ROOTFS_DIR" ]; then
+ msg "Waiting for removable media..."
+ C=0
+ while true
+ do
+ for i in `ls /run/media 2>/dev/null`; do
+ if [ -f /run/media/$i/$LIVE_ROOT_IMAGE ] ; then
+ found="yes"
+ LIVE_ROOT_DISK="$i"
+ break
+ elif [ -f /run/media/$i/isolinux/$LIVE_ROOT_IMAGE ]; then
+ found="yes"
+ LIVE_ISOLINUX="isolinux"
+ LIVE_ROOT_DISK="$i"
+ break
+ fi
+ done
+ if [ "$found" = "yes" ]; then
+ break;
+ fi
+ # don't wait for more than "shelltimeout" seconds, if it's set
+ if [ -n "$bootparam_shelltimeout" ]; then
+ msg -n " " $(( $bootparam_shelltimeout - $C ))
+ if [ $C -ge $bootparam_shelltimeout ]; then
+ msg "..."
+ msg "Mounted filesystems"
+ mount | grep media
+ msg "Available block devices"
+ cat /proc/partitions
+ msg "Cannot find $LIVE_ROOT_IMAGE file in /run/media/* , giving up booting live image in $LIVE_FAILURE_TIMEOUT seconds"
+ # Sleep a bit because continuing to boot may
+ # generate further output that pushes the
+ # important message of the screen. init-live
+ # starts a shell at this point (hence the
+ # parameter name). With initramfs-framework, use
+ # shell=after:live to achieve something similar.
+ sleep $LIVE_FAILURE_TIMEOUT
+ break
+ fi
+ C=$(( C + 1 ))
+ fi
+ sleep 1
+ done
+
+ if [ "$found" = "yes" ]; then
+ mknod /dev/loop0 b 7 0 2>/dev/null
+
+ if ! mount -o rw,loop,noatime,nodiratime /run/media/$LIVE_ROOT_DISK/$LIVE_ISOLINUX/$LIVE_ROOT_IMAGE $ROOTFS_DIR ; then
+ fatal "Could not mount rootfs image"
+ fi
+
+ if touch $ROOTFS_DIR/bin 2>/dev/null; then
+ # The root image is read-write, directly boot it up.
+ return
+ fi
+
+ # determine which unification filesystem to use
+ union_fs_type=""
+ if grep -q -w "overlayfs" /proc/filesystems; then
+ union_fs_type="overlayfs"
+ elif grep -q -w "aufs" /proc/filesystems; then
+ union_fs_type="aufs"
+ else
+ union_fs_type=""
+ fi
+
+ # make a union mount if possible
+ case $union_fs_type in
+ "overlayfs")
+ mkdir -p /rootfs.ro /rootfs.rw
+ if ! mount -n --move $ROOTFS_DIR /rootfs.ro; then
+ rm -rf /rootfs.ro /rootfs.rw
+ fatal "Could not move rootfs mount point"
+ else
+ mount -t tmpfs -o rw,noatime,mode=755 tmpfs /rootfs.rw
+ mount -t overlayfs -o "lowerdir=/rootfs.ro,upperdir=/rootfs.rw" overlayfs $ROOTFS_DIR
+ mkdir -p $ROOTFS_DIR/rootfs.ro $ROOTFS_DIR/rootfs.rw
+ mount --move /rootfs.ro $ROOTFS_DIR/rootfs.ro
+ mount --move /rootfs.rw $ROOTFS_DIR/rootfs.rw
+ fi
+ ;;
+ "aufs")
+ mkdir -p /rootfs.ro /rootfs.rw
+ if ! mount -n --move $ROOTFS_DIR /rootfs.ro; then
+ rm -rf /rootfs.ro /rootfs.rw
+ fatal "Could not move rootfs mount point"
+ else
+ mount -t tmpfs -o rw,noatime,mode=755 tmpfs /rootfs.rw
+ mount -t aufs -o "dirs=/rootfs.rw=rw:/rootfs.ro=ro" aufs $ROOTFS_DIR
+ mkdir -p $ROOTFS_DIR/rootfs.ro $ROOTFS_DIR/rootfs.rw
+ mount --move /rootfs.ro $ROOTFS_DIR/rootfs.ro
+ mount --move /rootfs.rw $ROOTFS_DIR/rootfs.rw
+ fi
+ ;;
+ "")
+ mount -t tmpfs -o rw,noatime,mode=755 tmpfs $ROOTFS_DIR/media
+ ;;
+ esac
+ fi
+ else
+ debug "No rootfs has been set"
+ fi
+}
diff --git a/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb b/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb
index 6c37b9a..7eccc08 100644
--- a/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb
+++ b/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb
@@ -12,6 +12,7 @@ SRC_URI = "file://init \
file://mdev \
file://udev \
file://e2fs \
+ file://live \
file://debug"
S = "${WORKDIR}"
@@ -32,6 +33,9 @@ do_install() {
# e2fs
install -m 0755 ${WORKDIR}/e2fs ${D}/init.d/10-e2fs
+ # live image booting
+ install -m 0755 ${WORKDIR}/live ${D}/init.d/15-live
+
# debug
install -m 0755 ${WORKDIR}/debug ${D}/init.d/00-debug
@@ -45,6 +49,7 @@ PACKAGES = "${PN}-base \
initramfs-module-mdev \
initramfs-module-udev \
initramfs-module-e2fs \
+ initramfs-module-live \
initramfs-module-debug"
FILES_${PN}-base = "/init /init.d/99-finish /dev"
@@ -61,6 +66,10 @@ SUMMARY_initramfs-module-e2fs = "initramfs support for ext4/ext3/ext2 filesystem
RDEPENDS_initramfs-module-e2fs = "${PN}-base"
FILES_initramfs-module-e2fs = "/init.d/10-e2fs"
+SUMMARY_initramfs-module-live = "initramfs live image support"
+RDEPENDS_initramfs-module-live = "${PN}-base"
+FILES_initramfs-module-live = "/init.d/15-live"
+
SUMMARY_initramfs-module-debug = "initramfs dynamic debug support"
RDEPENDS_initramfs-module-debug = "${PN}-base"
FILES_initramfs-module-debug = "/init.d/00-debug"
--
2.1.4
^ permalink raw reply related [flat|nested] 32+ messages in thread* [PATCH 07/10] image-vm.bbclass: avoid duplicating syslinux default values
2015-09-02 15:48 [PATCH 00/10] enhancing images, booting and runqemu Patrick Ohly
` (5 preceding siblings ...)
2015-09-02 15:48 ` [PATCH 06/10] initramfs-framework: support live images Patrick Ohly
@ 2015-09-02 15:48 ` Patrick Ohly
2015-09-02 15:48 ` [PATCH 08/10] image-vm.bbclass: support specifying an initramfs Patrick Ohly
` (4 subsequent siblings)
11 siblings, 0 replies; 32+ messages in thread
From: Patrick Ohly @ 2015-09-02 15:48 UTC (permalink / raw)
To: openembedded-core
Some of the SYSLINUX defaults are the same as in the underlying
syslinux.bbclass. Let's not duplicate them, because that makes
changing the default harder.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
---
meta/classes/image-vm.bbclass | 2 --
1 file changed, 2 deletions(-)
diff --git a/meta/classes/image-vm.bbclass b/meta/classes/image-vm.bbclass
index bc0503b..3df2c36 100644
--- a/meta/classes/image-vm.bbclass
+++ b/meta/classes/image-vm.bbclass
@@ -1,7 +1,5 @@
-SYSLINUX_ROOT ?= "root=/dev/sda2"
SYSLINUX_PROMPT ?= "0"
-SYSLINUX_TIMEOUT ?= "10"
SYSLINUX_LABELS = "boot"
LABELS_append = " ${SYSLINUX_LABELS} "
--
2.1.4
^ permalink raw reply related [flat|nested] 32+ messages in thread* [PATCH 08/10] image-vm.bbclass: support specifying an initramfs
2015-09-02 15:48 [PATCH 00/10] enhancing images, booting and runqemu Patrick Ohly
` (6 preceding siblings ...)
2015-09-02 15:48 ` [PATCH 07/10] image-vm.bbclass: avoid duplicating syslinux default values Patrick Ohly
@ 2015-09-02 15:48 ` Patrick Ohly
2015-09-02 15:48 ` [PATCH 09/10] boot loader: support root=UUID Patrick Ohly
` (3 subsequent siblings)
11 siblings, 0 replies; 32+ messages in thread
From: Patrick Ohly @ 2015-09-02 15:48 UTC (permalink / raw)
To: openembedded-core
Set INITRD_IMAGE to automatically add a custom initramfs to the boot
partition.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
---
meta/classes/image-vm.bbclass | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/meta/classes/image-vm.bbclass b/meta/classes/image-vm.bbclass
index 3df2c36..0632667 100644
--- a/meta/classes/image-vm.bbclass
+++ b/meta/classes/image-vm.bbclass
@@ -3,6 +3,11 @@ SYSLINUX_PROMPT ?= "0"
SYSLINUX_LABELS = "boot"
LABELS_append = " ${SYSLINUX_LABELS} "
+# Using an initramfs is optional. Enable it by setting INITRD_IMAGE.
+INITRD_IMAGE ?= ""
+INITRD ?= "${@'${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE}-${MACHINE}.cpio.gz' if '${INITRD_IMAGE}' else ''}"
+do_bootdirectdisk[depends] += "${@'${INITRD_IMAGE}:do_rootfs' if '${INITRD_IMAGE}' else ''}"
+
# need to define the dependency and the ROOTFS for directdisk
do_bootdirectdisk[depends] += "${PN}:do_rootfs"
ROOTFS ?= "${DEPLOY_DIR_IMAGE}/${IMAGE_BASENAME}-${MACHINE}.ext4"
--
2.1.4
^ permalink raw reply related [flat|nested] 32+ messages in thread* [PATCH 09/10] boot loader: support root=UUID
2015-09-02 15:48 [PATCH 00/10] enhancing images, booting and runqemu Patrick Ohly
` (7 preceding siblings ...)
2015-09-02 15:48 ` [PATCH 08/10] image-vm.bbclass: support specifying an initramfs Patrick Ohly
@ 2015-09-02 15:48 ` Patrick Ohly
2015-09-02 15:48 ` [PATCH 10/10] boot-directdisk.bbclass: use rootfs UUID by default Patrick Ohly
` (2 subsequent siblings)
11 siblings, 0 replies; 32+ messages in thread
From: Patrick Ohly @ 2015-09-02 15:48 UTC (permalink / raw)
To: openembedded-core
As mentioned when introducing the VM images
(https://bugzilla.yoctoproject.org/show_bug.cgi?id=7374), the
resulting images only work when the image is mounted as a disk that
results in the hard-coded path (/dev/sda in the current
default). Using the file system UUID to find the rootfs is more
flexible.
To enable this for boot-direct.bbclass and thus image-vm.bbclass (aka
FSTYPEs vdi/vmdk/qcow2), set SYSLINUX_ROOT =
"root=UUID=<<uuid-of-rootfs>>". The rootfs image must use an ext file
system.
The special string will get replaced in the APPEND line with the
actual UUID when the boot loader (grub-efi, syslinux or gummiboot)
writes the boot loader configuration files. At that time, the rootfs
image has already been created and its UUID can be extracted using
"tune2fs -l", which also should be available because the
e2fsprogs-native tools were needed to create the image in the first
place.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
---
meta/classes/fs-uuid.bbclass | 24 ++++++++++++++++++++++++
meta/classes/grub-efi.bbclass | 4 ++++
meta/classes/gummiboot.bbclass | 4 ++++
meta/classes/syslinux.bbclass | 5 ++++-
4 files changed, 36 insertions(+), 1 deletion(-)
create mode 100644 meta/classes/fs-uuid.bbclass
diff --git a/meta/classes/fs-uuid.bbclass b/meta/classes/fs-uuid.bbclass
new file mode 100644
index 0000000..bd2613c
--- /dev/null
+++ b/meta/classes/fs-uuid.bbclass
@@ -0,0 +1,24 @@
+# Extract UUID from ${ROOTFS}, which must have been built
+# by the time that this function gets called. Only works
+# on ext file systems and depends on tune2fs.
+def get_rootfs_uuid(d):
+ import subprocess
+ rootfs = d.getVar('ROOTFS', True)
+ output = subprocess.check_output(['tune2fs', '-l', rootfs])
+ for line in output.split('\n'):
+ if line.startswith('Filesystem UUID:'):
+ uuid = line.split()[-1]
+ bb.note('UUID of %s: %s' % (rootfs, uuid))
+ return uuid
+ bb.fatal('Could not determine filesystem UUID of %s' % rootfs)
+
+# Replace the special <<uuid-of-rootfs>> inside a string (like the
+# root= APPEND string in a syslinux.cfg or gummiboot entry) with the
+# actual UUID of the rootfs. Does nothing if the special string
+# is not used.
+def replace_rootfs_uuid(d, string):
+ UUID_PLACEHOLDER = '<<uuid-of-rootfs>>'
+ if UUID_PLACEHOLDER in string:
+ uuid = get_rootfs_uuid(d)
+ string = string.replace(UUID_PLACEHOLDER, uuid)
+ return string
diff --git a/meta/classes/grub-efi.bbclass b/meta/classes/grub-efi.bbclass
index 6d58d48..4ddc2bb 100644
--- a/meta/classes/grub-efi.bbclass
+++ b/meta/classes/grub-efi.bbclass
@@ -26,6 +26,9 @@ GRUB_OPTS ?= "serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1"
EFIDIR = "/EFI/BOOT"
+# Need UUID utility code.
+inherit fs-uuid
+
efi_populate() {
# DEST must be the root of the image so that EFIDIR is not
# nested under a top level directory.
@@ -129,6 +132,7 @@ python build_efi_cfg() {
initrd = localdata.getVar('INITRD', True)
if append:
+ append = replace_rootfs_uuid(d, append)
cfgfile.write('%s' % (append))
cfgfile.write(' %s' % btype[1])
cfgfile.write('\n')
diff --git a/meta/classes/gummiboot.bbclass b/meta/classes/gummiboot.bbclass
index dae1977..3d9c08b 100644
--- a/meta/classes/gummiboot.bbclass
+++ b/meta/classes/gummiboot.bbclass
@@ -15,6 +15,9 @@ GUMMIBOOT_CFG ?= "${S}/loader.conf"
GUMMIBOOT_ENTRIES ?= ""
GUMMIBOOT_TIMEOUT ?= "10"
+# Need UUID utility code.
+inherit fs-uuid
+
efi_populate() {
DEST=$1
@@ -108,6 +111,7 @@ python build_efi_cfg() {
lb = "install-efi"
entrycfg.write('options LABEL=%s ' % lb)
if append:
+ append = replace_rootfs_uuid(d, append)
entrycfg.write('%s' % append)
entrycfg.write('\n')
entrycfg.close()
diff --git a/meta/classes/syslinux.bbclass b/meta/classes/syslinux.bbclass
index d6498d9..44ef9a9 100644
--- a/meta/classes/syslinux.bbclass
+++ b/meta/classes/syslinux.bbclass
@@ -34,6 +34,9 @@ ISO_BOOTCAT = "isolinux/boot.cat"
MKISOFS_OPTIONS = "-no-emul-boot -boot-load-size 4 -boot-info-table"
APPEND_prepend = " ${SYSLINUX_ROOT} "
+# Need UUID utility code.
+inherit fs-uuid
+
syslinux_populate() {
DEST=$1
BOOTDIR=$2
@@ -177,7 +180,7 @@ python build_syslinux_cfg () {
cfgfile.write('initrd=/initrd ')
cfgfile.write('LABEL=%s '% (label))
-
+ append = replace_rootfs_uuid(d, append)
cfgfile.write('%s %s\n' % (append, btype[1]))
else:
cfgfile.write('APPEND %s\n' % btype[1])
--
2.1.4
^ permalink raw reply related [flat|nested] 32+ messages in thread* [PATCH 10/10] boot-directdisk.bbclass: use rootfs UUID by default
2015-09-02 15:48 [PATCH 00/10] enhancing images, booting and runqemu Patrick Ohly
` (8 preceding siblings ...)
2015-09-02 15:48 ` [PATCH 09/10] boot loader: support root=UUID Patrick Ohly
@ 2015-09-02 15:48 ` Patrick Ohly
2015-09-02 16:28 ` [PATCH 00/10] enhancing images, booting and runqemu Otavio Salvador
2015-09-03 18:42 ` [PATCH 0/8] enhancing images, booting and runqemu, simplified version Patrick Ohly
11 siblings, 0 replies; 32+ messages in thread
From: Patrick Ohly @ 2015-09-02 15:48 UTC (permalink / raw)
To: openembedded-core
This changes the default SYSLINUX_ROOTFS such that the rootfs is no
longer expected under a fixed device path. Instead, the UUID is used
to find it. This makes the resulting .hdddirect (and thus also the
vdi/vdmk/qcow2 images derived from that) more flexible.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
---
meta/classes/boot-directdisk.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/boot-directdisk.bbclass b/meta/classes/boot-directdisk.bbclass
index 600e21a..7cb0ab0 100644
--- a/meta/classes/boot-directdisk.bbclass
+++ b/meta/classes/boot-directdisk.bbclass
@@ -60,7 +60,7 @@ inherit ${EFI_CLASS}
AUTO_SYSLINUXCFG = "1"
DISK_SIGNATURE ?= "${DISK_SIGNATURE_GENERATED}"
-SYSLINUX_ROOT ?= "root=/dev/sda2"
+SYSLINUX_ROOT ?= "root=UUID=<<uuid-of-rootfs>>"
SYSLINUX_TIMEOUT ?= "10"
IS_VM = '${@bb.utils.contains_any("IMAGE_FSTYPES", ["vmdk", "vdi", "qcow2"], "true", "false", d)}'
--
2.1.4
^ permalink raw reply related [flat|nested] 32+ messages in thread* Re: [PATCH 00/10] enhancing images, booting and runqemu
2015-09-02 15:48 [PATCH 00/10] enhancing images, booting and runqemu Patrick Ohly
` (9 preceding siblings ...)
2015-09-02 15:48 ` [PATCH 10/10] boot-directdisk.bbclass: use rootfs UUID by default Patrick Ohly
@ 2015-09-02 16:28 ` Otavio Salvador
2015-09-03 18:42 ` [PATCH 0/8] enhancing images, booting and runqemu, simplified version Patrick Ohly
11 siblings, 0 replies; 32+ messages in thread
From: Otavio Salvador @ 2015-09-02 16:28 UTC (permalink / raw)
To: Patrick Ohly; +Cc: Patches and discussions about the oe-core layer
On Wed, Sep 2, 2015 at 12:48 PM, Patrick Ohly <patrick.ohly@intel.com> wrote:
> I've spent some time lately on building custom full-disk images with a
> custom initramfs based on the initramfs-framework. The ultimate goal
> is to initialize IMA in a initramfs-framework module.
>
> As part of that work, I enhanced runqemu such that it can boot
> full-disk images more easily, made those images more versatile (no
> more hard-coded root=/dev/sda2), and solved a kernel panic that only
> seems to appear under qemu (the /dev/console issue).
>
> Only a few patches are really important (because I'd probably not be
> able to achieve the same effect with setting variables elsewhere):
> boot loader: support root=UUID
> initramfs-framework: handle kernel parameters with . inside
> initramfs-framework: add separate init_verbose log level parameter
> initramfs-framework: support mounting rootfs in modules
> runqemu: support full-disk images
>
> But I think the rest might also be relevant for others and thus
> worthwile including.
>
> Note that the mechanism for root=UUID is separated from actually
> making that default. Changing the default this late in the development
> cycle might be a bit risky, so I'd be fine with leaving out the last
> patch which changes the default. On the other hand, it solves one
> potential snag for users of these images, so it might be better to
> include it - your choice.
I would like to thank you to work on this. This extends the use of the
initramfs-framework as we wished since we designed it and it allows
for the removal of the live specific recipes for more metadata
polishment.
This is indeed a step on the right direction.
I provided some feedback; hope it helps.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 32+ messages in thread* [PATCH 0/8] enhancing images, booting and runqemu, simplified version
2015-09-02 15:48 [PATCH 00/10] enhancing images, booting and runqemu Patrick Ohly
` (10 preceding siblings ...)
2015-09-02 16:28 ` [PATCH 00/10] enhancing images, booting and runqemu Otavio Salvador
@ 2015-09-03 18:42 ` Patrick Ohly
2015-09-03 18:42 ` [PATCH 1/8] runqemu: support full-disk images Patrick Ohly
` (7 more replies)
11 siblings, 8 replies; 32+ messages in thread
From: Patrick Ohly @ 2015-09-03 18:42 UTC (permalink / raw)
To: openembedded-core
These are the same patches as in the previous patch series, minus the
ones related to initramfs-framework which will need further
discussion. I split up the /dev/console change into two commits as
suggested by Otavio.
The usage of FS UUID is still turned on by default, see the last
patch. If that's too aggressive, feel free to drop that one. It's a
change that can also be done easily in a local.conf or distro conf.
The following changes since commit aba3ef50d65e0dc8659a48bf98d0fb00dd44a6fc:
debianutils: create package for run-parts (2015-09-02 23:51:16 +0100)
are available in the git repository at:
git://github.com/pohly/openembedded-core booting-simplified
https://github.com/pohly/openembedded-core/tree/booting-simplified
Patrick Ohly (8):
runqemu: support full-disk images
initramfs-framework: create /dev/console
initramfs-live-boot: create /dev/console
initramfs-framework: handle kernel parameters with . inside
image-vm.bbclass: avoid duplicating syslinux default values
image-vm.bbclass: support specifying an initramfs
boot loader: support root=UUID
boot-directdisk.bbclass: use rootfs UUID by default
meta/classes/boot-directdisk.bbclass | 2 +-
meta/classes/fs-uuid.bbclass | 24 ++++++++++++++++++++++
meta/classes/grub-efi.bbclass | 4 ++++
meta/classes/gummiboot.bbclass | 4 ++++
meta/classes/image-vm.bbclass | 7 +++++--
meta/classes/syslinux.bbclass | 5 ++++-
.../initrdscripts/initramfs-framework/init | 3 ++-
.../initrdscripts/initramfs-framework_1.0.bb | 7 ++++++-
.../initrdscripts/initramfs-live-boot_1.0.bb | 4 +++-
scripts/runqemu | 24 +++++++++++++---------
scripts/runqemu-internal | 10 ++++-----
11 files changed, 72 insertions(+), 22 deletions(-)
create mode 100644 meta/classes/fs-uuid.bbclass
--
2.1.4
^ permalink raw reply [flat|nested] 32+ messages in thread* [PATCH 1/8] runqemu: support full-disk images
2015-09-03 18:42 ` [PATCH 0/8] enhancing images, booting and runqemu, simplified version Patrick Ohly
@ 2015-09-03 18:42 ` Patrick Ohly
2015-09-03 18:42 ` [PATCH 2/8] initramfs-framework: create /dev/console Patrick Ohly
` (6 subsequent siblings)
7 siblings, 0 replies; 32+ messages in thread
From: Patrick Ohly @ 2015-09-03 18:42 UTC (permalink / raw)
To: openembedded-core
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".
---
scripts/runqemu | 24 ++++++++++++++----------
scripts/runqemu-internal | 10 +++++-----
2 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/scripts/runqemu b/scripts/runqemu
index 8271160..a4d9a23 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -28,7 +28,7 @@ usage() {
echo " MACHINE - the machine name (optional, autodetected from KERNEL filename if unspecified)"
echo " RAMFS - boot a ramfs-based image"
echo " ISO - boot an ISO image"
- echo " VM - boot a vmdk image"
+ echo " VM - boot a virtual machine image (= a file representing a full disk with boot loader)"
echo " Simplified QEMU command-line options can be passed with:"
echo " nographic - disables video console"
echo " serial - enables a serial console on /dev/ttyS0"
@@ -94,7 +94,7 @@ process_filename() {
error "conflicting FSTYPE types [$FSTYPE] and [$EXT]"
fi
;;
- /vmdk/)
+ /hddimg/|/hdddirect/|/vmdk/)
FSTYPE=$EXT
VM=$filename
;;
@@ -114,7 +114,7 @@ while true; do
[ -z "$MACHINE" ] && MACHINE=$arg || \
error "conflicting MACHINE types [$MACHINE] and [$arg]"
;;
- "ext2" | "ext3" | "ext4" | "jffs2" | "nfs" | "btrfs")
+ "ext2" | "ext3" | "ext4" | "jffs2" | "nfs" | "btrfs" | "hddimg" | "hdddirect" )
[ -z "$FSTYPE" -o "$FSTYPE" = "$arg" ] && FSTYPE=$arg || \
error "conflicting FSTYPE types [$FSTYPE] and [$arg]"
;;
@@ -235,12 +235,12 @@ if [ "$FSTYPE" = "nfs" -a -z "$ROOTFS" ]; then
fi
if [ -z "$MACHINE" ]; then
- if [ "x$FSTYPE" = "xvmdk" ]; then
+ if [ "x$FSTYPE" = "xvmdk" ] || [ "x$FSTYPE" = "xhddimg" ] || [ "x$FSTYPE" = "xhdddirect" ]; then
MACHINE=`basename $VM | sed -n 's/.*\(qemux86-64\|qemux86\|qemuarm64\|qemuarm\|qemumips64\|qemumips\|qemuppc\|qemush4\).*/\1/p'`
if [ -z "$MACHINE" ]; then
- error "Unable to set MACHINE from vmdk filename [$VM]"
+ error "Unable to set MACHINE from image filename [$VM]"
fi
- echo "Set MACHINE to [$MACHINE] based on vmdk [$VM]"
+ echo "Set MACHINE to [$MACHINE] based on image [$VM]"
else
MACHINE=`basename $KERNEL | sed -n 's/.*\(qemux86-64\|qemux86\|qemuarm64\|qemuarm\|qemumips64\|qemumips\|qemuppc\|qemush4\).*/\1/p'`
if [ -z "$MACHINE" ]; then
@@ -436,7 +436,7 @@ if [ -e "$ROOTFS" -a -z "$FSTYPE" ]; then
fi
fi
-if [ -z "$KERNEL" -a "x$FSTYPE" != "xvmdk" ]; then
+if [ -z "$KERNEL" -a "x$FSTYPE" != "xvmdk" -a "x$FSTYPE" != "xhddimg" -a "x$FSTYPE" != "xhdddirect" ]; then
setup_path_vars 1
eval kernel_file=\$${machine2}_DEFAULT_KERNEL
KERNEL=$DEPLOY_DIR_IMAGE/$kernel_file
@@ -462,10 +462,14 @@ fi
if [ "$LAZY_ROOTFS" = "true" ]; then
setup_path_vars 1
echo "Assuming $ROOTFS really means $DEPLOY_DIR_IMAGE/$ROOTFS-$MACHINE.$FSTYPE"
- ROOTFS=$DEPLOY_DIR_IMAGE/$ROOTFS-$MACHINE.$FSTYPE
+ if [ "$FSTYPE" = "hddimg" -o "x$FSTYPE" = "xhdddirect" ]; then
+ VM=$DEPLOY_DIR_IMAGE/$ROOTFS-$MACHINE.$FSTYPE
+ else
+ ROOTFS=$DEPLOY_DIR_IMAGE/$ROOTFS-$MACHINE.$FSTYPE
+ fi
fi
-if [ -z "$ROOTFS" -a "x$FSTYPE" != "xvmdk" ]; then
+if [ -z "$ROOTFS" -a "x$FSTYPE" != "xvmdk" -a "x$FSTYPE" != "xhddimg" -a "x$FSTYPE" != "xhdddirect" ]; then
setup_path_vars 1
T=$DEPLOY_DIR_IMAGE
eval rootfs_list=\$${machine2}_DEFAULT_ROOTFS
@@ -481,7 +485,7 @@ ROOTFS=`readlink -f $ROOTFS`
echo ""
echo "Continuing with the following parameters:"
-if [ "x$FSTYPE" != "xvmdk" ]; then
+if [ "x$FSTYPE" != "xvmdk" -a "x$FSTYPE" != "xhddimg" -a "x$FSTYPE" != "xhdddirect" ]; then
echo "KERNEL: [$KERNEL]"
echo "ROOTFS: [$ROOTFS]"
else
diff --git a/scripts/runqemu-internal b/scripts/runqemu-internal
index a691a80..1527268 100755
--- a/scripts/runqemu-internal
+++ b/scripts/runqemu-internal
@@ -315,13 +315,13 @@ case "$MACHINE" in
;;
esac
-if [ ! -f "$KERNEL" -a "x$FSTYPE" != "xvmdk" ]; then
+if [ ! -f "$KERNEL" -a "x$FSTYPE" != "xvmdk" -a "x$FSTYPE" != "xhddimg" -a "x$FSTYPE" != "xhdddirect" ]; then
echo "Error: Kernel image file $KERNEL doesn't exist"
cleanup
return 1
fi
-if [ "$FSTYPE" != "nfs" -a "$FSTYPE" != "vmdk" -a ! -f "$ROOTFS" ]; then
+if [ "$FSTYPE" != "nfs" -a "$FSTYPE" != "vmdk" -a "$FSTYPE" != "hddimg" -a "$FSTYPE" != "hdddirect" -a ! -f "$ROOTFS" ]; then
echo "Error: Image file $ROOTFS doesn't exist"
cleanup
return 1
@@ -440,7 +440,7 @@ if [ "$MACHINE" = "qemux86" ]; then
KERNCMDLINE="root=/dev/nfs nfsroot=$NFS_SERVER:$NFS_DIR,$UNFS_OPTS rw $KERNEL_NETWORK_CMD mem=$QEMU_MEMORY"
QEMUOPTIONS="$QEMU_NETWORK_CMD $QEMU_UI_OPTIONS"
fi
- if [ "$FSTYPE" = "vmdk" ]; then
+ if [ "$FSTYPE" = "vmdk" -o "$FSTYPE" = "hddimg" -o "$FSTYPE" = "hdddirect" ]; then
QEMUOPTIONS="$QEMU_NETWORK_CMD $QEMU_UI_OPTIONS"
fi
# Currently oprofile's event based interrupt mode doesn't work(Bug #828) in
@@ -476,7 +476,7 @@ if [ "$MACHINE" = "qemux86-64" ]; then
KERNCMDLINE="root=/dev/nfs nfsroot=$NFS_SERVER:$NFS_DIR,$UNFS_OPTS rw $KERNEL_NETWORK_CMD mem=$QEMU_MEMORY"
QEMUOPTIONS="$QEMU_NETWORK_CMD -cpu $CPU_SUBTYPE $QEMU_UI_OPTIONS"
fi
- if [ "$FSTYPE" = "vmdk" ]; then
+ if [ "$FSTYPE" = "vmdk" -o "$FSTYPE" = "hddimg" -o "$FSTYPE" = "hdddirect" ]; then
QEMUOPTIONS="$QEMU_NETWORK_CMD -cpu $CPU_SUBTYPE $QEMU_UI_OPTIONS"
fi
# Currently oprofile's event based interrupt mode doesn't work(Bug #828) in
@@ -702,7 +702,7 @@ fi
echo "Running $QEMU..."
# -no-reboot is a mandatory option - see bug #100
-if [ "$FSTYPE" = "vmdk" ]; then
+if [ "$FSTYPE" = "vmdk" -o "$FSTYPE" = "hddimg" -o "$FSTYPE" = "hdddirect" ]; then
echo $QEMUBIN $VM $QEMUOPTIONS $SERIALOPTS -no-reboot $SCRIPT_QEMU_OPT $SCRIPT_QEMU_EXTRA_OPT
LD_PRELOAD="$GL_LD_PRELOAD" $QEMUBIN $VM $QEMUOPTIONS $SERIALOPTS -no-reboot $SCRIPT_QEMU_OPT $SCRIPT_QEMU_EXTRA_OPT
elif [ "$FSTYPE" = "iso" ]; then
--
2.1.4
^ permalink raw reply related [flat|nested] 32+ messages in thread* [PATCH 2/8] initramfs-framework: create /dev/console
2015-09-03 18:42 ` [PATCH 0/8] enhancing images, booting and runqemu, simplified version Patrick Ohly
2015-09-03 18:42 ` [PATCH 1/8] runqemu: support full-disk images Patrick Ohly
@ 2015-09-03 18:42 ` Patrick Ohly
2015-09-03 21:34 ` Khem Raj
2015-09-03 18:42 ` [PATCH 3/8] initramfs-live-boot: " Patrick Ohly
` (5 subsequent siblings)
7 siblings, 1 reply; 32+ messages in thread
From: Patrick Ohly @ 2015-09-03 18:42 UTC (permalink / raw)
To: openembedded-core
Some kernels, for example linux-yocto 3.19 for qemux86, fail to
execute /init in an initramfs unless there is already a /dev/console
char device in the initramfs. Booting then fails with:
Kernel panic - not syncing: /dev/console is missing or not a character device!
Please ensure your rootfs is properly configured
The panic itself comes from a linux-yocto specific patch to
kernel_init_freeable in init/main.c, but even without it, that
function will print an error when /dev/console is missing. The
kernel's Documentation/initrd.txt also mentions creating that device.
It remained unclear why this is not a problem on other machines. On
intel-corei7-64 from meta-intel, something (the kernel?) creates
/dev/console and /dev/[012] before transfering control to the init
script. In that case, creating /dev/console in advance is not
necessary, but does not cause any problem either.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
---
meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb b/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb
index 89b900d..6c37b9a 100644
--- a/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb
+++ b/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb
@@ -34,6 +34,11 @@ do_install() {
# debug
install -m 0755 ${WORKDIR}/debug ${D}/init.d/00-debug
+
+ # Create device nodes expected by some kernels in initramfs
+ # before even executing /init.
+ install -d ${D}/dev
+ mknod -m 622 ${D}/dev/console c 5 1
}
PACKAGES = "${PN}-base \
@@ -42,7 +47,7 @@ PACKAGES = "${PN}-base \
initramfs-module-e2fs \
initramfs-module-debug"
-FILES_${PN}-base = "/init /init.d/99-finish"
+FILES_${PN}-base = "/init /init.d/99-finish /dev"
SUMMARY_initramfs-module-mdev = "initramfs support for mdev"
RDEPENDS_initramfs-module-mdev = "${PN}-base"
--
2.1.4
^ permalink raw reply related [flat|nested] 32+ messages in thread* Re: [PATCH 2/8] initramfs-framework: create /dev/console
2015-09-03 18:42 ` [PATCH 2/8] initramfs-framework: create /dev/console Patrick Ohly
@ 2015-09-03 21:34 ` Khem Raj
2015-09-04 7:08 ` Patrick Ohly
0 siblings, 1 reply; 32+ messages in thread
From: Khem Raj @ 2015-09-03 21:34 UTC (permalink / raw)
To: Patrick Ohly; +Cc: openembedded-core
[-- Attachment #1: Type: text/plain, Size: 433 bytes --]
> On Sep 3, 2015, at 11:42 AM, Patrick Ohly <patrick.ohly@intel.com> wrote:
>
> install -m 0755 ${WORKDIR}/debug ${D}/init.d/00-debug
> +
> + # Create device nodes expected by some kernels in initramfs
> + # before even executing /init.
> + install -d ${D}/dev
> + mknod -m 622 ${D}/dev/console c 5 1
> }
>
may be just use USE_DEVFS = “0” instead if we are not letting devtmpfs into initrd image
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH 2/8] initramfs-framework: create /dev/console
2015-09-03 21:34 ` Khem Raj
@ 2015-09-04 7:08 ` Patrick Ohly
0 siblings, 0 replies; 32+ messages in thread
From: Patrick Ohly @ 2015-09-04 7:08 UTC (permalink / raw)
To: Khem Raj; +Cc: openembedded-core
On Thu, 2015-09-03 at 14:34 -0700, Khem Raj wrote:
> > On Sep 3, 2015, at 11:42 AM, Patrick Ohly <patrick.ohly@intel.com> wrote:
> >
> > install -m 0755 ${WORKDIR}/debug ${D}/init.d/00-debug
> > +
> > + # Create device nodes expected by some kernels in initramfs
> > + # before even executing /init.
> > + install -d ${D}/dev
> > + mknod -m 622 ${D}/dev/console c 5 1
> > }
> >
>
> may be just use USE_DEVFS = “0” instead if we are not letting devtmpfs into initrd image
The fix above is meant for the case were devfs is enabled (USE_DEVFS =
"1"). In my observation, a completely empty /dev then prevents booting
under qemu (see the "qemu + initramfs" mail thread).
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH 3/8] initramfs-live-boot: create /dev/console
2015-09-03 18:42 ` [PATCH 0/8] enhancing images, booting and runqemu, simplified version Patrick Ohly
2015-09-03 18:42 ` [PATCH 1/8] runqemu: support full-disk images Patrick Ohly
2015-09-03 18:42 ` [PATCH 2/8] initramfs-framework: create /dev/console Patrick Ohly
@ 2015-09-03 18:42 ` Patrick Ohly
2015-09-03 18:42 ` [PATCH 4/8] initramfs-framework: handle kernel parameters with . inside Patrick Ohly
` (4 subsequent siblings)
7 siblings, 0 replies; 32+ messages in thread
From: Patrick Ohly @ 2015-09-03 18:42 UTC (permalink / raw)
To: openembedded-core
Some kernels, for example linux-yocto 3.19 for qemux86, fail to
execute /init in an initramfs unless there is already a /dev/console
char device in the initramfs. Booting then fails with:
Kernel panic - not syncing: /dev/console is missing or not a character device!
Please ensure your rootfs is properly configured
The panic itself comes from a linux-yocto specific patch to
kernel_init_freeable in init/main.c, but even without it, that
function will print an error when /dev/console is missing. The
kernel's Documentation/initrd.txt also mentions creating that device.
It remained unclear why this is not a problem on other machines. On
intel-corei7-64 from meta-intel, something (the kernel?) creates
/dev/console and /dev/[012] before transfering control to the init
script. In that case, creating /dev/console in advance is not
necessary, but does not cause any problem either.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
---
meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb b/meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb
index b54cb61..57b3025 100644
--- a/meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb
+++ b/meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb
@@ -11,9 +11,11 @@ S = "${WORKDIR}"
do_install() {
install -m 0755 ${WORKDIR}/init-live.sh ${D}/init
+ install -d ${D}/dev
+ mknod -m 622 ${D}/dev/console c 5 1
}
-FILES_${PN} += " /init "
+FILES_${PN} += " /init /dev "
# Due to kernel dependency
PACKAGE_ARCH = "${MACHINE_ARCH}"
--
2.1.4
^ permalink raw reply related [flat|nested] 32+ messages in thread* [PATCH 4/8] initramfs-framework: handle kernel parameters with . inside
2015-09-03 18:42 ` [PATCH 0/8] enhancing images, booting and runqemu, simplified version Patrick Ohly
` (2 preceding siblings ...)
2015-09-03 18:42 ` [PATCH 3/8] initramfs-live-boot: " Patrick Ohly
@ 2015-09-03 18:42 ` Patrick Ohly
2015-09-03 18:42 ` [PATCH 5/8] image-vm.bbclass: avoid duplicating syslinux default values Patrick Ohly
` (3 subsequent siblings)
7 siblings, 0 replies; 32+ messages in thread
From: Patrick Ohly @ 2015-09-03 18:42 UTC (permalink / raw)
To: openembedded-core
Kernel parameters like "uvesafb.mode_option=640x480-32" were turned
into shell variables named "bootparam_uvesafb.mode_option", which
triggered errors from the shell because the name is not valid. Now
points get replaced with underscores, leading to
bootparam_uvesafb_mode_option in this example.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
---
meta/recipes-core/initrdscripts/initramfs-framework/init | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-core/initrdscripts/initramfs-framework/init b/meta/recipes-core/initrdscripts/initramfs-framework/init
index 95fa9fb..e8f4713 100755
--- a/meta/recipes-core/initrdscripts/initramfs-framework/init
+++ b/meta/recipes-core/initrdscripts/initramfs-framework/init
@@ -13,6 +13,7 @@
#
# 'foo=value' as 'bootparam_foo=value'
# 'foo' as 'bootparam_foo=true'
+# 'foo.bar[=value] as 'foo_bar=[value|true]'
# Register a function to be called before running a module
# The hook is called as:
@@ -79,7 +80,7 @@ mount -t sysfs sysfs /sys
# populate bootparam environment
for p in `cat /proc/cmdline`; do
opt=`echo $p | cut -d'=' -f1`
- opt=`echo $opt | sed -e 's/-/_/'`
+ opt=`echo $opt | tr '.-' '__'`
if [ "`echo $p | cut -d'=' -f1`" = "$p" ]; then
eval "bootparam_${opt}=true"
else
--
2.1.4
^ permalink raw reply related [flat|nested] 32+ messages in thread* [PATCH 5/8] image-vm.bbclass: avoid duplicating syslinux default values
2015-09-03 18:42 ` [PATCH 0/8] enhancing images, booting and runqemu, simplified version Patrick Ohly
` (3 preceding siblings ...)
2015-09-03 18:42 ` [PATCH 4/8] initramfs-framework: handle kernel parameters with . inside Patrick Ohly
@ 2015-09-03 18:42 ` Patrick Ohly
2015-09-03 18:42 ` [PATCH 6/8] image-vm.bbclass: support specifying an initramfs Patrick Ohly
` (2 subsequent siblings)
7 siblings, 0 replies; 32+ messages in thread
From: Patrick Ohly @ 2015-09-03 18:42 UTC (permalink / raw)
To: openembedded-core
Some of the SYSLINUX defaults are the same as in the underlying
syslinux.bbclass. Let's not duplicate them, because that makes
changing the default harder.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
---
meta/classes/image-vm.bbclass | 2 --
1 file changed, 2 deletions(-)
diff --git a/meta/classes/image-vm.bbclass b/meta/classes/image-vm.bbclass
index bc0503b..3df2c36 100644
--- a/meta/classes/image-vm.bbclass
+++ b/meta/classes/image-vm.bbclass
@@ -1,7 +1,5 @@
-SYSLINUX_ROOT ?= "root=/dev/sda2"
SYSLINUX_PROMPT ?= "0"
-SYSLINUX_TIMEOUT ?= "10"
SYSLINUX_LABELS = "boot"
LABELS_append = " ${SYSLINUX_LABELS} "
--
2.1.4
^ permalink raw reply related [flat|nested] 32+ messages in thread* [PATCH 6/8] image-vm.bbclass: support specifying an initramfs
2015-09-03 18:42 ` [PATCH 0/8] enhancing images, booting and runqemu, simplified version Patrick Ohly
` (4 preceding siblings ...)
2015-09-03 18:42 ` [PATCH 5/8] image-vm.bbclass: avoid duplicating syslinux default values Patrick Ohly
@ 2015-09-03 18:42 ` Patrick Ohly
2015-09-03 18:42 ` [PATCH 7/8] boot loader: support root=UUID Patrick Ohly
2015-09-03 18:42 ` [PATCH 8/8] boot-directdisk.bbclass: use rootfs UUID by default Patrick Ohly
7 siblings, 0 replies; 32+ messages in thread
From: Patrick Ohly @ 2015-09-03 18:42 UTC (permalink / raw)
To: openembedded-core
Set INITRD_IMAGE to automatically add a custom initramfs to the boot
partition.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
---
meta/classes/image-vm.bbclass | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/meta/classes/image-vm.bbclass b/meta/classes/image-vm.bbclass
index 3df2c36..0632667 100644
--- a/meta/classes/image-vm.bbclass
+++ b/meta/classes/image-vm.bbclass
@@ -3,6 +3,11 @@ SYSLINUX_PROMPT ?= "0"
SYSLINUX_LABELS = "boot"
LABELS_append = " ${SYSLINUX_LABELS} "
+# Using an initramfs is optional. Enable it by setting INITRD_IMAGE.
+INITRD_IMAGE ?= ""
+INITRD ?= "${@'${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE}-${MACHINE}.cpio.gz' if '${INITRD_IMAGE}' else ''}"
+do_bootdirectdisk[depends] += "${@'${INITRD_IMAGE}:do_rootfs' if '${INITRD_IMAGE}' else ''}"
+
# need to define the dependency and the ROOTFS for directdisk
do_bootdirectdisk[depends] += "${PN}:do_rootfs"
ROOTFS ?= "${DEPLOY_DIR_IMAGE}/${IMAGE_BASENAME}-${MACHINE}.ext4"
--
2.1.4
^ permalink raw reply related [flat|nested] 32+ messages in thread* [PATCH 7/8] boot loader: support root=UUID
2015-09-03 18:42 ` [PATCH 0/8] enhancing images, booting and runqemu, simplified version Patrick Ohly
` (5 preceding siblings ...)
2015-09-03 18:42 ` [PATCH 6/8] image-vm.bbclass: support specifying an initramfs Patrick Ohly
@ 2015-09-03 18:42 ` Patrick Ohly
2015-09-03 18:42 ` [PATCH 8/8] boot-directdisk.bbclass: use rootfs UUID by default Patrick Ohly
7 siblings, 0 replies; 32+ messages in thread
From: Patrick Ohly @ 2015-09-03 18:42 UTC (permalink / raw)
To: openembedded-core
As mentioned when introducing the VM images
(https://bugzilla.yoctoproject.org/show_bug.cgi?id=7374), the
resulting images only work when the image is mounted as a disk that
results in the hard-coded path (/dev/sda in the current
default). Using the file system UUID to find the rootfs is more
flexible.
To enable this for boot-direct.bbclass and thus image-vm.bbclass (aka
FSTYPEs vdi/vmdk/qcow2), set SYSLINUX_ROOT =
"root=UUID=<<uuid-of-rootfs>>". The rootfs image must use an ext file
system.
The special string will get replaced in the APPEND line with the
actual UUID when the boot loader (grub-efi, syslinux or gummiboot)
writes the boot loader configuration files. At that time, the rootfs
image has already been created and its UUID can be extracted using
"tune2fs -l", which also should be available because the
e2fsprogs-native tools were needed to create the image in the first
place.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
---
meta/classes/fs-uuid.bbclass | 24 ++++++++++++++++++++++++
meta/classes/grub-efi.bbclass | 4 ++++
meta/classes/gummiboot.bbclass | 4 ++++
meta/classes/syslinux.bbclass | 5 ++++-
4 files changed, 36 insertions(+), 1 deletion(-)
create mode 100644 meta/classes/fs-uuid.bbclass
diff --git a/meta/classes/fs-uuid.bbclass b/meta/classes/fs-uuid.bbclass
new file mode 100644
index 0000000..bd2613c
--- /dev/null
+++ b/meta/classes/fs-uuid.bbclass
@@ -0,0 +1,24 @@
+# Extract UUID from ${ROOTFS}, which must have been built
+# by the time that this function gets called. Only works
+# on ext file systems and depends on tune2fs.
+def get_rootfs_uuid(d):
+ import subprocess
+ rootfs = d.getVar('ROOTFS', True)
+ output = subprocess.check_output(['tune2fs', '-l', rootfs])
+ for line in output.split('\n'):
+ if line.startswith('Filesystem UUID:'):
+ uuid = line.split()[-1]
+ bb.note('UUID of %s: %s' % (rootfs, uuid))
+ return uuid
+ bb.fatal('Could not determine filesystem UUID of %s' % rootfs)
+
+# Replace the special <<uuid-of-rootfs>> inside a string (like the
+# root= APPEND string in a syslinux.cfg or gummiboot entry) with the
+# actual UUID of the rootfs. Does nothing if the special string
+# is not used.
+def replace_rootfs_uuid(d, string):
+ UUID_PLACEHOLDER = '<<uuid-of-rootfs>>'
+ if UUID_PLACEHOLDER in string:
+ uuid = get_rootfs_uuid(d)
+ string = string.replace(UUID_PLACEHOLDER, uuid)
+ return string
diff --git a/meta/classes/grub-efi.bbclass b/meta/classes/grub-efi.bbclass
index 6d58d48..4ddc2bb 100644
--- a/meta/classes/grub-efi.bbclass
+++ b/meta/classes/grub-efi.bbclass
@@ -26,6 +26,9 @@ GRUB_OPTS ?= "serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1"
EFIDIR = "/EFI/BOOT"
+# Need UUID utility code.
+inherit fs-uuid
+
efi_populate() {
# DEST must be the root of the image so that EFIDIR is not
# nested under a top level directory.
@@ -129,6 +132,7 @@ python build_efi_cfg() {
initrd = localdata.getVar('INITRD', True)
if append:
+ append = replace_rootfs_uuid(d, append)
cfgfile.write('%s' % (append))
cfgfile.write(' %s' % btype[1])
cfgfile.write('\n')
diff --git a/meta/classes/gummiboot.bbclass b/meta/classes/gummiboot.bbclass
index dae1977..3d9c08b 100644
--- a/meta/classes/gummiboot.bbclass
+++ b/meta/classes/gummiboot.bbclass
@@ -15,6 +15,9 @@ GUMMIBOOT_CFG ?= "${S}/loader.conf"
GUMMIBOOT_ENTRIES ?= ""
GUMMIBOOT_TIMEOUT ?= "10"
+# Need UUID utility code.
+inherit fs-uuid
+
efi_populate() {
DEST=$1
@@ -108,6 +111,7 @@ python build_efi_cfg() {
lb = "install-efi"
entrycfg.write('options LABEL=%s ' % lb)
if append:
+ append = replace_rootfs_uuid(d, append)
entrycfg.write('%s' % append)
entrycfg.write('\n')
entrycfg.close()
diff --git a/meta/classes/syslinux.bbclass b/meta/classes/syslinux.bbclass
index d6498d9..44ef9a9 100644
--- a/meta/classes/syslinux.bbclass
+++ b/meta/classes/syslinux.bbclass
@@ -34,6 +34,9 @@ ISO_BOOTCAT = "isolinux/boot.cat"
MKISOFS_OPTIONS = "-no-emul-boot -boot-load-size 4 -boot-info-table"
APPEND_prepend = " ${SYSLINUX_ROOT} "
+# Need UUID utility code.
+inherit fs-uuid
+
syslinux_populate() {
DEST=$1
BOOTDIR=$2
@@ -177,7 +180,7 @@ python build_syslinux_cfg () {
cfgfile.write('initrd=/initrd ')
cfgfile.write('LABEL=%s '% (label))
-
+ append = replace_rootfs_uuid(d, append)
cfgfile.write('%s %s\n' % (append, btype[1]))
else:
cfgfile.write('APPEND %s\n' % btype[1])
--
2.1.4
^ permalink raw reply related [flat|nested] 32+ messages in thread* [PATCH 8/8] boot-directdisk.bbclass: use rootfs UUID by default
2015-09-03 18:42 ` [PATCH 0/8] enhancing images, booting and runqemu, simplified version Patrick Ohly
` (6 preceding siblings ...)
2015-09-03 18:42 ` [PATCH 7/8] boot loader: support root=UUID Patrick Ohly
@ 2015-09-03 18:42 ` Patrick Ohly
7 siblings, 0 replies; 32+ messages in thread
From: Patrick Ohly @ 2015-09-03 18:42 UTC (permalink / raw)
To: openembedded-core
This changes the default SYSLINUX_ROOTFS such that the rootfs is no
longer expected under a fixed device path. Instead, the UUID is used
to find it. This makes the resulting .hdddirect (and thus also the
vdi/vdmk/qcow2 images derived from that) more flexible.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
---
meta/classes/boot-directdisk.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/boot-directdisk.bbclass b/meta/classes/boot-directdisk.bbclass
index 600e21a..7cb0ab0 100644
--- a/meta/classes/boot-directdisk.bbclass
+++ b/meta/classes/boot-directdisk.bbclass
@@ -60,7 +60,7 @@ inherit ${EFI_CLASS}
AUTO_SYSLINUXCFG = "1"
DISK_SIGNATURE ?= "${DISK_SIGNATURE_GENERATED}"
-SYSLINUX_ROOT ?= "root=/dev/sda2"
+SYSLINUX_ROOT ?= "root=UUID=<<uuid-of-rootfs>>"
SYSLINUX_TIMEOUT ?= "10"
IS_VM = '${@bb.utils.contains_any("IMAGE_FSTYPES", ["vmdk", "vdi", "qcow2"], "true", "false", d)}'
--
2.1.4
^ permalink raw reply related [flat|nested] 32+ messages in thread