You are not logged in.
Done
Thank you very much! All is well again here.
The last apt upgrade of a runit install sends the system into busybox.
I tried with a fresh install, but the new VM also boots into busybox after fully updating.
That does explain the error.
I will keep on testing then.
UPDATE: after a few more clocking sessions, the difference in start-up time may be even lesser: 6-7s with vdev vs 7-8s with eudev. Not something I would have noticed without a timer anyway.
This is a great experience, possibly the lightest MATE experience to date. I installed it on a VM, and after some initial fumbling with the bios_grub partition thing it is now up and running next to one of its first cousins. Thank you! The default session runs as jeans@devuangreen.
I did work on a graphical interface for SUDO_ASKPASS in the past, but I stopped working on it time ago.
I have now removed policykit-1-gnome (and a whole bunch of dependencies it had pulled) and installed lxpolkit instead, and it does the job just as well. I only had to check the box in the session configuration GUI to get it to autostart.
After a fresh VM install of the 2025-02-11 iso, I have clocked 6 seconds to get from the GRUB menu to the lxdm greeter. After doing apt install eudev, I was getting about 8 seconds. I had to stop testing there, because for some reason I could not revert to vdev, so I installed afresh and I am getting 6 seconds to login screen again, using vdev.
I can keep testing further, but for now I am not sure why apt install vdev is not working. I am getting into a dependency trap, out of which the only way is to keep eudev and whatever can escape the trap.
UPDATE: I was eventually able to revert to vdev by using apt-get install vdev instead of apt install vdev, although the previous error may in fact have been caused by a network issue. Anyway, I have noticed that the keyboard layout used by the lxdm greeter is the one selected at install time if eudev is installed, while the default en-US is used when vdev is at work.
While trying to use the XFCE menu to start GUI programs requiring root privileges, I eventually awakened to what had been mentioned there almost half a year ago:
https://dev1galaxy.org/viewtopic.php?pid=51793#p51793
Installing policykit-1-gnome, as suggested in that post, brought up the password prompt, which is fine for the time being and for my usage, but maybe some alternative tweak is brewing in the gnuinos cauldron?
The 2025-01-18 iso image installed fine, thanks for the update. I did not have time to investigate further, but the previous one seemed to stall on network configuration during text install on a VM. All is well with the current image.
Upgrading an install from the 2024-06-01 iso also went smoothly - it had been partly reluctant at some point in the previous week, but any residual reluctance is now gone. Thank you!
apt update works fine on the older system, but I am currently getting error messages complaining about GPG on the newer one.
UPDATE: problem gone after reboot, both systems are now updated and fully upgraded. The error I was getting was related to the content of /var/lib/apt/lists:
Splitting up /var/lib/apt/lists/packages.gnuinos.org_merged_dists_daedalus_InRelease into data and signature failed
DENOUEMENT: The lack of space that triggered the error was caused by a ridiculously undersized root partition. An easy thing to miss.
The 2025-01-18 iso image installed fine, thanks for the update. I did not have time to investigate further, but the previous one seemed to stall on network configuration during text install on a VM. All is well with the current image.
Upgrading an install from the 2024-06-01 iso also went smoothly - it had been partly reluctant at some point in the previous week, but any residual reluctance is now gone. Thank you!
Some seem to believe that throwing ever more non-free microcode to solve a problem created by non-free microcode is a good idea. Others argue that there is indeed no basis to trust that the same people who produced insecure microcode in the first place are magically going to make it secure, since the newer microcode is as non-free as the older, and likewise unavailable for public scrutiny. Applying the appropriate mitigations, which does not involve injecting any extra non-free microcode, may thus sound like a better idea.
The current controversy around them left me somewhat confused though.
I also find a bit confusing that a software project called "libre*" would decide to distribute non-free bits. The libre bootloader controversy will probably ease in time and eventually become an archeological artefact. Meanwhile, GNU Boot offers a de-confusing option for those who are looking for a full commitment to software freedom.
# check-dfsg-status -s
Thank you very much for that hint. I am using -q instead, and enjoying the silence.
Indeed the non-free firmware is still kept in a separate Debian repo, even after the policy change, so whether the Debian installer now installs it by default is of no immediate concern to gnuinos users. Thank you for looking into hw-detect, and thank you again for your work on gnuinos, I really appreciate being able to tinker on a rather lightweight OS in all freedoms, init included.
the gnuinos flavor of debian-installer doesn't load any non-free firmware
Thanks for confirming. I thought the linux-libre kernel would most probably not load any of that anyway, but after the Debian policy change these matters have become a source of confusion.
And thank you for the new images.
That was a small glitch from some time ago, the repo currently works fine for me.
The LO window also freezes here after 5-10 seconds when I try to open 3_new.odt. Older kernel (5.15) and later LO (24.8), same system memory (8 GiO). So the devil really is in the details of the odt.
If you could overcome the Table-in-a-Frame copying bug, you may still have a chance to recover its content: if I keep scrolling along for about 20+ seconds, the beast eventually get tamed and I am able to get a reasonably pliant document. I also get one core running at 100% once the window has frozen, but the situation is not much better after taming the beast. It is still a wild beast after all, even if a tamed one.
Does the gnuinos flavor of debian-installer load any non-free firmware? If so, that would probably be a bug to fix.
It has been reported that (some versions of) this script may be broken, leading to non-free firmware being loaded and installed no matter what the user chooses:
I believe the iso images needed some time off, so they decided to take brief offline holidays.
Anyway, I had already downloaded the latest (2024.06.01) iso the other week, so I can confirm that the XFCE-runit amd64 image rocks, as usual.
The gnuinos.org website seems to be down. I am getting this page instead:
Updated summary of current results booting XFCE amd64 images from the USB flash drive on that workstation:
nvidia GPU plugged in - and set either as non-boot device or as primary VGA
all images return:
$ lspci -k | grep -EA3 'VGA|3D|Display'
00:02.0 VGA compatible controller: Intel [...] Integrated Graphics Controller
Kernel driver in use: i915
01:00.0 VGA compatible controller: NVIDIA [...]
Kernel driver in use: nouveau
all gnuinos test images boot into tty1, no graphical session
Devuan desktop-live boots into XFCE session OK, using whichever GPU is set as primary VGA
NB: it transpired that the Devuan desktop-live image is loading a bevy of nvidia firmware blobs to be used with that NV137 (GP107) GPU. Maybe gnuinos could try defaulting to llvmpipe instead?
nvidia GPU unplugged
all images boot into XFCE session OK, kernel driver in use i915
Just before seeing your last post, I had tried completely removing the nvidia GPU that was disabled at boot time but still plugged in, and I got an X session and a desktop, but no xfce4-panel.
I am now getting the same with the latest test image: graphical session starts, but no panel to be seen. So the last two test images (eudev and vdev) seem to behave the same when the integrated Intel graphics is the only GPU available. I will plug the nvidia GPU back in and let you know what happens.
UPDATE: I am getting the same Xorg error as with the previous test images when the nvidia GPU is plugged in (but disabled at boot time). So until now there has been no change in behavior, the only difference is triggered by unplugging the disabled external GPU.
Thank you. Still no luck with the eudev image, same situation as with vdev. The first line in the Xorg log that seems to indicate an error is the following one:
nvc0_screen_create:1072 - Base screen init failed: -19
EDIT: I am getting the same error log as that one, just substitute "crocus" for "iris": https://bugs.debian.org/cgi-bin/bugrepo … 867;msg=45. The live system sends me to a blinking cursor every so often, which makes it a bit tricky to type in commands.
I was able to boot from the USB into that computer using the devuan_daedalus_5.0.0_amd64_desktop-live image. 🤔
Crocus may be innocent after all.
After further testing, both runit and sysvinit XFCE images boot fine on the usual laptop with Intel GMA 3150.
They also boot fine into a VM on the desktop I am currently testing on (with Intel HD 4600 graphics), but from the USB flash drive I keep getting crocus_dri related errors in the Xorg log. I can start a session through tty, but no graphical session so far. Crocus mystery.
Anyway, elogind seems to be happy now, no error messages any more. 👍
Hi there, and thanks for the update! This does look like a nice Gtk GUI, so I thought I had to give it a try
Currently getting this when booting the runit XFCE amd64 live system:
elogind[XXXX]: Failed to connect to system bus: No such file or directory
elogind[XXXX]: Failed to fully start up daemon: No such file or directory
EDIT: it works fine on a VM, so the error could be caused by a failing USB flash drive.
Great, thank you! Both now boot fine into their respective DE/WM. I can also confirm that the xfce-runit image is booting fine, as expected.
It is just amazing to have so much choice on aging harware, in complete freedom.
It looks like the new JWM image does not have the dbus problem any more, thanks!
After checking further, the issue that prevents the graphical session from starting seems to be the same as with plasma-sysvinit: glamor also complains that it does not get enough instructions. So it is likely hardware related. I now need to try with the latest xfce-runit image, maybe more recent versions of some GPU driver require higher specs.
The xfce-sysvinit image boots fine on the same hardware, though.