Booting to a ramdisk

[wysiwyg]

Thanks for the reply Sandras.  I've been working on this since the original post and have made a little progress, but still no bash prompt.  I have, however, noticed some strange behavior.  First I wanted to make sure that the bash that I compile was working right, so I added it to the tinycore ramdisk and upon reaching the grub menu changed it's kernel line to include "init=/bin/bash" only to find that tinycore booted up normally instead of just going to the bash prompt.  Is this normal behavior?  Does the "init=" line for grub even work any more or has it been deprecated (NOTE: I'm using legacy grub)?

In additional efforts to figure out what's going on, I decided to copy the /dev directory from the TinyCore ramdisk to my project and now I no longer get the errors mentioned above, but the boot process still hangs when the flash driving that I'm booting off of is detected by the kernel when booting to my own ramdisk.  Any thoughts anyone?

Something else that was odd while trying to get this to work... instead of using my compiled bash, I figured I'd give the busybox from TinyCore a shot to see if that would work.  I copied the entire /bin contents from the TinyCore ramdisk to my own (since it's just busybox with associated symlinks).  I then ran ldd on busybox so I could copy over any libs.  Doing so produced a list of 4-5 that needed to be copied over.  However, none of those libs exist on the TinyCore ramdisk!!!  Now I'm really confused!

Also, Sandras, thanks for the tips using cpio without a ramdisk.  I've removed the steps you mentioned from the process.  I've also tried creating symlinks for /init and /sbin/init pointing to /bin/bash with no luck.  Any other thoughts?

Dave

[wysiwyg]

UPDATE: when looking at the ldd output from busybox, I realized that the files actually do exist in /lib except for linux-gate.so.1.  What threw me off initially is that I was looking for the "end result" of where the symlinks of the libs were pointing (which actually does not exist) based on the ldd output.  The actual symlinks do point to valid files however.  Anyone care to enlighten me what's going on here?


$ ldd busybox
        linux-gate.so.1 =>  (0x00b80000)
        libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0x00b0b000)
        libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x00bb6000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x00d39000)
        /lib/ld-linux.so.2 (0x00646000)

The /lib/tls directory doesn't exist on the TinyCore ramdisk nor does the linux-gate.so.1 lib.

[sandras]

It's just a thought, but perhaps when kernel is booting into an initial ramdisk, it does'nt take the "init=" option? It just seems so, because "init=" works when root is something like hda2. At least it is so for me.

Also I think you don't need to provide a "root= " option when booting to a ramdisk. But maybe that's just me.

[tinypoodle]

The /lib/tls directory doesn't exist on the TinyCore ramdisk nor does the linux-gate.so.1 lib.

linux-gate.so.1 is not a file, it's a virtual dynamically shared object

[tinypoodle]

It's just a thought, but perhaps when kernel is booting into an initial ramdisk, it does'nt take the "init=" option? It just seems so, because "init=" works when root is something like hda2. At least it is so for me.

Also I think you don't need to provide a "root= " option when booting to a ramdisk. But maybe that's just me.

I think you need to provide a "root=" option when booting to a ramdisk - as opposed to when booting to a initramfs.
You might wanna try "rdinit=" instead with a initramfs.

A pointer to documentation regarding differences had been provided in reply #8

[wysiwyg]

The /lib/tls directory doesn't exist on the TinyCore ramdisk nor does the linux-gate.so.1 lib.

linux-gate.so.1 is not a file, it's a virtual dynamically shared object

Ahh, nice to know.  That would explain why I can't locate it!    Thanks for the tip!

[wysiwyg]

It's just a thought, but perhaps when kernel is booting into an initial ramdisk, it does'nt take the "init=" option? It just seems so, because "init=" works when root is something like hda2. At least it is so for me.

Also I think you don't need to provide a "root= " option when booting to a ramdisk. But maybe that's just me.

I think you need to provide a "root=" option when booting to a ramdisk - as opposed to when booting to a initramfs.
You might wanna try "rdinit=" instead with a initramfs.

A pointer to documentation regarding differences had been provided in reply #8

I haven't looked at the documentation provided in that reply yet because I've stopped using the grub parameters to pass to the kernel (root=... init=...), but thanks for posting it.  I might have a look at it later just for the information.

Using a "root=" parameter has been removed in my setup because 1) TC doesn't use it to boot and I'm trying to mimic it 2) the failed boot is later than the previous posts (which was saying something along the lines of  "Can't find/mount root").  I know this for a fact because I created an /init bash script pointing to /bin/sh (busybox) that simply echo's "loading bash!!!" which I see on the screen and at which point the boot process stops (or at least I don't see the bash prompt).  I've also tried adding the line "exec /bin/bash" at the end of the /init file and actually copied bash to /init with no luck.  Any thoughts?

[wysiwyg]

Ok, after long periods of testing, this is what I've come up with...

