Error Message: setterm: $TERM is not defined

Qubes-Whonix
1

For the new Whonix experimental templates from the Qubes repo:

In Dom0, when running “qvm-” commands [1] specifically upon Whonix VMs, such as “qvm-start”, “qvm-run”, etc, it outputs 2 lines of the following error, like this…

setterm: $TERM is not defined. setterm: $TERM is not defined.

For example, if I run the following in the Dom0 terminal:

qvm-run --pass-io whonix-workstation 'date'

it outputs:

setterm: $TERM is not defined. setterm: $TERM is not defined. Sat Dec 25 12:00:00 UTC 2014

This error does not happen with other Fedora-based (non-Whonix) VMs in Qubes.

This error does not happen within the Whonix VM terminals themselves, just Dom0, when running “qvm-” commands upon the Whonix VMs.

I’m writing a toolkit for Qubes + Whonix and this error gets in the way of cleanly parsing and processing the output of commands issued to the Whonix VMs.

Checked $TERM variable inside the Whonix VM terminals, I echo $TERM:

echo $TERM

it outputs:

xterm

[1] https://qubes-os.org/wiki/DomZeroTools

Cross posted this to the qubes-users mailing list: https://groups.google.com/d/topic/qubes-users/ToWHLRXBy5c

2

@nrgaway successfully narrowed down the culprit of this error.

It seems to be part of a Whonix power savings disable script…

/etc/profile.d/20_power_savings_disable_in_vms.sh
Remove the file below and it will work for you :) /etc/profile.d/20_power_savings_disable_in_vms.sh

It’s a Whonix script so maybe ask Patrick for a work-around or maybe it is not needed. Let me know so I can fix it in a future release.

@Patrick

Would like to know what the significance of this power savings script is and what kind of bad effects, if any, might be expected from disabling it for users.

And if we can conditionally, for Qubes users only, disable the part that unsets the $TERM variable in the next Whonix release.

Thanks! :smiley:

3

package:
https://github.com/Whonix/power-savings-disable-in-vms

purpose of package:
https://github.com/Whonix/power-savings-disable-in-vms/blob/master/debian/control#L18

It’s not unsetting the $TERM variable.

“Code effective” parts:

(“Non-code effective” parts, the other files, are packaging, package description, licensing, …)

So the only adverse effect could be the usability issue of blanking the display (“power off”) after a while of inactivity using the VM (not the host - blanking the host display can be a usual, sane thing, that’s a separate discussion). But perhaps Qubes disables powersavings for VMs already some other way anyhow.

Feel free to disable it conditionally in next Whonix release. By checking some environment variable or file (slightly cleaner, I think) that only exists within Qubes. Please send a pull request or I’ll do it next year. (Pretty easy, small, fast change.) You got some file already, that only exists within Qubes that can be used for checking we’re running inside Qubes?

4

Great.

Ideally, we could somehow both retain the no screen blanking for vms feature and also resolve this $TERM not defined issue.

@nrgaway

You still know the anatomy of your Whonix Qubes implementation much better than I.

We may need to use this same method for making other Qubes specific changes to Whonix in the future.

Going forward, what specific hook would you recommend being most dependable for detecting the presence of our Qubes platform?

No significant rush. Thanks!

5

Maybe it’s just a symptom. Not the cause.

On a wheezy system using KDE, Konsole.

echo $TERM
xterm

On a wheezy system, using console tty0.

echo $TERM
linux

I guess the $TERM variable is not set when using Qubes? That would be a Qubes specific bug worth fixing.

Dumbing it down further, getting the whole power-savings-disable-in-vms package out of the equation…

What happens if you run the following in a Qubes plain Debian template? Try in KDE, Konsole as well as in a real login console such as tty0.

xset s off
xset -dpms
setterm -blank 0
setterm -powerdown 0

I guess you’re getting the $TERM not defined error?

6

