qemu + initramfs
Hello!
I just tried to boot a custom image under qemu with core-image-minimal-initramfs included in the kernel. For that, I added to my local.conf:
INITRAMFS_IMAGE = "core-image-minimal-initramfs" INITRAMFS_IMAGE_BUNDLE = "1"
The extended kernel now gets built fine with the normal "bitbake <image>".
To get runqemu to use the extended kernel, I had to mention it explicitly:
runqemu qemux86 <my-custom-image> ext4 serial kvm tmp-glibc/deploy/images/qemux86/bzImage-initramfs-qemux86.bin 'bootparams=systemd.journald.forward_to_console=1'
However, that failed initially with:
IP-Config: Complete:
device=eth0, hwaddr=52:54:00:12:34:56, ipaddr=192.168.7.2, mask=255.255.255.0, gw=192.168.7.1
host=192.168.7.2, domain=, nis-domain=(none)
bootserver=255.255.255.255, rootserver=255.255.255.255, rootpath=
ALSA device list:
No soundcards found.
Kernel panic - not syncing: /dev/console is missing or not a character device!
Please ensure your rootfs is properly configured
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.19.5-yocto-standard #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
00000000 00000000 cf89ff28 c18661ca c1cadc1c cf89ff40 c1864655 00000008
c1cadc1c 00000008 00000166 cf89ff98 c1c0fbf3 c1a80990 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 c236e380 cf8a0d60
Call Trace:
[<c18661ca>] dump_stack+0x4b/0x75
[<c1864655>] panic+0x81/0x178
[<c1c0fbf3>] kernel_init_freeable+0x16e/0x1e5
[<c186b98b>] ? _raw_spin_unlock_irq+0x1b/0x40
[<c106ae54>] ? finish_task_switch+0x54/0xc0
[<c1862970>] kernel_init+0x10/0xe0
[<c186c101>] ret_from_kernel_thread+0x21/0x30
[<c1862960>] ? rest_init+0x80/0x80
Kernel Offset: 0x0 from 0xc1000000 (relocation range: 0xc0000000-0xd07dffff)
---[ end Kernel panic - not syncing: /dev/console is missing or not a character device!
Please ensure your rootfs is properly configuredSearching for the kernel panic led me to:
http://stackoverflow.com/questions/10437995/initramfs-built-into-custom-linux-kernel-is-not-running
The hint given there (/dev/console must exist in the initramfs because the kernel opens it before executing /init) worked for like this:
(quoted diff) +0 -0
b/meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb index b54cb61..4066beb 100644
meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb +4 -1
@@ -11,9 +11,12 @@ 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 + mknod -m 622 ${D}/dev/tty0 c 4 0 } -FILES_${PN} += " /init " +FILES_${PN} += " /init /dev " # Due to kernel dependency PACKAGE_ARCH = "${MACHINE_ARCH}"
But I am surprised that I had to make such an adjustment. Isn't that something that also occurs in other build configurations? Do I perhaps miss something which avoids the issue (some kernel configuration perhaps)?
Signature · 6 lines
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.
Quoted 11 lines · Patrick Ohly
Hello!
I just tried to boot a custom image under qemu with core-image-minimal-initramfs included in the kernel. For that, I added to my local.conf:
INITRAMFS_IMAGE= "core-image-minimal-initramfs"INITRAMFS_IMAGE_BUNDLE= "1"The extended kernel now gets built fine with the normal "bitbake <image>".
Speaking of qemu and core-image-minimal-initramfs, that initramfs isn't really suitable as it stands. It uses init-live-boot, which expects to boot from removable media instead of the fixed disk provided by qemu.
Is there anything more suitable or do I have to roll my own init script entirely, perhaps based on initramfs-framework?
Signature · 6 lines
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.
Quoted 13 lines · Patrick Ohly
Quoted 11 lines · Patrick Ohly
Hello!
I just tried to boot a custom image under qemu with core-image-minimal-initramfs included in the kernel. For that, I added to my local.conf:
INITRAMFS_IMAGE= "core-image-minimal-initramfs"INITRAMFS_IMAGE_BUNDLE= "1"The extended kernel now gets built fine with the normal "bitbake <image>".
Quoted 6 lines
Speaking of qemu and core-image-minimal-initramfs, that initramfs isn't really suitable as it stands. It uses init-live-boot, which expects to boot from removable media instead of the fixed disk provided by qemu.
Is there anything more suitable or do I have to roll my own init script entirely, perhaps based on initramfs-framework?
Just a note, in meta-mentor we removed initramfs-live-install and initramfs-live-install-efi from core-image-minimal-initramfs and split that off into core-image-minimal-install-initramfs, and set INITRD_IMAGE = "core-image-minimal-install-initramfs" (that's what image-live.bbclass obeys). Not sure if that's ideal, and admittedly haven't done much testing with those images, but I think it makes more sense, name wise, for core-image-minimal-initramfs to be a general image, not something which handles installation.
Signature · 5 lines
Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics
Quoted 1 line · Patrick Ohly
However, that failed initially with:
[...]
Quoted 30 lines
Kernel Offset:
0x0from0xc1000000(relocation range: 0xc0000000-0xd07dffff) ---[ end Kernel panic - not syncing:/dev/consoleis missing or not a character device! Please ensure your rootfs is properly configuredSearching for the kernel panic led me to:
http://stackoverflow.com/questions/10437995/initramfs-built-into-custom-linux-kernel-is-not-runningThe hint given there (
/dev/consolemust exist in the initramfs because the kernel opens it before executing /init) worked for like this:meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb +4
-1@@ -11,9 +11,12 @@ 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 + mknod -m 622 ${D}/dev/tty0 c 4 0 } -FILES_${PN} += " /init " +FILES_${PN} += " /init /dev " # Due to kernel dependency PACKAGE_ARCH = "${MACHINE_ARCH}"
Quoted 4 lines
But I am surprised that I had to make such an adjustment. Isn't that something that also occurs in other build configurations? Do I perhaps miss something which avoids the issue (some kernel configuration perhaps)?
This is getting weirder. I checked MACHINE=intel-corei7-64 from meta-intel with a regular live image (i.e. without my fix above). Some additional ls debugging commands at the top of the init script show that /dev/console exists, with a time that changes during each boot. There's also /dev/0 -> /dev/console and similar entries for 1 and 2.
I know that /dev/ is from the rootfs (i.e. no tmpfs mounted on top of it) because I still see a fake /dev/rootfs-dev file that I created in the core-image-minimal-initramfs.
It almost looks like an overlay created or modified file system by the kernel (because it's there before /init does anything), but I have no idea what feature might responsible for that. Any hints?
Signature · 6 lines
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.