I'll test It again at home, thanks

@zapper: I'm referring to Jude Nelson's device manager

https://github.com/jcnelson/vdev

Syslog isn't the culprit, but some of the changes I did in the daedalus version of vdev (chimaera images do work). So, I've found the solution to the problem (at least in qemu) by comparing both releases. Tested with qemu and only in one machine, though. Give me a couple of days and I'll update daedalus images.

Thanks again for your patience and your tests, prospero!

I'm working on that. I would like to be able to integrate vdev in other systems like Hyperbola, Guix, Void, Alpine...

Nowadays udev is a transitional dummy package that is present only for backwards compatibility. If someone needs to upgrade a system with the old udev, this one will be replaced with an empty package that depends on eudev. Once the system has been upgrade, the superfluous package can be removed afterwards, as you use to do.

If you are using dhcpcd5, you can disable ipv6 by adding the line below to /etc/dhcpcd.conf:

# Don't solicit or accept IPv6 Router Advertisements and DHCPv6
noipv6

Thanks for the detailed video, fsmithred, it'll be very useful for sure. I've downloaded it

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

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.