Bug 7124 - Use BR toolchain externally results a non-bootable root filesystem
Summary: Use BR toolchain externally results a non-bootable root filesystem
Status: RESOLVED WORKSFORME
Alias: None
Product: buildroot
Classification: Unclassified
Component: Other (show other bugs)
Version: 2014.05
Hardware: PC Linux
: P5 major
Target Milestone: ---
Assignee: Thomas Petazzoni
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-31 13:03 UTC by xxiao
Modified: 2014-08-15 17:12 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:


Attachments
defconfig to build the toolchain (3.00 KB, application/octet-stream)
2014-05-31 14:09 UTC, xxiao
Details
defconfig using the built toolchain as an external toolchain (3.06 KB, application/octet-stream)
2014-05-31 14:10 UTC, xxiao
Details

Note You need to log in before you can comment on or make changes to this bug.
Description xxiao 2014-05-31 13:03:02 UTC
To reproduce(I used IMX6 board)
1. set HOST_DIR to wherever you want to relocate the toolchain.
2. make toolchain
3. build a rootfs using the above-built toolchain _externally_.
4. boot it up, you will find error saying "no init is found"

To fix it manually we need add a ld-linux.so.3 symlink under /lib on the rootfs
1. cd output/target/lib
2. ln -s ld-linux-armhf.so.3 ld-linux.so.3
3. boot with the modified rootfs

If we use internal buildroot toolchain directly, the ld-linux.so.3 is there. If we use external buildroot toolchain, the ld-linux.so.3 was not created somehow.
Comment 1 Thomas Petazzoni 2014-05-31 13:06:29 UTC
Thanks for your bug report!

Could you provide the .config you have used to build the toolchain, and then the .config you have used to build the root file system?
Comment 2 xxiao 2014-05-31 14:09:33 UTC
Created attachment 5420 [details]
defconfig to build the toolchain
Comment 3 xxiao 2014-05-31 14:10:20 UTC
Created attachment 5426 [details]
defconfig using the built toolchain as an external toolchain
Comment 4 Thomas Petazzoni 2014-08-15 17:12:45 UTC
I've just tested your use case, and it works fine here. Moreover, from your description, I believe a mistake was done on your side: when you use EABIhf, ld-linux.so.3 should *NOT* be present, and all executables should have /lib/ld-linux-armhf.so.3 as their program interpreter (see the output of "readelf -a").

Therefore, this makes me believe that you had some non-EABIhf binaries lying around, and they were still referencing /lib/ld-linux.so.3, which on purpose doesn't exist on EABIhf systems.

Consequently, I'm marking this bug as "works for me". Do not hesitate to reopen if you disagree with this conclusion.