You are not logged in.
@greenjeans, the only backport was xorgproto available in the same repository:
Installing from the 2025-09-09 runit ISO with LVM encryption gives a familiar piece of advice about life:
ALERT! /dev/mapper/gnuinos--5--0--1--vg-root does not exist. Dropping to a shell!
I should add that installing to disk from the 2025-09-09 live iso without encryption works well, with or without LVM. cool
As usual, I have been using the runit XFCE amd64 iso image
The runit XFCE isos tagged as 2025.10.08 worked with encryption. They have been uploaded today.
New live images with XLibre:
https://www.gnuinos.org/mirror/daedalus/runit
https://www.gnuinos.org/mirror/daedalus/sysvinit
We at XLibre are currently working on upstreaming the seatd support in https://github.com/X11Libre/xserver/issues/202 so XLibre can one day be officially included in Devuan
I've patched XLibre to support seatd management:
Installing from the 2025-09-09 runit ISO with LVM encryption gives a familiar piece of advice about life:
ALERT! /dev/mapper/gnuinos--5--0--1--vg-root does not exist. Dropping to a shell!
Thanks, prospero, the LVM partitioning without encryption worked for me as well. I will try to fix the issue with LVM encryption as soon as possible.
/dev/mapper/gnuinos--vg-root does not exist dropping to a shell!
@zapper: read my last post in DNG, please
[DNG] vdev available for devuan
On the other hand, live isos required a couple of additional udeb packages in order to get disk encryption in debian-installer, named libargon2-1-udeb and libjson-c5-udeb
Do they work now?
Thanks prospero, recently I fixed a bug related to the creation of symlinks at /dev/disk, as explained in the DNG mailing list:
Yes, the live-sdk
As for lxdm, I chosed it because it allows me to run a script that customizes the active plugins in xfce4-panel. I tried the same with other display managers, but I didn't succed.
different from the 32 bit version, with it the installation with the GNUinOS installer did work immediately (and the other way I did use in 32 bit starting from the iso live and installing after the installation from refractainstaller out the live started image would not start).
gnuinos live images contain the package nodm; and the removal of nodm during the preseed phase of the gnuinos-installer may lead to this matter
It seems to be parent with GNUinOS, perhaps is Refracta Linux the base of GNUinOS?
No, gnuinos isn't built upon refracta. Gnuinos modifies some packages taken from devuan and builds its own repository by adding a new level in the amprolla infrastructure.
Hence, the issue you are talking about, i.e. some input devices not processed by vdev has nothing to do with refracta. It happens, from my own experience, during live sessions under 32 bits. I'm fixing the problem right now (I've found the origin), and I'll update the iso images as you suggested. Thanks for your help
@golinux: the letter "C" doesn't exist. It would be Eskalibur
oui?
different from the 32 bit version, with it the installation with the GNUinOS installer did work immediately (and the other way I did use in 32 bit starting from the iso live and installing after the installation from refractainstaller out the live started image would not start).
So, the issue related to the 32bit installer happens with your refracta snapshot of gnuinos?
probably are the problems in 32 bits from the same kind but have only not the same tragic consequence: it seems not to be a matter of rights but only from dysfunction of the input equipment. I will try it again on my other laptops in the next days (to much time invested for today! I am now in the hurry...) having only an usual keyboard and touchpad...
Gnuinos uses vdev by default. Is the whole xinput equipment listed in /dev/metadata/udev/input file? What init system are you using?
I'm building Gtk3 without dbus by defining a variable that allows to enable/disable the atk-bridge part at build time.
This variable is used in the file `gtk/a11y/accesibility.c` as a preprocessor directive. For example:
#ifdef HAVE_ATK_BRIDGE
#include <atk-bridge.h>
#endif
In doing so, it's possible to remove dbus from Gtk3. Gtk2 doesn't depend on it.
As for luks2..., no answer yet
Thanks for your work, greenjeans!
Live sessions in qemu take too long at me as well. However, I don't think that the start-up messages you are showing are the culprit. Runit run scripts exit if dependencies are not satisfied (i.e. if a service starts before another service the earlier depends on) throwing such messages and retrying afterwards until it succeeds. But I need further testing, of course. Thanks!
The following images worked for me in qemu:
https://www.gnuinos.org/mirror/daedalus/runit/
I'll update the repository tomorrow.
it's using the alsa backend to do that as well
Keeping the gui updated in real-time according to the current values given by the alsa backend without thereby freezing the interface wasn't that easy for me when I developed the amixer-gtk. Didn't you push the source to any git repository yet?
I'll test It again at home, thanks
It looks nice. Which toolkit are you using?
@zapper: I'm referring to Jude Nelson's device manager
@Prowler_Gr: vdev has been notably improved since my last post, and now it works fine with runit, sysvinit and openrc, whereas s6 is a work in progress.
I'm updating the repository in order to rebuild the iso images as soon as possible.
If I was interested in making an init-diversity spin of GNUinOS, which variant in your opinion would be the most popular to base this on?
Thanks a lot for your interest in gnuinos. Well..., I don't know which would be the most popular. You can email me in private.
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!
@prospero: the website will be available today, thanks