Re: 2.4 -ac kernels with Adrian Bunk's potato packages?
On Wed, 31 Oct 2001 16:54, Eduard Bloch wrote:
> > > Sorry, that is not true: look in drivers/block/rd.c - in upstream
> > > source, the cramfs is not included in the list of autodetected
> > > filesystems. The needed modification is trivial, no idea why kernel
> > > guys droped the support.
> >
> > More than that is needed. Make merely that change and the result will
> > not be a system that is able to boot with a cramfs initrd.
>
> Eh, what?
>
> > Also once you get it working the kernel will still give errors if you
> > mount a cramfs file system on a running machine (instead of having it
> > only mount during the boot process).
>
> Eh, what are you talking about? Which errors? The only bug is the missing
> cramfs detection in the initrd code.
When I made such a patch to 2.4.12 it didn't give me a system that would boot
with CramFS.
> I cannot see why this should make
> later mount ability fail in any way.
I think it's a separate unrelated issue with Cramfs. It didn't seem to fail
to work, just logged lots of nasty messages to the kernel message buffer.
> > But when you have cramfs working you'll find that it results in larger
> > initrd images than using romfs and offers no benefits.
>
> Eh, what? The C in CramFS means compression. I did not know that any
> other common filesystem in 2.4 supports compression, do you? So why
> should it make larger images? I did allready hack mkinitrd to use
> genromfs, but I ended up with too big initrd images.
Generate a romfs image and run "gzip -9" on it and you get much better
compression. The kernel looks for a gzip signature and decompresses it if
necessary. It should even work with gzip compressed ext2 or minix file
systems too although I haven't tried them.
--
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page
Reply to: