Hi Anto,

Sorry for the late reply; I had been super busy with work over the last 24
hours.

On Wed, Apr 15, 2015 at 2:43 PM, Anto <aryanto@???> wrote:

> On 15/04/15 05:20, Jude Nelson wrote:
>
>> Hi Anto,
>>
>>

>>     Don't you want to know my setup?

>>
>> Yes, eventually :) Â However, I don't want to waste your time either, at
>> least until I am more confident that the vdev installation process works
>> correctly.
>> Â
>>

>>     Maybe there are some packages required by your vdev, but I don't
>>     have them installed on my PC. Or maybe the kernel 3.18.10 that I
>>     use require different treatment, so I need to use different kernel
>>     version to test your vdev. I think knowing that could help you
>>     troubleshoot the problem. I am really not sure the requirements to
>>     properly test your vdev at this stage. So perhaps having the same
>>     setup as your development environment could avoid any unnecessary
>>     issues.

>>
>>
>> Well, there is one thing, if you're not too busy and it's not too
>> inconvenient for you. Vdev logs its early boot messages to
>> /run/vdev/vdevd.boot.log. If you could capture that file and send it to
>> me, that would not only help me understand your setup, but also why vdev is
>> misbehaving.
>>
>> Better yet, from the initramfs shell, if you could run "vdevd -v2 -f -c
>> /etc/vdev/vdevd.conf --once /dev > /tmp/vdev-debugging.log" and send me the
>> contents of /tmp/vdev-debugging.log, that will not only populate /dev
>> (assuming vdevd works correctly on that invocation), but also generate a
>> lot of extra debugging information in /tmp/vdev-debugging.log that would
>> help me diagnose the problem.
>>
>> No worries if you're too busy or have better things to do, though :)
>>
>> Thanks again,
>> Jude
>>
>
> Hello Jude,
>
> Let's just say that I am doing this egoistically all for myself. :) So I
> will devote my time to test your vdev as much as I can.
>
> Unfortunately, I cannot get the debugging log that you are after. Using
> kernel 3.18.10 and 3.18.11, the keyboard was not being detected after it
> got to the (initramfs) prompt, so I could not type anything. I managed to
> execute the debugging command using kernel 3.2.0, but it didn't seem to
> write the log to the /tmp directory. I think that is due the disk was not
> detected. I could only capture the last messages using the camera of my old
> mobile phone, so the quality is not good. Please have a look on
> https://minifora.eu/public/devuan/vdev/vdev_debugging_15Apr15_3.jpg.
>

Thanks for sending me the picture :)

The "rc = -17" error code means that the device exists (i.e. it's
-EEXIST). If you look in /dev from the initramfs, you should see a bunch
of device files.

The "rc = -2" at the end is a minor bug--vdevd didn't create /dev/pts/ptmx,
so it couldn't look up any metadata under /dev/vdev for it (i.e. rc == -2
is -ENOENT). That by itself shouldn't prevent root from mounting, though.

Do you have devtmpfs mounted on /dev? That could be the reason it doesn't
boot. At this time, if a device file exists that vdevd did not create,
vdevd won't run any helper scripts for it when it processes it. If your
root partition device file exists (e.g. /dev/sda1) since e.g. devtmpfs
created it, and your /etc/fstab identifies your root device partition using
a persistent path (e.g. /dev/disk/by-uuid/... or the like), vdevd won't
generate the persistent path, since that's done by the helper scripts for
/dev/sda1. As such, the script routines that parse /etc/fstab won't find
the root device, and the initramfs init will abort and drop you into a
shell.

For those who don't know, devtmpfs is basically a no-frills devfs that
modern udev now requires to be mounted to work correctly (i.e. devtmpfs
makes the device files these days, not udev). vdevd is currently not
compatible with devtmpfs, since it expects to create all the device files
itself. I'll update the Linux port to check of devtmpfs is mounted before
running, so vdevd will still run the helper scripts even if devtmpfs
created the device files already.


> I am not sure if this would be relevant. I am using file-rc instead of
> sysv-rc, so I didn't actually have any /etc/rc?.d directories. After the
> installation of the "example", /etc/rcS.d directory and S02vdev link under
> it got created. It could possibly be a problem later on, but I think I will
> worry about that (add it into /etc/runlevel.conf) after the boot process
> can reach it.
>

That is relevant! I had assumed in the Makefile that the user is using
sysv-rc, with the /etc/rc*.d/ directories.

I'm not familiar with using file-rc, but I don't think it's involved in the
initramfs boot process (at least, not directly). That's all controlled by
the files in /usr/share/initramfs-tools/. However, I'd be happy to patch
the Makefile in example/ to install the vdev init script correctly for
file-rc users :) I just need to know what to do--could you maybe send me a
small script that would achieve this?

Thanks again,
Jude