Re: [Trinux-talk] (Solution) Alternative kernels and trinux-uml

[Jonathan R. <mma...@ya...>]

Hi trinux-talkers,

Yes, the solution did come from looking at Bill's kernel config
for his uml.  This is a really interesting problem.  What is happening is
that the order in which the VFS (Virtual File System) is being checked by
the kernel for filesystem type determines when the bug occurs. 

In this case cramfs is the culprit.  Notice what is happening below:

RAMDISK: Minix filesystem found at block 0
RAMDISK: Loading 4096 blocks [1 disk] into ram disk... done.
Freeing initrd memory: 4096k freed
cramfs: wrong magic
MINIX-fs: mounting unchecked file system, running fsck is recommended.
VFS: Mounted root (minix filesystem).
Warning: unable to open an initial console.
Kernel panic: No init found.  Try passing init= option to kernel.

When CONFIG_CRAMFS is made into a module or not included, the problem
disappears.  But when I ran the same uml kernel with cramfs on an initrd
which has ext2 fs, the problem also disappears.  This is because the
kernel uses an order when checking the fs.  You can look at this order in
/proc/filesystems. 

For instance:

nodev   rootfs
nodev   bdev
nodev   proc
nodev   sockfs
nodev   tmpfs
nodev   shm
nodev   pipefs
nodev   binfmt_misc
        ext2
        cramfs
        minix
        umsdos
        msdos

An initrd with minix will fail in the above situation, but an initrd with
ext2 won't.  So at this point if you want minix or msdos you can't have
cramfs included in the kernel.  This may be related to a documented bug in
cramfs, regardless, a simple solution would be to put cramf at the end of
the VFS check list since it would be nice to have cramfs and everything
else, too. 

Thanks for the config.  I am going to be posting a bug report at
user-mode-linux-devel, if you notice another fs causing this VFS problem
contact me, or add to this post. 

Regards,


Jonathan