[quote=“WhonixQubes, post:4, topic:763”][quote author=Patrick link=topic=839.msg6172#msg6172 date=1419743969]
Feel free to disable it conditionally in next Whonix release. By checking some environment variable or file (slightly cleaner, I think) that only exists within Qubes. Please send a pull request or I’ll do it next year. (Pretty easy, small, fast change.) You got some file already, that only exists within Qubes that can be used for checking we’re running inside Qubes?
[/quote]

Great.

Ideally, we could somehow both retain the no screen blanking for vms feature and also resolve this $TERM not defined issue.

@nrgaway

You still know the anatomy of your Whonix Qubes implementation much better than I.

We may need to use this same method for making other Qubes specific changes to Whonix in the future.

Going forward, what specific hook would you recommend being most dependable for detecting the presence of our Qubes platform?

No significant rush. Thanks![/quote]

If ‘/var/run/qubes’ exists, you are using a Qubes VM of some sort (template, proxy, etc). So that would be good to use to determine if running on Qubes.

7

No $TERM errors within the Whonix VMs themselves.

The $TERM variable seems to be set inside the Whonix VMs.

Dom0 has no problem with other (non-Whonix) VMs in Qubes.

Dom0 has no problem with Whonix VMs after deleting the “power-savings-disable-in-vms” package.

However, the Whonix “power-savings-disable-in-vms” package seems to “disrupt” Qubes Dom0 from knowing the $TERM variable of Whonix VMs.

Only get the $TERM error when working with Whonix VMs from Dom0 (qvm-run --pass-io, etc), when the “power-savings-disable-in-vms” package is enabled.

Qubes Test Results:

[hr]

In Whonix AppVM KDE Konsole:

echo $TERM
xterm

[hr]

In Dom0 KDE Konsole to Whonix AppVM:

qvm-run --pass-io whonix-workstation "echo $TERM"
setterm: $TERM is not defined.
setterm: $TERM is not defined.
xterm-256color

[hr]

In Whonix HVM TTY:

echo $TERM
linux

[hr]

In Whonix HVM TTY:

echo $TERM
linux

xset s off
xset:  unable to open display ""

xset -dpms
xset:  unable to open display ""

setterm -blank 0

setterm -powerdown 0

echo $TERM
linux

[hr]

In Debian 8 AppVM GNOME Terminal:

echo $TERM
xterm

[hr]

In Debian 8 AppVM GNOME Terminal:

echo $TERM
xterm

xset s off

xset -dpms

setterm -blank 0
setterm: terminal xterm does not support --blank

setterm -powerdown 0
 [14;0]

echo $TERM
xterm

[hr]

In Dom0 KDE Konsole to Debian 8 GNOME Terminal:

echo $TERM
xterm-256color

[hr]

In Debian 7 HVM GNOME Terminal:

echo $TERM
xterm

[hr]

In Debian 7 HVM GNOME Terminal:

echo $TERM
xterm

xset s off

xset -dpms

setterm -blank 0

setterm -powerdown 0
 [14;0]

echo $TERM
xterm

[hr]

In Debian 7 HVM TTY:

echo $TERM
linux

xset s off
-bash: xset: command not found

xset -dpms
-bash: xset: command not found

setterm -blank 0

setterm -powerdown 0

echo $TERM
linux

[hr]

Let me know if you need any further tests or clarifications on these ones.

8

Great. Thanks!

Will plan on checking for this directory specifically for Whonix Qubes conditionals:

/var/run/qubes
9

[quote=“Patrick, post:5, topic:763”]Maybe it’s just a symptom. Not the cause.

On a wheezy system using KDE, Konsole.

echo $TERM
xterm

On a wheezy system, using console tty0.

echo $TERM
linux

I guess the $TERM variable is not set when using Qubes? That would be a Qubes specific bug worth fixing.

Dumbing it down further, getting the whole power-savings-disable-in-vms package out of the equation…

What happens if you run the following in a Qubes plain Debian template? Try in KDE, Konsole as well as in a real login console such as tty0.

xset s off
xset -dpms
setterm -blank 0
setterm -powerdown 0

I guess you’re getting the $TERM not defined error?[/quote]

$TERM is set on Qubes. In a terminal shell using Whonix Gateway AppVM:

echo $TERM
xterm

As for running the following:

xset s off
xset -dpms
setterm -blank 0
setterm -powerdown 0

The last statement (setterm -powerdown 0) spits out a few bytes of garbage text, some type of escape sequence ([9;0][14;0]).
Qubes uses its own video (and input) drivers and does not rely on X-Windows due to security concerns (Any user can obtain access to any users x-window sessions keystrokes and such [url=http://theinvisiblethings.blogspot.ca/2011/04/linux-security-circus-on-gui-isolation.html]http://theinvisiblethings.blogspot.ca/2011/04/linux-security-circus-on-gui-isolation.html[/url])

Anyway, I suggest redirect any errors when when using the setterm command as follows:script to look like this:

setterm -blank 0 2>/dev/null
true "$0: exit code: $?"
setterm -powerdown 2>/dev/null
true "$0: exit code: $?"

The above code block works in Qubes and I imagine it would work as expected in other Vms as well. Maybe you can test that out?

10

[quote=“nrgaway, post:9, topic:763”]Anyway, I suggest redirect any errors when when using the setterm command as follows:script to look like this:

setterm -blank 0 2>/dev/null true "$0: exit code: $?" setterm -powerdown 2>/dev/null true "$0: exit code: $?" [/quote]

Confirmed as working in Qubes.

It simply suppresses the STDERR of these commands.

Should work universally.

But if wanting to implement specific to Qubes, here would be some simple conditional code:

Version #1: Give Whonix Standard code 1st position; and Whonix Qubes code 2nd position:

if [ ! -d "/var/run/qubes" ]; then
   setterm -blank 0
   true "$0: exit code: $?"
   setterm -powerdown 0
   true "$0: exit code: $?"
else
   setterm -blank 0 2>/dev/null
   true "$0: exit code: $?"
   setterm -powerdown 0 2>/dev/null
   true "$0: exit code: $?"
fi

Version #2: Give Whonix Qubes code 1st position; and Whonix Standard code 2nd position:

if [ -d "/var/run/qubes" ]; then
   setterm -blank 0 2>/dev/null
   true "$0: exit code: $?"
   setterm -powerdown 0 2>/dev/null
   true "$0: exit code: $?"
else
   setterm -blank 0
   true "$0: exit code: $?"
   setterm -powerdown 0
   true "$0: exit code: $?"
fi
11

Redirecting stderr to /dev/null is fine. Not sure if that should be conditional only done on Qubes, but not for others. I guess the former is better.

I don’t think /var/run/anything is a good conditional for this due to the nature how /var/run is created. There is some qubes specific folder in /usr/ already anyhow as far I remember.

The code without “!” is slightly faster to grasp, for me, because it avoid a negation.

12

[quote=“Patrick, post:11, topic:763”]Redirecting stderr to /dev/null is fine. Not sure if that should be conditional only done on Qubes, but not for others. I guess the former is better.

I don’t think /var/run/anything is a good conditional for this due to the nature how /var/run is created. There is some qubes specific folder in /usr/ already anyhow as far I remember.

The code without “!” is slightly faster to grasp, for me, because it avoid a negation.[/quote]

If wanting to universally apply “2>/dev/null” to all platforms, then that’s good.

setterm -blank 0 2>/dev/null
true "$0: exit code: $?"
setterm -powerdown 0 2>/dev/null
true "$0: exit code: $?"

[hr]

If wanting to apply “2>/dev/null” to Qubes only…

Maybe instead it would work to substitute in the following directory as the Qubes platform conditional check?

/usr/lib/qubes
if [ -d "/usr/lib/qubes" ]; then
   setterm -blank 0 2>/dev/null
   true "$0: exit code: $?"
   setterm -powerdown 0 2>/dev/null
   true "$0: exit code: $?"
else
   setterm -blank 0
   true "$0: exit code: $?"
   setterm -powerdown 0
   true "$0: exit code: $?"
fi
13

Looks good.

14

Added this:
https://github.com/Whonix/power-savings-disable-in-vms/commit/94dbabd43c54305822d7f045a7eb456db9d683d5

Are you sure there will be a /usr/lib/qubes folder?

The whonix-qubes package does not contain one. See qubes-whonix/usr/lib at master · nrgaway/qubes-whonix · GitHub.

15

[quote=“Patrick, post:14, topic:763”]Added this:
https://github.com/Whonix/power-savings-disable-in-vms/commit/94dbabd43c54305822d7f045a7eb456db9d683d5

Are you sure there will be a /usr/lib/qubes folder?

The whonix-qubes package does not contain one. See https://github.com/nrgaway/whonix-qubes/tree/master/usr/lib.[/quote]

The “/usr/lib/qubes” directory is a part of Qubes, so it is expected to NOT be in the “whonix-qubes” package made by nrgaway.

I just confirmed that “/usr/lib/qubes” it is present in the Qubes Fedora and Whonix templates, as well as all ProxyVMs and AppVMs that are created from these templates, including Whonix-Gateway ProxyVMs and Whonix-Workstation AppVMs.

It does seem to be always present from what I can tell by looking in various Qubes VMs.

It contains several Qubes system files:

ls /usr/lib/qubes

close-window
dispvm-prerun.sh
init
iptables-updates-proxy
network-manager-prepare-conf-dir
prepare-suspend
qfile-agent
qfile-unpacker
qopen-in-vm
qrexec-agent
qrexec_client_vm
qrexec-client-vm
qrun-in-vm
qubes-fix-nm-conf.sh
qubes-rpc-multiplexer
qubes-setup-dnat-to-ns
qubes-trigger-sync-appmenus.sh
qvm-copy-to-vm.gnome
qvm-copy-to-vm.kde
qvm-move-to-vm.gnome
qvm-move-to-vm.kde
setup-ip
show-hide-nm-applet.sh
sync-ntp-clock
tar2qfile
vm-file-editor
vusb-ctl.py
wrap-in-html-if-url.sh
16

Sounds good. So https://github.com/Whonix/power-savings-disable-in-vms/commit/94dbabd43c54305822d7f045a7eb456db9d683d5 should do.

Can you test please?

You just need this updated file:
https://github.com/Whonix/power-savings-disable-in-vms/blob/master/etc/profile.d/20_power_savings_disable_in_vms.sh

Get it either way. Copy/paste manually or install the upgraded package.

17

Just tested and confirmed as working in Qubes.

Working as in it now successfully allows commands to execute without error: “setterm: $TERM is not defined.”

18

You were getting this “setterm: $TERM is not defined.” for executing each and every command?

https://github.com/Whonix/power-savings-disable-in-vms/blob/master/etc/profile.d/20_power_savings_disable_in_vms.sh should only be executed after login to a virtual console.

If it happens for each and every command in a terminal emulator (ex: Konsole) (?), then it would mean that script is executed every time you type a command. That would be a Qubes specific bug, that would cause a lot unnecessary system load that should be fixed.

To make sure, consider adding some debug output to /etc/profile.d/20_power_savings_disable_in_vms.sh such as

echo "$0: debug"

after

#!/bin/bash
19

Not in the Whonix VMs themselves.
Yes in Qubes Dom0 Terminal using qvm-* commands.

https://qubes-os.org/wiki/DomZeroTools

[quote=“Patrick, post:18, topic:763”]To make sure, consider adding some debug output to /etc/profile.d/20_power_savings_disable_in_vms.sh such as

echo "$0: debug"

after

#!/bin/bash

This echos the following in Qubes Dom0 Terminal along with the additional output of the qvm-* commands:

-su: debug
20

Looks like a Qubes bug to me. Or just a strange way to implement this.