grub configure fails w/ "GRUB requires a working absolute objcopy"

[sbrown]

Somewhere between ld 2.17 & 2.18 the defaults changed. It's now necessary to add the ld parameter --build-id=none. Otherwise, ld produces massive images.

A patch is attached.

[blogic]

for me the same images are produced with and without the patch, what system are you building on ?

[sbrown]

I'm building a 2.6 system w/ PCEngines Alix profile.
See threads:
​http://forum.openwrt.org/viewtopic.php?id=15234
​http://forum.openwrt.org/viewtopic.php?id=14571

[framer99]

I just ran into something somewhat related to this issue.
Alix hardware wouldn't even boot to a grub prompt. I used the same "build-then-dd-to-disk" routine I have used dozens of times.

I traced it back through image build script's failure to mount the /boot parititon...

Then back farther to genext2fs' failure to create the fs for the boot partition due to not enough space(why does build continue after this?)

Then I traced that back to grub stage1/2 files that were over well over 100 MegaBytes each(yes, megabytes).

Finally, traced the stage1 file creation back to stage1.exec file which is around 2 Kilobytes, but near the end of the grub build, the command(from grub's internal Makefile):

objcopy -O binary stage1.exec stage1

produced the 128MB stage1 file. Obviously this is wrong.

[Side note: Could the build process be made to halt
when the genext2fs or other script/call fails? At
least spit out an error when NOT using V=99..
without V=99 you don't see genext2fs errors
(or fdisk errors later on).]

---

What I was able to figure out about the above problem:

Fedora added(possibly around Fedora 8?) a new objheader ".not.gnu.build-id" that gets inserted by gcc/ld by default nowadays.

It seems my x86 openwrt build uses my host's native compiler inserts the build-id header... or the toolchain build works the same way when it gets build on my machine with my native compiler. (more detail: it seems there is some interaction between detection of objcopy/gcc capbilites and then what version gets used and/or options passed. I haven't figured out the patches etc. since Trac was down hard all day when I worked on this. I was only able to find clues about this issue through snippets of google search results and the forum.)

In particular, grub builds a stage1.exec file has that exact .not.gnu.build-id header.
Grub then uses objcopy to binary to create the actual stage1 file. That extra "build-id header" causes the objcopy operation to go haywire and produce a stage1 file around 128MB.

This 128MB stage 1 (and also stage2 etc) file eventually causes genext2fs command to fail when creating the grub/boot partition since you generally have allocated only 4-8 meg or so.

grub builds its stageX.exec files with a gcc command line, so it seems you need to pass "-Wl,--build-id=none" instead of the ld option "--build-id=none"

I verified this "extra header messing things up" business by manually running objdump which produces

objdump -x stage1.exec
.....[snip]......
SYMBOL TABLE:
00007c00 l    d  .text	00000000 .text
08048094 l    d  .note.gnu.build-id	00000000 .note.gnu.build-id
00000000 l    d  .debug_aranges	00000000 .debug_aranges
00000000 l    d  .debug_info	00000000 .debug_info
00000000 l    d  .debug_abbrev	00000000 .debug_abbrev
00000000 l    d  .debug_line	00000000 .debug_line
00000000 l    df *ABS*	00000000 stage1.S
00007c4a l       .text	00000000 after_BPB
00007c04 l       .text	00000000 mode
00007c05 l       .text	00000000 disk_address_packet
.....[snip]......

and also doing this:

objcopy -R .note.gnu.build-id -O binary stage1.exec stage1

produces a proper stage1 file.

So the solutions I saw were to:

1. Make grub's internal makefile use "objcopy -R .note.gnu.build-id" instead of just a plain objcopy
2. Make grub's internal makefile use the gcc option "-Wl,--build-id=none" which would cause the stage1.exec file to not have the .note.gnu.build-id header to begin with (then objcopy doesn't need to remove that header on copy).

I chose Option 2 and added:

CFLAGS="-Wl,--build-id=none" \

to package/grub/Makefile after the CFLAGS line in Configure section (patch attached)

I guess this is distribution specific at least for now, and I don't know what the proper solution is.

Hopefully this (possibly flawed) explanation will keep someone else from wasting hours trying to track down why their latest image builds don't even boot to a grub prompt anymore.

In any case, I can build and boot openwrt images again :)

[framer99]

grub patch for dealing with build-id objheader inserted into stage1/2 files by native fedora tools

[nico]

Option 2 (global CFLAGS added to ./configure) seems to break builds on non-fedora systems (at least on an Ubuntu hardy system)

[florian]

Does the following patch fixes the problem for you ?

Index: package/grub/Makefile
===================================================================
--- package/grub/Makefile       (revision 15532)
+++ package/grub/Makefile       (working copy)
@@ -11,7 +11,7 @@

 PKG_NAME:=grub
 PKG_VERSION:=0.97
-PKG_RELEASE:=1
+PKG_RELEASE:=2

 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
 PKG_SOURCE_URL:=ftp://alpha.gnu.org/gnu/grub
@@ -78,6 +78,10 @@
        $(MAKE) -C $(PKG_BUILD_DIR) \
                GRUB_CFLAGS="\$$$$(STAGE2_CFLAGS)" \
                STAGE1_CFLAGS="\$$$$(STAGE2_CFLAGS)"
+       # Strip the .note.gnu.build-id section, see #3793
+       $(TARGET_CROSS)strip -R .note.gnu.build-id \
+               $(PKG_BUILD_DIR)/stage1/stage1.exec \
+               -o $(PKG_BUILD_DIR)/stage1/stage1
 endef

 define Build/InstallDev

[nico]

Less intrusive fix for 8.09, that should work on all host systems

[nico]

Should be fixed in [15608], thanks!

[John Schultz <jschultz0614@…>]

please see ticket 12141 @ ​/ticket/12141.html

[John Schultz <jschultz0614@…>]

This issue is still on going. please do not close it with out even gathering information to determine weather or not something inherently is broken.

[jow]

Please do not reopen old tickets without even providing basic information.

[John Schultz <jschultz0614@…>]

Replying to jow:

Please do not reopen old tickets without even providing basic information.

From Ticket: #12141
I currently have the following hardware: Alex 3D3, 4gb SanDisk CF Card, 2 Wistron DNMA-92 radios. Ive compiled the trunk version several times and have DD'd the combined image several times to the cf card from a different linux system. When the system boots it instantly goes to the PXE menu for my network (if the cable is connected) or a missing hddd is the cable is not attached. Almost as if the boot partition is missing. I have modified the menu.list multiple times with no luck. Any assistance on this issue would be most appreciative. Thanks in advance, John

For which no one has bothered to provide any assistance except for request for console info.

From Ticket: #3793
Information for this issue has allready been provided.

1. The system does not boot to a grub prompt.
2. The system behaves as iff there is no HDD at all.
3. The individual that stated about not enough size hit it on the head, the partition is too small. I have manually created a grub prompt and it boots to a grub prompt, however, the open wrt partitions are kinda set in stone.

[jow]

I fail to see how a non booting image is related to a compilation error in grub.
When grub compilation fails, there aren't any flashable images to begin with.

You cannot simply reopen random tickets only because to have the word "grub" in their summary.

[John Schultz <jschultz0614@…>]

Replying to jow:

I fail to see how a non booting image is related to a compilation error in grub.
When grub compilation fails, there aren't any flashable images to begin with.

You cannot simply reopen random tickets only because to have the word "grub" in their summary.

If the problem I am exhibiting duplicate exactly what 90% of this ticket covers, why shouldn't I re-open it. There is something wrong with the way grub is being installed. Not enough room, wrong package, I do not know, this is the reason I originally asked for help.

[jow]

This ticket is about a failure *compiling* grub, not about how its installed or configured.