Snappy

ubuntu-snappy.firstboot fails when oem snap contains preinstalled snap

Bug #1511435 reported by Simon Eisenmann on 2015-10-29

This bug affects 2 people

Affects

Status

Importance

Assigned to

Milestone

Snappy

Fix Released

Critical

John Lenton

You need to log in to change this bug's status.

Affecting:	Snappy
Filed here by:	Simon Eisenmann
When:	2015-10-29
Confirmed:	2015-10-29
Assigned:	2015-11-10
Started work:	2015-11-10
Completed:	2016-11-29

Target

Distribution
Package	(Find…)
Project	(Find…)

Status	Importance
	Critical

Assigned to

	Me
	John Lenton (chipaca)

Comment on this change (optional)

Email me about changes to this bug report

(?)

Bug Description

sudo systemctl status ubuntu-snappy.firstboot.service -l
● ubuntu-snappy.firstboot.service - Run snappy firstboot setup
   Loaded: loaded (/lib/systemd/system/ubuntu-snappy.firstboot.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Thu 2015-10-29 15:26:16 UTC; 4min 0s ago
  Process: 808 ExecStart=/usr/bin/snappy firstboot (code=exited, status=1/FAILURE)
Main PID: 808 (code=exited, status=1/FAILURE)

Oct 29 15:26:15 localhost.localdomain systemd[1]: Starting Run snappy firstboot setup...
Oct 29 15:26:16 localhost.localdomain snappy[808]: config failed with: 'aa-exec: ERROR: profile 'spreed-webrtc.sideload_snappy-config_IENQKIBcWPBJ' does not exist
Oct 29 15:26:16 localhost.localdomain snappy[808]: ' (exit status 1)
Oct 29 15:26:16 localhost.localdomain systemd[1]: ubuntu-snappy.firstboot.service: main process exited, code=exited, status=1/FAILURE
Oct 29 15:26:16 localhost.localdomain systemd[1]: Failed to start Run snappy firstboot setup.
Oct 29 15:26:16 localhost.localdomain systemd[1]: Unit ubuntu-snappy.firstboot.service entered failed state.
Oct 29 15:26:16 localhost.localdomain systemd[1]: ubuntu-snappy.firstboot.service failed.

This happens on the first boot of the created image with u-d-f build with an OEM snap which contains preinstalled: spreed-webrtc

Add tags Tag help

Simon Eisenmann (longsleep) wrote on 2015-10-29:

Seen on 15.04/stable (armhf)

Simon Eisenmann (longsleep) wrote on 2015-10-29:

Same problem with 15.04/edge

John Lenton (chipaca) on 2015-10-29

Changed in snappy:
status:	New → Confirmed
importance:	Undecided → Critical

Joachim Bauch (fancycode) wrote on 2015-10-30:

Also happens with non-sideloaded snaps:

● ubuntu-snappy.firstboot.service - Run snappy firstboot setup
   Loaded: loaded (/lib/systemd/system/ubuntu-snappy.firstboot.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Fri 2015-10-30 11:13:25 UTC; 1min 6s ago
  Process: 806 ExecStart=/usr/bin/snappy firstboot (code=exited, status=1/FAILURE)
Main PID: 806 (code=exited, status=1/FAILURE)

Oct 30 11:13:24 localhost.localdomain systemd[1]: Starting Run snappy firstboot setup...
Oct 30 11:13:25 localhost.localdomain snappy[806]: config failed with: 'aa-exec: ERROR: profile 'spreed-webrtc.longsleep_snappy-config_0.24.8-4' does not exist
Oct 30 11:13:25 localhost.localdomain snappy[806]: ' (exit status 1)
Oct 30 11:13:25 localhost.localdomain systemd[1]: ubuntu-snappy.firstboot.service: main process exited, code=exited, status=1/FAILURE
Oct 30 11:13:25 localhost.localdomain systemd[1]: Failed to start Run snappy firstboot setup.
Oct 30 11:13:25 localhost.localdomain systemd[1]: Unit ubuntu-snappy.firstboot.service entered failed state.
Oct 30 11:13:25 localhost.localdomain systemd[1]: ubuntu-snappy.firstboot.service failed.

John Lenton (chipaca) wrote on 2015-11-09:

snappy-systems_fail-built-in-config.diff Edit (486 bytes, text/plain)

Easy way to reproduce:

* branch snappy-systems, patch with attached diff, build oem package
* build system with that oem package
* boot it
* look at ubuntu-snappy.firstboot.service; notice it's marked as failed, and “sudo journalctl -u ubuntu-snappy.firstboot.service” tells you why.

John Lenton (chipaca) wrote on 2015-11-09:

The fix is to ensure run-hooks is run before firstboot.

John Lenton (chipaca) on 2015-11-10

Changed in snappy:
assignee:	nobody → John Lenton (chipaca)
status:	Confirmed → In Progress

Simon Eisenmann (longsleep) wrote on 2015-11-13:

When running run-hooks before firstboot is has the side effact that snap services start before firstboot. It lets firstboot run through fine, though all configuration applied by it is not there as firstboot ran too late.

A workaround is to add a external port to the service. That makes it run after snappy-wait4network.service which is after firstboot.

Michael Vogt (mvo) wrote on 2016-11-29:

This mechanism got reworked in ubuntu core 16 and firstboot and pre-installed snaps works now.