Description of problem: livecd-iso-to-disk produces an unbootable USB stick, that fails to boot with error: file '/isolinux/vmlinuz0' not found. The media's grub.cfg uses a path for the kernel that doesn't exist. Version-Release number of selected component (if applicable): livecd-tools-19.3-1.fc19 Fedora-Live-Desktop-x86_64-19-Beta-1.iso How reproducible: Always Steps to Reproduce: 1. Install livecd-tools 2. Run command: livecd-iso-to-disk --noverify --format --efi --overlay-size-mb 1000 /dev/sr0 /dev/sdb 3. Reboot booting from the created USB media 4. Choose the default boot option in the grub menu or wait for timeout. Actual results: error: file '/isolinux/vmlinuz0' no found. error: you need to load the kernel first. Press any key to continue... Expected results: For the computer to boot without this error. Additional info: For whatever reason they grub.cfg is looking in /isolinux, meanwhile the kernel and initrd are actually in /syslinux. If the grub.cfg is modified to look in /syslinux, then the system boots.
Created attachment 755320 [details] bash -x livecd-iso-to-disk
From the bash -x, the problem isn't with the grub.cfg, it's just copying the existing media's grub.cfg which references /isolinux; and on actual media the files are actually in /isolinux. But livecd-iso-to-disk is copying the files into /syslinux not /isolinux, and not updating the grub.cfg + cp /media/srctmp.CkrJ54/isolinux/boot.cat /media/srctmp.CkrJ54/isolinux/efiboot.img /media/srctmp.CkrJ54/isolinux/initrd0.img /media/srctmp.CkrJ54/isolinux/isolinux.bin /media/srctmp.CkrJ54/isolinux/isolinux.cfg /media/srctmp.CkrJ54/isolinux/macboot.img /media/srctmp.CkrJ54/isolinux/memtest /media/srctmp.CkrJ54/isolinux/vesamenu.c32 /media/srctmp.CkrJ54/isolinux/vmlinuz0 /media/tgttmp.LEWuQm/syslinux
Proposing as final blocker, Beta criterion: "All release-blocking images must boot in their supported configurations. ... Release-blocking live and dedicated installer images must boot when written to optical media of an appropriate size (if applicable) and when written to a USB stick with any of the officially supported methods." https://fedoraproject.org/wiki/Fedora_19_Beta_Release_Criteria#Release-blocking_images_must_boot
Looks like the patch for bug 962039 also fixed this one.
livecd-tools-19.4-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/livecd-tools-19.4-1.fc19
Package livecd-tools-19.4-1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing livecd-tools-19.4-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-9827/livecd-tools-19.4-1.fc19 then log in and leave karma (feedback).
Discussed at 2013-06-03 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-03/f19final-blocker-review-2.2013-06-03-16.00.log.txt . This seems like an obvious blocker, but in fact, it's pretty rare for people to be writing an F19 USB stick from F19 especially right around release time: what's much more common is to do it from F17/F18. And there's no real benefit to fixing this in the frozen package set; even if you are writing an F19 USB stick from F19, you can easily install updates before doing so. So this was rejected as a blocker and a freeze exception issue simply because the F19 use case is not that significant. In practice it's very likely that the fix will go stable before freeze anyway, so this becomes a bit academic.
Whoops.
The change only appears to be in the F19 version of df. If it shows up in previous releases I'll back port this.
livecd-tools-19.4-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.