Re: 2.4.1: cramfs and initrd
Mark van Walraven wrote:
>
> On Wed, Mar 28, 2001 at 09:29:14PM +1000, Herbert Xu wrote:
> > zhaoway <zw@debian.org> wrote:
> >
> > > Does anyone have this problem for kernel 2.4.1? When I compiled in
> > > cramfs, initrd cannot work. Kernel message screen just say:
> >
> > > wrong magic <== spit out by cramfs(?) which shouldn't be there in the
> > > 1st place?
>
> The kernel tries every registered partition driver to read the superblock
> of the initrd image. The cramfs driver disobeys the 'silent' flag passed
> to it (a bug) and grizzles that the superblock doesn't have the magic
> numbers expected of a cramfs superblock.
>
> > cramfs sets the block size to 4096 bytes, which breaks initrd because it was
> > read in 1024 byte blocks. This is worked around in kernel-source 2.4.2
> > where the rd block size defaults to 4096 if you've got cramfs enableed.
>
> I think the cure is worse than the disease. :-) Suddenly your 1k/block
> ext2 initrd fails to mount and the kernel panics without anything to
> tell you it's because the filesystem blocksize now no longer matches
> the new default ramdisk device blocksize ...
>
> You can either create the initrd filesystem with 4k blocks, or pass
> ramdisk_blocksize=1024 as a kernel boot parameter (assuming your ramdisk
> fs has 1k blocks), though if you do the latter, I don't think cramfs
> will work anyway. 4k blocks on an ext2 ramdisk probably isn't as bad as
> it sounds with regards to size - I imagine the wasted space compresses
> quite well.
>
> Regards,
>
> Mark.
>
Im thinking that iso9600 might be a good format for the initrd, because
the initrd will be compressed anyway cramfs doesnt save us anything on
the boot disk.
ISO9660 fs support adds less to the kernel size than any other fs.
It is much more likely that isofs support will be needed again (if
installing from cd), cramfs wont be wanted post boot.
On the downsize it is a bit more fiddling around to make the initrd as
iso, and i havent got any hard number to compare its overheads against
cramfs, ext2 etc, i suspect it would be good though.
Glenn
Reply to: