Try this script:
if [ $# -ne 2 ]; then
echo "Usage: $0 <image.tar.gz> <modules.tgz>"
if [ ! -d rootfs ]; then
echo "Creating dir \`rootfs' ..."
echo "Cleaning old \`rootfs' ..."
rm -rf rootfs/*
echo "Untaring rootfs image ..."
tar -xzf $1 -C rootfs
echo "Untaring modules ..."
tar -xzf $2 -C rootfs
echo "Creating devices ..."
cd dev || exit 1
rm -rf *
mknod -m 0660 console c 5 1
mknod -m 0660 full c 1 7
mknod -m 0660 hda b 3 0
mknod -m 0660 hda1 b 3 1
mknod -m 0660 kmem c 1 2
mknod -m 0660 kmsg c 1 11
mknod -m 0660 mem c 1 1
mknod -m 0660 loop0 b 7 0
mknod -m 0660 loop1 b 7 1
mknod -m 0660 loop2 b 7 2
mknod -m 0660 loop3 b 7 3
mknod -m 0666 null c 1 3
mknod -m 0660 ram0 b 1 0
mknod -m 0660 ram1 b 1 1
mknod -m 0660 random c 1 8
mknod -m 0660 tty c 5 0
mknod -m 0660 ttyS0 c 4 64
mknod -m 0660 urandom c 1 9
mknod -m 0666 zero c 1 5
chmod 755 pts shm
ln -sf /tmp/log log
echo "Creating \`/etc/modules' ..."
tsc2003" > etc/modules
echo "Disabling some init scripts ..."
for rcdir in rcS.d rc5.d rc3.d; do
for rcscript in S10checkroot.sh S35mountall.sh S20boa S20ntpd S23bluetooth
S25alsa-state S90i2c; do
if [ -e $rcdir/$rcscript ]; then
echo "Disabling \`$rcdir/$rcscript' ..."
mv $rcdir/$rcscript $rcdir/x$rcscript
echo "Creating init symlink ..."
ln -s /sbin/init.sysvinit init
echo "Building \`ramdisk.img' ..."
(cd rootfs; find . | cpio -o -H newc | gzip) > initrd.img
$HOME/gumstix/gumstix-oe/tmp/staging/i686-linux/bin/mkimage -A arm -O linux
-T ramdisk -C gzip -a 0 -e 0 -n rootfs -d initrd.img ramdisk.img
echo "All done :)"
This will create the proper device-nodes, move the rc-scripts not working
and create a symlink to the regular init.
After this, the ramdisk will be build.
Please customize the path to your mkimage-path.
Ian Meier wrote:
> Hi Michael,
> Thanks for you help. This is actually the path I'd started on, as I had
> no luck mounting the ext2 ramdisk. Bitbake will actually generate a
> cpio.gz image automatically, if you add it to IMAGE_FSTYPES. Using an
> initramfs image, I've managed to mount the root filesystem but the init
> script (linked to init.sysvinit) isn't successful. It seems to have
> trouble starting udev- the "mount -n -o bind /dev /etc/udev" call in the
> S03udev script fails. After this, most of the drivers fail to load. Do
> you have experience getting udev to work with initramfs?
> Thanks again,
> Ian Meier
> Michael Tellers wrote:
>> Hi Ian.
>> It is an old-fashioned way to use a static-sized ramdisk.
>> The better approach is to utilize a concept called "early userland".
>> Mostly all current distributions uses an initrd to load modules , e.g.
>> the filesystem drivers, to have the possibility to access a filesystem
>> at all.
>> We use this concept by just staying in the early userland.
>> With more or less success (it works, but there are little issues...)
>> Do the steps explained on http://www.klc.net.nz/linux/?page_id=10 but do
>> not use the init-file given (in fact, the author discuss an REALLY
>> initrd-concept and you will see, that the init-file just mounts the real
>> Just paste a link to the rootfs: ln -s /sbin/init.sysvinit init instead,
>> so the initV-process will run.
>> Some rc-scripts may not work, so you have to customize the init-process
>> as well as some device-nods.
>> Finally run the mkinitramfs-script suggested in the tutorial.
>> I'm looking forward to hearing from your prosperousnesses!
>> Best regards,
>> Michael Tellers
>> Ian Meier wrote:
>>> Has anyone used a ramdisk-based rootfilesystem with OE? I've added
>>> ex2.gz to IMAGE_FSTYPES and it generates a compresssed ext2 filesystem
>>> image. However, I haven't figured out the proper bootargs so the kernel
>>> will decompress and mount it. I just get a "Bad Magic Number" error.
>>> Do I need to use mkimage to put a U-Boot header on it? My goal is to
>>> store a compressed ramdisk image in NOR flash, and have the kernel
>>> decompress it into ram and use it as a ramdisk rather than a jffs2
>>> Also, the convention seems to be to load the kernel image to address
>>> a2000000. What happens to the memory from a000000 to a1ffffff? Is this
>>> memory available for system RAM?
>>> Ian Meier
View this message in context: http://www.nabble.com/Ramdisk-Root-Filesystem-tp16818330p16932485.html
Sent from the Gumstix mailing list archive at Nabble.com.