I build an embedded linux with YOCTO for the KARO TX6S-8035 target. I use the
Mfgtools-TX6-2018-01 tool to flash images into the board but when i boot the device i have the following error: Kernel panic - not syncing: Requested init /linuxrc failed (error -2).
How can i fix this?
Here is the result of printenv from U-BOOT:
printenv
And the serial output from the board: serial output
The kernel is looking for the init program and cannot find it. Most likely your image is corrupt. More info here: What is linuxrc purpose and is it needed in the rootfs?
I would try:
reflash the image
check the image to be sure that linuxrc exists
post a questions to the meta-freescale mailing list
Also, I do not know what setup you are using, but I would look at the FSL Community BSP. There is a good chance others are building for that platform.
Kernel panic - not syncing: Requested init /linuxrc failed (error -2)
In my case, I create initrd with busybox. /linuxrc execute error, because of it can't find the dynamic library.
execute below script after mount the initrd
file linuxrc
linuxrc: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, stripped
Fix-Option1:
copy library to initrd.
mkdir -p $WORKSPACE/initrd
mount $WORKSPACE/ramdisk.img $WORKSPACE/initrd -t ext2 -o loop=/dev/loop0
pushd $WORKSPACE/initrd/
cp -rf /opt/buildtools/gcc-arm-10.2-2020.11-x86_64-aarch64-none-linux-gnu/aarch64-none-linux-gnu/libc/lib ./
cp -rf /opt/buildtools/gcc-arm-10.2-2020.11-x86_64-aarch64-none-linux-gnu/aarch64-none-linux-gnu/libc/lib64 ./
aarch64-none-linux-gnu-strip $WORKSPACE/initrd/lib/*
aarch64-none-linux-gnu-strip $WORKSPACE/initrd/lib64/*
aarch64-none-linux-gnu-strip $WORKSPACE/initrd/bin/busybox
popd
umount $WORKSPACE/initrd
gzip -9 $WORKSPACE/ramdisk.img
Fix-Option2:
build busybox statically.
make -j16 -C $WORKSPACE/$BUSYBOX ARCH="arm64" LDFLAGS="--static" CROSS_COMPILE="aarch64-none-linux-gnu-" install
busybox-1.32.1/_install/bin/busybox: ELF 64-bit LSB executable, ARM aarch64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.7.0, stripped
Related
I am trying to build the linux kernel for user-mode linux (um) architecture and x86-64 sub-architecture.
I am getting this build error:
arch/um/drivers/vde_user.c:8:24: fatal error: libvdeplug.h: No such file or directory
I installed libvdeplug-dev, and I can see the header file installed:
$ sudo dpkg -L libvdeplug-dev
/.
/usr
/usr/include
/usr/include/libvdeplug.h
/usr/include/libvdeplug_mod.h
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/libvdeplug.a
/usr/share
/usr/share/doc
/usr/share/doc/libvdeplug-dev
/usr/share/doc/libvdeplug-dev/changelog.Debian.gz
/usr/share/doc/libvdeplug-dev/copyright
/usr/share/doc/vdeplug4
/usr/share/doc/vdeplug4/howto_create_a_vdeplug_plugin.gz
/usr/share/man
/usr/share/man/man3
/usr/share/man/man3/libvdeplug.3.gz
/usr/lib/x86_64-linux-gnu/libvdeplug.so
/usr/lib/x86_64-linux-gnu/libvdeplug_mod.so
/usr/share/man/man3/vde_close.3.gz
/usr/share/man/man3/vde_ctlfd.3.gz
/usr/share/man/man3/vde_datafd.3.gz
/usr/share/man/man3/vde_open.3.gz
/usr/share/man/man3/vde_recv.3.gz
/usr/share/man/man3/vde_send.3.gz
But I am still getting the same build error above.
Here is my build command:
make -s -j 7 ARCH=um SUBARCH=x86_64 CROSS_COMPILE=../x86-64-core-i7--glibc--stable/bin/x86_64-linux-
I ran the same build command above with "allyesconfig" to generate the config file.
I am building the 5.18-rc1, which is I believe is the current tip.
How am I supposed to fix this?
This question already has answers here:
what does "-sh: executable_path:not found" mean
(2 answers)
Closed 3 years ago.
I have cross-compiled the small application for my beaglebone board:
/* led_test.c */
int main(int argc, char const *argv[])
{
return 0;
}
Compiling was done successfully, but if I try to run the application in target board, I get this:
# cd /bin/
# ls -la | grep led_test
-rwxr-xr-x 1 default default 13512 Feb 5 2020 led_test
# led_test
-sh: ./led_test: not found
Why can't I run custom application on my Beaglebone board? Could anyone explain me it, please?
Some information about my environment:
1. work-station: Ubuntu 18.04.4 LTS x86-64
2. target machine: ARMv7 beaglebone board
3. cross-compiler: gcc-linaro-7.3.1-2018.05-x86_64_arm-linux-gnueabihf
4. I built u-boot and Linux kernel with this toolchain and mounted rootfs via NFS.
UPD 1:
I tried use this ./led_test instead led_test. It doesn't matter, because my application is placed into /bin directory.
It's likely your userspace was not built with the cross-toolchain that you compiled your binary with. Maybe you compiled the kernel with it, but that does not matter, what matters is the rootfs.
Your program is dynamically linked. When the program runs, the kernel really loads the dynamic linker, and that then maps the executable into the process's address space along with the libraries.
To see the dynamic linker, run readelf -l on your host or target system on the binary. Example:
$ readelf -l a.out
Elf file type is EXEC (Executable file)
[... more lines ...]
[Requesting program interpreter: /lib/ld-linux-armhf.so.3]
[... more output ...]
The line with program interpreter is the one to look file. file will also give this information. It's probably the case the the file named here is not preset on your rootfs. That is the "file not found" that the error is from.
What you need to do is use the correct cross-toolchain (which uses the same C library version) for the rootfs you are using or build a new rootfs with the same toolchain.
Take a look at buildroot for an easy way to make a new, simple, BeagleBone Black rootfs that's way faster and simpler than using Yocto/Poky to make one.
try run by absolute path, or if you in directory run as ./led_test
Also, show output from file
file /bin/led_test
Or run application with gdb
I try to use remotely the gdbserver for debug as follows
Start the gdbserver on target machine
$ gdbserver localhost:2000 hello -l 20 -b 10 --enable-targets=all
Host machine has the program binary with debugging enabled
"copied binary from ARM target to host"
Run gdb on host machine
$ gdb -q --args hello --enable-target=all
Connect to the target
(gdb) target remote 192.168.15.132
192.168.15.132: No such file or directory.
(gdb) target remote 192.168.15.132:2000
Remote debugging using 192.168.15.132:2000
warning: while parsing target description (at line 11): Target description specified unknown architecture "aarch64"
warning: Could not load XML target description; ignoring
Remote register badly formatted: T051d:0000000000000000;1f:80fcffffffff0000;20:403cfdb7ffff0000;thread:pd60.d60;core:1;
here: 00000000;1f:80fcffffffff0000;20:403cfdb7ffff0000;thread:pd60.d60;core:1;
(gdb) q
I am looking for an advice to correctly debug with ARM remote target.
To debug executables compiled for a different architecture, install gdb-multiarch and run gdb-multiarch instead of gdb. Different distributions compile gdb differently and some even lack the multiarch version in their repositories - RHEL doesn't include it, but it's present in Ubuntu and Debian.
Since you are reporting that your GDB supports the following architectures:
i386:x64-32 i386:x86-64:intel i386 i386:x64-32:intel i386:x86-64:nacl i386:intel i386:x64-32:nacl i8086 i386:nacl i386:x86-64, you may be attempting to remotely debug an aarch64-linux-gnu executable using an x86_64-targeted version of gdb.I would suggest to download/install gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu.tar.xz:
wget https://releases.linaro.org/components/toolchain/binaries/latest-7/aarch64-linux-gnu/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu.tar.xz
tar Jxvf gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu.tar.xz -C /opt
and then use /opt/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-gdb for remotely debugging your program.
I installed the golang.
~/go/bin$ ls
go godoc gofmt
Trying to test, but to no avail.
~/go/bin$ go version
-bash: /home/orc/go/bin/go: no such file or directory
My $PATH:
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/orc/go/bin:
Info:
~/go/bin$ uname -m
x86_64
~/go/bin$ file go
go: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
~/go/bin$ pwd
/home/orc/go/bin
Please tell me what's wrong?
UPDATE
~/go/bin$ ls -l
итого 28688
-rwxr-xr-x 1 orc orc 9571864 Фев 18 14:40 go
-rwxr-xr-x 1 orc orc 16164032 Фев 18 14:41 godoc
-rwxr-xr-x 1 orc orc 3594712 Фев 18 14:40 gofmt
~/go/bin$ ./go
-bash: ./go: Нет такого файла или каталога
!!!
~/go/bin$ file $(which ls)
/bin/ls: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
~/go/bin$ uname -a
Linux olimp-web 2.6.32-5-amd64 #1 SMP Mon Jun 13 05:49:32 UTC 2011 x86_64 GNU/Linux
Please explain how to fix it?
Have you checked that you have the correct version for your architecture installed. I have just had this exact problem when I put a 32-bit binary on a 64-bit virtual machine. I removed the 32-bit version and installed the architecture appropriate version (based on the instructions on the website) and it worked. Hope that works for you too.
A couple of things to check, which may come to nothing, but they'll at least rule out things:
There's no indication in your question that your current directory is within /home/orc, a simple pwd should clarify that.
Can you run the file directly, such as with ./go or ~/go/bin/go?
Is it executable? The output of ls -l should clarify that.
Get the full machine details with uname -a.
Check the system executables in case it's somehow not 64-bit, despite the indication: file $(which ls).
Make sure there's no funny characters in the path that would prevent it being picked up there: echo $PATH | od -xcb.
Make sure your GOPATH is set up correctly (not sure this would affect go version but it's something extra to try).
In my case go compiler and language were not installed...
sudo apt install golang-go
For me this was the answer, this is on ubuntu18.04 windows subsystem linux 2 install:
export GOPATH=$HOME/go
export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin
I was facing the same issue in Docker, I'm writing an answer for anybody that may be using docker, In my case I had to install glibc, for context I'm using alpine3.17
And here's the portion of my dockerfile -
COPY --from=golang:1.19.5-alpine3.17 /usr/local/go/ /usr/local/go/
ENV GOPATH=/go
ENV PATH="${PATH}:/usr/local/go/bin:$GOPATH/bin"
RUN apk update && apk add --no-cache wget gcompat && apk -U upgrade
RUN wget -q -O /etc/apk/keys/sgerrand.rsa.pub https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub
RUN wget https://github.com/sgerrand/alpine-pkg-glibc/releases/download/2.35-r0/glibc-2.35-r0.apk
RUN apk add --force-overwrite glibc-2.35-r0.apk
I download the w_scan project(a small command line utility used to perform frequency scans for DVB and ATSC transmissions.) from http://wirbel.htpc-forum.de/w_scan/index_en.html. I also install gcc-arm-linux-gnueabi on my Ubuntu x86_64. I use the ./configure --host=arm-linux CC=arm-linux-gnueabi-gcc command to cross-compile, and it generates a binary file. However, I copy that file to my target board and execute that file, it shows sh: ./w_scan: No such file or directory.
I use the file command to see information of that binary file, it shows ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.31, BuildID[sha1]=0x9a584b4720fadf5eb5b77034ac85092daeb728c9, not stripped.
I found that error message stands the configuration of cross-compile doesn't correct.(reference http://ubuntuforums.org/showthread.php?t=1141792). How can I fix my configuration and correct cross-compile that project, THANKS!
./configure --host=arm-linux CC=arm-linux-gnueabi-gcc
make CFLAGS=-static
copy that binary file to my target board, it can execute normally and successfully.
And the file w_scan will shows
ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, for GNU/Linux 2.6.31, BuildID[sha1]=0x67b7e9f93015607f891c0b77493d9e47059ef6a1, not stripped.