trinux-talk

[Trinux-talk] Alternative kernels and trinux-uml

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

Hi,

I've been trying to get the initrd from trinux-uml-0.1.tgz to work with
another kernel which has both CONFIG_BLK_DEV_RAM and CONFIG_BLK_DEV_INITRD
configured, the minix fs mounts, but for some reason an initial console
can't be found, and this isn't a devfs issue either since nomount is used.

Usually, in a situation like this it would be safe to assume that
something is amiss in the initrd, but this is definitely not the case, and
the initrd does work properly with the kernel which comes with trinux-uml. 
I thought maybe it was a compiler issue so I made a uml (2.4.17-5um) with
the same compiler used to make the trinux-uml kernel, but I still had the
same results.

This leads me to suspect that it is a configuration conflict.  Could you
please send me the .config you used for the trinux-uml kernel?  It would
also be a good idea to include this .config with the trinux-uml package. 

The kernel which ships with gbootroot (gbootroot.sf.net) exhibits the same
problem, and the config used to make this kernel is included.  I am
thinking that it may be something simple causing this problem. 

Thanks,


Jonathan


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. 

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

[Matthew F. <mf...@ci...>]

Hi Jonathan,

Based on the traffic from uml mailing list I think the initrd is broken in
the latest release. I had similar problems and Bill Burdick's kernel was
the only one I could get working. I also tried multiple compilers and
glibc's, too.

I have the config on my laptop at work, but the solution is probably to go
back a few releases of UML and not use the latest.

- mdf

>
> Hi,
>
> I've been trying to get the initrd from trinux-uml-0.1.tgz to work with
> another kernel which has both CONFIG_BLK_DEV_RAM and CONFIG_BLK_DEV_INITRD
> configured, the minix fs mounts, but for some reason an initial console
> can't be found, and this isn't a devfs issue either since nomount is used.
>
> Usually, in a situation like this it would be safe to assume that
> something is amiss in the initrd, but this is definitely not the case, and
> the initrd does work properly with the kernel which comes with trinux-uml.
> I thought maybe it was a compiler issue so I made a uml (2.4.17-5um) with
> the same compiler used to make the trinux-uml kernel, but I still had the
> same results.
>
> This leads me to suspect that it is a configuration conflict.  Could you
> please send me the .config you used for the trinux-uml kernel?  It would
> also be a good idea to include this .config with the trinux-uml package.
>
> The kernel which ships with gbootroot (gbootroot.sf.net) exhibits the same
> problem, and the config used to make this kernel is included.  I am
> thinking that it may be something simple causing this problem.
>
> Thanks,
>
>
> Jonathan
>
>
> 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.
>
>
>
>
>
> _______________________________________________
> Trinux-talk mailing list
> Tri...@li...
> https://lists.sourceforge.net/lists/listinfo/trinux-talk
>

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

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

On Sun, 10 Feb 2002, Matthew Franz wrote:

> 
> Hi Jonathan,
> 
> Based on the traffic from uml mailing list I think the initrd is broken in
> the latest release. I had similar problems and Bill Burdick's kernel was
> the only one I could get working. I also tried multiple compilers and
> glibc's, too.

Yes, there was a segv problem with 2.4.17-10um, but Jeff provided a
solution for that.

We'll have to find out what Bill did differently, because I used the same
compiler (2.96 20000731), uml patch (2.4.17-5um), and perhaps the same
glibc (2.2.4) that he used to create the successful kernel included with
trinux-uml.

> I have the config on my laptop at work, but the solution is probably to go
> back a few releases of UML and not use the latest.

Hopefully, the mystery lies within the config, unless, there were some
additional alterations to the kernel code. 

> > Hi,
> >
> > I've been trying to get the initrd from trinux-uml-0.1.tgz to work with
> > another kernel which has both CONFIG_BLK_DEV_RAM and CONFIG_BLK_DEV_INITRD
> > configured, the minix fs mounts, but for some reason an initial console
> > can't be found, and this isn't a devfs issue either since nomount is used.
> >
> > Usually, in a situation like this it would be safe to assume that
> > something is amiss in the initrd, but this is definitely not the case, and
> > the initrd does work properly with the kernel which comes with trinux-uml.
> > I thought maybe it was a compiler issue so I made a uml (2.4.17-5um) with
> > the same compiler used to make the trinux-uml kernel, but I still had the
> > same results.
> >
> > This leads me to suspect that it is a configuration conflict.  Could you
> > please send me the .config you used for the trinux-uml kernel?  It would
> > also be a good idea to include this .config with the trinux-uml package.
> >
> > The kernel which ships with gbootroot (gbootroot.sf.net) exhibits the same
> > problem, and the config used to make this kernel is included.  I am
> > thinking that it may be something simple causing this problem.
> >
> > Thanks,
> >
> >
> > Jonathan
> >
> >
> > 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.
> >
> >
> >
> >
> >
> > _______________________________________________
> > Trinux-talk mailing list
> > Tri...@li...
> > https://lists.sourceforge.net/lists/listinfo/trinux-talk
> >
> 

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

[Bill B. <bi...@ap...>]

The problem might be in the args you're passing to the kernel.  Here are
the command line args I'm using (from my run script):

umid=bob initrd=initrd root=/dev/ram0 umlpacks=$dir/$disk eth0=daemon
eth1=daemon $args

umid -- identifies this instances name for uml_mconsole
initrd	-- identifies initrd file
	-- note that you need this one, NOT init=
	-- this could be your problem right here
root=/dev/ram0 -- identifies the device for initrd
umlpacks=$dir/$disk -- stuff for my linuxrc
eth0=daemon -- ethernet device.  run uml_switch for this to work.
eth1=daemon -- ethernet device


Also, you must make sure that initrd and minix are compiled into the
kernel (not as modules), and make sure that the ram dev size is big
enough (I use 7168)


On Sun, 2002-02-10 at 17:25, Jonathan Rosenbaum wrote:
> Hi,exec ../linux 
> 
> I've been trying to get the initrd from trinux-uml-0.1.tgz to work with
> another kernel which has both CONFIG_BLK_DEV_RAM and CONFIG_BLK_DEV_INITRD
> configured, the minix fs mounts, but for some reason an initial console
> can't be found, and this isn't a devfs issue either since nomount is used.
> 
> Usually, in a situation like this it would be safe to assume that
> something is amiss in the initrd, but this is definitely not the case, and
> the initrd does work properly with the kernel which comes with trinux-uml. 
> I thought maybe it was a compiler issue so I made a uml (2.4.17-5um) with
> the same compiler used to make the trinux-uml kernel, but I still had the
> same results.
> 
> This leads me to suspect that it is a configuration conflict.  Could you
> please send me the .config you used for the trinux-uml kernel?  It would
> also be a good idea to include this .config with the trinux-uml package. 
> 
> The kernel which ships with gbootroot (gbootroot.sf.net) exhibits the same
> problem, and the config used to make this kernel is included.  I am
> thinking that it may be something simple causing this problem. 
> 
> Thanks,
> 
> 
> Jonathan
> 
> 
> 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. 
> 
> 
> 
> 
> 
> _______________________________________________
> Trinux-talk mailing list
> Tri...@li...
> https://lists.sourceforge.net/lists/listinfo/trinux-talk
-- 
	Bill Burdick
	Bi...@ap...

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

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

On 11 Feb 2002, Bill Burdick wrote:

> The problem might be in the args you're passing to the kernel.  Here are
> the command line args I'm using (from my run script):
> 
> umid=bob initrd=initrd root=/dev/ram0 umlpacks=$dir/$disk eth0=daemon
> eth1=daemon $args
> 
> umid -- identifies this instances name for uml_mconsole

This shouldn't be a factor.

> initrd	-- identifies initrd file
> 	-- note that you need this one, NOT init=
> 	-- this could be your problem right here

Yes, I've been using initrd=initrd.

> root=/dev/ram0 -- identifies the device for initrd

Same here.

> umlpacks=$dir/$disk -- stuff for my linuxrc

A customized switch, but this only matters if the linuxrc is executed, and
this isn't happening with my kernel, though it does with your kernel.

> eth0=daemon -- ethernet device.  run uml_switch for this to work.
> eth1=daemon -- ethernet device
> 
> 
> Also, you must make sure that initrd and minix are compiled into the
> kernel (not as modules), and make sure that the ram dev size is big
> enough (I use 7168)

Initrd and minix are compiled into the kernel.

You should be able to pass ramdisk_size=7168, this may be the problem
because the RAMDISK doesn't seem to recognize this switch.  I'll try the
7168 compiled into the kernel to find out whether this makes a difference.
It may be a uml bug or just the lack of this feature.

If you can, please send or post that .config just in case it is a weird
interaction in the kernel.  Thanks. 
 
> On Sun, 2002-02-10 at 17:25, Jonathan Rosenbaum wrote:
> > Hi,exec ../linux 
> > 
> > I've been trying to get the initrd from trinux-uml-0.1.tgz to work with
> > another kernel which has both CONFIG_BLK_DEV_RAM and CONFIG_BLK_DEV_INITRD
> > configured, the minix fs mounts, but for some reason an initial console
> > can't be found, and this isn't a devfs issue either since nomount is used.
> > 
> > Usually, in a situation like this it would be safe to assume that
> > something is amiss in the initrd, but this is definitely not the case, and
> > the initrd does work properly with the kernel which comes with trinux-uml. 
> > I thought maybe it was a compiler issue so I made a uml (2.4.17-5um) with
> > the same compiler used to make the trinux-uml kernel, but I still had the
> > same results.
> > 
> > This leads me to suspect that it is a configuration conflict.  Could you
> > please send me the .config you used for the trinux-uml kernel?  It would
> > also be a good idea to include this .config with the trinux-uml package. 
> > 
> > The kernel which ships with gbootroot (gbootroot.sf.net) exhibits the same
> > problem, and the config used to make this kernel is included.  I am
> > thinking that it may be something simple causing this problem. 
> > 
> > Thanks,
> > 
> > 
> > Jonathan
> > 
> > 
> > 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. 
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Trinux-talk mailing list
> > Tri...@li...
> > https://lists.sourceforge.net/lists/listinfo/trinux-talk
> -- 
> 	Bill Burdick
> 	Bi...@ap...
> 

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

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

Actually, the ramdisk_size switch does work properly.  Compiling 7168 into
the kernel didn't help.  It has to be something, and I am suspicious that
this factor may be found in the config you are using. 

> > Also, you must make sure that initrd and minix are compiled into the
> > kernel (not as modules), and make sure that the ram dev size is big
> > enough (I use 7168)
> 
> Initrd and minix are compiled into the kernel.
> 
> You should be able to pass ramdisk_size=7168, this may be the problem
> because the RAMDISK doesn't seem to recognize this switch.  I'll try the
> 7168 compiled into the kernel to find out whether this makes a difference.
> It may be a uml bug or just the lack of this feature.
> 
> If you can, please send or post that .config just in case it is a weird
> interaction in the kernel.  Thanks. 
>  
> > On Sun, 2002-02-10 at 17:25, Jonathan Rosenbaum wrote:
> > > Hi,exec ../linux 
> > > 
> > > I've been trying to get the initrd from trinux-uml-0.1.tgz to work with
> > > another kernel which has both CONFIG_BLK_DEV_RAM and CONFIG_BLK_DEV_INITRD
> > > configured, the minix fs mounts, but for some reason an initial console
> > > can't be found, and this isn't a devfs issue either since nomount is used.
> > > 
> > > Usually, in a situation like this it would be safe to assume that
> > > something is amiss in the initrd, but this is definitely not the case, and
> > > the initrd does work properly with the kernel which comes with trinux-uml. 
> > > I thought maybe it was a compiler issue so I made a uml (2.4.17-5um) with
> > > the same compiler used to make the trinux-uml kernel, but I still had the
> > > same results.
> > > 
> > > This leads me to suspect that it is a configuration conflict.  Could you
> > > please send me the .config you used for the trinux-uml kernel?  It would
> > > also be a good idea to include this .config with the trinux-uml package. 
> > > 
> > > The kernel which ships with gbootroot (gbootroot.sf.net) exhibits the same
> > > problem, and the config used to make this kernel is included.  I am
> > > thinking that it may be something simple causing this problem. 
> > > 
> > > Thanks,
> > > 
> > > 
> > > Jonathan
> > > 
> > > 
> > > 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. 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > Trinux-talk mailing list
> > > Tri...@li...
> > > https://lists.sourceforge.net/lists/listinfo/trinux-talk
> > -- 
> > 	Bill Burdick
> > 	Bi...@ap...
> > 
> 
> 
> _______________________________________________
> Trinux-talk mailing list
> Tri...@li...
> https://lists.sourceforge.net/lists/listinfo/trinux-talk
> 

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

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

[Matthew F. <mf...@ci...>]

Thanks for tracking this down -- if there is enough interest I can create
a trinux-uml mailing list so we can take this off the trinux-talk list.

I really haven't done a formal release announcement but there might be
some interest in using a UML version of trinux for various things.

- mdf

> Date: Tue, 12 Feb 2002 01:06:31 -0500 (EST)
> From: Jonathan Rosenbaum <mma...@ya...>
> To: Bill Burdick <bi...@ap...>
> Cc: tri...@li..., Matthew Franz <mf...@ci...>
> Subject: Re: [Trinux-talk] (Solution) Alternative kernels and trinux-uml
>
> 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
>
>
>
> _______________________________________________
> Trinux-talk mailing list
> Tri...@li...
> https://lists.sourceforge.net/lists/listinfo/trinux-talk
>