BeagleBox

I'm having problems getting the initrd to run init. I keep getting the "not syncing: Attempted to kill init!" message. The problem is definitely with the initrd though there may be problems with the BeagleBox kernel too.

The first step is to get an initrd that boots to a shell using the BeagleBoard kernel. Once that works, then get a BeagleBox kernel to boot that initrd. Then we can work from there to get the initrd to pivot to the real root file system on the SD card.

Some links to places that discuss how to build the initrd;

http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/Bootdisk-HOWTO.html#BUILDROOT
        or http://www.tldp.org/HOWTO/Bootdisk-HOWTO/
    http://www.tldp.org/HOWTO/From-PowerUp-To-Bash-Prompt-HOWTO.html
    http://linux-boot.net/InitRD/Config/
    http://linux-boot.net/InitRD/Creating/

This one creates necessary dev files:
        http://www.ibm.com/developerworks/linux/library/l-initrd.html

Note that I'm checking in code that builds the initrd and boot scripts today even though they don't yet boot properly.

Okay, so now I think I'm doing this all wrong. First, initrd is deprecated (or at least not the most modern solution). Now it seems initramfs is the "new" thing (though its been around awhile and I just thought, originally, it was older than initrd). The documentation for initramfs is in the kernel docs:

Documentation/filesystems/ramfs-rootfs-initramfs.txt

I've attached it here for reference. See also:

Documentation/filesystems/tmpfs.txt
Documentation/early-userspace/buffer-format.txt

The gist of this is that the initial root file system is created as a cpio file embedded in the kernel. We no longer use the pivot_root process but rather use the switch_root process which essentially deletes the initramfs files from "rootfs", mounts the new rootfs over it and then runs the /sbin/init from that.

I've used this before but its been so long since I've done this I'd forgotten how to do it. It appears the same basic process I've been using can be used except I don't need to create a file system image. Instead the initrd.gz is actually a gzipped cpio file. That will eliminate the requirement of running the initrd build as root. Using an external cpio.gz (instead of embedding it in the kernel image) allows modification to the rootfs without having to rebuild the kernel. The external cpio.gz is specified using the initrd=... kernel command line argument but without specifying a root=... argument. The kernel will autodetect that the file is an initramfs and not the older initrd format.

Note that buildroot can do this for us but it seems overkill to get buildroot to build busybox to create an initramfs when the steps for the initramfs are fairly small outside of building busybox.

Uh, I guess I could read one of my own articles:
http://lwn.net/Articles/210046/

and the init script that goes with it:
http://lwn.net/Articles/210056/

You can tell I haven't done this in awhile.....

Also see MLandley's articles:
http://landley.net/writing/rootfs-programming.html
http://landley.net/writing/

Okay, I can see nothing wrong with the cpio archive I created for the initramfs nor can I see any reason why the kernel would not use it when given the correct boot args. The only possible issue might be that initramfs doesn't like to be passed the cpio image in memory, which is what I've been doing with it:

setenv console ttyS2,115200n8
setenv vram 128M
setenv videomode tv:ntsc
setenv defaultdisplay tv
setenv kerneladdr 0x80200000
setenv ramaddr 0x81600000
setenv mmcargs setenv bootargs console=${console} console=tty0 vram=${vram} omapfb.mode=${videomode} omapfb.debug=y omapdss.def_disp=${defaultdisplay} initrd=${ramaddr}
mmcinit
fatload mmc 0 ${kerneladdr} uImage.bin
fatload mmc 0 ${ramaddr} initramfs.cpio.gz
bootm ${kerneladdr}

When you do this, you get an error message that the rootfs can't be found on NFS. See attached log of the boot session.

I traced through the kernel init code and can see no obvious reason why the initrd isn't picked up and unpacked. So I'm going back to an initrd (not initramfs) and trying to get it to work. That much, I know, should work because it's only slightly different than the validation images which use an initrd that never pivots.

Success - up to a point. I have an rcS that gets me to a shell prompt. From there I can manually run rcSwitch to test switching to the rootfs on the SD card. This almost works except switch_root doesn't work - BusyBox only has pivot_root. I thought switch_root was the new one and pivot_root was the old? Well, I can change to using pivot_root by looking up some examples.

Here is what it looks like so far:

RAMDISK: gzip image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
Freeing init memory: 164K

Please press Enter to activate this console. mmc0: new SD card at address 88f7
mmcblk0: mmc0:88f7 SU01G 942 MiB
mmcblk0: p1 p2

BusyBox v1.16.1 (2010-11-07 16:46:16 MST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

1. ls /dev
   console null ttyS0 ttyS2 zero
   loop0 random ttyS1 urandom
2. sh /etc/init.d/rcSwitch
   This script mounts rootfs and boots it up, nothing more!
   Creating devices...
   EXT2-fs (mmcblk0p2): warning: mounting unchecked fs, running e2fsck is recommended
   Unmounting /proc, /sys...
   Switching to /dev/mmcblk0p2...
   /etc/init.d/rcSwitch: exec: line 38: switch_root: not found

switch_root is for initramfs and pivot_root for initrd. I was using switch_root because I wanted an initramfs (the preferred mechanism with modern kernels). I need to have the build create either one and test with both. Why? So I can show how to do either. Remember, a goal of this project is to learn new things.

Along with that, here is an initramfs init script I found online. Looks interesting and might be worth dissecting to see if its worth modifying for the initramfs/initrd in BeagleBox. The script comes from the Paldo distribution: http://www.paldo.org/

I noted today that if I dd the validation image ramdisk to the SD card and use src/uboot/boot-sd.txt as the boot script the system comes up correctly. So my problems with the initrd and my real rootfs are probably in my real rootfs.

One thing I'm doing it switching to sysvinit from Busybox init. I know it a little better and the validation rootfs uses it. I'm also trying a more simplistic inittab. We'll see what those uncover.

Note: the tracking of the real rootfs booting is in FS#48. This issue will be closed when the initrd can actually pivot to a working rootfs.

Pivoting is no longer required. The rootfs on the second partition boots just fine now. While it is an interesting intellectual exercise to verify the initrd does pivot, it isn't of high priority and for now I'll just push it back for when I have some free time to verify.