Re: Question regarding kernel policy: Why ext2 as module?
- To: Andree Leidenfrost <email@example.com>
- Cc: firstname.lastname@example.org
- Subject: Re: Question regarding kernel policy: Why ext2 as module?
- From: Sven Luther <email@example.com>
- Date: Sun, 18 Jul 2004 11:32:32 +0200
- Message-id: <20040718093232.GA7212@pegasos>
- In-reply-to: <firstname.lastname@example.org>
- References: <email@example.com>
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