#956 Fedora-28-updates-20181101.1 DOOMED
Opened 2 years ago by dustymabe. Modified 2 years ago

pungi.global.log

  • No Task ID, look at log statement
[ERROR   ] [FAIL] Ostree (variant Everything, arch x86_64) failed, but going on anyway.
[ERROR   ] Runroot task failed: None. See /mnt/koji/compose/updates/Fedora-28-updates-20181101.1/logs/x86_64/Everything/ostree-4/runroot.log for more details.
  • No Task ID, look at log statement
[ERROR   ] [FAIL] Ostree (variant Everything, arch ppc64le) failed, but going on anyway.
[ERROR   ] Runroot task failed: None. See /mnt/koji/compose/updates/Fedora-28-updates-20181101.1/logs/ppc64le/Everything/ostree-2/runroot.log for more details.
  • No Task ID, look at log statement
[ERROR   ] [FAIL] Ostree (variant Everything, arch aarch64) failed, but going on anyway.
[ERROR   ] Runroot task failed: None. See /mnt/koji/compose/updates/Fedora-28-updates-20181101.1/logs/aarch64/Everything/ostree-3/runroot.log for more details.
  • Compose run failed because: - No Task ID, look at log statement
[ERROR   ] Compose run failed: Runroot task failed: None. See /mnt/koji/compose/updates/Fedora-28-updates-20181101.1/logs/x86_64/Everything/ostree-1/runroot.log for more details.

interesting errors from the runroot logs:

error: With policy root '/proc/self/fd/42/etc/selinux/targeted': selabel_open(SELABEL_CTX_FILE): No such file or directory

@jlebon - do these messages ring any bells?

i can try to run this compose locally and see if I have the same issues. if we are blocked right now on this then I would say we can remove the ostree parts of the compose and continue on.

@sinnykumari may also be able to investigate in the morning.

Hmm, yeah I think this might be a regression from https://github.com/projectatomic/rpm-ostree/pull/1630. Investigating.

Note the way I reproduced this was to enable SELINUX in /etc/selinux/config and then do e.g. mv /etc/selinux/targeted{,.bak} so that loading the policy failed. If that's what pungi is hitting, either it should make sure selinux-policy-targeted is installed, or SELINUX should be disabled. Enabling it in the config but not providing the policy doesn't sound right.

Anyway, I think the patch above still makes sense since we don't technically need the host sepolicy at compose time in non-unified core mode.

thanks @jlebon - once that PR gets merged can we backport and submit a BRO? I think that will get us unblocked.

(I'll let one of you set up the BRO since I'm not sure how long you'd like it active for).

@jlebon Thanks for your help, I will take care of it. Probably we need it for few days until we get it to stable, so that the daily runs wont fail.

Login to comment on this ticket.

Metadata