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

Stretch template slow boot time #2913

Closed
unman opened this Issue Jul 17, 2017 · 19 comments

Comments

Projects
None yet
3 participants
@unman
Member

unman commented Jul 17, 2017

Qubes OS version (e.g., R3.2):

R3.2

Affected TemplateVMs (e.g., fedora-23, if applicable):

Stretch


Expected behavior:

Template or Template-based-VM will boot normally

Actual behavior:

Very slow boot time - 90-120 secs.

Steps to reproduce the behavior:

Install Stretch template.
Fix X issues - see #2909
Start template or TemplateBasedVM

General notes:

delay seems to be on sys-subsytem-net-devices-multi-user.device


Related issues:

@tasket

This comment has been minimized.

Show comment
Hide comment
@tasket

tasket Nov 3, 2017

The delay is still there with the build from today.

Template upgraded from jessie to stretch doesn't have this issue.

tasket commented Nov 3, 2017

The delay is still there with the build from today.

Template upgraded from jessie to stretch doesn't have this issue.

@tasket

This comment has been minimized.

Show comment
Hide comment
@tasket

tasket Nov 9, 2017

Looking at the differences between upgraded debian-8-to-9 and the qubes-template-debian-9 VMs, I found this in the stalling (latter) one:

/etc/systemd/system/multi-user.target.wants/wpa_supplicant@.service

This was alongside wpa_supplicant.service (without 'at' symbol). So I deleted wpa_supplicant@.service and now the template and VMs based on it are booting fine, without the 90sec delay.

tasket commented Nov 9, 2017

Looking at the differences between upgraded debian-8-to-9 and the qubes-template-debian-9 VMs, I found this in the stalling (latter) one:

/etc/systemd/system/multi-user.target.wants/wpa_supplicant@.service

This was alongside wpa_supplicant.service (without 'at' symbol). So I deleted wpa_supplicant@.service and now the template and VMs based on it are booting fine, without the 90sec delay.

@tasket

This comment has been minimized.

Show comment
Hide comment
@tasket

tasket Nov 9, 2017

Wondering how this 'extra' link got into /etc, I noticed that qubes-builder-debian lists wpasupplicant in packages_wheezy.list and packages_stretch.list... but not packages_jessie.list.

tasket commented Nov 9, 2017

Wondering how this 'extra' link got into /etc, I noticed that qubes-builder-debian lists wpasupplicant in packages_wheezy.list and packages_stretch.list... but not packages_jessie.list.

@tasket

This comment has been minimized.

Show comment
Hide comment
@tasket

tasket Nov 11, 2017

BTW full path and command is:

sudo rm /etc/systemd/system/multi-user.target.wants/wpa_supplicant@.service

tasket commented Nov 11, 2017

BTW full path and command is:

sudo rm /etc/systemd/system/multi-user.target.wants/wpa_supplicant@.service
@unman

This comment has been minimized.

Show comment
Hide comment
@unman

unman Nov 14, 2017

Member

wpasupplicant is installed in jessie as well as stretch, so the absence from packages is neither here nor there.
Deleting the link from multi-user.target.wants doesn't fix the issue for me.
@tasket Did you make any other changes?

Member

unman commented Nov 14, 2017

wpasupplicant is installed in jessie as well as stretch, so the absence from packages is neither here nor there.
Deleting the link from multi-user.target.wants doesn't fix the issue for me.
@tasket Did you make any other changes?

@tasket

This comment has been minimized.

Show comment
Hide comment
@tasket

tasket Nov 14, 2017

No other changes I recall. Will try again with a fresh template.

Remember, wpa_supplicant.service is still there in debian-8 and debian-9. But debian-9 also has another link to service with at-sign; its this one I deleted.

tasket commented Nov 14, 2017

No other changes I recall. Will try again with a fresh template.

Remember, wpa_supplicant.service is still there in debian-8 and debian-9. But debian-9 also has another link to service with at-sign; its this one I deleted.

@tasket

This comment has been minimized.

Show comment
Hide comment
@tasket

tasket Nov 14, 2017

@unman Tried a newly-installed debian-9 template. Bootup time = 130sec.

Then removed the @.service link then boot time = 12sec.

The template version I'm using is 9-4.0.0-201711030329

tasket commented Nov 14, 2017

@unman Tried a newly-installed debian-9 template. Bootup time = 130sec.

Then removed the @.service link then boot time = 12sec.

The template version I'm using is 9-4.0.0-201711030329

@tasket

This comment has been minimized.

Show comment
Hide comment
@tasket

tasket Nov 14, 2017

Re-adding the link causes template to return to 130+sec start time. The service in question has this status:

● wpa_supplicant@multi-user.service - WPA supplicant daemon (interface-specific version)
   Loaded: loaded (/lib/systemd/system/wpa_supplicant@.service; enabled; vendor preset: enabled)
   Active: inactive (dead)

Nov 14 13:37:40 debian-9 systemd[1]: Dependency failed for WPA supplicant daemon (interface-specific version).
Nov 14 13:37:40 debian-9 systemd[1]: wpa_supplicant@multi-user.service: Job wpa_supplicant@multi-user.service/start failed with result 'dependency'.

tasket commented Nov 14, 2017

Re-adding the link causes template to return to 130+sec start time. The service in question has this status:

● wpa_supplicant@multi-user.service - WPA supplicant daemon (interface-specific version)
   Loaded: loaded (/lib/systemd/system/wpa_supplicant@.service; enabled; vendor preset: enabled)
   Active: inactive (dead)

Nov 14 13:37:40 debian-9 systemd[1]: Dependency failed for WPA supplicant daemon (interface-specific version).
Nov 14 13:37:40 debian-9 systemd[1]: wpa_supplicant@multi-user.service: Job wpa_supplicant@multi-user.service/start failed with result 'dependency'.
@tasket

This comment has been minimized.

Show comment
Hide comment
@tasket

tasket Nov 14, 2017

More complete from journalctl:

Nov 14 13:55:13 debian-9 systemd[1]: sys-subsystem-net-devices-multi-user.device: Job sys-subsystem-net-devices-multi-user.device/start timed out.
Nov 14 13:55:13 debian-9 systemd[1]: Timed out waiting for device sys-subsystem-net-devices-multi-user.device.
Nov 14 13:55:13 debian-9 systemd[1]: Dependency failed for WPA supplicant daemon (interface-specific version).
Nov 14 13:55:13 debian-9 systemd[1]: wpa_supplicant@multi-user.service: Job wpa_supplicant@multi-user.service/start failed with result 'dependency'.
Nov 14 13:55:13 debian-9 systemd[1]: sys-subsystem-net-devices-multi-user.device: Job sys-subsystem-net-devices-multi-user.device/start failed with result 'timeout'.

tasket commented Nov 14, 2017

More complete from journalctl:

Nov 14 13:55:13 debian-9 systemd[1]: sys-subsystem-net-devices-multi-user.device: Job sys-subsystem-net-devices-multi-user.device/start timed out.
Nov 14 13:55:13 debian-9 systemd[1]: Timed out waiting for device sys-subsystem-net-devices-multi-user.device.
Nov 14 13:55:13 debian-9 systemd[1]: Dependency failed for WPA supplicant daemon (interface-specific version).
Nov 14 13:55:13 debian-9 systemd[1]: wpa_supplicant@multi-user.service: Job wpa_supplicant@multi-user.service/start failed with result 'dependency'.
Nov 14 13:55:13 debian-9 systemd[1]: sys-subsystem-net-devices-multi-user.device: Job sys-subsystem-net-devices-multi-user.device/start failed with result 'timeout'.
@unman

This comment has been minimized.

Show comment
Hide comment
@unman

unman Nov 14, 2017

Member

Ok thanks for that. I'll have to see why it isnt working for me.

Member

unman commented Nov 14, 2017

Ok thanks for that. I'll have to see why it isnt working for me.

@tasket

This comment has been minimized.

Show comment
Hide comment
@tasket

tasket Nov 14, 2017

I can also report that adding the @.service link to my upgraded-8-to-9 template causes the delay to appear for the same 1:30 duration. (Prior comments said "130sec" but its really 1m 30sec; sorry about that.)

tasket commented Nov 14, 2017

I can also report that adding the @.service link to my upgraded-8-to-9 template causes the delay to appear for the same 1:30 duration. (Prior comments said "130sec" but its really 1m 30sec; sorry about that.)

@unman

This comment has been minimized.

Show comment
Hide comment
@unman

unman Nov 16, 2017

Member

So a newly built stretch template DOES show the interaction with @.service that @tasket describes, but my more elderly not updated template did not (afaik).
However, new builds DO show that behaviour.
We cant simply delete the wpasupplicant service because from a quick test it will break use of wifi in a stretch based sys-net. @tasket Can you check this?

Member

unman commented Nov 16, 2017

So a newly built stretch template DOES show the interaction with @.service that @tasket describes, but my more elderly not updated template did not (afaik).
However, new builds DO show that behaviour.
We cant simply delete the wpasupplicant service because from a quick test it will break use of wifi in a stretch based sys-net. @tasket Can you check this?

@tasket

This comment has been minimized.

Show comment
Hide comment
@tasket

tasket Nov 16, 2017

I've been using for sys-net an upgraded-to-9 template with wpasupplicant for almost a week, no problems. Of course, it contains a link to regular .service but not for the @.service.

Question: Does a regular Debian 9 install setup this @.service link, or could this be some artifact from the template building process? I have to wonder since apt upgrade process doesn't put it there.

tasket commented Nov 16, 2017

I've been using for sys-net an upgraded-to-9 template with wpasupplicant for almost a week, no problems. Of course, it contains a link to regular .service but not for the @.service.

Question: Does a regular Debian 9 install setup this @.service link, or could this be some artifact from the template building process? I have to wonder since apt upgrade process doesn't put it there.

@unman

This comment has been minimized.

Show comment
Hide comment
@unman

unman Nov 17, 2017

Member

No a standard install on laptop with wifi adapter doesn't include EITHER service in the "wants": neither the regular nor the @ service.
It isn't there in the "prepared" image and is in the qubeized image. The fact that the link is set up in qubeization explains why the @ link is not present in upgraded-to-stretch templates. Interesting.

Member

unman commented Nov 17, 2017

No a standard install on laptop with wifi adapter doesn't include EITHER service in the "wants": neither the regular nor the @ service.
It isn't there in the "prepared" image and is in the qubeized image. The fact that the link is set up in qubeization explains why the @ link is not present in upgraded-to-stretch templates. Interesting.

@unman

This comment has been minimized.

Show comment
Hide comment
@unman

unman Dec 13, 2017

Member

@tasket - would it be possible for you to test using a Debian-9 (not upgraded from 8) for sys-net, with the @.service link removed?
I have limited wifi adapters and they dont play well with NetworkManager anyway - everything works just fine with wicd.

Member

unman commented Dec 13, 2017

@tasket - would it be possible for you to test using a Debian-9 (not upgraded from 8) for sys-net, with the @.service link removed?
I have limited wifi adapters and they dont play well with NetworkManager anyway - everything works just fine with wicd.

@tasket

This comment has been minimized.

Show comment
Hide comment
@tasket

tasket Dec 13, 2017

@unman - OK. New template installed. Removed the @ link. Installed firmware-iwlwifi package.
Setup netvm. Works!

But doesn't work for me without adding firmware-iwlwifi.

tasket commented Dec 13, 2017

@unman - OK. New template installed. Removed the @ link. Installed firmware-iwlwifi package.
Setup netvm. Works!

But doesn't work for me without adding firmware-iwlwifi.

@unman

This comment has been minimized.

Show comment
Hide comment
@unman

unman Dec 13, 2017

Member

@tasket - Excellent - thanks for that.
Obviously the firmware requirement will be dependent on the NIC and isn't included in standard packages.

Member

unman commented Dec 13, 2017

@tasket - Excellent - thanks for that.
Obviously the firmware requirement will be dependent on the NIC and isn't included in standard packages.

@unman unman referenced this issue in QubesOS/qubes-core-agent-linux Dec 14, 2017

Merged

Disable wpa_supplicant@.service #78

marmarek added a commit to marmarek/qubes-core-agent-linux that referenced this issue Dec 15, 2017

debian: use systemd-preset logic from rpm package
It is more robust, especially handle "# Units below this line will be
re-preset on package upgrade" part of 75-qubes-vm.preset file. This is
needed to fix system configuration without the need to rebuild the whole
template.

QubesOS/qubes-issues#2913

marmarek added a commit to marmarek/qubes-core-agent-linux that referenced this issue Dec 15, 2017

debian: use systemd-preset logic from rpm package
It is more robust, especially handle "# Units below this line will be
re-preset on package upgrade" part of 75-qubes-vm.preset file. This is
needed to fix system configuration without the need to rebuild the whole
template.

QubesOS/qubes-issues#2913

(cherry picked from commit d5fe5ae)

marmarek added a commit to marmarek/qubes-core-agent-linux that referenced this issue Dec 15, 2017

debian: use systemd-preset logic from rpm package
It is more robust, especially handle "# Units below this line will be
re-preset on package upgrade" part of 75-qubes-vm.preset file. This is
needed to fix system configuration without the need to rebuild the whole
template.

QubesOS/qubes-issues#2913

marmarek added a commit to marmarek/qubes-core-agent-linux that referenced this issue Dec 15, 2017

debian: use systemd-preset logic from rpm package
It is more robust, especially handle "# Units below this line will be
re-preset on package upgrade" part of 75-qubes-vm.preset file. This is
needed to fix system configuration without the need to rebuild the whole
template.

QubesOS/qubes-issues#2913

marmarek added a commit to QubesOS/qubes-core-agent-linux that referenced this issue Dec 15, 2017

debian: use systemd-preset logic from rpm package
It is more robust, especially handle "# Units below this line will be
re-preset on package upgrade" part of 75-qubes-vm.preset file. This is
needed to fix system configuration without the need to rebuild the whole
template.

QubesOS/qubes-issues#2913

(cherry picked from commit 47e6a84)
@tasket

This comment has been minimized.

Show comment
Hide comment
@tasket

tasket Dec 16, 2017

@unman - Did I mention I'm using R4.0-rc3? (Probably doesn't matter though.)

tasket commented Dec 16, 2017

@unman - Did I mention I'm using R4.0-rc3? (Probably doesn't matter though.)

@unman

This comment has been minimized.

Show comment
Hide comment
@unman

unman Feb 2, 2018

Member

After disabling wpa_supplicant (thanks @tasket), problem is resolved.

Member

unman commented Feb 2, 2018

After disabling wpa_supplicant (thanks @tasket), problem is resolved.

@unman unman closed this Feb 2, 2018

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