Management console is hard to find

[ben-grande]

Qubes OS release

Qubes OS 4.2

Brief summary

I want to disable gui for some qubes:

• GUI tools do not consider qube can have gui feature disabled #9787

But saying to users that they need to run qvm-console-dispvm QUBE is not nice, there are few GUI options and they are hard to find. Only disabling the gui is not enough if users cannot open a management console.

Qube Manager:

• Right click qube and Open console in qube

App-menu (Q menu):

• No option

qui-domain:

• No option

CLI:

• qvm-console-dispvm

Steps to reproduce

1. Search for management console in GUI tools app-menu, qui-domains, qube manager.

Expected behavior

Find the management console available in more GUI tools, such as app-menu and qui-domains.

Actual behavior

Management console is not easy to run with GUI tools.

Additional information

The name console is nice, but it has to be consistent and to make it distinct than a terminal, I suggest adding management, as in management console, because it is created from the management_dispvm and because it does what it says, it manages even without a GUI.

Another name is debug console. I don't really want one name more than the other, but only console is confusing.

[alimirjamali]

Generating custom .desktop file which should run qvm-console-dispvm vmname instead of the conventional qvm-run is relatively easy. It would allow users to easily add/remove them to the AppMenu (Q Menu) for desired qubes. The other approach for AppMenu is to show console option with specific feature or property.

For qui-domain, it is really easy. But I guess it might be better to enable it only with specific feature or property.

[ben-grande]

Generating custom .desktop file which should run qvm-console-dispvm vmname instead of the conventional qvm-run is relatively easy. It would allow users to easily add/remove them to the AppMenu (Q Menu) for desired qubes. The other approach for AppMenu is to show console option with specific feature or property.

I am not sure if users should be allowed to remove that from the app-menu or it should be considered a system setting such as the option Qube settings which is always present.

For qui-domain, it is really easy. But I guess it might be better to enable it only with specific feature or property.

Also I don't know if it should be optional, it is useful with the gui feature enabled or not, it is very useful to debugging (as long as qrexec agent can start in the qube, else only xl console can connect).

Can you please clarify why it should be enabled conditionally to understand your reasoning?

[alimirjamali]

I am not sure if users should be allowed to remove that from the app-menu or it should be considered a system setting such as the option Qube settings which is always present.

I am not 100% sure either. That was a suggestion. Both options are possible.

Can you please clarify why it should be enabled conditionally to understand your reasoning?

This is very simple. Since the current existing code does this. And it would fail if gui=''. Doesn't it?

[ben-grande]

This is very simple. Since the current existing code does this. And it would fail if gui=''. Doesn't it?

Doesn't "fail", it hangs and no message is shown because it waits-for-session. See:

• qvm-run --gui waits indefinetly for GUI application even if gui feature is disabled #9789

[Atrate]

I agree that "Open Console" should be a default option in the qui-domains widget, it would be very handy and useful.

[unman]

On Fri, Feb 21, 2025 at 03:04:37AM -0800, ben-grande wrote: I am not sure if users should be allowed to remove that from the app-menu or it should be considered a system setting such as the option `Qube settings` which is always present.

I do not think it should be a "system setting". Naive users will click it if it is there, and find it confusing, and experienced will find it wherever it is.

[alimirjamali]

I believe we should consult @marmarta as well. What to do?

1. Always show it
2. Show it with some advanced feature, or use debug preference to enable it, or maybe both?
3. Never show it.

Like below (but with a better icon):

[marmarta]

I feel like we're getting into more and more complicated console options (there's also: QubesOS/qubes-desktop-linux-manager#243 ) ... A couple of questions:

• when is this console useful, outside of turning off the GUI?
• how often should it be used, how many users would use it often/rarely?

If this is a debug-only, rare feature that's supposed to be used rarely by less then 5% of the users, I'm not sure if it should go to the widget - qubes manager feels like a good place for it. But maybe I don't get the usefullness here. I'd prefer the widget to keep to the "commonly used" features, so that reading through the options can be as fast as possible.

[Atrate]

when is this console useful, outside of turning off the GUI?
how often should it be used, how many users would use it often/rarely?

It's very useful whenever something goes wrong with X or anything else that could cause a "normal" terminal not to be displayed. As far as my Qubes usage goes, this unfortunately means somewhere around once in 10 qube launches, which is less than desirable. As such, having this feature would be quite nice.

Also, considering other projects like the Mirage Unikernel firewall (and hoping they proceed successfully), the feature may become even more used.

[marmarta]

It's very useful whenever something goes wrong with X or anything else that could cause a "normal" terminal not to be displayed. As far as my Qubes usage goes, this unfortunately means somewhere around once in 10 qube launches, which is less than desirable. As such, having this feature would be quite nice.

Well, I have used it less then 10 times over last 7 years, so now we have two types of experience: once per year or multiple times per day. I think we'd need more data here.

[marmarek]

I am not sure if users should be allowed to remove that from the app-menu or it should be considered a system setting such as the option Qube settings which is always present.

IMO it shouldn't be included always, only when user wants it. Maybe with some suggestion when gui=''. Similar for the domains widget, most of the time, normal terminal launched in a qube is preferable choice, management/debug console is only a fallback if normal terminal cannot be used (either because some issue, or because gui is disabled).

[andrewdavidwong]

Well, I have used it less then 10 times over last 7 years, so now we have two types of experience: once per year or multiple times per day. I think we'd need more data here.

One more data point: My usage rate seems to be around 0-2 times per decade (basically only if something breaks and someone directs me to use it).

[unman]

I have used the console somewhat regularly, but do not think it should be included in the widget by default.

[ben-grande]

I feel like we're getting into more and more complicated console options (there's also: QubesOS/qubes-desktop-linux-manager#243 ) ...

A couple of questions:

* when is this console useful, outside of turning off the GUI?

When the GUI can't start, either because of Xorg or terminal emulator issue as well when there is no terminal emulator installed.

* how often should it be used, how many users would use it often/rarely?

Depends on the user and what they do with their qubes. A user who only open web browsers, office suite and file manager will rarely if ever open the terminal and much less open the management console.

I see a future where the usage of the management console increases:

• sys-gui and variants: when user can't login, the window manager (Xfwm4, Plasma ...) fails or the window system (Xorg, Wayland ...), they can't get a terminal emulator in the qube, they have to resort to the management console. sys-gui adoption is quite low due to withstanding bugs, but when it becomes more stable, this usage will increase.
• OS distributions comes bundled with more services, making it harder to have a computer with 16GB of RAM without lags and patience. Maybe asking how many GBs of RAM a user has is an important question in the research. There is the HCL of course, but that doesn't represent the Qubes user base, just what hardware works. The gui feature can be disabled in the future for some service qubes.
• Getting a root terminal without running the window system as root, I am not sure Wayland allows to run applications as root, qvm-run --user root --service -- QUBE qubes.StartApp+qubes-run-terminal won't work.

Some common usage is:

• Hardware debugging: PCI loading issue after suspend (sys-usb, sys-net, sys-gui-gpu?) or a qube that the user passthrough the GPU or an unstable distribution that keeps crashing before Xorg is made available, but still depends on the qrexec-agent and dependencies starting.
• Breaking shell startup files (~/.profile, ~/.bashrc etc)
• Debugging anything, such as Snap or when there is some problem that no windows open and the program requires custom properties to be set in by the window system.

If this is a debug-only, rare feature that's supposed to be used rarely by less then 5% of the users, I'm not sure if it should go to the widget - qubes manager feels like a good place for it. But maybe I don't get the usefullness here. I'd prefer the widget to keep to the "commonly used" features, so that reading through the options can be as fast as possible.

I don't know if it is 5% of the users right now, but it is something that can be increased when moving to Wayland, using sys-gui variants and OS distributions becoming more memory intensive. So not debugging only but most people don't use it as:

• They use the basics of Qubes, no customization of shell startup, not touching the terminal (not even in dom0 anymore as Qubes Updater and Global Config seems to allow a GUI experience without requiring dom0 terminal)
• Don't have PCI problems
• Don't require custom Xorg configuration
• Don't use sys-gui variants as it is not stable a full replacement to window system of dom0 yet
• Don't have the gui feature disabled for service qubes as it is not currently the default (but can become)

I am not sure if users should be allowed to remove that from the app-menu or it should be considered a system setting such as the option Qube settings which is always present.

IMO it shouldn't be included always, only when user wants it. Maybe with some suggestion when gui=''. Similar for the domains widget, most of the time, normal terminal launched in a qube is preferable choice, management/debug console is only a fallback if normal terminal cannot be used (either because some issue, or because gui is disabled).

If QubesOS/qubes-desktop-linux-manager#243 is implemented for root terminal, it also would make sense to have a key combination in qui-domains for the qvm-console-dispvm.

This is nice Ali, can you share the code, to see if it is easily customizable to appear only gui is disabled?

---

Most people in the Core team seem to disagree that it should be the default (mostly because gui is enabled by default). Then the outcomes I see is:

• Q menu: adding an application entry
• qui-domains: substituting by terminal option gui is disabled

But the qui-domains won't be useful to open the console when the user has problems and the gui is enabled but not working.

[alimirjamali]

This is nice Ali, can you share the code, to see if it is easily customizable to appear only gui is disabled?

Sure. I believe it should be shown in 3 conditions:

1. gui = ''
2. qube debug mode is on
3. A global feature. Something like advanced-mode, debug-mode or wizard-mode for dom0

And I believe the original Run Terminal should be disabled if gui = ''?

I will work on the draft.

p.s.: Draft PR submitted @ben-grande . It lacks property change and feature change watches for live changes. It also lacks unittests.