It wasn't a network issue. It just so happened that I was merging the repository with amprolla during the night. I already signed it and uploaded to https://packages.gnuinos.org/merged an hour ago. Now It should work.

Gnuinos iso images have been updated today:

https://www.gnuinos.org/mirror/daedalus/runit

with a new version of vdev. The most important change is that vdev now is able to use the linux netlink connection as eudev does. Therefore, the use of the eventfs filesystem that provides an infrastructure for containers as well as for BSD systems -not implemented yet (bear in mind that netlink is linux specific)- is optional from now on.

On the other hand, libudev-compat has a dual behaviour: it may send udev devices through netlink or as a serialized device events to the eventfs filesystem depending on whether the eventfs filesystem is mounted at /dev/metadata/udev/events/serial. Thanks to this duality, you can change from eudev and vdev or vice versa just running apt-get install vdev or apt-get install eudev without the need of changing from libeudev to libudev-compat because eudev will work with the latter as well. Don't forget that eudev will rename your network devices.

All this said, I would like you to compare start-up times in both cases.

Ok, fsmithred, I didn't read your release notes before. Now I see that this is intended, but the packages increase the size of the image a lot. After removing them, I got a 466,7 MiB sized filesystem.

Security is complicated. Paraphrasing the Arch wiki, you can never make a system 100% secure unless you unplug the machine from all networks, turn it off, lock it in a safe, smother it in concrete and never use it.

The contents of the non-free part (i.e, the CPU-vendor-provided "opaque" update data) are unknown to debian. Why should I need to install them if the vendor doesn't tell me what bugs they're fixing? Debian argues that it's very difficult to know for sure whether you need a microcode update or not, but it is not safe at all to just ignore them or you could experience one of those unexplainable and infrequent issues.

"Privacy is complicated". I find this a less misleading sentence

For what it's worth, I've never install any microcode update (whatever the company) and I never had any problems. However, it doesn't mean that I am not discouraged. But rather I would prefer to give a try to some of the existing libre bootloaders. The current controversy around them left me somewhat confused though.

Another possible solution:

https://askubuntu.com/questions/1400034 … 404-rugged

You can verify this by the following way (you need to install check-dfsg-status):

# check-dfsg-status -s
No non-free or contrib packages installed on gnuinos!  You have completed the first step to enlightenment.

Bear in mind that the forced use of packages.gnuinos.org in APT's sources.list during the installation makes sure not installing non-free firmware just because sections like contrib, non-free or non-free-firmware don't exist in this archive (only main, main/debian-installer...). As a result, the bad behaviour of hw-detect has no harmful side effects in the gnuinos-installer.

Btw, I'm updating the iso images with the last version of vdev that speeds up the boot process:

https://www.gnuinos.org/mirror/daedalus/runit/

Read the header of /etc/fuse.conf. I have the following setup (fuse is required by vdev):

# The file /etc/fuse.conf allows for the following parameters:
#
# user_allow_other - Using the allow_other mount option works fine as root, in
# order to have it work as user you need user_allow_other in /etc/fuse.conf as
# well. (This option allows users to use the allow_other option.) You need
# allow_other if you want users other than the owner to access a mounted fuse.
# This option must appear on a line by itself. There is no value, just the
# presence of the option.

user_allow_other

# mount_max = n - this option sets the maximum number of mounts.
# Currently (2014) it must be typed exactly as shown
# (with a single space before and after the equals sign).

#mount_max = 1000

i.e., you want to enable user_allow_other.

I made a payment a few days ago but the process hung. I supposed that it was a glitch in the client area, so I did phone my provider and they told me that they would send me an invoice via email. The fact is that I never received that invoice; nevertheless, my website continued working on following days. This is why I supposed that the payment process did succeed. I'll have to ask my provider again on monday. Thanks for the information, prospero!

The good news is that today I got a tiny version of vdev working for the devuan installer. The challange is to build a vdev-udeb mini-package focused to d-i.

Hello Ralph

In order to discard possible issues with kernel drivers/modules I've recompiled the image replacing linux-libre with the stock kernel of debian:

https://www.gnuinos.org/tests/debian-kernel/

There is also another minor change: the option modprobe.blacklist=pcspkr has been removed from the boot parameters.

On the other hand, can you say me what's the output of the command below in the various scenarios (including devuan live)?

$ lspci -k | grep -EA3 'VGA|3D|Display'

Thanks again for your patience!

DISCLAIMER: debian-installer probably won't work with debian's kernel because it's built with linux-libre, but we're interested on live sessions.

Please, can you try with this other image?

https://www.gnuinos.org/eudev/

It's the same xfce x86_64, but with eudev instead of vdev.

Thanks in advance.

It works fine for me. However, there was a missing script /etc/sv/dbus/check in the openbox and xfce images. So, I recompiled and uploaded those images. Thanks for the advertisement!