| Summary: | Bootable ISO image creation seems to have stopped working since 2012.08 | ||
|---|---|---|---|
| Product: | buildroot | Reporter: | gfx229-uclibc |
| Component: | Other | Assignee: | unassigned |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | buildroot |
| Priority: | P5 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Host: | Target: | ||
| Build: | |||
FWIW - the kernel and initramfs (cpio) images work independently of the ISO image created (just the current formatting as a bootable ISO seems disrupted). Additional information - I hand-built an ISO using the stage2_eltorito bits built from my 2012.08 build and the resulting ISO is bootable. So I imagine there's something amiss with the grub-0.97 bits between now and then that are contributing to my hang. Will continue to investigate as time permits. FYI, to clarify, I combined bits built from my current 2013.02 build and el-torito bits from my 2012.08 builds. Thus the focus is on the Grub bits used to create a bootable ISO. Thanks. FYI - I now believe this is a GCC versionitis issue per se. Kicking my build back to GCC 4.5.x (instead of 4.6.x as is the current default) restores the bootability of the resulting bits. I'm not sure how these newer compilers are impacting the build of the Grub directory but I will ad this note as an advisory at this point. If you wish to close this as not a bug you wish to track (but rather document for work-around status), please feel free. Thanks for your continued valued work. Thanks a lot for the great investigation! Can you try the patch at http://free-electrons.com/~thomas/pub/0001-grub-bump-to-0.97-67.patch ? I think it should fix the gcc 4.6 problem. The patch simply bumps the Grub version we use to a slightly more recent Debian patch version, which precisely includes a gcc 4.6 related fix. Did you had the time to test the proposed patch? Sorry, this one got past me as we were using the work around here. I will try it asap. (Is it already in the RC betas?) Thank you and apologies for the delay. (In reply to comment #6) > Did you had the time to test the proposed patch? We have run into this problem today when trying to create a bootable ISO image of our firmware for use on our continuous integration server. We are using the 2013.05 release with gcc 4.7. I've applied the patch that bumps grub to 0.97-67 but the boot still hangs at "Loading Stage2 ....." Based on a Gentoo patch, I found that adding the flag "-fno-reorder-functions" to GRUB_CFLAGS in boot/grub/grub.mk makes the ISO bootable again. The Gentoo patch only adds it to STAGE2_CFLAGS, but changing grub.mk is easier than making a new patch since it doesn't interfere with the other patches being applied. I've tested ISO support with Grub recently on the master Buildroot branch, and it just worked. I did a few improvements to make things slightly better, but I'm not experiencing the problems described in this bug report. Therefore, I believe the bug has been fixed. If not, feel free to reopen, after testing the latest Buildroot version. Thanks! |
2012.08 and prior generated bootable ISO images whereas the changes after this (which defaulted to CPIO initramfs from Ext2 filesystem image) seems to have stopped working (could be operator error but no obvious documentation in this scenario). Repro (2012.11 to 2013.02) - used mostly straight-line defaults: [ ] Linux kernel - Install kernel image to /boot in target, used i386_defconfig extracted from Linux kernel build as defined kernel config [ ] Bootloaders - specified both grub and syslinux (Install isolinux) [ ] Filesystem images - iso image, fs/iso9660/menu.lst - cpio the root filesystem (no compression method) [ ] Package selection - nothing but BusyBox Observed behavior - burned ISO boots and hangs after "Loading Stage2 ....." Previous good (2012.08) [ ] Burned ISO bootable (I think because initrd is Ext2 rather than Initramfs/CPIO) --- Perhaps I'm doing something wrong or need other configuration parameters for the Linux kernel (I tried adding other filesystem module support but that did not help nor do I suspect it is necessary). If there is some BuildRoot documentation that I'm overlooking or need to do more directly with Linux kernel configuration to ensure even a "linked-in" initramfs copy works, I'm happy to further investigate my own issues. (It just was working fine with the Ext2 initrd but seems to have stopped after the changes in 2012.11 so I was wondering where I've gone wrong or if this is not a widely tested scenario.) Thank you very much and best regards.