If there is “not enough RAM”, rads does not attempt to start gdm3.
There could have been a bug in theory if rads supported only gdm but not gdm3. Then with “not enough RAM”, gdm3 would have still been started, because rads might have missed to inhibit autostart of gdm3. But that’s not happening here.
The root cause is that Virtual Consoletty1 is missing by default which is a systemd issue:
For first boot into Whonix CLI:
The workaround until virtual console tty1 is automatically started is to use a different virtual console such as tty2 as per documentation.
I didn’t test this for Whonix KVM but switching virtual console from tty1 to tty2, tty3, … is fully functional with Whonix VirtualBox. Just now tested, confirmed.
Having tty1 functional by default seems non-trivial and requires further troubleshooting. Help welcome.
# replaces the getty
Conflicts=getty@tty1.service
After=getty@tty1.service
Problem seems to be that gdm takes tty1 by default instead of tty7 (lightdm default). That’s why gdm is getting in the way.
Somehow above issue is even triggered although rads already created the required status files for systemd to recognize that “gdm condition for startup failed”. Seems like the systemd unit keyword Conflicts= is also active even if gdm won’t start due to “condition for startup failed” (status file created by rads because “not enough RAM”).
KVM cannot see a virtual console anymore? Why not? I think it could last time I checked.
Found some arbitrary screenshot online, this is what I mean: https://www.tecmint.com/wp-content/uploads/2015/02/Booting-Virtual-Machine-620x448.jpeg
That is a virtual console.
Also grub boot menu while not considered a virtual console (?) uses similar (virtual) hardware access to draw to the CLI screen as virtual console.
Just to clarify:
Virtual console is different from serial console.
(Actually non-trivial from wikipedia to guess who serial console is used nowadays in context of host reading textual output from the kernel from a KVM VM without need for a functional graphic device/driver.)
This forum thread is about virtual console only.
Serial console is really cool but entirely different thing as far as I understand. (Serial Console) Should be unrelated.
Then in this case yes. I assume this isn’t a KVM specific bug? There is a flickering cursor. So now that it is so, is this fixed in since 16.0.2.7 or a WIP?
In VM or on the host?
A plain Alt + Crtl + F2 on the host would switch to tty2 on the host. Doing it in VM mostly requires some special action.
Assuming in VM…
If you had tty2 with login inside a KVM VM… Then no, not KVM specific bug. General bug as described in original post here.
[1] If there is only a flickering cursor and no other output from rads and swap-file-creator then that’s a KVM specific bug.
If KVM specific bug, then no, bug not understood, not analyed, not fixed.
More output expected as per [1].
There’s a workaround in place in the testers repository now. Should be solid. rads switches to virtual console tty2 now if not starting a desktop environment using chvt 2.
