Skip to contentSkip to conversation

qemu + initramfs

PATCH Patrick Ohly 2 participants 4 messages Aug 24, 2015 – Aug 25, 2015

lore
Share & tools
lore
#0 lore raw

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 configured

Searching 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.
#1 lore raw
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.
#2 lore raw
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
#3 lore raw
In reply to Patrick Ohly
Quoted 1 line · Patrick Ohly

However, that failed initially with:

[...]

Quoted 30 lines

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 configured

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

meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb +4 -1
index b54cb61..4066beb 100644
@@ -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.