You are not logged in.
If at some point you can test openrc, that would be appreciated. I would more likely use it if that were the case.
Freedom is never more than one generation away from extinction. Feelings are not facts
If you wish to be humbled, try to exalt yourself long term If you wish to be exalted, try to humble yourself long term
Favourite operating systems: Hyperbola Devuan OpenBSD
Peace Be With us All!
Offline
Just a heads-up gnuinos.org is currently giving the same page as in https://dev1galaxy.org/viewtopic.php?pid=50515#p50515.
Offline
I am currently getting a timeout when trying the 2025.04.23 xfce runit image on a VM. So the live system would not start, and the installed system also fails to start. I am getting a message about default-syslog, but have no idea whether that is the actual culprit.
Offline
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!
Last edited by aitor (2025-06-18 00:21:42)
If you work systematically, things will come by itself (Lev D. Landau)
Offline
Hi @aitor.
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?
Offline
@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.
If you work systematically, things will come by itself (Lev D. Landau)
Offline
@aitor what do you mean by vdev? ZFS?
Curious.
If you mean ZFS, I think there are better options for Hyperbola, such as HAMMER2.
Freedom is never more than one generation away from extinction. Feelings are not facts
If you wish to be humbled, try to exalt yourself long term If you wish to be exalted, try to humble yourself long term
Favourite operating systems: Hyperbola Devuan OpenBSD
Peace Be With us All!
Offline
@zapper: I'm referring to Jude Nelson's device manager
If you work systematically, things will come by itself (Lev D. Landau)
Offline
@aitor looks interesting... you have a point.
Freedom is never more than one generation away from extinction. Feelings are not facts
If you wish to be humbled, try to exalt yourself long term If you wish to be exalted, try to humble yourself long term
Favourite operating systems: Hyperbola Devuan OpenBSD
Peace Be With us All!
Offline
Syslog isn't the culprit, but some of the changes I did in the daedalus version of vdev (chimaera images do work)
It looks like the live 2025-07-02 xfce runit amd64 image also gets stuck at some point in the startup process in a VM. I thought it might be VM related, so I tried with a live USB and...the live system boots to a full xfce desk.
I will now try to tweak those VM settings and see if it helps. Thank you for the new images!
UPDATE: the system does boot into a graphical session after installing in a VM, but only after switching to tty2 to log in.
Last edited by prospero (2025-07-04 08:24:21)
Offline
The following images worked for me in qemu:
https://www.gnuinos.org/mirror/daedalus/runit/
I'll update the repository tomorrow.
If you work systematically, things will come by itself (Lev D. Landau)
Offline
Thank you! I just gave a try to the latest iso.
In a VM, the live system still ends up with a blinking cursor for at least twenty minutes and counting, after printing various expected messages, the last of which being the default-syslog line mentioned above.
Once installed in a VM through the graphical installer, the system now works without having to switch to tty2 (Alt+F2) in order to boot into a graphical session, but goes through up to five minutes of blinking before getting there. So this is a bit different from the previously reported 7-8 seconds to GUI. The last displayed message during the blinking phase is also about default-syslog. Those three lines look very much like the usual start-up messages, only they keep blinking for a while instead of just being displayed then removed.
gnuinos-5 login: ok: run: dbus: (pid 2176) 1s
ok: run: elogind: (pid 2170) 1s
timeout: run: default-syslog: (pid 2180) 8s
As before, once dd'ed to a USB drive the live iso boots fine into Xfce, so I need to investigate further on the VM side.
Last edited by prospero (2025-07-07 08:10:22)
Offline
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!
If you work systematically, things will come by itself (Lev D. Landau)
Offline
@aitor would it be possible to run gnuinos with dbus stripped away as much as possible and also, with LUKS2 instead of luks1.
I am using libreboot, so luks2's bugs wouldn't affect me anyhow.
If you could put in an option to make it optional to use luks2 that would be helpful.
Freedom is never more than one generation away from extinction. Feelings are not facts
If you wish to be humbled, try to exalt yourself long term If you wish to be exalted, try to humble yourself long term
Favourite operating systems: Hyperbola Devuan OpenBSD
Peace Be With us All!
Offline
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
Last edited by aitor (2025-07-26 19:28:49)
If you work systematically, things will come by itself (Lev D. Landau)
Offline
@aitor You can probably remove dbus from anything that exists in hyperbola currently.
As for LUKS2 being optional when you get to the partitioning scheme, that might be a challenge to do. I don't expect that will be easy to figure out. That being said, would be nice for sure!
Freedom is never more than one generation away from extinction. Feelings are not facts
If you wish to be humbled, try to exalt yourself long term If you wish to be exalted, try to humble yourself long term
Favourite operating systems: Hyperbola Devuan OpenBSD
Peace Be With us All!
Offline
Actually, don't worry about luks2, supposedly debian has already switched to it since debian 11. And we know that devuan inherits that. So just the no dbus requirement would be good.
Freedom is never more than one generation away from extinction. Feelings are not facts
If you wish to be humbled, try to exalt yourself long term If you wish to be exalted, try to humble yourself long term
Favourite operating systems: Hyperbola Devuan OpenBSD
Peace Be With us All!
Offline