digging into a chroot I grabbed the lorax logs. the relevant failure is
2016-11-16 03:28:59,906 DEBUG pylorax.ltmpl: template line 42: treeinfo images-x86_64 product.img images/product.img 2016-11-16 03:28:59,906 DEBUG pylorax.ltmpl: template line 43: runcmd mkisofs -o /mnt/koji/compose/25/Fedora-25-20161115.0/work/x86_64/Workstation/ostree_installer/images/boot.iso -b isolinux/isolinux.bin -c isolinux/boot.cat -boot-load-size 4 -boot-info-table -no-emul-boot -eltorito-alt-boot -e images/efiboot.img -no-emul-boot -R -J -V Fedora-WS-ostree-x86_64-25 -T -graft-points images/install.img=/mnt/koji/compose/25/Fedora-25-20161115.0/work/x86_64/Workstation/ostree_installer/images/install.img isolinux=/mnt/koji/compose/25/Fedora-25-20161115.0/work/x86_64/Workstation/ostree_installer/isolinux images/pxeboot=/mnt/koji/compose/25/Fedora-25-20161115.0/work/x86_64/Workstation/ostree_installer/images/pxeboot EFI/BOOT=/mnt/koji/compose/25/Fedora-25-20161115.0/work/x86_64/Workstation/ostree_installer/EFI/BOOT images/efiboot.img=/mnt/koji/compose/25/Fedora-25-20161115.0/work/x86_64/Workstation/ostree_installer/images/efiboot.img images/product.img=/mnt/koji/compose/25/Fedora-25-20161115.0/work/x86_64/Workstation/ostree_installer/images/product.img /var/tmp/lorax.2j0tvzxf/iso-graft 2016-11-16 03:28:59,907 DEBUG pylorax.ltmpl: running command: ('mkisofs', '-o', '/mnt/koji/compose/25/Fedora-25-20161115.0/work/x86_64/Workstation/ostree_installer/images/boot.iso', '-b', 'isolinux/isolinux.bin', '-c', 'isolinux/boot.cat', '-boot-load-size', '4', '-boot-info-table', '-no-emul-boot', '-eltorito-alt-boot', '-e', 'images/efiboot.img', '-no-emul-boot', '-R', '-J', '-V', 'Fedora-WS-ostree-x86_64-25', '-T', '-graft-points', 'images/install.img=/mnt/koji/compose/25/Fedora-25-20161115.0/work/x86_64/Workstation/ostree_installer/images/install.img', 'isolinux=/mnt/koji/compose/25/Fedora-25-20161115.0/work/x86_64/Workstation/ostree_installer/isolinux', 'images/pxeboot=/mnt/koji/compose/25/Fedora-25-20161115.0/work/x86_64/Workstation/ostree_installer/images/pxeboot', 'EFI/BOOT=/mnt/koji/compose/25/Fedora-25-20161115.0/work/x86_64/Workstation/ostree_installer/EFI/BOOT', 'images/efiboot.img=/mnt/koji/compose/25/Fedora-25-20161115.0/work/x86_64/Workstation/ostree_installer/images/efiboot.img', 'images/product.img=/mnt/koji/compose/25/Fedora-25-20161115.0/work/x86_64/Workstation/ostree_installer/images/product.img', '/var/tmp/lorax.2j0tvzxf/iso-graft') 2016-11-16 03:29:02,301 DEBUG pylorax.ltmpl: command output: Using DA192000.COM;1 for /var/tmp/lorax.2j0tvzxf/iso-graft/content/repo/objects/3e/da1921bee11ded73e53f9eed6c32b0fcf1b0ff2b3720ca33bb36ca10316d22.commitmeta (da1921bee11ded73e53f9eed6c32b0fcf1b0ff2b3720ca33bb36ca10316d22.commit) genisoimage: Error: /var/tmp/lorax.2j0tvzxf/iso-graft/content/repo/objects/3e/da1921bee11ded73e53f9eed6c32b0fcf1b0ff2b3720ca33bb36ca10316d22.commitmeta and /var/tmp/lorax.2j0tvzxf/iso-graft/content/repo/objects/3e/da1921bee11ded73e53f9eed6c32b0fcf1b0ff2b3720ca33bb36ca10316d22.commit have the same Joliet name Joliet tree sort failed. The -joliet-long switch may help you. NOTE: multiple source directories have been specified and merged into the root of the filesystem. Check your program arguments. genisoimage is not tar.
Ah! So it's a new failure because the commits are signed, and the naming conflicts with ISO short names. I don't often test this locally, will look at changing that.
Ugh. This may involve reworking how we store the content to move it out of the ISO into another loopback mounted store.
Long term what I want to do is https://github.com/rhinstaller/lorax/issues/143
I haven't fully investigated this, but I suspect the reason this isn't failing in the distributions that were already doing signing is that they've been signing after making the ISO.
It is definitely nicer if the signature is in the ISO, since it will show up on the initial atomic host status. But it isn't actually a security mechanism, because the ISO has to be verified externally.
atomic host status
@walters - what were we doing in the past? could we revert back to the old way and get successful builds that we can work with for F25 ?
The quickest fix is to back out the signing, or delete the signatures during the ISO generation. At the moment we aren't verifying them anyways, that's https://bugzilla.redhat.com/show_bug.cgi?id=1393545
That said I was actually working on the latter bug, and having Fedora's signatures there is nice for testing.
We could also just try using -joliet-long as the error indicated, since the filenames are 73 characters, and 73 < 103.
If for some reason that is not an option, of those alternatives, I would not like the backing out of signature alltogether, since that would mean that people that download updates also have no way to verify it anymore, and we basically revert all of the signing progress we made.
We could theoretically temporarily remove the commitmeta files from the image files that make up the iso, so that they don't end up in the generated iso. I, however, have no clue where that would need to be changed or how those images are generated.
At the end, I think that ostree should deal with this situation. Maybe it'd be an idea to rename .commitmeta to .metacommit, so that with Jolliet's 8.3 it still is different?
PR: https://pagure.io/fedora-lorax-templates/pull-request/6
Trivial safe fix: https://pagure.io/fedora-lorax-templates/pull-request/7
@walters - now that we are signing things in f25 we'd like to enable our deliverables to check gpg signatures. Is this still blocking that for f25?
I notice that https://pagure.io/fedora-lorax-templates/pull-request/8 (f25) and https://pagure.io/fedora-lorax-templates/pull-request/6 (rawhide) were merged.
There is this, but I don't know if it went anywhere: https://pagure.io/fedora-lorax-templates/pull-request/6
closing as this is no longer an issue.
Metadata Update from @dustymabe: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.