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
[email protected]
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
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
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
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.
On Thu, 2003-08-21 at 12:03, [email protected]
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
On Thu, Aug 21, 2003 at 12:57:34PM -0700, Bryan O'Sullivan wrote:
> On Thu, 2003-08-21 at 12:03, [email protected]
> 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"
:-)
On Thu, Aug 21, 2003 at 12:57:34PM -0700, Bryan O'Sullivan wrote:
> On Thu, 2003-08-21 at 12:03, [email protected]
> 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?
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 [email protected] /
/_http://www.almesberger.net/____________________________________________/
[email protected] wrote:
> On Thu, Aug 21, 2003 at 12:57:34PM -0700, Bryan O'Sullivan wrote:
>
>>On Thu, 2003-08-21 at 12:03, [email protected]
>>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
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
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 [email protected] /
/_http://www.almesberger.net/____________________________________________/
Followup to: <[email protected]>
By author: Jeff Garzik <[email protected]>
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
--
<[email protected]> at work, <[email protected]> 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