* Marc Haber [Fri Sep 15, 2017 at 02:11:41PM +0200]:
On Thu, Sep 14, 2017 at 09:41:55AM +0200, Marc Haber wrote:
I retried with grml-live 0.29.7 as it is on 2017.05 proper.
On Sun, Sep 10, 2017 at 01:55:43PM +0200, Marc Haber wrote:
[ WARN ] Skipping stage 'fai dirinstall' as /root/output/grml_chroot exists already.
This warning is also present in the output of 0.29.7, but...
[ OK ] No missing packages found, generating empty junit report. [ OK ] Generating /conf/bootid.txt with entry grml001. [ FAIL ] Can not access GRUB efi image /root/output/grml_chroot//boot/bootx64.efi, required for Secure Boot support
... this FAIL does not happen with 0.29.7. 0.29.7 fails significantly later than 0.31.
On a grml-full built on Debian unstable, with the current jenkins grml-live, using: sudo grml-live -A -V -s sid -c DEBORPHAN,GRMLBASE,GRML_FULL,RELEASE,AMD64,IGNORE,SNAPSHOT -r "test20170915" -g grml64 -o ~/grml-remaster/tmp the behavior is the same. Can't get any more current than that, can I?
I'd need the full command line output (including the startup message which prompts for user input before execution) to be able to tell you why:
| Executing shell: GRMLBASE/45-grub-images
doesn't seem to be executed on your system.
Though I'm a bit lost on what exactly you're doing and how your environment looks like. Should I be able to reproduce your situation with just taking the official grml64-small 2017.05 ISO and rebuild that one with grml-live -e...?
I can just guess that grml-live -e /dev/cdrom doesn't copy bootx86.efi correctly from the mounted ISO image. The file _is_ in /efi/boot/bootx64.efi on the medium mounted to /lib/live/mount/medium. Where does grml-live expect it to be?
As the error message says, it expects /boot/bootx64.efi to be there (/root/output/grml_chroot//boot/bootx64.efi in your case), that's different from /efi/boot/bootx64.efi.
regards, -mika-