[yocto] Issues creating /dev/ nodes in an initramfs

[ChenQi]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20141022/ac4c8e40/attachment.html>