initramfs for /dev/console with udev?

initramfs for /dev/console with udev?

[Robert Schwebel]

Hi, 

If I understand Documentation/early-userspace/README correctly it should
be possible to solve the "unable to open an initial console" problem by
using a file like 

dir /dev 0755 0 0
nod /dev/console 0600 0 0 c 5 1
nod /dev/null 0600 0 0 c 1 3
dir /root 0700 0 0

and let CONFIG_INITRAMFS_SOURCE point to that file. The gpio archive is
built correctly with that, but my kernel doesn't seem to use it. 

Is anything else needed to use an initrd, like a command line argument?
My kernel boots from a nfs partition, so it sets nfsroot=... 

As I still get the "unable to open an initial console" message it looks
like the initramfs is not extracted, mounted or however that works. 

Robert 
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9

Re: initramfs for /dev/console with udev?

[Rob Landley]

On Wednesday 02 November 2005 16:20, Robert Schwebel wrote:
> Hi,
>
> If I understand Documentation/early-userspace/README correctly it should
> be possible to solve the "unable to open an initial console" problem by
> using a file like
>
> dir /dev 0755 0 0
> nod /dev/console 0600 0 0 c 5 1
> nod /dev/null 0600 0 0 c 1 3
> dir /root 0700 0 0
>
> and let CONFIG_INITRAMFS_SOURCE point to that file. The gpio archive is
> built correctly with that, but my kernel doesn't seem to use it.

1) You have no init in initramfs, so it goes ahead and mounts whatever root= 
points to over it.  I'm guessing that's where it's looking for /dev/console 
from.

2) What's the directory /root for?

> Is anything else needed to use an initrd, like a command line argument?
> My kernel boots from a nfs partition, so it sets nfsroot=...

Note that initramfs and initrd and very different things.

> As I still get the "unable to open an initial console" message it looks
> like the initramfs is not extracted, mounted or however that works.
>
> Robert

Rob

Re: initramfs for /dev/console with udev?

[Robert Schwebel]

On Wed, Nov 02, 2005 at 09:40:24PM -0600, Rob Landley wrote:
> > dir /dev 0755 0 0
> > nod /dev/console 0600 0 0 c 5 1
> > nod /dev/null 0600 0 0 c 1 3
> > dir /root 0700 0 0
> >
> > and let CONFIG_INITRAMFS_SOURCE point to that file. The gpio archive is
> > built correctly with that, but my kernel doesn't seem to use it.
> 
> 1) You have no init in initramfs, so it goes ahead and mounts whatever root= 
> points to over it. I'm guessing that's where it's looking for /dev/console 
> from.

Hmm, I thought something like that. That means that I do need a complete
klibc based early userspace, just to get these two device nodes? Seems
like I'll have to do some deeper investigation of klibc; last time I
looked it didn't even compile for ARCH=um.  

> 2) What's the directory /root for?

Just a relict from the default script; the first three lines should be
enought. But it shouldn't matter. 

> > Is anything else needed to use an initrd, like a command line argument?
> > My kernel boots from a nfs partition, so it sets nfsroot=...
> 
> Note that initramfs and initrd and very different things.

Is there any other known possibility to get just these two device nodes
in an automatic way? I'm trying to get rid of devfs, and udev works just
fine. The only thing not solved yet is how to get the beast started
without /dev/console and /dev/null. I don't want to create the nodes
statically, because that's only possible with root permissions. 

Some background: I'm building root filesystems for embedded systems with
PTXdist; the user is able to build the whole thing without root
permissions; either with a cross compiler and mount it via NFS or build
a JFFS2 image, or, with one switch, build and run it with an uml kernel.

I also tried ndevfs, just to get these two nodes, but I didn't find out
how to automatically mount it on boot yet. 

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9

Re: initramfs for /dev/console with udev?

[Rob Landley]

On Thursday 03 November 2005 00:47, Robert Schwebel wrote:
> On Wed, Nov 02, 2005 at 09:40:24PM -0600, Rob Landley wrote:
> > > dir /dev 0755 0 0
> > > nod /dev/console 0600 0 0 c 5 1
> > > nod /dev/null 0600 0 0 c 1 3
> > > dir /root 0700 0 0
> > >
> > > and let CONFIG_INITRAMFS_SOURCE point to that file. The gpio archive is
> > > built correctly with that, but my kernel doesn't seem to use it.
> >
> > 1) You have no init in initramfs, so it goes ahead and mounts whatever
> > root= points to over it. I'm guessing that's where it's looking for
> > /dev/console from.
>
> Hmm, I thought something like that. That means that I do need a complete
> klibc based early userspace, just to get these two device nodes?

No, you just need a statically linked init program.  (Which can be a shell 
script using a statically linked shell.  For testing purposes it can be 
statically linked against glibc, it'll just be a bloated pig.)

I have a /tools directory that builds uClibc executables.  (Like Linux From 
Scratch Chapter 5: extract it as /tools, export PATH=/tools/bin:$PATH, and 
then build software as normal.)  I can post that somewhere if you'd like, or 
you can extract it yourself out of my firmware linux build 
(http://www.landley.net/code/firmware)...

The switch_root program in busybox is still being banged on (by me).  I 
haven't quite worked out what to do about /dev/console yet.  I'm thinking if 
it's not there, keep the one from initramfs, but haven't implemented that 
tweak yet...

You also have the option of putting a single static node (console) in the /dev 
directory you're going to overmount.  It shouldn't hurt anything at present.  
And if nothing else, it'll confirm where it's trying to get the sucker 
from...

> Seems 
> like I'll have to do some deeper investigation of klibc; last time I
> looked it didn't even compile for ARCH=um.

Klibc didn't, or the kernel didn't?

> > 2) What's the directory /root for?
>
> Just a relict from the default script; the first three lines should be
> enought. But it shouldn't matter.
>
> > > Is anything else needed to use an initrd, like a command line argument?
> > > My kernel boots from a nfs partition, so it sets nfsroot=...
> >
> > Note that initramfs and initrd and very different things.
>
> Is there any other known possibility to get just these two device nodes
> in an automatic way?

>From initramfs, you could try:

mount -t sysfs /sys /sys
CDEV=`cat /sys/class/tty/console`
mknod /dev/console c $(echo $CDEV | sed 's/:.*//') \
  $(echo $CDEV | sed 's/.*://')

Bit of a chicken and egg problem if it refuses to run /init if it's not 
already there, though.  We're heading towards fully dynamic devices, but not 
quite there yet...

> I'm trying to get rid of devfs, and udev works just 
> fine. The only thing not solved yet is how to get the beast started
> without /dev/console and /dev/null. I don't want to create the nodes
> statically, because that's only possible with root permissions.

You don't need root access to make an initramfs configuration text file. :)

> Some background: I'm building root filesystems for embedded systems with
> PTXdist; the user is able to build the whole thing without root
> permissions; either with a cross compiler and mount it via NFS or build
> a JFFS2 image, or, with one switch, build and run it with an uml kernel.

I did something like that, only from scratch:
http://www.landley.net/code/firmware

I'll probably release version 0.8.10 later today.  (Still need to make an 
installer for the bootable version before I can call it 0.9...)

> I also tried ndevfs, just to get these two nodes, but I didn't find out
> how to automatically mount it on boot yet.

Presumably, either via initramfs or from init/main.c

> Robert

Rob

Re: initramfs for /dev/console with udev?

[Robert Schwebel]

On Thu, Nov 03, 2005 at 11:38:09AM -0600, Rob Landley wrote:
> No, you just need a statically linked init program.  (Which can be a shell 
> script using a statically linked shell.  For testing purposes it can be 
> statically linked against glibc, it'll just be a bloated pig.)

I'll try that. 

> You also have the option of putting a single static node (console) in the /dev 
> directory you're going to overmount.  It shouldn't hurt anything at present.  
> And if nothing else, it'll confirm where it's trying to get the sucker 
> from...

Well, that only works with root permissions.

> > Seems 
> > like I'll have to do some deeper investigation of klibc; last time I
> > looked it didn't even compile for ARCH=um.
> 
> Klibc didn't, or the kernel didn't?

The kernel works pretty good with 2.6.14; I can now do 'make world' in
PTXdist and get a rootfs for the ARM and do 'make world NATIVE=1' and
'make run NATIVE=1' and the same thing builds for x86 and starts in a
console. klibc didn't compile for ARCH=um. 

> > Is there any other known possibility to get just these two device nodes
> > in an automatic way?
> 
> From initramfs, you could try:
> 
> mount -t sysfs /sys /sys
> CDEV=`cat /sys/class/tty/console`
> mknod /dev/console c $(echo $CDEV | sed 's/:.*//') \
>   $(echo $CDEV | sed 's/.*://')
> 
> Bit of a chicken and egg problem if it refuses to run /init if it's not 
> already there, though.  We're heading towards fully dynamic devices, but not 
> quite there yet...

All that means that I need some libc and tools linking against it (or
static tools)... 

> > I'm trying to get rid of devfs, and udev works just 
> > fine. The only thing not solved yet is how to get the beast started
> > without /dev/console and /dev/null. I don't want to create the nodes
> > statically, because that's only possible with root permissions.
> 
> You don't need root access to make an initramfs configuration text file. :)

That was the idea ;) But it seems that if I buy initramfs I'll have to
buy doing the mknod and rootfs mounting stuff from early userspace as
well... 

> > Some background: I'm building root filesystems for embedded systems with
> > PTXdist; the user is able to build the whole thing without root
> > permissions; either with a cross compiler and mount it via NFS or build
> > a JFFS2 image, or, with one switch, build and run it with an uml kernel.
> 
> I did something like that, only from scratch:
> http://www.landley.net/code/firmware
> 
> I'll probably release version 0.8.10 later today.  (Still need to make an 
> installer for the bootable version before I can call it 0.9...)

I'll have a look :)

Thx, 

Robert 
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9

Re: initramfs for /dev/console with udev?

[Rob Landley]

On Thursday 03 November 2005 12:51, Robert Schwebel wrote:
> > > Seems
> > > like I'll have to do some deeper investigation of klibc; last time I
> > > looked it didn't even compile for ARCH=um.
> >
> > Klibc didn't, or the kernel didn't?
>
> The kernel works pretty good with 2.6.14; I can now do 'make world' in
> PTXdist and get a rootfs for the ARM and do 'make world NATIVE=1' and
> 'make run NATIVE=1' and the same thing builds for x86 and starts in a
> console. klibc didn't compile for ARCH=um.

I repeat my question: what is it that didn't compile, klibc or the kernel?

ARCH=um is an argument given to the kernel, yet because of an argument given 
to the kernel build, klibc didn't compile?    I'm confused.  Were you 
attempting to compile klibc under User Mode Linux, and the klibc build 
failed?  Or do you mean the kernel is what didn't compile, when you attempted 
to link user mode linux kernel against klibc?

(Yes, I confuse easily sometimes...)

> > > Is there any other known possibility to get just these two device nodes
> > > in an automatic way?
> >
> > From initramfs, you could try:
> >
> > mount -t sysfs /sys /sys
> > CDEV=`cat /sys/class/tty/console`
> > mknod /dev/console c $(echo $CDEV | sed 's/:.*//') \
> >   $(echo $CDEV | sed 's/.*://')
> >
> > Bit of a chicken and egg problem if it refuses to run /init if it's not
> > already there, though.  We're heading towards fully dynamic devices, but
> > not quite there yet...
>
> All that means that I need some libc and tools linking against it (or
> static tools)...

Well, it means you have to work around the deficiency in glibc that "hello 
world" is 400k statically linked.  This is a problem with glibc.  That's why 
I use uClibc instead.  (Full featured, you can build X and everything under 
it, and hello world is 7k statically linked, most of which is the iostream 
stuff.  If you use write() instead, with -Os stripped and statically linked, 
it's 4.2k.)

> > > I'm trying to get rid of devfs, and udev works just
> > > fine. The only thing not solved yet is how to get the beast started
> > > without /dev/console and /dev/null. I don't want to create the nodes
> > > statically, because that's only possible with root permissions.
> >
> > You don't need root access to make an initramfs configuration text file.
> > :)
>
> That was the idea ;) But it seems that if I buy initramfs I'll have to
> buy doing the mknod and rootfs mounting stuff from early userspace as
> well...

I added switch_root to busybox, and I'm planning on adding a stripped down 
udev as well, since this is likely to be a common need.  (Udev itself is 
already pretty small, but it requires fairly extensive configuration to get 
it to do anything, and wants to maintain a database.)

That said, for Firmware Linux, I'm working on a system that has the root 
partition (squashfs) appended to the kernel image.  So the kernel command 
line will have an argument ala FIRMWARE=hda1:/path/to/firmware.img so it can 
find itself, and then chops out the "hda1" from the environment variable, 
finds that under /sys/block, does the appropriate mknod based on what that 
dev file says, and mounts the new root.  This is a very small shell script.  
(The rest finds the firmware image, does an losetup -o $offset, mounts the 
loop device, and does the switch_root.)

> > > Some background: I'm building root filesystems for embedded systems
> > > with PTXdist; the user is able to build the whole thing without root
> > > permissions; either with a cross compiler and mount it via NFS or build
> > > a JFFS2 image, or, with one switch, build and run it with an uml
> > > kernel.
> >
> > I did something like that, only from scratch:
> > http://www.landley.net/code/firmware
> >
> > I'll probably release version 0.8.10 later today.  (Still need to make an
> > installer for the bootable version before I can call it 0.9...)
>
> I'll have a look :)

This morning I had it pointed out to me that it doesn't build an x86-64 
version yet.  In my defense, I haven't got that hardware.  (I have qemu 
though.  It's on my todo list...)

> Thx,
>
> Robert

Rob

Re: initramfs for /dev/console with udev?

[Roland Dreier]

 > On Thursday 03 November 2005 12:51, Robert Schwebel wrote:
 > > [...] klibc didn't compile for ARCH=um.

 > I repeat my question: what is it that didn't compile, klibc or the kernel?

come on, dude -- how much clearer can he be?

 - R.

Re: initramfs for /dev/console with udev?

[Rob Landley]

On Thursday 03 November 2005 13:57, Roland Dreier wrote:
>  > On Thursday 03 November 2005 12:51, Robert Schwebel wrote:
>  > > [...] klibc didn't compile for ARCH=um.
>  >
>  > I repeat my question: what is it that didn't compile, klibc or the
>  > kernel?
>
> come on, dude -- how much clearer can he be?

How do you feed ARCH=um to klibc?

Rob

Re: initramfs for /dev/console with udev?

[Rob Landley]

On Thursday 03 November 2005 13:57, Roland Dreier wrote:
>  > On Thursday 03 November 2005 12:51, Robert Schwebel wrote:
>  > > [...] klibc didn't compile for ARCH=um.
>  >
>  > I repeat my question: what is it that didn't compile, klibc or the
>  > kernel?
>
> come on, dude -- how much clearer can he be?

Ah, I see.  The linux kernel headers you feed it were from a kernel compiled 
with ARCH=um.  Right.  It's been a while since I tried feeding any libc 
actual kernel headers.  (I build uClibc against the cleaned up userspace ones 
here: http://ep09.pld-linux.org/~mmazur/linux-libc-headers/ .)

It's also been a while since I played with klibc, and I notice that it doesn't 
work with Maszur's headers.  (It sort of works, with lots of warnings, until 
about halfway through when it wants to touch "asm/signal.h", when Maszur's 
just has linux/signal.h, and symlinking the two still isn't happy because 
sigset_t is never defined...  In klibc there's definitions for ia64, sparc, 
and parisc.  But nothing for x86...

Ok, checking 2.6.14/include/asm-i386 it's an unsigned long, so typedef that...  
Nope, still not happy, wants numerous other symbols now...  Okay, try 
grabbing asm-i386/signal.h from libc...  And asm-generic/signal.h which 
_that_ includes...  And now there's a "previous declaration of 'wait3"' 
conflicting.  Beautiful...)

Ok, I remember why I stopped playing with klibc now.  It's still deep in 
alpha-test stage, requires way more incestuous knowledge of the kernel 
headers than anything not bundled with the kernel itself has any excuse for, 
and I'm still not sure what advantage it claims to have over uClibc except 
for being BSD licensed.

If you have to make it work, I'd suggest extracting a fresh kernel tarball, do 
"make allyesconfig" (without ARCH=um), and use _those_ headers.  Or just 
accept that it doesn't work and try uClibc. :)

Rob

Re: initramfs for /dev/console with udev?

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 2550 bytes --]

On Thu, 2005-11-03 at 15:29 -0600, Rob Landley wrote:
> On Thursday 03 November 2005 13:57, Roland Dreier wrote:
> >  > On Thursday 03 November 2005 12:51, Robert Schwebel wrote:
> >  > > [...] klibc didn't compile for ARCH=um.
> >  >
> >  > I repeat my question: what is it that didn't compile, klibc or the
> >  > kernel?
> >
> > come on, dude -- how much clearer can he be?
> 
> Ah, I see.  The linux kernel headers you feed it were from a kernel compiled 
> with ARCH=um.  Right.  It's been a while since I tried feeding any libc 
> actual kernel headers.  (I build uClibc against the cleaned up userspace ones 
> here: http://ep09.pld-linux.org/~mmazur/linux-libc-headers/ .)
> 
> It's also been a while since I played with klibc, and I notice that it doesn't 
> work with Maszur's headers.  (It sort of works, with lots of warnings, until 
> about halfway through when it wants to touch "asm/signal.h", when Maszur's 
> just has linux/signal.h, and symlinking the two still isn't happy because 
> sigset_t is never defined...  In klibc there's definitions for ia64, sparc, 
> and parisc.  But nothing for x86...
> 
> Ok, checking 2.6.14/include/asm-i386 it's an unsigned long, so typedef that...  
> Nope, still not happy, wants numerous other symbols now...  Okay, try 
> grabbing asm-i386/signal.h from libc...  And asm-generic/signal.h which 
> _that_ includes...  And now there's a "previous declaration of 'wait3"' 
> conflicting.  Beautiful...)
> 
> Ok, I remember why I stopped playing with klibc now.  It's still deep in 
> alpha-test stage, requires way more incestuous knowledge of the kernel 
> headers than anything not bundled with the kernel itself has any excuse for, 
> and I'm still not sure what advantage it claims to have over uClibc except 
> for being BSD licensed.
> 

Well, apparently the plan is to eventually bundle it with the kernel if
not mistaken.  Also, it have seen a stable release, and it works well
for what it was intended for, and still have a less footprint than
uClibc if space is really an issue.

> If you have to make it work, I'd suggest extracting a fresh kernel tarball, do 
> "make allyesconfig" (without ARCH=um), and use _those_ headers.  Or just 
> accept that it doesn't work and try uClibc. :)
> 

It does work, just need to be fixed up for ARCH=um compiled kernel.  I
did a quick hack to do this, but HPA don't like it (and I do not blame
him).  Can be found here:

http://bugs.gentoo.org/attachment.cgi?id=67478


-- 
Martin Schlemmer


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: initramfs for /dev/console with udev?

[Rob Landley]

On Friday 04 November 2005 15:39, Martin Schlemmer wrote:
> > Ok, I remember why I stopped playing with klibc now.  It's still deep in
> > alpha-test stage, requires way more incestuous knowledge of the kernel
> > headers than anything not bundled with the kernel itself has any excuse
> > for, and I'm still not sure what advantage it claims to have over uClibc
> > except for being BSD licensed.
>
> Well, apparently the plan is to eventually bundle it with the kernel if
> not mistaken.  Also, it have seen a stable release, and it works well
> for what it was intended for, and still have a less footprint than
> uClibc if space is really an issue.

*shrug*.  It only does static linking and uClibc can static link too.  But 
there are no plans to bundle uClibc with the kernel. :)

> > If you have to make it work, I'd suggest extracting a fresh kernel
> > tarball, do "make allyesconfig" (without ARCH=um), and use _those_
> > headers.  Or just accept that it doesn't work and try uClibc. :)
>
> It does work, just need to be fixed up for ARCH=um compiled kernel.  I
> did a quick hack to do this, but HPA don't like it (and I do not blame
> him).  Can be found here:
>
> http://bugs.gentoo.org/attachment.cgi?id=67478

And apparently one of the goals of the 2.6.14 release (or one of the dot 
releases after it) is working with klibc, so I'll wander back to playing with 
uClibc...

Rob

Re: initramfs for /dev/console with udev?

[Rob Landley]

On Friday 04 November 2005 17:10, Rob Landley wrote:

> And apparently one of the goals of the 2.6.14 release (or one of the dot

Of Mazur's header files...

Rob

Re: initramfs for /dev/console with udev?

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1250 bytes --]

On Fri, 2005-11-04 at 17:10 -0600, Rob Landley wrote:
> On Friday 04 November 2005 15:39, Martin Schlemmer wrote:
> > > Ok, I remember why I stopped playing with klibc now.  It's still deep in
> > > alpha-test stage, requires way more incestuous knowledge of the kernel
> > > headers than anything not bundled with the kernel itself has any excuse
> > > for, and I'm still not sure what advantage it claims to have over uClibc
> > > except for being BSD licensed.
> >
> > Well, apparently the plan is to eventually bundle it with the kernel if
> > not mistaken.  Also, it have seen a stable release, and it works well
> > for what it was intended for, and still have a less footprint than
> > uClibc if space is really an issue.
> 
> *shrug*.  It only does static linking and uClibc can static link too.  But 
> there are no plans to bundle uClibc with the kernel. :)
> 

It can link dynamic ...

-----
$ readelf -a /usr/lib64/klibc/bin/sh | grep -2 INTERP | tail -n 3
  INTERP         0x0000000000000190 0x0000000000400190 0x0000000000400190
                 0x000000000000002a 0x000000000000002a  R      1
      [Requesting program interpreter: /lib/klibc-zbHWOqxodx0Aind6t75AzMTNE9c.so]
-----


-- 
Martin Schlemmer


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: initramfs for /dev/console with udev?

[Rob Landley]

On Friday 04 November 2005 18:26, Martin Schlemmer wrote:
> > *shrug*.  It only does static linking and uClibc can static link too. 
> > But there are no plans to bundle uClibc with the kernel. :)
>
> It can link dynamic ...

Cool.  As I said, been a while...

Rob

Re: initramfs for /dev/console with udev?

[Rob Landley]

On Thursday 03 November 2005 13:57, Roland Dreier wrote:
>  > On Thursday 03 November 2005 12:51, Robert Schwebel wrote:
>  > > [...] klibc didn't compile for ARCH=um.
>  >
>  > I repeat my question: what is it that didn't compile, klibc or the
>  > kernel?
>
> come on, dude -- how much clearer can he be?

And confirming:

cd ~
tar xvjf linux-2.6.14.tar.bz2
cd linux-2.6.14
make allyesconfig
cd ~
tar xvzf klibc-1.1.tar.gz
cd klibc-1.1
ln -s ~/linux-2.6.14/include/asm-i386 include/asm
ln -s ~/linux-2.6.14/include/asm-generic/ include/asm-generic
ln -s ~/linux-2.6.14/include/linux include/linux
make  

Does indeed build klibc.

I get the strong feeling klibc-1.1 should be called klibc-2.6.14, but oh 
well...

Rob