On 17/04/15 06:00, Jude Nelson wrote:
> Hi Anto,
>
> I just committed preliminary support for using vdevd with devtmpfs.
> vdevd should automatically detect whether or not devtmpfs is mounted
> on /dev, and nevertheless run device setup scripts (by using its own
> device metadata tree in /dev/vdev/ to see whether or not the device
> was actually processed).
>
> NB for developers: this problem isn't specific to Linux--I expect to
> encounter it with FreeBSD as well, since it has a full-blown in-kernel
> devfs. vdevd will keep track of "OS quirks" in the future--one of
> which is the "Device Already Exists" quirk, whereby vdevd simply
> expects the OS to provide the device file (regardless of the
> mechanism). The Linux-specific vdevd back-end now checks to see if
> vdevd will create files on a devtmpfs filesystem, and enables that
> quirk if so.
>
> Funny, undocumented (!!) discovery: the devtmpfs filesystem type (see
> statfs(2)) is the same (!!) as the tmpfs filesystem type, despite
> being a fundamentally different filesystem. I'm surprised that this
> wasn't caught during the devtmpfs code review--guess I'll have to file
> a bug report. Anyway, if you find yourself wondering why vdev has to
> detect devtmpfs by parsing /proc/mounts and verifying that the
> realpath of the mountpoint is the same as or is a subdirectory of a
> devtmpfs mountpoint, that's why--we (currently) can't rely on the
> f_fsid in statfs(2) or statvfs(2).
>
> Thanks,
> Jude
>

Hello Jude,

I just realised that you updated the installation guide on
https://github.com/jcnelson/vdev/blob/master/INSTALL.md, with
update-rc.d command to disable udev. I just tried to boot using vdev's
initrd and init with /etc/init.d/udev disabled on /etc/runlevel.conf. I
also tried to use the init from initramfs-tools with vdev's initrd. But
the results are the same as the previous one, which logs I sent out
earlier. Please just let me know if you need more information related to
that logs.

Cheers,

Anto