Booting to a ramdisk

[wysiwyg]

Hi all, this will be my first post here!  I'm working on building an embedded version of GNU/Linux for some hardware I recently purchased (plus I'm interested in learning).  I've wondered around this website and think TinyCore is a great project and decided to mirror parts of it.  Starting from "scratch", I grabbed TinyCore's Linux Kernel and mostly followed the directions to install it due to mine going on an SD card vs an HD.  Using that combo, I have no problem booting up successfully into TinyCore (and might I say, in the blink of an eye!).  Knowing that grub and the kernel are working without a problem, I decided to add my own ramdisk image into the mix.  I modified the /boot/grub/menu.lst file to use my ramdisk.  At the moment my ramdisk only contains a statically linked compiled version of bash 4.1 and ram0 & console device files.  I planned on just passing "init=/bin/bash" to the kernel option in menu.lst.  At first I kept getting errors stating "please append a correct "root=" boot option; ..." and "VFS: Unable to mount root fs on unknown-block(8,3)".  Later, I added a "root=" parameter to the menu.lst and have the entire string read: kernel /boot/kernel_2.6.33.3 init=/bin/bash root=/dev/ram0
That gets further in the boot process, and (coincidentally) when it gets to the part where the USB detects the SD (via USB adapter) that's being booted off of, the boot process halts.  I'm not sure if the boot process is finished, but it doesn't know what to "init" for whatever reason or the boot process is hung.  I'm also not sure if I'm missing more mandatory files in my ramdisk.  I'd like to have my project boot up in a ramdisk and stay there just like TinyCore does.  I'd greatly appreciate any help on getting my ramdisk up and running as well as the few questions below.

Thanks,
Dave

1). Where can I get TinyCore's kernel config file to see what I might need to add or remove for my own project?
2). How can I access the TinyCore ramdisk contents?  I tried unzipping it with gunzip and dd'ing it to a ramdisk, but when I try to mount it, it keeps asking for a filesystem type.
3). What were the compile parameters used when compiling the core software packages for the TinyCore base?

[maro]

(1) The kernel config files are here. The TC specific patches are in the sub-dirrectory and the sources already patched are in the "big file".

(2) I assume what you mean with "TinyCore ramdisk contents" is the content of the initrd (igoring the fact that files restored from backup and extensions loaded later on also become part of the ramdisk). I'd use zcat tinycore.gz | sudo cpio -idum to extract all those files from the initrd (in a different "world" you could even use something like '7zFM' to extract the lot).

(3) That might be a question for someone else to answer: The sources of the Core components should be found under here, but unlike the extension sources which mostly (but not always) have some build script I'm not sure where to find the same for the Core components.

[curaga]

The conventions are different depending if you use an initramfs (cpio) or an initrd, including the location of init. I don't remember how the older side went, but a basic set of /dev and static bash as /init in a cpio archive should work.

[tinypoodle]

2). How can I access the TinyCore ramdisk contents?  I tried unzipping it with gunzip and dd'ing it to a ramdisk, but when I try to mount it, it keeps asking for a filesystem type.

AFAIK, TC does not make any use of ramdisks at all. ramdisks would need to be formatted in order to be mounted - as opposed to initramfs, rootfs and tmpfs.

A search in wiki for "remastering" regarding unpacking and repacking of tinycore.gz might be helpful.

[wysiwyg]

Thanks everyone!  You've provided me with some helpful information that I'm going to try to digest later this afternoon (after house chores .  Has anyone here thought of making a tutorial/HowTo on all creating an OS of this calibur and type?  It would be an invaluable resource for people who would want to learn.  I know there are already several documents (I was using the Pocket Linux Guide), but those are all dated and not completely applicable any longer.  Food for thought! 

Dave

[wysiwyg]

The conventions are different depending if you use an initramfs (cpio) or an initrd, including the location of init. I don't remember how the older side went, but a basic set of /dev and static bash as /init in a cpio archive should work.

Can you think of any mandatory /dev files other than console and ram0 at this point?  Also, if I pass "init=/bin/bash" to the kernel through grub, I shouldn't need an /init or /usr/sbin/init file right?  Shouldn't bash load automatically after the kernel has finished with the boot process?

[wysiwyg]

AFAIK, TC does not make any use of ramdisks at all. ramdisks would need to be formatted in order to be mounted - as opposed to initramfs, rootfs and tmpfs.

A search in wiki for "remastering" regarding unpacking and repacking of tinycore.gz might be helpful.

I'm currently using an initrd (dd and gzip).  Are their advantages of one type over another?  At this point, I just want to mimic what TC is doing since it's obviously working, and working well.   Does someone know which of the three mentioned above is actually in use with TC?  I'll take a look at the "remastering" section to gain access to the image file.

[tinypoodle]

You don't specify what you do with dd...

A dev would probably be able to answer your questions better, but as far as I understand, initramfs is extracted to rootfs which is a unique instance of tmpfs.
Have a look at /etc/mtab. One thing I have never understood myself is what the extra tmpfs mounted over /dev/shm is good for...

AFAIK, TC base does not make any use of images.
Noone claimed that the wiki was referring to remastering of any image file; it refers to unpacking and repacking a (gzipped) cpio archive.

[curaga]

Can you think of any mandatory /dev files other than console and ram0 at this point?  Also, if I pass "init=/bin/bash" to the kernel through grub, I shouldn't need an /init or /usr/sbin/init file right?  Shouldn't bash load automatically after the kernel has finished with the boot process?

If you'd rather pass a param, sure. ram0 is not needed if using cpio, but null, zero, std{in,out,err}, random, urandom.

I'm currently using an initrd (dd and gzip).  Are their advantages of one type over another?  At this point, I just want to mimic what TC is doing since it's obviously working, and working well.  Does someone know which of the three mentioned above is actually in use with TC?  I'll take a look at the "remastering" section to gain access to the image file.

The differences are well documented in the kernel docs (initrd.txt, filesystems/ramfs-rootfs-initfamfs.txt)
TC uses initramfs, or a gzipped cpio archive.

One thing I have never understood myself is what the extra tmpfs mounted over /dev/shm is good for...

POSIX shared memory

[tinypoodle]

One thing I have never understood myself is what the extra tmpfs mounted over /dev/shm is good for...

POSIX shared memory

Yes, that much I understood, and I had myself mounted tmpfs over /dev/shm years ago (~kernel 2.4.20) in scatter installed system for my own purposes.

What I do not understand is:

tmpfs                   900.5M    134.2M    766.3M  15% /
tmpfs                   500.3M         0    500.3M   0% /dev/shm

running TC in default mode, when there is a tmpfs of 90% of size of RAM mounted over / which is populated from the very beginning by the whole tree of the system hierarchy, of what purpose a second mounted tmpfs of 50% of size of RAM mounted over /dev/shm could be (which by default always remains unpopulated).

[wysiwyg]

Ok guys, I'm still having no luck with my boot "ramdisk".  Here are the steps I've taken so far:

1) dd if=/dev/zero of=/dev/ram7 bs=1k count=8190
2) mke2fs /dev/ram7
3) mount /dev/ram7 /mnt/rd
4) cd /mnt/rd
5) mkdir bin dev sbin
6) copy the statically compiled bash to bin and made the following devices: zero, null, console, tty, tty0-6, ram0, initctl
7) find | sudo cpio -o -H newc | gzip > /mnt/source/boot/ramdisks/myrd.gz (/mnt/source is the bootable partition on the media)

grub parameters:
kernel /boot/kernel_2.6.33.3 init=/bin/bash [root=/dev/ram0] (this is just a renamed TinyCore Linux Kernel)
initrd /boot/ramdisks/myrd.gz

If I don't include the "root=/dev/ram0" I get:
VFS: Cannot open root device "(null)" or unknown-block(8,3)
Please append a correct "root=" boot option; here are the available partitions:
0b00     10448575 sr0 driver: sr
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,3)
... some codes ...

If I do include the "root=/dev/ram0" I get:
No filesystem could mount root, tried: ext2 ext3 ext4 cramfs iso9660 fuseblk
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)

I got further along in the boot process using the following dd commands instead of cpio above:
7a) umount /mnt/rd
8a) dd if=/dev/ram7 of=/mnt/source/boot/ramdisks/myrd bs=1k count=8190
9a) gzip /mnt/source/boot/ramdisks/myrd

Any help would greatly be appreciated...

[curaga]

What I do not understand is:

tmpfs                   900.5M    134.2M    766.3M  15% /
tmpfs                   500.3M         0    500.3M   0% /dev/shm

running TC in default mode, when there is a tmpfs of 90% of size of RAM mounted over / which is populated from the very beginning by the whole tree of the system hierarchy, of what purpose a second mounted tmpfs of 50% of size of RAM mounted over /dev/shm could be (which by default always remains unpopulated).

It's separate, so that apps may still use it with the root being full / near full. In conventional systems it is a tmpfs so that it's automatically cleaned on reboot, in addition to the "full root" part.

50% is just the default tmpfs size.


@wysiwyg

I wonder if you could post more of the dmesg (set up a netconsole/serial console? A serial console can be output to a text file in Qemu).

[tinypoodle]

What I do not understand is:

tmpfs                   900.5M    134.2M    766.3M  15% /
tmpfs                   500.3M         0    500.3M   0% /dev/shm

running TC in default mode, when there is a tmpfs of 90% of size of RAM mounted over / which is populated from the very beginning by the whole tree of the system hierarchy, of what purpose a second mounted tmpfs of 50% of size of RAM mounted over /dev/shm could be (which by default always remains unpopulated).

It's separate, so that apps may still use it with the root being full / near full. In conventional systems it is a tmpfs so that it's automatically cleaned on reboot, in addition to the "full root" part.

50% is just the default tmpfs size.

On scatter installed systems I had made use of all that, either by relinking /tmp to /dev/shm/tmp or by specifying certain configurable paths to use a subdir of /dev/shm or by copying data and/or executables to /dev/shm.
Never though have I seen any app using /dev/shm per default (without manual user intervention), if any such exists, then it would make sense of course.
What I have seen is certain "Live" Linux systems mounting part of the file tree over /dev/shm by default, which is not the case with TC.

I'd estimate that if on TC the tmpfs mounted over / being 90% of ram size would become full, any attempt to use the tmpfs mounted over /dev/shm in addition would result in a "swap party".
OTOH, the way the swap mechanism works under kernel 2.6, I'd expect that there might still be some gain of speed in comparison to using a block device filesystem for file storage.

What is my real curiosity is what possible positive and/or negative consequences umount-ing /dev/shm while running TC in default mode could potentially have.

[wysiwyg]

@wysiwyg

I wonder if you could post more of the dmesg (set up a netconsole/serial console? A serial console can be output to a text file in Qemu).

I'd love to, but I don't have dmesg compiled as of yet.  I'm still trying to get the "ramdisk" containing just bash up and running.  I'm also not familiar with setting up a netconsole or serial console.  Would any of the codes from the failed boot be of any help?

 Is it possible for anyone to construct a "ramdisk" in the fashion I provided above (or in your own way) to see if I can use it with my install?  I'm just not sure if it's something I'm doing or some config on my dev computer.

[sandras]

I myself am growing a Linux/Busybox/uClibc system. And I think I have some thing to note.

First, you should get rid of the first three steps in constructing your ramdisk. Because actually, what you are constructing is a simple archive which is later loaded by the bootloader to the ram and kernel extracts it into an instance of a ramdisk.

So you should go like this:
1) mkdir /tmp/myrd
2) cd /tmp/myrd
3) mkdir bin, dev, sbin , etc, etc. (see what i did there? : D)
4) make device nodes in dev, copy over bash.
5) find | sudo cpio -o -H newc | gzip > /mnt/source/boot/ramdisks/myrd.gz
something like this...

Second, I don't know why exactly, but I too have had problems with pointing the  kernel to what the real init is, but was able to boot, when i really had an /init (not /sbin/init, not /bin/init, not /usr/bin/init). Whatever stood for init, it worked. I think I had similar problems with kernel not mounting ramdisk too, but as far as I can remember most of the problems were solved by having something to stand there as an /init.