Modify

Opened 10 years ago

Closed 5 years ago

Last modified 5 years ago

#3793 closed defect (invalid)

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

Reported by: sbrown Owned by: florian
Priority: high Milestone: Kamikaze 8.09.1
Component: base system Version: Kamikaze 8.09
Keywords: grub objcopy Cc:

Description

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.

Attachments (3)

grub.patch (5.4 KB) - added by anonymous 10 years ago.
020-build-id-objheader.patch (372 bytes) - added by framer99 9 years ago.
grub patch for dealing with build-id objheader inserted into stage1/2 files by native fedora tools
ticket-3793.patch (1.6 KB) - added by nico 9 years ago.
Less intrusive fix for 8.09, that should work on all host systems

Download all attachments as: .zip

Change History (18)

Changed 10 years ago by anonymous

comment:1 follow-up: Changed 10 years ago by blogic

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

comment:2 in reply to: ↑ 1 Changed 10 years ago by 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

comment:3 Changed 9 years ago by 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 :)

Changed 9 years ago by framer99

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

comment:4 Changed 9 years ago by florian

  • Milestone changed from Kamikaze to Kamikaze 8.09.1
  • Owner changed from developers to florian
  • Priority changed from normal to high
  • Status changed from new to assigned
  • Version set to Kamikaze 8.09

comment:5 Changed 9 years ago by nico

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

comment:6 Changed 9 years ago by 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

Changed 9 years ago by nico

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

comment:7 Changed 9 years ago by nico

  • Resolution set to fixed
  • Status changed from assigned to closed

Should be fixed in [15608], thanks!

comment:8 Changed 5 years ago by John Schultz <jschultz0614@…>

  • Resolution fixed deleted
  • Status changed from closed to reopened

please see ticket 12141 @ /ticket/12141.html

comment:9 Changed 5 years ago by jow

  • Resolution set to invalid
  • Status changed from reopened to closed

comment:10 Changed 5 years ago by John Schultz <jschultz0614@…>

  • Resolution invalid deleted
  • Status changed from closed to reopened

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.

comment:11 follow-up: Changed 5 years ago by jow

  • Resolution set to invalid
  • Status changed from reopened to closed

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

comment:12 in reply to: ↑ 11 Changed 5 years ago by John Schultz <jschultz0614@…>

  • Resolution invalid deleted
  • Status changed from closed to reopened

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.

comment:13 follow-up: Changed 5 years ago by jow

  • Resolution set to invalid
  • Status changed from reopened to closed

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.

comment:14 in reply to: ↑ 13 Changed 5 years ago by 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.

comment:15 Changed 5 years ago by jow

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

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.