[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Question regarding kernel policy: Why ext2 as module?



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).

So unless, Debian kernels come with ext2 compiled in, all I can do is to
tell users of the package that they have to recompile the kernel to
actually be able to use it. This is quite unsatisfactory in general, and
in particular because I would really like to try and lower the threshold
for people to be able to use it, because I believe that making backups
or distaster recovery media should be easier in Debian.

Having said all that, I'm sure there is a reason why ext2 is not
compiled in, and I am also aware that changes to the kernel are probably
not made that easily - especially not if the requester is just some
package co-maintainer guy. But it would be great if you could consider
my case and/or let me know of other ways to work around the issue.

Best regards
Andree
-- 
Andree Leidenfrost
Sydney - Australia



Reply to: