In the process of Configuring NES environment for mobile edge computing using DPDK, system is generating an error message as follows:
Qemu-System-X86_64: -Chardev Socket,Id=Char1,Path=/Usr/Bin/Usvhost-1:
Failed To Connect Socket: No Such File Or Directory
Note: I am using CentOS 7.
List of commands used as follows:
mkdir -p /mnt/huge-1048576kB
mount -t hugetlbfs nodev /mnt/huge-1048576kB
./scripts/setup.sh
nginx
redis-server /etc/redis/redis.conf &
tunctl -t tap0
brctl addif virbr0 tap0
ifconfig eno1 0 up
ip addr add 10.138.77.17/24 dev virbr0
export RTE_SDK=/opt/dpdk-stable-16.07.2
export RTE_TARGET=x86_64-native-linuxapp-gcc
make
export NES_SERVER_CONF=/opt/intel/nev_sdk/nes_root/scripts/nes.cfg
cd scripts/
./nes-daemon-start
0000:1c:00.1 already bound to driver igb_uio, skipping
0000:1c:00.0 already bound to driver igb_uio, skipping
/usr/local/bin/qemu-system-x86_64 -enable-kvm -cpu host -m 4096 -no-reboot -no-hpet -drive file=/home/tcs/ubuntu-14.04.5-desktop-amd64.iso,if=virtio,id=drive-virtio-disk1,format=raw -object memory-backend-file,id=mem,size=4096M,mem-path=/mnt/huge-1048576kB/,share=on -numa node,memdev=mem -mem-prealloc -device virtio-net-pci,netdev=net0,mac=ac:1f:6b:09:cb:9a -netdev type=tap,id=net0 -chardev socket,id=char1,path=/usr/bin/usvhost-1 -netdev type=vhost-user,id=mynet1,chardev=char1 -device virtio-net-pci,mac=52:54:00:00:00:01,netdev=mynet1,id=net1,csum=off,gso=off,guest_csum=off,guest_tso4=off,guest_tso6=off,guest_ecn=off
Qemu-System-X86_64: -Chardev Socket,Id=Char1,Path=/Usr/Bin/Usvhost-1: Failed To Connect Socket: No Such File Or Directory
I am not familiar with NES, but from the listed commands it looks like after ./nes-daemon-start there should be a Unix socket in /Usr/Bin/Usvhost-1.
Since QEMU fails to connect to socket /Usr/Bin/Usvhost-1, apparently nes-daemon-start creates socket in another place.
The solution would be to check if the path /Usr/Bin/Usvhost-1 is correct. On most Unix file systems there is a differentiation in letter case, i.e. /Usr and /usr are different paths. So maybe this is the case QEMU cannot find the provided path.
Related
Building a cpp binary inside a docker builder with cmake
FROM ubuntu:focal as builder
WORKDIR /var/lib/project
RUN cmake ... && make ...
Then copying the built binary to final image which also is ubuntu:focal, to a WORKDIR.
WORKDIR /var/lib/project
COPY --from=builder /usr/src/project/bin/binary ./binary
EXPOSE 8080
CMD ["./binary"]
Running the docker with docker run hangs the docker (even with -d), no input and output. To stop the docker, I have to kill it from another terminal.
However, if I exec into that same container while it is hanging, and run the binary from the shell inside the docker, it will work as expected.
Command used to build the docker
docker build . --platform=linux/amd64 --file docker/Dockerfile --progress=plain -c 32 -t mydocker:latest
Tried:
CMD ["/bin/bash", "-c" , "./binary"]
CMD ["/bin/bash", "-c" , "exec", "./binary"]
And same configurations with ENTRYPOINT too.
Same behavior.
I'm guessing there is a problem with how the binary is built, maybe some specific flags are needed, because if I do docker run ... ls or any other built in command it will work and output to my stdout.
Expecting to have my binary std* redirected to my std* just like any other command inside docker.
There is another related question, as of now, unanswered.
Update:
Main binary is built with these
CXX_FLAGS= -fno-builtin-memcmp -fPIC -Wfatal-errors -w -msse -msse4.2 -mavx2
Update:
Main part of the binary code,
The version is apache arrow 10.0.1
int main() {
arf::Location srv_loc = arf::Location::ForGrpcTcp("127.0.01", 8080).ValueUnsafe();
arf::FlightServerOptions opt(srv_loc);
auto server = std::make_unique<MyService>();
ARROW_RETURN_NOT_OK(server->Init(opt));
std::printf("Starting on port: %i\n", server->port());
return server->Serve().ok();
}
UPDATE: The problem seems to be here:
While the container is hanging, I entered into it, and did a ps aux.
The binary gets PID=1, I don't know why this happens, but hardly this is the correct behavior.
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.2 0.0 341520 13372 ? Ssl 07:52 0:00 ./binary
root 12 0.5 0.0 4116 3412 pts/0 Ss 07:52 0:00 /bin/bash
root 20 0.0 0.0 5900 2884 pts/0 R+ 07:52 0:00 ps aux
UPDATE:
./binary is executable, chmod +x is useless.
Adding printfs to multiple places did not work, unless the last line server->Serve() is commented out, or prints are really large, then everything gets printed.
Separating return statement from server->Server() makes no difference.
UPDATE:
Running the built container with docker --init -d flag, works.
Tough is this the right way? and if so how can this be forced in dockerfile?
This problem is related to the pid of the process in the container. You can use the --init flag to avoid the problem. for more information visit this site- https://docs.docker.com/engine/reference/run/#specify-an-init-process
I'm currently tiptoeing into custom kernel building.
I first started on a VM in VirtualBox, installing a fresh distribution of Ubuntu Server 20.04.
I followed the following procedure:
# getting the archive
cd ~/src/linux/
wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.4.91.tar.xz
tar -xf linux-5.4.91.tar.xz
cd linux-5.4.91/
# getting the config of the kernel currently running
cp -v /boot/config-$(uname -r) .config
# adapting the config to the target kernel, selecting the default for everything
make oldconfig
# adding manually a suffix to the kernel name: "-tony"
make menuconfig
# building and installing modules & image
time make -j $(nproc)
sudo make modules_install
sudo make install
Everything goes fine, although the build takes a bit longer than expected (~30 minutes on a 6-core AMD Ryzen 5 3600 6-Core Processor, with 32 GB of RAM; I assigned 6 CPUs over the 12 available to the VM).
However, when I check the size of the source directory, now containing the object files of everything built, the size of the drivers directory bothers me:
user#vm:~/src/linux/linux-5.4.91$ du -hd 1
1.3G ./fs
544K ./certs
34M ./block
128K ./usr
41M ./tools
208K ./LICENSES
58M ./security
48M ./Documentation
3.4M ./init
58M ./include
895M ./sound
73M ./lib
5.1M ./ipc
95M ./crypto
2.0G ./net
2.2M ./samples
446M ./arch
5.2M ./scripts
195M ./.git
4.8M ./virt
142M ./kernel
56M ./mm
13G ./drivers
20G .
13 GB looks like a lot.
When I look at the installed files, the modules also looks very big (5.6G):
root#vm:/# find -name '*5.4.91*' | xargs du -hs
20G ./home/user/src/linux/linux-5.4.91
105M ./home/user/src/linux/linux-5.4.91.tar.xz
5.6G ./usr/lib/modules/5.4.91-tony+
4.0K ./var/lib/initramfs-tools/5.4.91-tony+
912M ./boot/initrd.img-5.4.91-tony+
232K ./boot/config-5.4.91-tony+
12M ./boot/vmlinuz-5.4.91-tony+
4.5M ./boot/System.map-5.4.91-tony+
Especially when I compare with the vanilla kernel installed with the distribution:
root#vm:/# find -name '*5.4.0-62*' | xargs du -hs
...
262M ./usr/lib/modules/5.4.0-62-generic
4.0K ./usr/lib/modprobe.d/blacklist_linux_5.4.0-62-generic.conf
4.0K ./var/lib/initramfs-tools/5.4.0-62-generic
...
12M ./boot/vmlinuz-5.4.0-62-generic
79M ./boot/initrd.img-5.4.0-62-generic
236K ./boot/config-5.4.0-62-generic
4.6M ./boot/System.map-5.4.0-62-generic
262M vs 5.6G seems like a lot of difference, taken into account that I took the same config file (the cp -v /boot/config-$(uname -r) .config command).
I also reproduced the same results on Ubuntu Server 18.04.
Moreover, I tried on my host directly (no VM) with again the same results.
I am obviously missing something here, but I cannot find what:
should I strip the kernel / the modules from unused symbols?
is there a configuration that is missing somewhere ?
Thank you in advance for your help!
Disabling CONFIG_SLUB_DEBUG, CONFIG_DEBUG_INFO and CONFIG_DEBUG_MISC in the kernel configuration resulted in reasonable build performance:
real 22m19.559s
user 119m17.273s
sys 12m15.424s
And the following size for the modules:
root#vm:/usr/lib/modules# du -hs *
261M 5.10.10-stripped+
262M 5.4.0-64-generic
Which is even better than the shipped kernel :) (notice I updated the kernel source, but it doesn't change the result if using the same kernel).
Apparently, one can also use make modules_install INSTALL_MOD_STRIP=1 to strip the modules when they are built with debug symbols, reducing the size without having to change the build options.
Installing with that option on the already-stripped kernel & modules as described above resulted in the following size:
user#vm:/usr/lib/modules$ du -hs *
260M 5.10.10-stripped+
262M 5.4.0-64-generic
We effectively gain one more megabyte from this additionnal stripping.
I'm using freeBSD on VirtualBox on Windows10.
I want to mount on Windows. (HOST:Windows GUEST:freeBSD)
I run mount command but got an error below.
mount -t vboxvfs -w mp /mnt/vbox
mount: mp: Operation not supported by device
How can I solve this error?
What I did:
I install virtualbox-ose-additions-nox11-5.2.34 and virtualbox-ose-kmod-5.2.34,
then append vboxguest_enable="YES" and vboxservice_enable="YES" to my /etc/rc.config.
mp is normal empty folder on C:
I also install Guest Additions following Virtualbox's dialog.
this error caused by typo.
wrong : vboxfs
correct: vboxvfs
(I write correct command in this Question but I enter wrong command to my machine.)
When I run make run.byte I get this error ocsigenserver: ocsigen:main: Fatal - You are not allowed to use port 80.. I've tried sudo make run.byte but sudo doesn't know about opam or ocsigenserver. I've tried to play with wwwuser in the Makefile.options, but I can't make it work.
The README generated by the distillery doesn't give much information, and I can't find anything online.
make test.byte works just fine.
Any idea please?
edit:
It looks like it has nothing to do with eliom/ocaml, non root users just can't run anything on ports lower than 1024 on Ubuntu. But I still don't understand why the distillery suggests that I can do it if my wwwuser is me, I don't think there's any way this is ever going to work.
I also don't understand how I am supposed to run sudo make run.byte, opam is installed in my ~ directory, sudo cannot find ocsigenserver.
I could make it work by running everything as root, but anytime I run an opam command as root I get the you shouldn't use opam as root warning. I don't think this is the way I'm supposed to run it. Something's not right.
With previous release of eliom (eliom.5.0.0) - I have not used yet the fresh 6.0.0 release - you have to install first your eliom application :
sudo make install
Then you have to kill the process listening to the 80/tcp port (ex: sudo netstat -tulpn 80 | grep :80 will help identify the process listening to that port - most likely apache2 or lighthttpd).
Then, you run your executable:
sudo PATH=$PATH OCAMLPATH=$OCAMLPATH LD_LIBRARY_PATH=$LD_LIBRARY_PATH
make run.byte
This is what is written in README created with eliom-distillery - but take care to set your env variables before :
OCAMLPATH is the location of ocaml used in your env (in my env :~/.opam/4.02.3/bin).
LD_LIBRARY_PATH : .opam/4.02.3/lib/stublibs (otherwise dllssl_threads_stubs is not found)
I have compiled nwipe open source utility in Centos. Once compiled it works absolutely fine on the machine where it was compiled. I have also copied the compiled package to another machine running Centos along with required libraries and it works fine.
I have tried to package this utility to work with Busybox RAMBOX embedded linux. The purpose of this utility is to PXEBoot the workstations via TFTP and auto wipe all the hard-drives.
In order to achieve this, I have used Linux kernel from Centos netboot CD and downloaded the busybox, copied nwipe utility that I compiled on another Centos development server.
I also copied all the required libraries. See below.
when I do ldd nwipe. It shows the dependencies for the libraries.
[root#localhost src]# ldd nwipe
linux-gate.so.1 => (0x00a78000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00650000)
libparted.so.2 => /usr/lib/libparted.so.2 (0x007fd000)
libpanel.so.5 => /usr/lib/libpanel.so.5 (0x00dd0000)
libncurses.so.5 => /lib/libncurses.so.5 (0x006db000)
libc.so.6 => /lib/libc.so.6 (0x004b0000)
libtinfo.so.5 => /lib/libtinfo.so.5 (0x007e2000)
/lib/ld-linux.so.2 (0x0048a000)
libuuid.so.1 => /lib/libuuid.so.1 (0x0025b000)
libdl.so.2 => /lib/libdl.so.2 (0x00649000)
libdevmapper.so.1.02 => /lib/libdevmapper.so.1.02 (0x0073c000)
libselinux.so.1 => /lib/libselinux.so.1 (0x006ba000)
libsepol.so.1 => /lib/libsepol.so.1 (0x00a2e000)
libudev.so.0 => /lib/libudev.so.0 (0x0066d000)
so I copied all these libraries dependencies to the busybox /lib /usr/lib folders.
Finally I compiled the busybox and used cpio and gzip to get the initrd.img file.
Then I use centos netboot kernel 2.6 and initrd.img to pxeboot the workstation. Everything works fine, I can use all the busybox basic linux commands. But when I execute ./nwipe it does not work. It simply shows the shell prompt again.
/# ./nwipe
/#
see below the content of my init file.
#!/bin/sh
#Mount things needed by this script
mount -t proc proc /proc
mount -t sysfs sysfs /sys
#Disable kernel messages from popping onto the screen
echo 0 > /proc/sys/kernel/printk
#Clear the screen
clear
#Create all the symlinks to /bin/busybox
busybox --install -s
#Create device nodes
mknod /dev/null c 1 3
mknod /dev/tty c 5 0
mdev -s
#Function for parsing command line options with "=" in them
# get_opt("init=/sbin/init") will return "/sbin/init"
get_opt() {
echo "$#" | cut -d "=" -f 2
}
#Defaults
init="/sbin/init"
root="/dev/hda1"
#Process command line options
for i in $(cat /proc/cmdline); do
case $i in
root\=*)
root=$(get_opt $i)
;;
init\=*)
init=$(get_opt $i)
;;
esac
done
#Mount the root device
mount "${root}" /newroot
#Check if $init exists and is executable
if [[ -x "/newroot/${init}" ]] ; then
#Unmount all other mounts so that the ram used by
#the initramfs can be cleared after switch_root
umount /sys /proc
#Switch to the new root and execute init
exec switch_root /newroot "${init}"
fi
#This will only be run if the exec above failed
echo "Failed to switch_root, dropping to a shell"
exec sh
Could someone please help me what I have to do to fix this?
How I can run my compiled software with busybox?
Thanks well in advance for reading this post.
I have managed to fix this by not using busybox. This time around I have used Centos minimal install and used dracut utility to create kernel and initramfs and mounted the root file system as NFS on the server. It works like a charm.
It works like a full blown Linux Centos and it is pretty fast.
Thank you for looking at this post :)