Pre-alpha testing on D945GCLF

[anto]

Hello Jude,

Since vdev installation change and remove some important files, like removing /etc/init.d/udev, so I started to test it on my D945GCLF mini-ITX PC which is only being used for testing. It is using the default Debian wheezy packages.

I pulled your latest commit, d402d54, then compiled and installed vdev as per your INSTALL.md instruction.

However, I cannot proceed further as the build of initramfs failed with the following messages:

root@devuan:/home/anto/packages/vdev# make initramfs
make -C example initramfs
make[1]: Entering directory `/home/anto/packages/vdev/example'
mkdir -p ./build/etc/
mkdir -p ./build/etc//vdev
mkdir -p ./build/etc//init.d
mkdir -p ./build/initramfs/
test -d /usr/share/initramfs-tools || (echo "You must install the initramfs-tools package" && exit 1)
test -e /sbin/vdevd || (echo "You must install vdevd first" && exit 1)
test -e /etc/vdev || (echo "You must install vdev's /etc files first" && exit 1)
cp -a /usr/share/initramfs-tools/* ./build/initramfs//
cp -a ./initramfs//scripts/* /etc/initramfs-tools/scripts/
cp -a ./initramfs//hooks/* /etc/initramfs-tools/hooks/
rm ./build/initramfs//scripts/init-top/udev ./build/initramfs//scripts/init-bottom/udev ./build/initramfs//hooks/udev ./build/initramfs//init
cp -a ./initramfs//init ./build/initramfs//
../tools//initramfs/mkinitramfs -t ./build/initramfs/ -o ./initrd.img-`uname -r`
E: /etc/initramfs-tools/hooks/vdev failed with return 1.
make[1]: *** [initramfs] Error 1
make[1]: Leaving directory `/home/anto/packages/vdev/example'
make: *** [initramfs] Error 2
root@devuan:/home/anto/packages/vdev# 

I am not sure how to give you more information about the error. So please let me know if you need more information.

Cheers,

Anto

[anto]

sysv-rc is being used on D945GCLF

root@d945gclf:~# apt-cache policy sysv-rc
sysv-rc:
  Installed: 2.88dsf-41+deb7u1
  Candidate: 2.88dsf-41+deb7u1
  Version table:
 *** 2.88dsf-41+deb7u1 0
        500 http://ftp.debian.org/debian/ wheezy/main amd64 Packages
        100 /var/lib/dpkg/status
root@d945gclf:~# 

[anto]

hostname was changed from "devuan" into "d945gclf"

[jcnelson]

Hi Anto,

Thanks for reporting this. Regarding that last command:

../tools//initramfs/mkinitramfs -t ./build/initramfs/ -o ./initrd.img-`uname -r`

Can you try running it manually from that directory, but with the -v flag? That will print out where it's failing.

Thanks!

[anto]

Hello Jude,

I have just tried to manually execute mkinitramfs with -v option, but it just tells me the following error:

E: /etc/initramfs-tools/hooks/vdev failed with return 1.

Please find the detail output on https://minifora.eu/public/devuan/vdev/manual_vdev_mkinitramfs_29Apr15_1744.log.gz.

Cheers,

Anto

[anto]

I just realised from the previous mkinitramfs output that I don't have iucode-tool package installed. I have installed it and re-run again mkinitramfs manually, but the result is exactly the same as before.

The different is only that after iucode-tool package installed, 3 microcodes are successfully added.

[jcnelson]

Hi Anto,

I haven't gotten a chance to look at this in depth. Let me try for this weekend.

-Jude

[jcnelson]

It looks like the vdev hook is failing after it tries to copy over /sbin/blkid (at line 42 in example/initramfs/hooks/vdev). The next set of binaries it tries and fails to copy are the LVM2 tools (i.e. /sbin/lvs, /sbin/pvs, /sbin/lvm).

Do you have those tools installed? Even if you don't have any LVM2 volumes, vdev's helpers will still need to use the LVM2 tools to check to see if a block device corresponds to a mapped volume.

[anto]

Hello Jude,

I am using the default minimal install of Debian wheezy on the PC to test your vdev. So no, there is no any kind of volume managers installed.

I think your scripts must check the availability of any binaries that vdev needs to load. Otherwise, there will be a lot of other failures due to the unavailability of the binaries that the users do not use.

Cheers,

Anto

[jcnelson]

Hi Anto,

I just add these checks in the initramfs hook, and it seems to work on my end. I'm going to test with file-rc next. Stay tuned...

-Jude

[anto]

Hello Jude,

I just pulled your latest commits, compile and install it as per your INSTALL.md. That means I didn't use vdev's init file under example/initramfs folder. I thought changing the current init with vdev's init was just for getting more debugging information. So if it is important to use vdev's init, please let me know that so I can try it and please include them into INSTALL.md.

On this mini-ITX board, I am using the minimal install of Debian wheezy with udev 175-7.2 and kernel 3.2.0-4-amd64 for this latest test. I included vdev's initrd into grub.cfg in recovery mode.

There seems to be a progress but I am still stuck at (initramfs) prompt. Please have a look on the vdev.boot.log, vdev-debugging.log and the log of compilation steps that I did on https://minifora.eu/public/devuan/vdev/vdev_debugging_logs_11May15.tar.gz.

Cheers,

Anto

[anto]

Sorry. I always forget to mention this. On Debian wheezy image, sysv-rc is being used instead of file-rc as below.

anto@d945gclf:~$ dpkg -l | grep "\-rc"
ii  sysv-rc                            2.88dsf-41+deb7u1             all          System-V-like runlevel change mechanism
anto@d945gclf:~$ 

[jcnelson]

I've confirmed that your problems are not due to the fact that you're running file-rc. I've tried it myself.

The problem is somewhere in the hacky initramfs script. This is not something I want to spend too much more time on, since it's not going to be used in production anyway (it's only for testing). What I need to be spending time on is packaging vdev so that when you install it with dpkg, the initramfs gets built as part of the installation process.

Thanks again for sending me the logs! I've gotten everything I can out of them. I'm going to close this issue, since I need to focus my time on getting a package ready instead.

[anto]

Hello Jude,

I don't think the problem is due to file-rc because on Debian wheezy install that I use on this mini-ITX board, systemd-rc is always being used. Please scroll up and see my previous comments.

Cheers,

Anto

[anto]

Hello Jude,

I just read your latest comment again, and I am sorry that I missed the word "NOT" in "your problems are not due to the fact that you're running file-rc".

Yes. I agree that testing using the complete package will be much better.

Cheers,

Anto