On 2016-09-06 09:35, Khem Raj wrote: >> On Sep 4, 2016, at 1:25 PM, Stefan Agner <[email protected]> wrote: >> >> The kernel does not automatically mount devtmpfs when using initramfs >> based booting (even when using CONFIG_DEVTMPFS_MOUNT). If the rootfs >> is built with USE_DEVFS=1 (which is the default), the system ends up >> with a completely empty /dev to begin with. >> >> Busybox uses the first entry in inittab slightly different than >> other init systems: >> <id>: WARNING: This field has a non-traditional meaning for BusyBox init! >> >> The id field is used by BusyBox init to specify the controlling tty for >> the specified process to run on. The contents of this field are >> appended to "/dev/" and used as-is. >> >> Since /dev/null is not there yet, Busybox throws errors instead of >> executing the commands, and hence never mounts devtmpfs: >> init started: BusyBox v1.24.1 (2016-09-04 11:53:14 PDT) >> can't open /dev/null: No such file or directory >> can't open /dev/null: No such file or directory >> can't open /dev/null: No such file or directory >> can't open /dev/null: No such file or directory >> can't open /dev/null: No such file or directory >> can't open /dev/null: No such file or directory >> can't open /dev/null: No such file or directory >> >> Avoid this circular dependency by not specifing <id>. With that >> Busybox ends up using the stdio of the init process and executes >> the inittab just fine. > > This looks good. Have you also tested it when using busybox/mdev as main > init system just not in initramfs >
I remember that I tried it once with squashfs and ramdisk, which, as far as I can recall, behaves as if it is a regular rootfs wrt devtmpfs mount... -- Stefan -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
