So currently I have Busybox installed on an embedded kernel in its /system/bin/ folder and can call manually to the VI editor by typing busybox vi and vi will be executed. HOWEVER, I want to create a symbolic link to busybox vi by just typing vi file.txt instead of busybox vi file.txt so I won't have to type busybox every time. How to do this? I already tried this:
Installing Busybox
If the Busybox executable is renamed to one of the commands it supports, it will act as that command automatically:
ln -s busybox pwd
./pwdfrom
...from Busybox's website but still doesn't work, all it says is on my terminal for which command is:
127|root#nitrogen6x:/system/bin # ln -s busbox which
root#nitrogen6x:/system/bin # which ls
/system/bin/sh: which: not found
127|root#nitrogen6x:/system/bin # ls -la which lrwxrwxrwx root root 1970-01-03 18:15 which -> busbox
any ideas what I'm doing wrong? My $PATH is: /sbin:/vendor/bin:/system/sbin:/system/bin:/system/xbin
I figured out how to get this to work
HERE'S HOW:
So I went to root directory:
cd /
Then I remounted the /system/ directory:
mount -o rw,remount /system
Then I went into the binary folder where busybox was located:
cd /system/bin/
Then I used the link command for the busybox binary I wanted:
ln -s busybox lsusb (remember you must be in /system/bin directory already)
For Already Linked Files:
For already linked files like ls, remove the linked file and replace with Busybox binary instead (I know it sounds crazy but you can always go back to system's binary utilities):
sudo rm /system/bin/ls
ln -s busybox ls (remember you must be in /system/bin directory already)
You should get something like this when you do ls -l ls:
lrwxrwxrwx 1 0 0 7 Jan 4 21:53 ls -> busybox
One point to consider is that you have to be on the same file system.
For example if you are trying to create a symbolic link from one mounted file system to a file on another file system then that's an issue.
If your / and /usr are not on the same mounted file system as there might be the case for embedded systems, then you cannot create a symbolic link /usr/bin/which to point to /bin/busybox.
One possible solution is to put a copy of busybox binary in /urs/bin and create link to that.
Related
I am setting up a foreign chroot environment to build for architectures other than amd64 from a GitLab CI image. Steps were mostly taken from https://www.hellion.org.uk/blog/posts/foreign-chroots-with-schroot-and-qemu/, except that I am skipping the schroot/sbuild part.
- export CROSS_ARCH=armhf
- export CROSS_ROOT=/opt/chroot/$CROSS_ARCH
- export DISTRO=stretch
- export CROSS_MIRROR=http://deb.debian.org/debian/
- apt-get update
- apt-get -y install debootstrap qemu-user-static binfmt-support
- mkdir -p $CROSS_ROOT
- debootstrap --variant=buildd --include=fakeroot,build-essential --arch=$CROSS_ARCH --foreign $DISTRO $CROSS_ROOT $CROSS_MIRROR
- mkdir -p $CROSS_ROOT/usr/bin
- cp /usr/bin/qemu-arm-static $CROSS_ROOT/usr/bin/
- chroot $CROSS_ROOT ./debootstrap/debootstrap --second-stage
When I now try to run a command in the target environment like this:
chroot $CROSS_ROOT qemu-arm-static uname -a
the command exits with an error (nonzero exit status), but no error message is printed. It works, however, if I specify the path:
chroot $CROSS_ROOT qemu-arm-static /bin/uname -a
And it gives me the following output, which indicates I am running inside the armhf environment:
Linux runner--azerasq-project-40807358-concurrent-0 5.4.109+ #1 SMP Wed Jun 16 20:00:10 PDT 2021 armv7l GNU/Linux
Oddly, the following works:
chroot $CROSS_ROOT qemu-arm-static /bin/bash -c "uname -a"
i.e. full path to bash, but no path for the command after -c.
Suspecting that there could be something wrong with $PATH, I ran:
chroot $CROSS_ROOT qemu-arm-static /bin/bash -c set
I get all of the GitLab-specific variables, as well as a bunch of others, including the following ones:
MACHTYPE=arm-unknown-linux-gnueabihf
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
When I run
chroot $CROSS_ROOT qemu-arm-static /usr/bin/env
some variables (such as $MACHTYPE) are missing but $PATH is the same. So $PATH seems to be set correctly, and a diff of the outputs (after sorting) does not indicate anything that looks related – the extra variables for bash -c set look mostly bash-specific.
Why won’t qemu-arm-static accept binaries without a full path if they are on $PATH? Where else should I look to debug?
Why won’t qemu-arm-static accept binaries without a full path if they
are on $PATH?
Because qemu-user is not a shell, it doesn't have code that would search the PATH. This is the piece of qemu-user code that opens executable image when it's started as in the examples that you give, and as you can see here exec_path comes directly from the command line.
On the other hand you can install qemu-user as a binfmt-misc handler, in which case the shell will do the PATH search and the kernel will invoke qemu-user with an open file descriptor of the executable file in the AT_EXECFD entry in the aux vectors.
From Windows, I can access the file systems of all the WSL containers from under \\wsl$.
And from inside a WSL container, I can access the windows C:\ drive as /mnt/c.
But how can I access another container's drive from inside a WSL container?
I'm trying to access \\wsl$\othercontainer\some\file from inside a WSL container.
wslpath can normally convert Windows file paths to paths accessible from WSL:
WSL2#~» wslpath 'C:\Windows\System32\drivers\etc\hosts'
/mnt/c/Windows/System32/drivers/etc/hosts
But it doesn't work for:
WSL2#~» wslpath '\\wsl$\othercontainer\some\file'
wslpath: \\wsl$\othercontainer\some\file
WSL2#~» echo $?
1
And of course:
WSL2#~» ls -l '\\wsl$\othercontainer\some\file'
ls: cannot access '\\wsl$\othercontainer\some\file': No such file or directory
This answer provided the answer:
sudo mkdir /mnt/othercontainer
sudo mount -t drvfs '\\wsl$\othercontainer' /mnt/othercontainer
ls -l /mnt/othercontainer/some/file
NOTE: It looks like symbolic links aren't supported. When one is encountered, we get an error like:
$ ls -l /mnt/othercontainer/bin
ls: cannot read symbolic link '/mnt/othercontainer/bin': Function not implemented
lrwxrwxrwx 1 root root 7 Apr 23 2020 /mnt/othercontainer/bin
Abstract
When I mount a folder to my container and the path to the folder is not yet created on the client podman will create it for me. I can set the permissions for the mounted folder on my host machine to match it to the container-user, but the created path folders do not have the same permissions.
Steps to reproduce
For example lets assume in my image the home directory of the user ist empty. Then I will do on my host:
$ mkdir foo
$ podman unshare chown 1000:100 foo
$ podman run -v $PWD/foo:/home/myuser/bar/foo:z [...] some/image:latest
that will result on my container as:
~ # ls -la
drwxr-xr-t 3 root root 4096 Jan 28 12:43 bar
~ # cd bar
~/bar # ls -la
drwxrwxr-x 2 1000 users 4096 Jan 28 12:42 foo
~/bar #
is this behavior intentional?
is there a way to tell podman to create the path with the same permissions as the destination folder?
I can imagine a work around, but it would be nice if I could tell it in the run command.
Use Case
In my case I try to run different jupyter notebooks as disposable container direct from docker.io. But I do want to share the user-settings. The user-settings folder is not present when the container mounts the volumes. So podman will create them, but as root. So the jupyter user cannot access the folders created by podman and will fail.
I could create a Buildfile from the images and create the folders in the buildphase. But I use different images all the time and I dont want to create a custom image for all my use cases.
I could mount the volume to the parent folder, but all kinds of different stuff gets stored there and I dont want to share this to all the different containers.
I could not dispose the containers after the initial boot, but I dont know when I want to reuse this container, if at all...
Maybe it is possible to map the jupyter user to your user with the --uidmap command-line option?
(untested)
$ mkdir foo
$ jupyterUID=1234 # Replace 1234 with the correct UID for the jupyter user
$ podman run -v $PWD/foo:/home/myuser/bar/foo:z [...] --uidmap=0:1:$jupyterUID --uidmap=$(expr $jupyterUID + 1):$(expr $jupyterUID + 1):$(expr 65536 - $jupyterUID - 1) --uidmap=${jupyterUID}:0:1 some/image:latest
I think something like this is needed when the container starts as the container root user and then runs a program as another user. If that other user would write files in a bind-mounted directory, the files would be owned by your normal user on the host. I don't know, though, if that is the case with your Jupyter container image.
Edit 4 April 2022
A related Stackoverflow answer that I wrote:
https://stackoverflow.com/a/71741794/757777
I also wrote a troubleshooting tip about using --uidmap and --gidmap in the Podman troubleshooting guide.
I'm trying to create a bash script to change the titles of my terminal windows so I can identify what they are doing. I spent a few hours on this and cant figure it out. The idea is to be able to execute settitle NewTitle. Thank you.
This is my echo:$PATH. It looks like Users/klik/bin is there twice. Maybe that is the issue?
~ klik echo $PATH
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Users/klik/bin:/Users/klik/bin
This is the script which was created in textedit in plain text format.
#!/bin/bash
# settitle: set the Mac Terminal title
# usage: to set the titlebar to 'PLAY', type: settitle PLAY
echo -e "\033]0;${1}\007\c"
This is my bash_profile and bin file.
if [ -f ~/.bashrc ]; then
source ~/.bashrc
fi
export PATH=$PATH:$HOME/bin
alias desk='cd ~/Desktop/'
alias down='cd ~/Downloads/'
alias github='cd ~/github/'
This is my ls -a output
Current directories
~ klik ls -l $HOME/bin | pbcopy
total 8
-rwx--x--x# 1 klik staff 147 Mar 9 21:39 settitle.sh
Try this:
echo -e "\033]0;FreddyFrog\007\c"
You need to use -e to turn on interpretation of escape characters. You can also use printf.
printf '\033]0;%s\007\015' "Hippo Croco Horror Pig"
This issue above was that the file was saved with .txt extension. I dont know why this was the case given the ls command showed a .sh ext. At any rate, this is the process I used for creating this script and and executing it.
Open Finder -> Applications->TextEdit in Mac.
Select New Document at bottom left.
From menu select Format -> Make Plain Text
Paste in this code:
#!/bin/sh
# settitle: set the Mac Terminal title
# usage: to set the titlebar to 'PLAY', type: settitle PLAY
echo "\033]0;${1}\007\c"
Thanks to Alvin Alexander for the code.
Still in TextEdit select menu File -> Save
Uncheck "If no extension is provided, use ".txt" "
When I chose my file name I saved it with no extension so i could just type the command settitle NewTitle without having to type the extension every time.
Note the folder the file is being saved to. It defaults to desktop on my machine.
Open Finder -> Go -> Go to Folder
Type in the path to your User Bin folder: mine was /Users/klik/bin
You can check to see if you have a User/bin folder by running: ls -l from your home directory.
If you don't have a bin folder in this directory you can create one by going to your $HOME directory and executing:
mkdir bin
To find out what is your home directory see this
You can then open the directory by executing:
open bin
This will open the folder in Finder.
Drag the script file you created into this folder.
Make sure the script is executable by executing the following command from the folder the file is in or by including the path to the file in name of file:
chmod +x <name of file>
Make sure that the script is in your executable $PATH by executing:
echo $PATH
You will get something like this:
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Users/<you>/bin
If you dont see the path of your script, ie /Users/''/bin, then the script file is not in your executable path and you need to put it in your .bash_profile. Execute ls -l to see if you have a .bash_profile file.
ls -l
If you don't have one, make sure your are in your $HOME directory then create one by executing:
mkdir .bash_profile
Open your .bash_profile file in your default editor:
open .bash_profile
Or open with nano (to save and close nano see this link):
nano .bash_profile
Add the following line to the .bash_profile then save/close:
export PATH=$PATH:$HOME/bin
Exit the terminal to reset by executing:
exit
Open the terminal then type:
settitle <whateveryouwant>
I hope this saves someone some time. Thanks to Mark Setchell for his constructive help.
I have a Arduino Yun and want setup the server for Yun.
So what I want is to copy a folder that contain a py file and a index.html to my Yun
I used mac terminal to do this operation
the command looks like this
scp -r /Users/gudi/Desktop/LobsterHeartRate root#192.168.240.1:/mnt/sda1
and then terminal asked for the password
after I typed, it shows
scp: /mnt/sda1/LobsterHeartRate: Not a directory
I didn't type /mnt/sda1/LobsterHeartRate why it shows this error
Your code
scp -r /Users/gudi/Desktop/LobsterHeartRate root#192.168.240.1:/mnt/sda1
requires that the remote directory /mnt/sda1 exists. This looks like it is not true in your case. Check it using ssh root#192.168.240.1 ls /mnt/sda1.
scp is simple tool and it does not allow you to rename directories on the fly and the target directory must exists. You might try
scp -r /Users/gudi/Desktop/LobsterHeartRate root#192.168.240.1:/mnt/
ssh root#192.168.240.1 mv /mnt/LobsterHeartRate /mnt/sda1
or so, if it will suit your needs. But copying more files, rsync is usually more suitable. Check its manual page and give it a try next time.
As #Jens Höpken notes, your post is a bit sparse. But trying to read between the lines of your post I suspect that LobsterHeartRate is a DIRECTORY on your local system but a FILE named LobsterHeartRate in your target system. This might be happening right at the top of the directory tree, or perhaps you have directories/files of the same name further down the tree. scp -rv might help resolve any confusions here.
Beware: scp -r resolves symbolic links. If you want to preserve symlinks you need to do something else. For historic reasons I use the following, though cpio with a find front-end opens up interesting possibilities for fine-grained file selections.
( cd /Users/gudi/Desktop && tar -cf - LobsterHeartRate ) |
ssh root#192.168.240.1 'cd /mnt/sda1 && tar -xf -'
For a safe "dry run" you could change the -xf to a -tf. The && chains are required to prevent bad things from happening if any prior command fails.
Disclaimer: any debugging is left as an exercise for the student.