Initramfs

Initramfs

[Garrett Kajmowicz]

I would like to start off by thanking everybody for their help with my last 
question,  Much appreciated.

I am currently testing kernel 2.6.0-test3, specifically the initramfs feature, 
under VMWare

Upon booting I get the following:

Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8196 (order: 3, 32768 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
->(three characters, an 'o' with an I superimposed, a carat^, and a white 
smilyface)
Kernel panic: populate_root: bogus mode: 0

In idle task - not syncing

===Creation details - verbose===

I have created a directory tree on my system that I would like to use as a 
root fs.  I then created (from the root of that structure) the cpio archive 
by using
find | cpio -ov > ../filesystem.cpio
cd ..
gzip -9 filesystem.cpio
I then copied the file into the proper location in the source tree, compiled 
and had everything boot nicely.

I used syslinux to boot the kernel from a disk (only way I could get it to 
work on the virtual disk image to boot under VMWare)

===End of Creation details===

How would you suggest I go about fixing this problem, or do you require more 
information?  Also, is there a good detailed FAQ or a HOWTO document available 
online that I might be able to refer to?

Once again, thank you for your assistance.

Garrett Kajmowicz
gkajmowi@tbaytel.net

Re: Initramfs

[Bryan O'Sullivan]

On Wed, 2003-08-20 at 21:44, Garrett Kajmowicz wrote:

> Upon booting I get the following:
> 
> Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
> Inode-cache hash table entries: 8196 (order: 3, 32768 bytes)
> Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
> ->(three characters, an 'o' with an I superimposed, a carat^, and a white 
> smilyface)
> Kernel panic: populate_root: bogus mode: 0
> 
> In idle task - not syncing

The initramfs cpio unpacker is quite cranky, and has some undocumented
limits.  What does "cpio -itv" report on your cpio archive?

If your archive contains any symlinks, for example, the unpacker will
almost certainly blow up.

> How would you suggest I go about fixing this problem, or do you require more 
> information?

If you actually want to fix the problem, you'll want to port
init/initramfs.c to userspace, hammer on it until it unpacks what you
want, then port the patches back to the kernel code and test them
there.  Unless you're unbelievably patient, in which case do all the
hacking on the kernel code and reboot a lot.

> Also, is there a good detailed FAQ or a HOWTO document available 
> online that I might be able to refer to?

No.  initramfs is stuck in limbo at the moment, and early userspace is
unlikely to see any real work until 2.7.  Feel free to ask questions,
but don't expect them to result in anything actually happening.

If you want to do real work in this area, the klibc mailing list is the
place to go: http://www.zytor.com/mailman/listinfo/klibc

	<b

Re: Initramfs

[Jeff Garzik]

Bryan O'Sullivan wrote:
> No.  initramfs is stuck in limbo at the moment, and early userspace is
> unlikely to see any real work until 2.7.  Feel free to ask questions,
> but don't expect them to result in anything actually happening.
> 
> If you want to do real work in this area, the klibc mailing list is the
> place to go: http://www.zytor.com/mailman/listinfo/klibc


Correct, though there is one thing I am thinking about adding to 2.6:

Support replacing "initrd=" with "initramfs=", so that bootloaders can 
pass a cpio image into the standard initrd memory space.

	Jeff

Re: Initramfs

[Bryan O'Sullivan]

On Thu, 2003-08-21 at 07:19, Jeff Garzik wrote:

> Support replacing "initrd=" with "initramfs=", so that bootloaders can 
> pass a cpio image into the standard initrd memory space.

That would be nice to have, but it would also increase the pressure to
fix the cpio unpacker.  At least right now, its deficiencies don't cause
many problems, because initramfs is less than convenient to use.

	<b

Re: Initramfs

[viro]

On Thu, Aug 21, 2003 at 11:28:10AM -0700, Bryan O'Sullivan wrote:
> On Thu, 2003-08-21 at 07:19, Jeff Garzik wrote:
> 
> > Support replacing "initrd=" with "initramfs=", so that bootloaders can 
> > pass a cpio image into the standard initrd memory space.
> 
> That would be nice to have, but it would also increase the pressure to
> fix the cpio unpacker.  At least right now, its deficiencies don't cause
> many problems, because initramfs is less than convenient to use.

RTFM.  cpio -o -H newc should be used to create an archive; _not_ the
"binary" format that is default.

Re: Initramfs

[Bryan O'Sullivan]

On Thu, 2003-08-21 at 12:03, viro@parcelfarce.linux.theplanet.co.uk
wrote:

> RTFM.  cpio -o -H newc should be used to create an archive; _not_ the
> "binary" format that is default.

There is no FM to R in this regard.

	<b

Re: Initramfs

[Willy Tarreau]

On Thu, Aug 21, 2003 at 12:57:34PM -0700, Bryan O'Sullivan wrote:
> On Thu, 2003-08-21 at 12:03, viro@parcelfarce.linux.theplanet.co.uk
> wrote:
> 
> > RTFM.  cpio -o -H newc should be used to create an archive; _not_ the
> > "binary" format that is default.
> 
> There is no FM to R in this regard.

Except if he meant "Reclaim The Future Manual"
:-)

Re: Initramfs

[viro]

On Thu, Aug 21, 2003 at 12:57:34PM -0700, Bryan O'Sullivan wrote:
> On Thu, 2003-08-21 at 12:03, viro@parcelfarce.linux.theplanet.co.uk
> wrote:
> 
> > RTFM.  cpio -o -H newc should be used to create an archive; _not_ the
> > "binary" format that is default.
> 
> There is no FM to R in this regard.

Ouch.  My apologies - I'd assumed that it got into the tree and hadn't
checked that.  Google for "initramfs buffer spec" will give the text
I had in mind.  Probably ought to go in Documentation/*, unless hpa
has any problems with it.  Peter?

Re: Initramfs

[Werner Almesberger]

Jeff Garzik wrote:
> Support replacing "initrd=" with "initramfs=", so that bootloaders can 
> pass a cpio image into the standard initrd memory space.

This sounds like a very good idea, yes.

Or, maybe even make it such that initramfs acts like a file system,
that will just de-cpio the content of a block device to a ramfs.

Pro:
 - requires less or no changes to existing initrd
 - one can experiment with initramfs loaded from other sources than
   an initrd

Contra: 
 - needs more infrastructure than plain initramfs

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/

Re: Initramfs

[H. Peter Anvin]

viro@parcelfarce.linux.theplanet.co.uk wrote:
> On Thu, Aug 21, 2003 at 12:57:34PM -0700, Bryan O'Sullivan wrote:
> 
>>On Thu, 2003-08-21 at 12:03, viro@parcelfarce.linux.theplanet.co.uk
>>wrote:
>>
>>>RTFM.  cpio -o -H newc should be used to create an archive; _not_ the
>>>"binary" format that is default.
>>
>>There is no FM to R in this regard.
> 
> Ouch.  My apologies - I'd assumed that it got into the tree and hadn't
> checked that.  Google for "initramfs buffer spec" will give the text
> I had in mind.  Probably ought to go in Documentation/*, unless hpa
> has any problems with it.  Peter?

I concur wholeheartedly.

	-hpa

Re: Initramfs

[Jeff Garzik]

Werner Almesberger wrote:
> Jeff Garzik wrote:
> 
>>Support replacing "initrd=" with "initramfs=", so that bootloaders can 
>>pass a cpio image into the standard initrd memory space.
> 
> 
> This sounds like a very good idea, yes.
> 
> Or, maybe even make it such that initramfs acts like a file system,
> that will just de-cpio the content of a block device to a ramfs.


initramfs _must_ act like a file system ;-)

Basically, instead of rd+ext2, you have rootfs.

	Jeff

Re: Initramfs

[Werner Almesberger]

Jeff Garzik wrote:
> initramfs _must_ act like a file system ;-)

Yes, yes :-) I mean, not only during operation, but also when
initializing (i.e. that it loads its data from a block device).

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/

Re: Initramfs

[H. Peter Anvin]

Followup to:  <3F44D504.7060909@pobox.com>
By author:    Jeff Garzik <jgarzik@pobox.com>
In newsgroup: linux.dev.kernel
>
> Bryan O'Sullivan wrote:
> > No.  initramfs is stuck in limbo at the moment, and early userspace is
> > unlikely to see any real work until 2.7.  Feel free to ask questions,
> > but don't expect them to result in anything actually happening.
> > 
> > If you want to do real work in this area, the klibc mailing list is the
> > place to go: http://www.zytor.com/mailman/listinfo/klibc
> 
> Correct, though there is one thing I am thinking about adding to 2.6:
> 
> Support replacing "initrd=" with "initramfs=", so that bootloaders can 
> pass a cpio image into the standard initrd memory space.
> 

Note that the initrd= option is actually a boot loader option, not a
kernel option, so the name of the option shouldn't change.

But yes, an initramfs image loaded into initrd space should be
unpacked *on top of* what's already compiled into the kernel.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
If you send me mail in HTML format I will assume it's spam.
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

initramfs

[Jacek Jabłoński]

Hello,
Do You know any tool to create initramfs (not initrd)?
If not, please tell me how to do that?
Jacek Jabłoński

Re: initramfs

[Wakko Warner]

Wakko Warner wrote:
> Lennart Sorensen wrote:
> > I didn't know you could use CPIO archives as initrd images.  I have used
> > gzip'd ext2 and cramfs (on Debian kernels only so far).  Actually I
> > didn't know cpio was even considered a filesystem (and hence would be
> > difficult to mount at all).
> 
> Apparently, initrd is just a name and a buffer.  Whatever it does with it is
> a different story.  If the buffer looks like a cpio archive, it mounts tmpfs
> as / and populates it from the archive.  No ramdisk driver, no filesystem
> driver required.

Unfortunately, I noticed that the ramdisk driver has to be compiled in (I
didn't try w/o initrd support).  Atleast I dropped ext2 from my compiled in
list (NO filesystems in my kernel!)

Now it would be nice if I could remove rd from the compiled in list as well
(even thought it would only save a few K)

> Unfortunately for me, it doesn't work.  I'm still trying to figure out how
> it works.

As I stated earlier it now works.  error with my archive.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: initramfs

[Wakko Warner]

Wakko Warner wrote:
> running cpio -tv, I see:
> ...
> -rwxr-xr-x   1 root     root       452508 May  5 14:33 bin/busybox
> ...
> -rwxr-xr-x   1 root     root         1328 May  9 15:46 init
> ...
> 
> Now I see a message saying:
> Kernel panic - not syncing: No init found.  Try passing init= option to kernel.

My fault. I haven't used cpio much.  The cpio archive contained only files,
no directories, thus there was no /bin to put /bin/busybox in.  I now have
it working.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: initramfs

[Wakko Warner]

Lennart Sorensen wrote:
> I didn't know you could use CPIO archives as initrd images.  I have used
> gzip'd ext2 and cramfs (on Debian kernels only so far).  Actually I
> didn't know cpio was even considered a filesystem (and hence would be
> difficult to mount at all).

Apparently, initrd is just a name and a buffer.  Whatever it does with it is
a different story.  If the buffer looks like a cpio archive, it mounts tmpfs
as / and populates it from the archive.  No ramdisk driver, no filesystem
driver required.

Unfortunately for me, it doesn't work.  I'm still trying to figure out how
it works.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: initramfs

[Lennart Sorensen]

On Wed, May 25, 2005 at 01:41:35PM -0400, Wakko Warner wrote:
> I'm having problems with this.  I apparently have a cpio archive that the
> kernel likes.  I am starting via grub with basically:
> kernel /mykernel
> initrd /mycpiofile
> 
> At first, I got "can't mount root".  A little reading in main.c has it
> looking for /init  (shouldn't this be /bin/init instead?)
> 
> I moved my ./bin/init to . in my init filesystem tree and recreated the
> cpio.  my ./init script is a "#!/bin/busybox ash" script.
> 
> running cpio -tv, I see:
> ...
> -rwxr-xr-x   1 root     root       452508 May  5 14:33 bin/busybox
> ...
> -rwxr-xr-x   1 root     root         1328 May  9 15:46 init
> ...
> 
> Now I see a message saying:
> Kernel panic - not syncing: No init found.  Try passing init= option to kernel.
> 
> I did that.  According to the source, init= is overridden when /init exists.
> 
> I'd like to get off the initrd ramdisk style to save some more on space.
> 
> I assume it is populating properly since also I don't see the initial console
> warning message.
> 
> Kernel: vanilla 2.6.12-rc4 compiled with -Os with debian gcc 3.3.5-1

I didn't know you could use CPIO archives as initrd images.  I have used
gzip'd ext2 and cramfs (on Debian kernels only so far).  Actually I
didn't know cpio was even considered a filesystem (and hence would be
difficult to mount at all).

Len Sorensen

initramfs

[Wakko Warner]

I'm having problems with this.  I apparently have a cpio archive that the
kernel likes.  I am starting via grub with basically:
kernel /mykernel
initrd /mycpiofile

At first, I got "can't mount root".  A little reading in main.c has it
looking for /init  (shouldn't this be /bin/init instead?)

I moved my ./bin/init to . in my init filesystem tree and recreated the
cpio.  my ./init script is a "#!/bin/busybox ash" script.

running cpio -tv, I see:
...
-rwxr-xr-x   1 root     root       452508 May  5 14:33 bin/busybox
...
-rwxr-xr-x   1 root     root         1328 May  9 15:46 init
...

Now I see a message saying:
Kernel panic - not syncing: No init found.  Try passing init= option to kernel.

I did that.  According to the source, init= is overridden when /init exists.

I'd like to get off the initrd ramdisk style to save some more on space.

I assume it is populating properly since also I don't see the initial console
warning message.

Kernel: vanilla 2.6.12-rc4 compiled with -Os with debian gcc 3.3.5-1

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals