#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)
Change History (18)
Changed 10 years ago by anonymous
comment:1 follow-up: ↓ 2 Changed 10 years ago by blogic
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:
- Make grub's internal makefile use "objcopy -R .note.gnu.build-id" instead of just a plain objcopy
- 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
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: ↓ 12 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.
- The system does not boot to a grub prompt.
- The system behaves as iff there is no HDD at all.
- 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: ↓ 14 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.
for me the same images are produced with and without the patch, what system are you building on ?