Re: Question regarding kernel policy: Why ext2 as module?
On Sun, Jul 18, 2004 at 07:05:20PM +1000, Andree Leidenfrost wrote:
> Dear list
>
> I'm the co-maintainer of the mindi/mondo packages, a disaster recovery
> suite. I am currently working on the packages of the new stable major
> release (In case anyone is interested, they can be found at
> http://www.desknow.com/desknow/directfiles/aleidenfrost/mr-debs-unofficial/index.html - feedback more than welcome.;-) )
>
> My problem is that things don't work with a stock Debian kernel, because
> the Debian stock kernel doesn't have ext2 compiled in (in fact i386 did
> last time I checked, but e.g. 2.6.6-k7 doesn't).
>
> The reason I need ext2 compiled into the kernel is that the first
> recover media created by mindi/mondo is bootable and contains an initrd
> image which is used as root filesystem. It needs to be writable, so it
> can't be cramfs (which is compiled into the kernel), but is in fact
> ext2. mindi uses the kernel that is currently running together with the
> currently loaded modules to ensure that recovery will succeed. (I'm
> aware that more sophisticated approaches are thinkable, but it generally
> works and this is how it is implemented upstream anyway.)
>
> So, I'm pretty much between chairs: my packages require ext2 to be
> compiled into the kernel, but the stock Debian kernel doesn't have it.
> Therefore I wonder what the reason is that ext2 is not compiled in by
> default and whether this could be changed. I would assume that other
> tools that try to use the currently running Debian kernel for disaster
> recovery or rescue media would face exactly the same problem: They would
> need a kernel that can access an initrd image that can be written to,
> i.e. cramfs doesn't do the trick and ext2 as the standard linux
> filesystem comes to mind.
>
> 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 ?
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.
Friendly,
Sven Luther
Reply to: