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
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
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
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
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
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
> 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.
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
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
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
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
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
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
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
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