All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.