From: Rob Landley <rob@landley.net>
To: Robert Schwebel <r.schwebel@pengutronix.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: initramfs for /dev/console with udev?
Date: Thu, 3 Nov 2005 11:38:09 -0600 [thread overview]
Message-ID: <200511031138.10414.rob@landley.net> (raw)
In-Reply-To: <20051103064727.GR23316@pengutronix.de>
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
next prev parent reply other threads:[~2005-11-03 17:38 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-02 22:20 initramfs for /dev/console with udev? Robert Schwebel
2005-11-03 3:40 ` Rob Landley
2005-11-03 6:47 ` Robert Schwebel
2005-11-03 17:38 ` Rob Landley [this message]
2005-11-03 18:51 ` Robert Schwebel
2005-11-03 19:13 ` Rob Landley
2005-11-03 19:57 ` Roland Dreier
2005-11-03 21:00 ` Rob Landley
2005-11-03 21:29 ` Rob Landley
2005-11-04 21:39 ` Martin Schlemmer
2005-11-04 23:10 ` Rob Landley
2005-11-04 23:11 ` Rob Landley
2005-11-05 0:26 ` Martin Schlemmer
2005-11-05 2:56 ` Rob Landley
2005-11-03 21:41 ` Rob Landley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200511031138.10414.rob@landley.net \
--to=rob@landley.net \
--cc=linux-kernel@vger.kernel.org \
--cc=r.schwebel@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox