it is not possible to change user's shell

[wwaites]

changing user's shell to a more comfortable alternative such as tcsh does not work.

to duplicate the problem, install tcsh and change user's shell in the appropriate template vm.
then starting such a vm,

qvm-run -a foo-vm-tcsh gnome-terminal

will hang waiting for qrexec agent.

[marmarek]

Not sure if relevant, but which template?

[marmarek]

Not sure if relevant, but which template?

[unman]

Qubes 3.2 - Specifically, it isn't possible to change shell to tcsh.
sh, dash, bash, rbash and zsh all work fine.

If the user shell is set to tcsh in the template, then AppVMs startup hangs at "Waiting for qubes-session"
If the user shell is set to rc in the template, then AppVMs appear to start properly but no display is output.
In both cases it's possible to attach console, login to user account and use as normal from command line,(including using all qubes tools).
Is this because the environment isn't set properly in /etc/csh.* ?

[unman]

Qubes 3.2 - Specifically, it isn't possible to change shell to tcsh.
sh, dash, bash, rbash and zsh all work fine.

If the user shell is set to tcsh in the template, then AppVMs startup hangs at "Waiting for qubes-session"
If the user shell is set to rc in the template, then AppVMs appear to start properly but no display is output.
In both cases it's possible to attach console, login to user account and use as normal from command line,(including using all qubes tools).
Is this because the environment isn't set properly in /etc/csh.* ?

[marmarek]

Maybe lack of /etc/profile.d/qubes-session.csh? Some logs would be useful, especially ~/.xsession-errors.

[marmarek]

Maybe lack of /etc/profile.d/qubes-session.csh? Some logs would be useful, especially ~/.xsession-errors.

[unman]

@marmarek This is just down to syntax.
qubes-run-xorg.sh contains:
exec su -l user -c "/usr/bin/xinit $XSESSION -- $XORG :0 -nolisten tcp vt07 -wr -config xorg-qubes.conf > ~/.xsession-errors 2>&1"

Neither tcsh or rc like that redirect syntax. If it's replaced with native forms, (or redirect of standard error is removed), the the appVMs start correctly. I haven't tested them in any detail, but they seem to work fine once this is fixed.
I think the best way to close this is with an entry in FAQ detailing solution. Agreed?

[unman]

@marmarek This is just down to syntax.
qubes-run-xorg.sh contains:
exec su -l user -c "/usr/bin/xinit $XSESSION -- $XORG :0 -nolisten tcp vt07 -wr -config xorg-qubes.conf > ~/.xsession-errors 2>&1"

Neither tcsh or rc like that redirect syntax. If it's replaced with native forms, (or redirect of standard error is removed), the the appVMs start correctly. I haven't tested them in any detail, but they seem to work fine once this is fixed.
I think the best way to close this is with an entry in FAQ detailing solution. Agreed?

[marmarek]

Is there a syntax for redirecting both stdout and stderr that would work on all shells? If so, lets just use it.

[marmarek]

Is there a syntax for redirecting both stdout and stderr that would work on all shells? If so, lets just use it.

[unman]

I really dont think there is. In place of > ~/.xsession-errors 2>&1
tcsh has >& ~/.xsession-errors
rc has > ~/.xsession-errors >[2=1]

