public inbox for linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox