From: ChenQi <Qi.Chen@windriver.com>
To: <yocto@yoctoproject.org>
Subject: Re: Issues creating /dev/ nodes in an initramfs
Date: Wed, 22 Oct 2014 16:05:05 +0800 [thread overview]
Message-ID: <54476531.3070900@windriver.com> (raw)
In-Reply-To: <CAP3LV0OBfM_S7cwr7tt9qae=m-iF6mvk-E65oromXk9EFnELQA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1915 bytes --]
On 10/20/2014 02:09 AM, Mitchell Skiba wrote:
> I've been building a kernel with an initramfs, by using
> INITRAMFS_IMAGE to specify a recipe that generates an image as a
> .cpio.gz archive. I've been having issues creating /dev/console (or
> any other device file) in the image. (The 3.14 kernel panics if
> /dev/console is not a character device.)
>
> It seems there is already a way to create dev nodes via the
> IMAGE_DEVICE_TABLE and IMAGE_DEVICE_TABLES variables. However this
> mechanism, through the makedevs utility, appears to require the
> building user to have permission to call mknod. (Makedevs ignores the
> return code from the mknod call, so it doesn't outright fail on the
> permissions error, but device files will not be created.)
>
> I've hacked around it in my image recipe by appending a step onto
> do_rootfs, but I'm not too happy with the way I did it. It seems like
> the proper way to fix this is to change the image commands in
> image_types.bbclass. However, each image type would need a different
> way of adding in the special files. (At this point I only care about
> cpio archives for the initramfs.)
>
>
> Does anyone have the current IMAGE_DEVICE_TABLE implementation
> working? (As in, is there something that I have missed?)
>
> I'm considering fixing this by changing the IMAGE_COMMAND_cpio
> function in image_typyes.bbclass to generate a cpio archive with only
> the contents described in IMAGE_DEIVCE_TABLE(S), then use the cpio
> utility's append mode to add in the rootfs contents. (It is simpler to
> create a new archive with a script than it is to append to an existing
> one, so I thought I'd let the cpio utility handle the archive appending.)
> Does this sound like a reasonable approach, and the correct place to
> fix it?
>
>
How about setting USE_DEVFS to "0" in your image recipe?
Regards,
Chen Qi
[-- Attachment #2: Type: text/html, Size: 3656 bytes --]
prev parent reply other threads:[~2014-10-22 8:03 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-19 18:09 Issues creating /dev/ nodes in an initramfs Mitchell Skiba
2014-10-22 8:05 ` ChenQi [this message]
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=54476531.3070900@windriver.com \
--to=qi.chen@windriver.com \
--cc=yocto@yoctoproject.org \
/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.