1) The ramdisk image *HAS TO HAVE* an "init" file in the root (/init) and *NOWHERE* else (e.g. /sbin/init, /bin/init, or /etc/init).  It doesn't matter if /init is a bash script, symlink, or bash itself renamed to /init, as long as that file is present and is a shell or init binary or a symlinking point to one.  The absence of /init will produce faulty/erroneous error messages by the Linux Kernel stating either "You must include a root= parameter" or "Couldn't determine the filesystem of the ramdisk; tried ext2, ext3, etc".  (NOTE: those aren't the exact error messages, but that's what they're conveying)

2)  Also the legacy grub kernel parameter "init=" does *NOT* work.  I'm not sure if these are "patches" to the TinyCore Linux kernel to increase speed or what.  Anyone have any contributions to why this is the case?

3) Apparently all the previous boots that got past the invalid error messages listed in #1 were a successful boot and I didn't know because my wireless keyboard wouldn't work (probably because of the absence of a /dev file).  As soon as I plugged in a wired keyboard and got to the point where the boot flash drive was detected, I could hit enter and see the good old familiar bash prompt!  I included #3 so that if anyone behind me ran into the same problems, hopefully they'll stumble upon this post...

Dave

[sandras]

Even with my own kernel I noticed that init= option doesn't work well on initramfs. At least for me it didn'r might have done something wrong. Anyway, so it seems you must have /init in the .gz cpio archive that gets extracted to the in ram file system at boot time.

[tinypoodle]

Even with my own kernel I noticed that init= option doesn't work well on initramfs. At least for me it didn'r might have done something wrong. Anyway, so it seems you must have /init in the .gz cpio archive that gets extracted to the in ram file system at boot time.

Have you read Reply #19?

[sandras]

Sorry, I missed that. Actually, I'll have to try "rdinit=" option just out of pure curiosity.

[maro]

I also initially skipped over reply #19, but I had a quick search over the kernel sources and there is the following snippit in 'init/main.c':

Code: [Select]

if (!ramdisk_execute_command)
ramdisk_execute_command = "/init";
And then the penny dropped, insofar as I figured that 'ramdisk_execute_command' gets populated with the value of 'rdinit=...'.

A quick test with the un-altered initrd using QEMU (i.e. qemu -kernel bzImage -initrd tinycore.gz -m 48 -append "rdinit=/bin/sh") confirmed just that. I ended up in a truely minimal root shell, which I consider to be exactly what wysiwyg wants.

[wysiwyg]

Even with my own kernel I noticed that init= option doesn't work well on initramfs. At least for me it didn'r might have done something wrong. Anyway, so it seems you must have /init in the .gz cpio archive that gets extracted to the in ram file system at boot time.

Have you read Reply #19?

Sorry TinyPoodle, when you were mentioning that command, I thought you were saying to use rdinit= in order to specify the ramdisk image (which was already working properly with my config).  I just tried that parameter instead of init= and it worked like a charm!  Thanks for the tip!  Sorry I misunderstood. 

Anyone got any experience with compiling busybox (Sandras)?  I keep running into an error when issuing the "make" command after running "make menuconfig" and saving to a .config file.  Error snippets:

  HOSTCC  applets/usage
In file included from applets/usage.c:24:
include/usage.h:23:28: warning: missing terminating " character
In file included from applets/usage.c:24:
include/usage.h:25: error: expected identifier or ‘(’ before string constant
include/usage.h:33:10: warning: missing terminating " character
include/usage.h:33: error: missing terminating " character
include/usage.h:38:26: warning: missing terminating " character
include/usage.h:41:29: warning: missing terminating " character
include/usage.h:40: error: missing terminating " character
include/usage.h:50:24: warning: missing terminating " character
...
applets/usage.c:37: error: dereferencing pointer to incomplete type
applets/usage.c:37: error: dereferencing pointer to incomplete type
applets/usage.c:37: error: dereferencing pointer to incomplete type
applets/usage.c: In function ‘main’:
applets/usage.c:52: error: request for member ‘usage’ in something not a structure or union
applets/usage.c:52: error: request for member ‘usage’ in something not a structure or union
make[1]: *** [applets/usage] Error 1
make: *** [applets_dir] Error 2

[tinypoodle]

Even with my own kernel I noticed that init= option doesn't work well on initramfs. At least for me it didn'r might have done something wrong. Anyway, so it seems you must have /init in the .gz cpio archive that gets extracted to the in ram file system at boot time.

Have you read Reply #19?

Sorry TinyPoodle, when you were mentioning that command, I thought you were saying to use rdinit= in order to specify the ramdisk image (which was already working properly with my config).  I just tried that parameter instead of init= and it worked like a charm!  Thanks for the tip!  Sorry I misunderstood. 

Never ever having had a need to use it, I wouldn't have remembered that detail, all I did was looking at the documentation to which you had been referred 19(!!) posts earlier:

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

and there it is very obvious!