New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sys-net still starts automatically after deselecting "Start VM automatically on boot" #3606

Open
andrewdavidwong opened this Issue Feb 19, 2018 · 1 comment

Comments

Projects
None yet
2 participants
@andrewdavidwong
Member

andrewdavidwong commented Feb 19, 2018

Qubes OS version:

R3.2


Steps to reproduce the behavior:

  1. In Qubes Manager, open the VM settings for sys-net.
  2. Deselect "Start VM automatically on boot".
  3. Click "OK".
  4. Reboot the whole system.

Expected behavior:

sys-net no longer starts automatically on boot.

Actual behavior:

sys-net still starts automatically on boot.

General notes:

In order to stop sys-net from starting automatically on boot, the user has to enter this command:

systemctl disable qubes-netvm.service

This is exactly what deselecting "Start VM automatically on boot" should do.


Related issues:

#3554

@donob4n

This comment has been minimized.

Show comment
Hide comment
@donob4n

donob4n Mar 2, 2018

AFAIK, qubes-netvm.service starts the default-netvm and qubes-vm@.service's (auto started VM's?) wait for it. Maybe there are some purposes for qubes-netvm that I don't find.

I think there are three options:

  1. Since qubes-vm@.service relies on qvm-start, all netVM dependencies should start fine without the need of systemd waiting, so probably just removing qubes-netvm.service seems fine (qubes-reload-firewall also waits but it could be removed since this service won't be loaded without the VM already running)

  2. Modify qubesmanager for detect when the vm is the default netVM and ask user if wants to change default netVM or disable qubes-netvm.service

  3. Just not consider this a bug.

What do you think?

donob4n commented Mar 2, 2018

AFAIK, qubes-netvm.service starts the default-netvm and qubes-vm@.service's (auto started VM's?) wait for it. Maybe there are some purposes for qubes-netvm that I don't find.

I think there are three options:

  1. Since qubes-vm@.service relies on qvm-start, all netVM dependencies should start fine without the need of systemd waiting, so probably just removing qubes-netvm.service seems fine (qubes-reload-firewall also waits but it could be removed since this service won't be loaded without the VM already running)

  2. Modify qubesmanager for detect when the vm is the default netVM and ask user if wants to change default netVM or disable qubes-netvm.service

  3. Just not consider this a bug.

What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment