I'm trying to run the hello_ompi program on two Ubuntu virtual machines on my computer.
This program can be found here.
The VMs have two processors and one core per processor.
The installed OS is Ubuntu 20.04.3-LTS 64 bit.
The hostfile I'm using is as follows:
192.168.xxx.xxx
192.168.xxx.xxx
I tried:
mpirun -n 2 --hostfile my_hostfile hello_ompi
The ouptut was:
--------------------------------------------------------------------------
mpirun was unable to find the specified executable file, and therefore
did not launch the job. This error was first reported for process
rank 0; it may have occurred for other processes as well.
NOTE: A common cause for this error is misspelling a mpirun command
line parameter option (remember that mpirun interprets the first
unrecognized command line token as the executable).
Node: 192.168.xxx.xxx
Executable: hello_ompi
--------------------------------------------------------------------------
I realized that the executable needs to be in a directory that is identical to that of the host node.
i.e. if on the host node path to the executable is:
/home/youruser/somedir/executable.c
Then on all of the machines in the hostfile the executable must be in the exact same directory on those machines.
The command ran perfectly once I corrected this.
Related
I was trying to use QEMU with a kernel ISO I am building but I am unable to run the test.
I am using Windows 10 64 bit and I have added the pc-bios folder to PATH if that matters.
I have tried the following commands till now:
Windows terminal screenshot
You can use bios-256k.bin that comes with QEMU. Add the following while running your command ... -L "C:\Program Files\qemu". Where "C:\Program Files\qemu" is the path to QEMU installation.
Add -L C:\Users\Ratul\AppData\Local\Android\Sdk\emulator\lib\pc-bios\ option to your command line. You tried this option, but used the path and name of the binary, and iIt should contain only the path.
I am trying to figure out what exactly an issue is, below is the step i am trying :
on Windows 2019, installed cygwin64, directly from cygwin terminal, executing beloow "configure" script works fine, below is the configure command :
bash configure --with-freetype=bundled --with-tools-dir=/cygdrive/c/progra~2/micros~1/2017/Enterprise/VC/Tools/ --with-boot-jdk=/cygdrive/c/jdk-10.0.2/ --with-jtreg=/cygdrive/c/jtreg-5.1-b01/ --with-version-pre=sncmid --with-version-build=$build --with-version-opt=
However when i automate using jenkins which will execute on windows slave node, it is failing with this below
configure: Found potential Boot JDK using configure arguments
configure: Potential Boot JDK found at /cygdrive/c/jdk-10.0.2/ is incorrect JDK version (Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 -Dsun.jnu.encoding=UTF-8); ignoring
configure: (Your Boot JDK version must be one of: 10 11)
configure: error: The path given by --with-boot-jdk does not contain a valid Boot JDK
configure exiting with result code 1
Wondering why the difference between "direct execute on cygwin works fine" and "from jenkins job" where i called using "c:\cygwin64\bin\bash.exe -l script.sh" this script.sh executes configure script.
Invocation of the script
c:\cygwin64\bin\bash.exe -l '%WORKSPACE%\script.sh' %BUILD_NUMBER% /cygdrive/c/openjdk11windows
content of script.sh:
#!/bin/bash
echo $1
build=$1
source ~/.bash_profile
source ~/.bashrc
bash configure --with-freetype=bundled --with-tools-dir=/cygdrive/c/progra~2/micros~1/2017/Enterprise/VC/Tools/ --with-boot-jdk=/cygdrive/c/jdk-10.0.2/ --with-jtreg=/cygdrive/c/jtreg-5.1-b01/ --with-version-pre=sncmid --with-version-build=$build --with-version-opt=
If any one has idea about this, please share.
I am trying to run a local build of gvfs. I have followed the Newcomers document to set up a working build environment, built gvfs from sources and am now trying to figure out how to run it.
The docs have instructions on running applications or the GNOME shell, which say I need to kill the current instance, then launch the newly-built binary with jhbuild run, as in:
$ killall gnome-weather
$ jhbuild run gnome-weather
or, in the case of the shell,
$ jhbuild run gnome-shell --replace
For gvfs, I see that it spawns a bunch of processes (all children of P1 running under my account), the first of them (lowest PID) being gvfsd. So I tried the following:
$ killall gvfsd
$ jhbuild run gvfs
Which gives me the error message:
jhbuild run: Unable to execute the command 'gvfs': [Errno 2] No such file or directory
If instead I try
$ jhbuild run gvfsd
I get the same message. Same when I try any of the above two with --replace.
Since gvfs is a daemon rather than an application, I searched around a bit and came across this post, which suggests launching daemons with
jhbuild run dbus-launch --exit-with-session name-of-daemon
No joy either... no matter whether I use gvfs or gvfsd for the name, I get the error message
Couldn't exec gvfs: No such file or directory
(reporting the name I specified in the command).
Is this the correct way to launch gvfs at all? If not, what is? If it is, how can I find out what's going wrong?
EDIT: Apparently, the code I intend to modify is part of the gvfs-mtp-volume-monitor binary – but essentially the same goes here. How do I launch my own version of the binary rather than the one that came with my OS distro?
jhbuild run can be used for gvfs in the same manner.
For gvfsd do the following:
jhbuild run ~/jhbuild/install/libexec/gvfsd -r
The -r switch tells gvfsd to replace any running version. gvfsd will also start gvfsd-fuse if it was built and you didn't disable it via a command-line switch.
You will also need to replace any volume monitors (and other processes you need), such as:
killall gvfs-mtp-volume-monitor
jhbuild run ~/jhbuild/install/libexec/gvfs-mtp-volume-monitor
Care must be taken with anything that is invoked over dbus:
Namespaces may change between versions. If that happened between the version shipped with your OS and the current one, the latter will not work unless you tweak your dbus config to reflect that.
If dbus is used to spawn processes, it will fall back to the binaries shipped with your OS. Again you would need to modify your dbus config (specifically .service entries) to point to your binaries.
I want to make some modifications in the kvm module in my Linux kernel. For this, I did the following:
Obtained the Kernel sources:
apt-get source linux-image-source-$(uname-r)
Modified a function in the file emulate.c - changed some variables and added a printk statement.
Built the kernel:
fakeroot debian/rules clean
fakeroot debian/rules binary-headers binary generic
Installed the packages produced as a result of building:
sudo dpkg -i linux*(version)*.deb
Rebooted the system.
Executed QEMU with kvm enabled.
However the changes I made, didn't seem to reflect when I try to test them in QEMU. Neither did the printk statement execute when I checked with dmesg.
Can anyone please point out which part I am getting wrong?
Installing a new kernel wont necessarily make it boot into it, you may need to change the default in your boot loader. (e.g. grub)
You can check whether the kernel you just compiled and installed is the same as what you booted with using:
cat /proc/version
If this is not as expected, then you need to tweak your Grub config and/or reboot and manually choose the correct kernel.
Having established the correct kernel, you may need to change the level of which messages are reported by the kernel (via dmesg)
This is controlled by a kernel proc file. You can see what the current values are by printing this file:
cat /proc/sys/kernel/printk
Example output:
4 4 1 7
The first argument - messages with severity < 4 (i.e. 0, 1 2 or 3) will be recorded.
The second argument - messages with no specified severity default to 4 and thus not seen by the system in the above example.
So the following will change the log so that all kernel messages are seen:
echo 8 > /proc/sys/kernel/printk
See (for example) http://www.makelinux.net/books/lkd2/ch18lev1sec3 for further information.
I need to change somehow size of files (increase or decrease) on Windows machine using bash scripts. (Content of files doesnt matter) But i have to run this scripts from remote linux machine. I've selected truncate command for size changing, this is exactly that i need, cause i need to change size exactly of chosen file, without changing it's descriptor. It is very important.
But i DO NOT have truncate on my linux machine and i CANNOT install it there (So dont tell me to install it there plz :)). I cannot install nothing on my linux machine it has specific kernel - this is a main option of all my problems.
So i've decided to install cygwin on my Windows machine, cause it has truncate command. Also i know that there are fallocate command, but my linux machine also doesnt have it, and cygwin doesnt have it too. So if there is some another command i wanna know it :)
Then after this steps i tried to change file size from cygwin terminal via truncate and all works perfectly. And the last problem that i had to solve was just run cygwin's bash from my remote linux, i've chosen winexe for that.
Finally the way that i've chosen is:
I run winexe command on my linux machine that runs:
winexe myHost "c:\cygwin\bin\bash.exe myScriptWithTRUNCATE"
on my Win machine.
But it doesnt work and i dunno why. truncate command doesnt change size of files at all. When i type
truncate --help
all works, i can see result of help option on my linux terminal, but e.g.
truncate -s someSize myFile
doesnt work, size of file doesnt change. Also error code from truncate -s someSize myFile is 0
Any suggestions?
try giving the name of your script that is "myScriptWithTRUNCATE" directly in winexe command .
example:-
winexe myHost "c:\cygwin\bin\bash.exe myScriptWithTRUNCATE"
also check debug log of winexe by modifying winexe command as :-
winexe -d 5 myHost "c:\cygwin\bin\bash.exe myScriptWithTRUNCATE"
see in this log what actually is sent over to windows as command in place for your script.
specifically see in " CTRL: sending command : run xxxxx"
see what "xxxxx" is in that debug log.
winexe gives you the control of windows command line(cmd.exe).
Try running you script after it has got control of cmd.exe.
Based on some findings above , try this link for more help
http://blog.dotsmart.net/2011/01/27/executing-cygwin-bash-scripts-on-windows/