1

I am new to qemu and am trying to learn kernel programming, I create an initrd which has busy box, but when I add a big tarbal ~80Mb in the cpio qemu fails to load.

I wanted to include golang in intrd, so that i could test the new kernel.

This is what is happening:

mfrw@kp ~/os/busybox/test_build
 % ls
bin  linuxrc  sbin  usr
mfrw@kp ~/os/busybox/test_build
 % !find
find . | cpio -o -H newc | gzip > rootfs_bb.gz
cpio: File ./rootfs_bb.gz grew, 1261568 new bytes not copied
7374 blocks
mfrw@kp ~/os/busybox/test_build
 % ls -ltrh
total 2.6M
drwxr-xr-x 2 mfrw mfrw 4.0K Mar 18 01:56 bin
lrwxrwxrwx 1 mfrw mfrw   11 Mar 18 01:56 linuxrc -> bin/busybox
drwxr-xr-x 2 mfrw mfrw 4.0K Mar 18 01:56 sbin
drwxr-xr-x 4 mfrw mfrw 4.0K Mar 18 15:24 usr
-rw-r--r-- 1 mfrw mfrw 2.6M Mar 18 15:31 rootfs_bb.gz
mfrw@kp ~/os/busybox/test_build
 %

Then I run it using qemu with a freshly made kernel with rootfs = 2.6 M

mfrw@kp ~/os/linux_staging % qemu-system-x86_64 -nographic -no-reboot -kernel arch/x86/boot/bzImage -initrd ./../busybox/test_build/rootfs_bb.gz  -append "panic=1 console=ttyS0 rdinit=/bin/sh"
[    0.000000] Linux version 4.11.0-rc2+ (mfrw@kp) (gcc version 6.3.1 20170109 (GCC) ) #7 SMP Sat Mar 18 02:34:27 IST 2017
[    0.000000] Command line: panic=1 console=ttyS0 rdinit=/bin/sh
[    0.000000] x86/fpu: x87 FPU will use FXSAVE
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
...... the kernel boots fine

But When I include the tar.gz for golang in the rootfs, it shoots upto 80M and then fails to boot

mfrw@kp ~/os/busybox/test_build
 % cp ~/go/go1.6.linux-amd64.tar.gz usr 
mfrw@kp ~/os/busybox/test_build
 % !fin
find . | cpio -o -H newc | gzip > rootfs_bb.gz
170406 blocks
mfrw@kp ~/os/busybox/test_build
 % ls -ltrh
total 82M
drwxr-xr-x 2 mfrw mfrw 4.0K Mar 18 01:56 bin
lrwxrwxrwx 1 mfrw mfrw   11 Mar 18 01:56 linuxrc -> bin/busybox
drwxr-xr-x 2 mfrw mfrw 4.0K Mar 18 01:56 sbin
drwxr-xr-x 4 mfrw mfrw 4.0K Mar 18 15:34 usr
-rw-r--r-- 1 mfrw mfrw  82M Mar 18 15:34 rootfs_bb.gz
mfrw@kp ~/os/busybox/test_build
 %

I try to run it with the same command and it fails to run...

mfrw@kp ~/os/linux_staging % qemu-system-x86_64 -nographic -no-reboot -kernel arch/x86/boot/bzImage -initrd ./../busybox/test_build/rootfs_bb.gz  -append "panic=1 console=ttyS0 rdinit=/bin/sh"
.... no .. output

What am I doing wrong ? Any pointers please :)

mfrw
  • 99
  • 1
  • 11
  • Maybe kernel configuration has small default for initrd / initramfs size? – 0andriy Mar 18 '17 at 19:49
  • Use an initramfs instead of initrd (which is deprecated). The initramfs is dynamically sized, and can be as large as available memory. BTW the rootfs is not accessed until late in the kernel boot sequence (i.e. after device initializations). If you get *"no ...output"*, then kernel initialization is failing. Try enabling the **earlyprintk** feature. – sawdust Mar 18 '17 at 20:58
  • @sawdust, they are using *initramfs* (note `cpio -o -H newc` above). – 0andriy Mar 20 '17 at 11:32
  • @0andriy -- Then what does the `-initrd ./../busybox/test_build/rootfs_bb.gz` in the **qemu** command line(s) specify? – sawdust Mar 20 '17 at 18:43
  • 1
    It specifies the initramfs/initrd that you want to use... (rootfs)... Btw I found the solution, I was not giving enough memory to qemu ... I used the flag -m size=512 it ran... – mfrw Mar 20 '17 at 21:21
  • @sawdust, you may check `kernel/init.c` IIRC for details of automatic recognition the file format. It doesn't matter what the name or format (initrd / initramfs) of the file. – 0andriy Mar 20 '17 at 21:32
  • You guys are conflating initrd and initramfs. They are not the same thing. BTW that was a rhetorical question, and you got the answer wrong according to the qemu manual. – sawdust Mar 22 '17 at 00:36
  • I agree both of them are not the same, but in my opinion the kernel is sane enough to figure out, and act appropriately – mfrw Mar 22 '17 at 03:54

1 Answers1

3

I found the solution finally, did not give it enough memory so it was failing. I finally ran it with

-m size=512

And it ran well

mfrw
  • 99
  • 1
  • 11