[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Unable to compose on x86_64.



On Tue, 11 Jun 2013, Peter Jones wrote:

On Sun, Jun 09, 2013 at 02:13:54PM -0600, William F. Acker WB2FLW +1 303 722 7209 wrote:
Hi all,

     I don't know if this should go here or buildsys, but I thought
I'd try here first.
Around the time of anaconda-19.30.3, I'm getting this.
rebuilding boot/upgrade-3.9.4-301.fc19.x86_64.img
/usr/lib/dracut/modules.d/99base/dracut-lib.sh: line 80: /proc/cmdline: No such file or directory
populating output tree and building boot images
running x86.tmpl
template command error in x86.tmpl:
  install boot/efi/EFI/*/MokManager.efi EFI/BOOT/
  IOError: nothing matching /home/wacker/19/work/x86_64/installroot/boot/efi/EFI/*/MokManager.efi in /
Traceback (most recent call last):
  File "/bin/pungi", line 256, in <module>
    main()
  File "/bin/pungi", line 146, in main
    mypungi.doBuildinstall()
  File "/usr/lib/python2.7/site-packages/pypungi/__init__.py", line 937, in doBuildinstall
    workdir=workdir, outputdir=outputdir)
  File "/usr/lib/python2.7/site-packages/pylorax/__init__.py", line 316, in run
    treebuilder.build()
  File "/usr/lib/python2.7/site-packages/pylorax/treebuilder.py", line 220, in build
    self._runner.run(templatefile, kernels=self.kernels)
  File "/usr/lib/python2.7/site-packages/pylorax/ltmpl.py", line 180, in run
    self._run(commands)
  File "/usr/lib/python2.7/site-packages/pylorax/ltmpl.py", line 199, in _run
    f(*args)
  File "/usr/lib/python2.7/site-packages/pylorax/ltmpl.py", line 232, in install
    for src in rglob(self._in(srcglob), fatal=True):
  File "/usr/lib/python2.7/site-packages/pylorax/ltmpl.py", line 95, in rglob
    raise IOError, "nothing matching %s in %s" % (pathname, root)
IOError: nothing matching /home/wacker/19/work/x86_64/installroot/boot/efi/EFI/*/MokManager.efi in /

Any ideas?

Yeah - I'm re-arranging what provides what between shim-unsigned and
shim-signed, and unfortunately the latter package necessarily lags a
couple of days behind the former.  I've actually pulled the
shim-unsigned you were testing with from the repo, so it should work
again now, but it might break again soon - I'll try to limit the time
it's broken for as much as I can, but there's only so mcuh that's under
my control there.

--
Thanks, Peter. As I said in my last post, which landed just after yours, I can work around it in the repo statements. BTW, it seems strange to me that the binary package Shim comes from a source package called Shim -signed, and Shim-unsigned comes from Shim. Haven't seen anything like that before.

          Thanks.

--
          Bill in Denver


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]