Interestingly, fish (implicated in #2596 ) does support2>&1, so there must be something else going on there.

[unman]

I really dont think there is. In place of > ~/.xsession-errors 2>&1
tcsh has >& ~/.xsession-errors
rc has > ~/.xsession-errors >[2=1]

Interestingly, fish (implicated in #2596 ) does support2>&1, so there must be something else going on there.

[marmarek]

Maybe another wrapper script (with #!/bin/sh), which would setup redirection, then exec that xinit command? What do you think?

Otherwise, indeed the "solution" would be a FAQ entry and not fix it at all.

[marmarek]

Maybe another wrapper script (with #!/bin/sh), which would setup redirection, then exec that xinit command? What do you think?

Otherwise, indeed the "solution" would be a FAQ entry and not fix it at all.

[tikums]

I can confirm: changing default login shell ("chsh -s /bin/zsh") in a Fedora template prevents some services from starting up properly. Demonstrably, changing the login shell breaks audio in the AppVM and TemplateVM, reverting the shell back to default fixes the issue on next reboot. This is also visible by investigating the difference of "systemctl status --all" output. If the login shell is changed, session-c2.scope does not start pulseaudio.

[tikums]

I can confirm: changing default login shell ("chsh -s /bin/zsh") in a Fedora template prevents some services from starting up properly. Demonstrably, changing the login shell breaks audio in the AppVM and TemplateVM, reverting the shell back to default fixes the issue on next reboot. This is also visible by investigating the difference of "systemctl status --all" output. If the login shell is changed, session-c2.scope does not start pulseaudio.

[buquser]

I can confirm that the fish shell doesn't work properly as well.
If I run a command directly after startup the environment is not set up completely.
So if I start a program with qvm-run -a -p appvm the variable "DISPLAY" is not set and programs like firefox fail. If I run the command a second time, so the appvm is already running the variable "DISPLAY" is set and everything works fine.

For reproducing:
install fish
run qvm-run -p -a appvm env twice. Only after the second run the envoriment is set up properly.

[buquser]

I can confirm that the fish shell doesn't work properly as well.
If I run a command directly after startup the environment is not set up completely.
So if I start a program with qvm-run -a -p appvm the variable "DISPLAY" is not set and programs like firefox fail. If I run the command a second time, so the appvm is already running the variable "DISPLAY" is set and everything works fine.

For reproducing:
install fish
run qvm-run -p -a appvm env twice. Only after the second run the envoriment is set up properly.

[larsthegeek]

I just finished debugging a similar issue with ZSH, wherein qvm-run would not work with any commands that produced a graphical output. Commands like "qvm-run -a -p work 'env'" work correctly but "qvm-run -a -p work xterm" would error. My solution (correct or not) was to source /etc/profile from /etc/zsh/zprofile. After I did that in my template-vm "qvm-run" commands began working again.

[larsthegeek]

I just finished debugging a similar issue with ZSH, wherein qvm-run would not work with any commands that produced a graphical output. Commands like "qvm-run -a -p work 'env'" work correctly but "qvm-run -a -p work xterm" would error. My solution (correct or not) was to source /etc/profile from /etc/zsh/zprofile. After I did that in my template-vm "qvm-run" commands began working again.

[unman]

@larsthegeek What did you have in /etc/profile and /etc/zsh/zprofile.?

[unman]

@larsthegeek What did you have in /etc/profile and /etc/zsh/zprofile.?

[larsthegeek]

@unman, the problems existed in my debian-10 template. /etc/profile was unchanged from the default:

# /etc/profile: system-wide .profile file for the Bourne shell (sh(1))
# and Bourne compatible shells (bash(1), ksh(1), ash(1), ...).

if [ "`id -u`" -eq 0 ]; then
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
  PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi
export PATH

if [ "${PS1-}" ]; then
  if [ "${BASH-}" ] && [ "$BASH" != "/bin/sh" ]; then
    # The file bash.bashrc already sets the default PS1.
    # PS1='\h:\w\$ '
    if [ -f /etc/bash.bashrc ]; then
      . /etc/bash.bashrc
    fi
  else
    if [ "`id -u`" -eq 0 ]; then
      PS1='# '
    else
      PS1='$ '
    fi
  fi
fi

if [ -d /etc/profile.d ]; then
  for i in /etc/profile.d/*.sh; do
    if [ -r $i ]; then
      . $i
    fi
  done
  unset i
fi

/etc/zsh/zprofile simply contains "source /etc/profile"

I'm fairly certain the problem lies with zsh not sourcing the qubes-related files in /etc/profile.d, namely

• qubes-gpg.sh
• qubes-gui.sh
• qubes-session.sh

Tracing through the files, it seems /etc/profile.d/qubes-session.sh sources /tmp/qubes-session-env, where most of the necessary environment variables appear to passed.

I've been using zsh with all of my debian-based templates for quite some time and I'm not sure what changed to cause zsh to no longer properly acquire the environment variables. Oddly enough, I've not had to edit /etc/zsh/zprofile on my qubes v 4 system, only on my qubes 3.2 system.

Also, I must be completely missing it but I can't find where (on the qubes v4 system) the qubes environment variables are being sourced by zsh.

[larsthegeek]

@unman, the problems existed in my debian-10 template. /etc/profile was unchanged from the default:

# /etc/profile: system-wide .profile file for the Bourne shell (sh(1))
# and Bourne compatible shells (bash(1), ksh(1), ash(1), ...).

if [ "`id -u`" -eq 0 ]; then
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
  PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi
export PATH

if [ "${PS1-}" ]; then
  if [ "${BASH-}" ] && [ "$BASH" != "/bin/sh" ]; then
    # The file bash.bashrc already sets the default PS1.
    # PS1='\h:\w\$ '
    if [ -f /etc/bash.bashrc ]; then
      . /etc/bash.bashrc
    fi
  else
    if [ "`id -u`" -eq 0 ]; then
      PS1='# '
    else
      PS1='$ '
    fi
  fi
fi

if [ -d /etc/profile.d ]; then
  for i in /etc/profile.d/*.sh; do
    if [ -r $i ]; then
      . $i
    fi
  done
  unset i
fi

/etc/zsh/zprofile simply contains "source /etc/profile"

I'm fairly certain the problem lies with zsh not sourcing the qubes-related files in /etc/profile.d, namely

• qubes-gpg.sh
• qubes-gui.sh
• qubes-session.sh

Tracing through the files, it seems /etc/profile.d/qubes-session.sh sources /tmp/qubes-session-env, where most of the necessary environment variables appear to passed.

I've been using zsh with all of my debian-based templates for quite some time and I'm not sure what changed to cause zsh to no longer properly acquire the environment variables. Oddly enough, I've not had to edit /etc/zsh/zprofile on my qubes v 4 system, only on my qubes 3.2 system.

Also, I must be completely missing it but I can't find where (on the qubes v4 system) the qubes environment variables are being sourced by zsh.