I noticed that here,
http://penguinppc.org/embedded/howto/root-filesystem.html
it says:
It turns out that cramfs is not supported for a root fs or initrd.
Basically, the kernel checks a hardcoded list of supported
filesystems and if the MAGIC number doesn't match it bails.
Then, a couple lines later it says this, which clearly implies
a read-only cramfs root fs is possible::
ramfs from the 2.4 kernel is a simple filesystem ideal for use in a
ramdisk. It can be used in combination with a cramfs read-only root
filesystem, to mount writable filesystems on /tmp and /var, which
typically need to be writable. This combination is ideal for
systems which don't require persistent storage.
So, I figured I'd try cramfs as a root fs and see if I'm lucky
and the first statement is just a mistake, and I get:
RAMDISK: Compressed image found at block 0 Freeing initrd memory: 1270k freed cramfs: wrong magic Kernel panic: VFS: Unable to mount root fs on 01:00 <0>Rebooting in 180 seconds..
Well, it appears maybe the first statement is correct.
Then again, the message seems to be coming from the cramfs
part of the system...
So when I made my cramfs, I used mkcramfs which I got today (jun 24 2002)
from sourceforge. I noticed older versions had some notes about endianness.
This version seems to say that little-endian is the proper format for the
filesystem data, and this is what kind of cramfs it makes and the kernel
on a big endian machine like mine needs to do the necessary byte swapping
to handle it. Also, I created the cramfs on an intel box (little endian)
so in any case the fs is little endian.
Does the linuxppc_2_4_devel kernel from bitkeeper
handle little-endian cramfs filesystems? Or is there
a patch for this? Or a patch to mkcramfs to make it
create a big-endian cramfs (despite threads I read saying
this is the wrong way to proceed.)
Or am I on the wrong track completely in trying to use
cramfs for a root filesystem?
Thanks,
-- steve
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
It looks like you still have an initrd. Don't try running cramfs as an
initrd. I don't know if anything has changed in later versions of 2.4
but earlier ones used a 1k blocks size for the ramdisk and even if you
tried changing the rd blocksize to 4k to match cramfs it still didn't
work properly ...
There were patches floating around for building a big-endian cramfs,
rather than fixing the cramfs implemention to convert to little endian.
I don't know if newer versions of cramfs support explicit little
endian rather than native endian. I can send you a version of mkcramfs
with the swap endian flag if you want.
I'm in the process of getting ramfs to work with cramfs on my system as
we speak.
david
Stephen Cameron wrote:I noticed that here,
http://penguinppc.org/embedded/howto/root-filesystem.html
it says:
quoted
It turns out that cramfs is not supported for a root fs or initrd.
Basically, the kernel checks a hardcoded list of supported
filesystems and if the MAGIC number doesn't match it bails.
Then, a couple lines later it says this, which clearly implies
a read-only cramfs root fs is possible::
quoted
ramfs from the 2.4 kernel is a simple filesystem ideal for use in a
ramdisk. It can be used in combination with a cramfs read-only root
filesystem, to mount writable filesystems on /tmp and /var, which
typically need to be writable. This combination is ideal for
systems which don't require persistent storage.
So, I figured I'd try cramfs as a root fs and see if I'm lucky
and the first statement is just a mistake, and I get:
RAMDISK: Compressed image found at block 0 Freeing initrd memory: 1270k freed cramfs: wrong magic Kernel panic: VFS: Unable to mount root fs on 01:00 <0>Rebooting in 180 seconds..
Well, it appears maybe the first statement is correct.
Then again, the message seems to be coming from the cramfs
part of the system...
So when I made my cramfs, I used mkcramfs which I got today (jun 24 2002)
from sourceforge. I noticed older versions had some notes about endianness.
This version seems to say that little-endian is the proper format for the
filesystem data, and this is what kind of cramfs it makes and the kernel
on a big endian machine like mine needs to do the necessary byte swapping
to handle it. Also, I created the cramfs on an intel box (little endian)
so in any case the fs is little endian.
Does the linuxppc_2_4_devel kernel from bitkeeper
handle little-endian cramfs filesystems? Or is there
a patch for this? Or a patch to mkcramfs to make it
create a big-endian cramfs (despite threads I read saying
this is the wrong way to proceed.)
Or am I on the wrong track completely in trying to use
cramfs for a root filesystem?
Thanks,
-- steve
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Hi Stephen,
I have actually been using a cramfs initrd reliably for about 2
years. You do need a kernel patch to add cramfs to the list of
filesystems to check for in the initrd, also my patch forces the
blocksize of the initrd to 4K if it finds that it contains cramfs.
(I unfortunately don't have a publicly accessible web page to
stick this patch, so I'll attach it at the end of this email).
I have also previously posted a patch to mkcramfs to swap
endianness on a cramfs filesystem (this is also what I do,
create a PPC big endian cramfs using a little endian Intel PC).
I have posted this a couple of times, here's a link to the
most recent:
http://lists.linuxppc.org/linuxppc-embedded/200206/msg00128.html
These two patches should get you going with a cramfs initrd.
Good luck!
Steve
David Blythe wrote:
It looks like you still have an initrd. Don't try running cramfs as an
initrd. I don't know if anything has changed in later versions of 2.4
but earlier ones used a 1k blocks size for the ramdisk and even if you
tried changing the rd blocksize to 4k to match cramfs it still didn't
work properly ...
There were patches floating around for building a big-endian cramfs,
rather than fixing the cramfs implemention to convert to little endian.
I don't know if newer versions of cramfs support explicit little
endian rather than native endian. I can send you a version of mkcramfs
with the swap endian flag if you want.
I'm in the process of getting ramfs to work with cramfs on my system as
we speak.
david
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Steve Hein (ssh@sgi.com) Engineering Diagnostics/Software
Silicon Graphics, Inc.
1168 Industrial Blvd. Phone: (715) 726-8410
Chippewa Falls, WI 54729 Fax: (715) 726-6715
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~