Bug 4632 - udev 182 init script should mount devtmpfs instead tmpfs
Summary: udev 182 init script should mount devtmpfs instead tmpfs
Status: RESOLVED FIXED
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: core (show other bugs)
Version: unspecified
Hardware: All Multiple
: Medium major
Target Milestone: 1.5 M2
Assignee: Saul Wold
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2013-06-10 17:18 UTC by Alex Olson
Modified: 2013-07-08 10:41 UTC (History)
2 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: ---


Attachments
suggested fix (625 bytes, text/plain)
2013-06-10 17:18 UTC, Alex Olson
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Olson 2013-06-10 17:18:38 UTC
Created attachment 1255 [details]
suggested fix

Since udev 172, the 'mknod' logic was removed from udev. This means /dev is now required to be a devtmpfs filesystem (maintained by the kernel).    If the root filesystem is a ramdisk,  the kernel's auto-mount of /dev doesn't activate since there is no rootfs to actually mount... 

The bug causes an unusuable system as /dev doesn't contain even basic nodes required to even get a login prompt.


The Yocto  udev/init script mounts tmpfs if it does not detect tmpfs or devtmpfs mounted at /dev.  This appears to be  outdated logic that is no longer correct.

I believe the Yocto udev init script should be checking and mounting only 'devtmpfs' on dev.  (But I am not a udev expert).  See attached patch for a suggestion.
Comment 1 Saul Wold 2013-06-10 22:58:39 UTC
This looks like a good patch, if you would please submit a proper patch to list, please do so, otherwise I can put this patch in.
Comment 2 Alex Olson 2013-06-25 20:15:36 UTC
(In reply to comment #1)
> This looks like a good patch, if you would please submit a proper patch to
> list, please do so, otherwise I can put this patch in.

I submitted it today to the OE-core list and will monitor the thread.
http://lists.openembedded.org/pipermail/openembedded-core/2013-June/080311.html