[gentoo-amd64] Re: Self created initramfs cannot work

[Duncan]

David Shen <davidshen84@××××××××××.com> posted
53e35fd50906261832h34fc472at65cada9042585194@××××××××××.com, excerpted
below, on  Sat, 27 Jun 2009 09:32:50 +0800:

> ##################################################### chmod +x
> /usr/src/initramfs/init
>
> then I use find /usr/src/initramfs/init | cipo -oHnewc | gzip -9 >
> /boot/initramfs.gz
>
> But when I try to boot my system, I got kernel panic, and it says it
> cannot find the init script. If I remove the 'initrd' instruction from
> the grub.conf file, the error message does different, which means the
> system WAS trying to process the initramfs. But I do not know why it
> cannot find the init script.

*MAJOR**DISCLAIMER:*  I've never needed and thus never created and worked 
with my own initramfs/initrd, here.  I run both kernel mdp/RAID and LVM2, 
but deliberately chose /not/ to put my / and rootbak partitions on LVM, 
and start the mdp/RAID / directly from the kernel using kernel 
commandline parameters, to avoid the complexity of a required initramfs/
initrd.  Also, I don't have busybox on the system as I don't need it, and 
I had trouble building it initially, so I just skipped it and put an 
entry -*sys-apps/busybox in my /etc/portage/profile/packages file so it's 
no longer part of my profile's system packages.  Thus, comments below are 
simply based on the documentation and general kernel and boot process 
knowledge.  If the documentation's wrong, the comments are likely to be 
so as well, tho general experience and knowledge goes some way.  That's 
why I had left it until now, preferring to let someone else that actually 
had initrd/initramfs experience answer.  However, since there's been only 
one reply so far and it didn't solve the problem, maybe my admittedly
not-entirely-informed comments below /will/ help...

From the separate file part of the link you listed...
http://en.gentoo-wiki.com/wiki/Initramfs#Creating_a_Separate_File

cd /usr/src/initramfs
find . -print0 | cpio -ov -0 --format=newc | /
  gzip -9 > /boot/my-initramfs.cpio.gz

(Note that I used the \<newline> convention for wrapping.  The find 
command continues on the second line, piping into gzip.)

Your actual creation of the compressed initrd (initramfs indicates it's 
appended to the kernel itself, initrd is the older separate file method, 
which you are using here, so initrd it is) is rather different:

find /usr/src/initramfs/init | cipo -oHnewc | gzip -9 > /boot/initramfs.gz

Now, presuming the cpio commandline parameters are correct (I didn't 
doublecheck those), what we have here is that you are telling find to 
find JUST THAT ONE FILE and create an archive out of it.  That one file 
is the script, by itself.  The script is fine, but it won't run BY 
ITSELF.  At the very minimum, it'll need the busybox executable that runs 
the script based on the shebang (shebang: #!<whatever> as the first line 
of a script, indicating the executable that should be run to execute the 
script).  However, due to the contents of the script, you'll need the lvm 
executable, the various device files, etc, as well.

Also noting that first shebang line in the script:

#!/bin/busybox sh

Noting your earlier copy:

cp -aL /bin/bb /usr/src/initramfs/bin # copy the busybox

So as-is, the kernel won't be able to find the necessary executable 
called by the shebang, busybox, since you've named it bb instead. You 
must either change the executable from bb to busybox, or change the 
shebang line to call bb, not busybox.

So there's two things to change in your procedure.  First, make sure the 
shebang line in the script actually corresponds to an executable you'll 
have in the initrd, in the initrd, changing either the bb executable to 
busybox, or changing the shebang line of the init script to bb instead of 
busybox.  Second, compress the whole initramfs directory into the initrd, 
not just that single init shell script, by changing the find command 
portion of that compression command to see the entire directory contents, 
not just the single initscript.

Whether it actually works then or not, I haven't actually examined the 
script well enough to be able to say, but if I'm correct, that should at 
least let the kernel find and start executing its init.  (You may or may 
not need the init=/init kernel commandline bit Branko mentioned.  I 
suspect you won't as I think the kernel checks both paths by default, but 
I haven't double-checked documentation to be sure, nor tried it myself, 
tho I /have/ used init=/bin/bash on occasion when the init system was 
screwed up, and know /that/ works, of course when there's a /bin/bash for 
it to execute. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman