https://code.engineering.redhat.com/gerrit/#/c/106608/

The changes in comment #2 into installer-post.ks seem to cause the rpm-ostree-toolbox throw a traceback while generating an install_tree.

"""
(686/687) [100%] installing iwl3945-firmware-15.32.2.9-52.el7.noarch
(687/687) [100%] installing iwl7260-firmware-22.0.7.0-52.el7.noarch
2017-05-19 20:42:58,779: plymouth.x86_64 0:0.8.9-0.26.20140113.el7 - u scriptlet output:
2661 blocks

plymouth.x86_64 0:0.8.9-0.26.20140113.el7 - u scriptlet output:
2661 blocks

2017-05-19 20:44:01,394: kernel.x86_64 0:3.10.0-663.el7 - i scriptlet output:
No '/dev/log' or 'logger' included for syslog logging

kernel.x86_64 0:3.10.0-663.el7 - i scriptlet output:
No '/dev/log' or 'logger' included for syslog logging

Traceback (most recent call last):
  File "/usr/sbin/lorax", line 337, in <module>
    main(sys.argv)
  File "/usr/sbin/lorax", line 235, in main
    remove_temp=True)
  File "/usr/lib/python2.7/site-packages/pylorax/__init__.py", line 259, in run
    rb.install()
  File "/usr/lib/python2.7/site-packages/pylorax/treebuilder.py", line 116, in install
    self._runner.run(tmpl, **self.add_template_vars)
  File "/usr/lib/python2.7/site-packages/pylorax/ltmpl.py", line 181, in run
    commands = t.parse(templatefile, variables)
  File "/usr/lib/python2.7/site-packages/pylorax/ltmpl.py", line 50, in parse
    template = lookup.get_template(template_file)
  File "/usr/lib/python2.7/site-packages/mako/lookup.py", line 245, in get_template
    return self._load(srcfile, uri)
  File "/usr/lib/python2.7/site-packages/mako/lookup.py", line 311, in _load
    **self.template_args)
  File "/usr/lib/python2.7/site-packages/mako/template.py", line 321, in __init__
    module = self._compile_from_file(path, filename)
  File "/usr/lib/python2.7/site-packages/mako/template.py", line 399, in _compile_from_file
    filename)
  File "/usr/lib/python2.7/site-packages/mako/template.py", line 647, in _compile_text
    generate_magic_comment=template.disable_unicode)
  File "/usr/lib/python2.7/site-packages/mako/template.py", line 628, in _compile
    node = lexer.parse()
  File "/usr/lib/python2.7/site-packages/mako/lexer.py", line 232, in parse
    if self.match_expression():
  File "/usr/lib/python2.7/site-packages/mako/lexer.py", line 395, in match_expression
    lineno=line, pos=pos)
  File "/usr/lib/python2.7/site-packages/mako/lexer.py", line 132, in append_node
    node = nodecls(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/mako/parsetree.py", line 180, in __init__
    self.code = ast.PythonCode(text, **self.exception_kwargs)
  File "/usr/lib/python2.7/site-packages/mako/ast.py", line 37, in __init__
    expr = pyparser.parse(code.lstrip(), "exec", **exception_kwargs)
  File "/usr/lib/python2.7/site-packages/mako/pyparser.py", line 60, in parse
    ), **exception_kwargs)
mako.exceptions.SyntaxException: (SyntaxError) invalid syntax (<unknown>, line 1) (u'ostree_remote:-') in file '/root/lorax.tmpl' at line: 15 char: 779
Traceback (most recent call last):
  File "/usr/lib64/rpm-ostree-toolbox/py/rpmostreecompose-main", line 75, in <module>
    main()
  File "/usr/lib64/rpm-ostree-toolbox/py/rpmostreecompose-main", line 59, in main
    installer.main(cmd)
  File "/usr/lib64/rpm-ostree-toolbox/py/rpmostreecompose/installer.py", line 232, in main
    composer.create(post=args.post)
  File "/usr/lib64/rpm-ostree-toolbox/py/rpmostreecompose/taskbase.py", line 484, in create
    self.impl_create(**kwargs)
  File "/usr/lib64/rpm-ostree-toolbox/py/rpmostreecompose/installer.py", line 187, in impl_create
    run_sync(dr_cmd, env=child_env)
  File "/usr/lib64/rpm-ostree-toolbox/py/rpmostreecompose/utils.py", line 36, in run_sync
    subprocess.check_call(args, **kwargs)
  File "/usr/lib64/python2.7/subprocess.py", line 542, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['docker', 'run', '--rm', '--workdir', '/out', '--net=host', '--privileged=true', '-v', '/data/GA.staging/Atomic-7.4-20170519.0/x86_64/install_tree/work:/out', 'registry.access.redhat.com/rhel72/rpmostree-toolbox-lorax']' returned non-zero exit status 1
"""

We got it fixed after an update to the instaler-post.ks

After booting the most recent 7.4 cloud image (rhel-atomic-cloud-7.4.0-5.x86_64.qcow2) which corresponds to the ostree commit 0b62181fb3, the system ends up with two specifications for the 'rhel-atomic-host-ostree' remote.


# ostree remote list -u
rhel-atomic-host         http://download.eng.bos.redhat.com/devel/candidate-trees/latest-Atomic-7.4/x86_64/ostree/repo/
rhel-atomic-host-ostree  file:///install/ostree/repo

# cat /etc/ostree/remotes.d/rhel-atomic-host{,-ostree}.conf
[remote "rhel-atomic-host"]
url=http://download.eng.bos.redhat.com/devel/candidate-trees/latest-Atomic-7.4/x86_64/ostree/repo/
gpg-verify=false
[remote "rhel-atomic-host-ostree"]
# This remote configuration is just a stub; use subscription-manager or
# a local mirror of the repository.
url=file:///install/ostree/repo

# subscription-manager register  
Registering to: subscription.rhn.stage.redhat.com:443/subscription
The system has been registered with ID: df769f40-c5b2-434f-959b-e483825dc443 

Installed Product Current Status:
Product Name: Red Hat Enterprise Linux Atomic Host
Status:       Subscribed

Product Name: Red Hat Enterprise Linux Server
Status:       Subscribed

# ostree remote list -u                                                                                                                                                            
error: Multiple specifications found for remote "rhel-atomic-host-ostree"

# ls /etc/ostree/remotes.d/
redhat.conf  rhel-atomic-host.conf  rhel-atomic-host-ostree.conf

# cat /etc/ostree/remotes.d/redhat.conf 
[remote "rhel-atomic-host-ostree"]
url = https://cdn.redhat.com/content/dist/rhel/atomic/7/7Server/x86_64/ostree/repo
gpg-verify = false
tls-client-cert-path = /etc/pki/entitlement/2042810464506967397.pem
tls-client-key-path = /etc/pki/entitlement/2042810464506967397-key.pem
tls-ca-path = /etc/rhsm/ca/redhat-uep.pem



Just putting this out there as an FYI.

*** Bug 1464369 has been marked as a duplicate of this bug. ***

*** Bug 1464361 has been marked as a duplicate of this bug. ***

[root@atomic-host-test cloud-user]# atomic host status
State: idle
Deployments:
● rhel-atomic-host-ostree:rhel-atomic-host/7/x86_64/standard
                Version: 7.4.0 (2017-06-27 16:55:35)
                 Commit: 13b30690b7573d0749bf15d0e60394a5ee939a70f5272f4982fa29209042e7ad
           GPGSignature: 1 signature
                         Signature made Tue 27 Jun 2017 04:59:28 PM UTC using RSA key ID 199E2F91FD431D51
                         Good signature from "Red Hat, Inc. <security>"

[root@atomic-host-test cloud-user]# ls /etc/ostree/remotes.d/
redhat.conf  rhel-atomic-host-ostree.conf

*** Bug 1465800 has been marked as a duplicate of this bug. ***

*** Bug 1466437 has been marked as a duplicate of this bug. ***

Latest compose also has two deployments/commits listed when booting a QCOW2 cloud image for the first time:

# atomic host status
State: idle
Deployments:
● rhel-atomic-host-ostree:rhel-atomic-host/7/x86_64/standard
                Version: 7.4.0 (2017-06-27 16:55:35)
                 Commit: 13b30690b7573d0749bf15d0e60394a5ee939a70f5272f4982fa29209042e7ad

● rhel-atomic-host-ostree:rhel-atomic-host/7/x86_64/standard
                Version: 7.4.0 (2017-06-27 16:55:35)
                 Commit: 13b30690b7573d0749bf15d0e60394a5ee939a70f5272f4982fa29209042e7ad



Side-effect of having multiple remotes defined in /etc/ostree/remotes.d/  perhaps?

The findings in comment #1 still exist in the latest 7.4 compose.

I started with a system at 7.3.6 and then rebased to the the latest 7.4 compose.  I ran our automated sanity test against it and they failed because the 'unconfigured-state' line remains in the origin file.


# atomic host status 
State: idle
Deployments:
● 7.4_latest:rhel-atomic-host/7/x86_64/standard
                Version: 7.4.0 (2017-06-30 18:37:40)
                 Commit: 8018f95c2f2f38a79e68f174dd5888b53769c0e4adcd89c87a802219091c9d0e
           GPGSignature: 1 signature
                         Signature made Fri 30 Jun 2017 06:59:48 PM UTC using RSA key ID 199E2F91FD431D51
                         Good signature from "Red Hat, Inc. <security>"
               Unlocked: hotfix

  7.4_latest:rhel-atomic-host/7/x86_64/standard
                Version: 7.4.0 (2017-06-30 18:37:40)
                 Commit: 8018f95c2f2f38a79e68f174dd5888b53769c0e4adcd89c87a802219091c9d0e
           GPGSignature: 1 signature
                         Signature made Fri 30 Jun 2017 06:59:48 PM UTC using RSA key ID 199E2F91FD431D51
                         Good signature from "Red Hat, Inc. <security>"

# rpm-ostree install httpd
error: origin unconfigured-state: This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.

# cat $(ostree admin --print-current-dir).origin
[origin]
refspec=7.4_latest:rhel-atomic-host/7/x86_64/standard
unconfigured-state=This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
unlocked=hotfix

Hmm...you did a subscription *after* the rebase?  Offhand, I don't think customers can hit that case since there's no rebasing for them, just upgrades.

Basically the vast majority of cases (and I think all customer ones) fall under:

1) Upgrading a subscribed system
2) Fresh 7.4 cloud images or ISO installs

But we should fix this anyways; it's going to crop up in various ways.

(In reply to Colin Walters from comment #20)
> Hmm...you did a subscription *after* the rebase?  Offhand, I don't think
> customers can hit that case since there's no rebasing for them, just
> upgrades.

Yeah, that was a side-effect of running the sanity tests (I think).

If I subscribe, rebase, then try to 'rpm-ostree install'...all is well.

Let's change the tests to do the sed in
https://github.com/projectatomic/rpm-ostree/issues/232#issue-140188132
?

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.