Re: Question regarding kernel policy: Why ext2 as module?
On Sun, 2004-07-18 at 21:28, Sven Luther wrote:
> On Sun, Jul 18, 2004 at 08:58:00PM +1000, Andree Leidenfrost wrote:
> > Hi Sven
> >
> > First of all thanks a lot for your response!
> >
> > On Sun, 2004-07-18 at 19:32, Sven Luther wrote:
> > > On Sun, Jul 18, 2004 at 07:05:20PM +1000, Andree Leidenfrost wrote:
> > > [most of my original posting removed]
> > > >
> > > > I've looked into using a bare-bones cramfs initrd image that would only
> > > > load the ext2 module, mount the actual image via the loop device and do
> > > > a pivot_root to that. But apart from the fact that it would require
> > > > substantial and hard to justify changes upstream, I've really hit a
> > > > brickwall because cramfs only supports files < 16MB and my image is
> > > > substantially larger (~ 42MB).
> > >
> > > Could it be possible to boot into a minimal initrd, as one generated by
> > > mkinitrd for example, and then use this to mount the larger ramdisk into
> > > one of the /dev/ram devices or something, and then pivot_root into this ?
> >
> > The chief problem seems to be accessing the image for the larger
> > ramdisk: If I want to mount it, it needs to be accessible as a file by
> > mount. Therefore it needs to be part of the initial (cramfs) initrd
> > image. This in turn is where I have a problem because cramfs only
> > supports files up to 16MB. Maybe I'm overlooking something very obvious
> > here...
>
> Where is all this provided ? On a CD or something such ? Have you looked
> at how the liveCD stuff does it ?
Yep, it's on a CD. Might look at the liveCD stuff. Thanks for the hint.
> > > This should be the same kind of stuff that is already done with the
> > > initrd kernels, except you would need to add some script hook to load
> > > the ramdisk.
> >
> > I've looked at the initrd image that comes with the 2.6.6-k7 kernel.
>
> No, look at the mkinitrd manpage and source, not the initrd. In
> particular it has hooks to running user selected scripts.
I guess my real problem is getting the second image into the cramfs
image (16MB file size limit, cf. above). Francesco in his post probably
holds the key: I've tried cpio and that works. Yeehah!
> > What linuxrc seems to be doing is resetting the root filesystem to
> > what's configured in the kernel. I can't see any use of a secondary
>
> you need to mount the ramdisk somehow, and then pass it the
> root=/dev/mem or whatever arg, i think, Not sure, i am no ramdisk
> expert.
> > ramdisk. Also, I've looked at Debian Installer a few months ago. That
> > also uses a ext2 initrd image If I'm not mistaken. Where would I be able
>
> Nope, don't think so.
I think it does. From the daily sarge netinst CD 18 Jul 04:
aurich:/tmp# gunzip initrd.gz
aurich:/tmp# file initrd
initrd: Linux rev 0.0 ext2 filesystem data
Which brings me back to one of my original points: Why do the i386
kernels have ext2 compiled in and the architecture-optimised kernels
don't? Is the reason maybe that the Debian Installer needs this?
As a side note, I'm just trying to understand why I should invest
substantial amounts of work only because we don't have ext2 compiled
into the standard kernels. Time, I might add, that I could possibly
better spend on more Debian Installer testing. ;-)
> > to see the use of a secondary ramdisk from within a primary initrd
> > image?
>
> No idea.
>
> Friendly,
>
> Sven Luther
Thanks a lot & best regards
Andree
--
Andree Leidenfrost
Sydney - Australia
Reply to: