Problem exists with grub-0.97-13 in rawhide too +++ This bug was initially created as a clone of Bug #151834 +++ Description of problem: The grub file compiled when the src.rpm is built on a x86_64 system cannot execute since it is being dynamically linked incorrectly. When grub is run the error: [paris@paris x86_64]$ grub bash: /sbin/grub: /usr/lib/libc.so.1: bad ELF interpreter: No such file or directory is seen. Readelf -a shows a dynamic section (which is wrong since we want static linking) and also shows in the program header section: Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x000034 0x08048034 0x08048034 0x000e0 0x000e0 R E 0x4 INTERP 0x000114 0x08048114 0x08048114 0x00013 0x00013 R 0x1 [Requesting program interpreter: /usr/lib/libc.so.1] LOAD 0x000000 0x08048000 0x08048000 0x2afec 0x2afec R E 0x1000 LOAD 0x02b000 0x08073000 0x08073000 0x06ff8 0x12d20 RW 0x1000 DYNAMIC 0x02b014 0x08073014 0x08073014 0x000c8 0x000c8 RW 0x4 NOTE 0x000128 0x08048128 0x08048128 0x00020 0x00020 R 0x4 GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4 Where it is trying to use libc.so.1. If this were properly dynamically linked it would use ld-linux-x86-64.so.2. But shouldn't be doing this at all.... The problem seems to stem from the line where we actually create the grub binary which reads: gcc -fwritable-strings -m32 -Os -g -static -o grub main.o asmstub.o ../stage2/libgrub.a ../lib/libcommon.a -Wl,-Bstatic -lncurses -Wl,-Bdynamic Notice that we throw the -Wl,-Bdynamic on the end of the line. This little bit of code comes from the grub-0.95-staticcurses.patch which changes the autoconf to include this. The patch has: - AC_CHECK_LIB(ncurses, wgetch, [GRUB_LIBS="$GRUB_LIBS -lncurses" + AC_CHECK_LIB(ncurses, wgetch, [GRUB_LIBS="$GRUB_LIBS -Wl,-Bstatic -lncurses -Wl,-Bdynamic" All of the .o files were created correctly and statically, but the last binary is allowed this bit of dynamic linking. I hacked both the spec file and the patch to get this to work. My hack made the spec file have: %ifarch x86_64 CFLAGS="$CFLAGS -static" ; export CFLAGS DYNAMIC=static; export DYNAMIC %else DYNAMIC=dynamic; export DYNAMIC %endif And the patch to have (in both places): - AC_CHECK_LIB(ncurses, wgetch, [GRUB_LIBS="$GRUB_LIBS -lncurses" + AC_CHECK_LIB(ncurses, wgetch, [GRUB_LIBS="$GRUB_LIBS -Wl,-Bstatic -lncurses -Wl,-B$DYNAMIC" This way autoconf will let make decide on the fly what to put after the static ncurses linking. How reproducible: Always for me Steps to Reproduce: 1. Download src rpm 2. Run rpmbuild --rebuild src.rpm (or some varient) 3. Install the rpm 4. Try to run /sbin/grub Actual results: [paris@paris x86_64]$ grub bash: /sbin/grub: /usr/lib/libc.so.1: bad ELF interpreter: No such file or directory Expected results: Grub Starts -- Additional comment from tao on 2007-06-04 11:59 EST -- So if you try to build grub from src.rpm on a x86_64 machine with minimum installation + few needed pkgs; rpm rpm-build rpm-python ncurses-devel automake autoconf gcc cpp libgcc x86, x86_64 x86 glibc glibc-common glibc-headers glibc-kernheaders glibc Then, it would build properly... But if you build it with everything install or... adding X devel pkgs, gnome devel pkgs or KDE devel pkgs, it would build it properly, but if you look at /usr/src/redhat/BUILD/grub-0.95/grub/grub, then it would show something like; BUILD/grub-0.95/grub/grub: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked If you use dynamically linked grub, as soon as you install, you will get following error; sbin/grub-install: /sbin/grub: /usr/lib/libc.so.1: bad ELF interpreter: No such file or directory /sbin/grub-install: /sbin/grub: /usr/lib/libc.so.1: bad ELF interpreter: No such file or directory /sbin/grub-install: /sbin/grub: /usr/lib/libc.so.1: bad ELF interpreter: No such file or directory /sbin/grub-install: /sbin/grub: /usr/lib/libc.so.1: bad ELF interpreter: No such file or directory /sbin/grub-install: /sbin/grub: /usr/lib/libc.so.1: bad ELF interpreter: No such file or directory The file /boot/grub/stage1 not read correctly. -- Additional comment from markmc on 2007-07-05 06:35 EST -- Okay, here's the deal: - We build grub in a build root with only ncurses-devel.x86_64 installed - Since we're building a 32 bit binary, the configure script doesn't find the ncurses library: checking for wgetch in -lncurses... no checking for wgetch in -lcurses... no - To verify that it's not built with ncurses, try running the "clear" command in /sbin/grub ... compare to i386 - If you try and re-build grub with ncurses-devel.i386 installed, then it creates a borked dynamically linked /sbin/grub due to the -Wl,-Bdynamic
Based on the date this bug was created, it appears to have been reported during the development of Fedora 8. In order to refocus our efforts as a project we are changing the version of this bug to '8'. If this bug still exists in rawhide, please change the version back to rawhide. (If you're unable to change the bug's version, add a comment to the bug and someone will change it for you.) Thanks for your help and we apologize for the interruption. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
For the future "BugZappers" - this bug is present in F9 and in the current rawhide too (grub-0.97-34.fc10.x86_64 with a build date "Wed 25 Jun 2008" as for this moment). Makes for a hard recovery in case of booting troubles.
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Bug still present in rawhide
*** Bug 306301 has been marked as a duplicate of this bug. ***
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.