Here am experimenting on including firmware-atheros network driver package of Debian flavor of OS. Here goes the command
$ sudo mkosi -d debian -r buster -f -b -t gpt_ext4 --checksum --password password --package=vim,curl,git,firmware-atheros,linux-image-amd64 -o image.raw
Error on screen: subprocess.CalledProcessError:.... returned non-zero exit status 100.
Let me know what would be the issue when am trying to include the firmware-atheros package? is it in-compatible? or anything else I should include for resolving this conflict?
The above issue if you ever encounter, while working on generating a minimal operating system by using this command mkosi. Please include --repositories=main,non-free option. Since by default it only considers main only.
Related
I am trying to install kaldi on a windows computer using cygwin.
When I run ./tools/check_dependencies.sh (as requested in the INSTALL file)
I get "zlib is not installed", so I go to the cygwin package list and try to install.
The thing is - there is no "zlib" per say see snapshot
there are all kinds of packages but their execution name is not "zlib" (except one which is irrelevant), it's always something-zlib-somthing.
And so I end up getting the same message even after I install them.
The code in check_dependencies.sh that does that is:
if ! echo "#include " | $CXX -E - >&/dev/null; then
echo "$0: zlib is not installed."
add_packages zlib-devel zlib1g-dev zlib-devel
fi
I understood there is no (relevant) way of installing zlib directly with cygwin - so that's a dead end.
Anyway I tried to make it work but no success - your help is very much appreciated.
Using Kaldi in cygwin is originally a bad idea. Its kind of supported but you will have many problems here and there. Simply install Linux either on a separate server or in a virtual machine.
I'm currently trying to get Vagrant to provision a working CentoOS7 image on Windows10, using Hyper-V. Vagrant 1.8.4, current latest.
I envcounter a problem where the provisioning fails and I need to workaround each time. The CentOS7 image is a minimal image and does not include cifs-utils, therefore the mount wont work. So, I need cifs-utils installed before mount.
Error:
==> default: Mounting SMB shared folders...
default: C:/Programs/vagrant_stuff/centos7 => /vagrant
Failed to mount folders in Linux guest. This is usually because
the "vboxsf" file system is not available. Please verify that
the guest additions are properly installed in the guest and
can work properly. The command attempted was:
mount -t cifs -o uid=`id -u vagrant`,gid=`getent group vagrant | cut -d: -f3`,sec=ntlm,credentials=/etc/smb_creds_4d99b2
d500a1bcb656d5a1c481a47191 //192.168.137.1/4d99b2d500a1bcb656d5a1c481a47191 /vagrant
mount -t cifs -o uid=`id -u vagrant`,gid=`id -g vagrant`,sec=ntlm,credentials=/etc/smb_creds_4d99b2d500a1bcb656d5a1c481a
47191 //192.168.137.1/4d99b2d500a1bcb656d5a1c481a47191 /vagrant
The error output from the last command was:
mount: wrong fs type, bad option, bad superblock on //192.168.137.1/4d99b2d500a1bcb656d5a1c481a47191,
missing codepage or helper program, or other error
(for several filesystems (e.g. nfs, cifs) you might
need a /sbin/mount.<type> helper program)
In some cases useful info is found in syslog - try
dmesg | tail or so.
As it is now, the provisioning has to fail, and I need to:
vagrant ssh (powershell)
(connect to instance via putty/ssh)
sudo yum install cifs-utils -y (putty/ssh)
(wait for install...)
exit (putty/ssh)
vagrant reload --provision (powershell)
This is obviously a pain and I am trying to streamline the process.
Does anyone know a better way?
You can install the missing package in your box and repackage this box so you can distribute a new version of this box containing the missing package.
In order to provision a vagrant box you need to create it from an iso. While preparing the box you can install all needed packages for you. In your case it is Hyper-v - https://www.vagrantup.com/docs/hyperv/boxes.html
Best Regards
Apparently my original question was downvoted for some reason. #whatever
As I mentioned in one of the comments above:
I managed to repackage and upload an updated version. Thanks for the advice. Its available in Atlas as "KptnKMan/bluefhypervalphacentos7repack".
Special thanks to #frédéric-henri :)
As a follow-up of this question, I started building MPICH2 from source. I found this tutorial: Installing MPICH2 on a Single Machine and so far what I did is this:
./configure --disable-f77 --disable-fc --disable-fortran
[seems to be OK]
make; sudo make install
[long output with one warning]
libtool: warning: relinking 'lib/libmpicxx.la'
root#pythagoras:/home/gsamaras/mpich-3.1.4# mpich2version
bash: mpich2version: command not found
What am I doing wrong? Notice that I had first installed MPICH2 with apt-get and in order to remove it, I did:
apt-get remove --purge mpich2
apt-get autoremove // which might removed something that I need now
Tomorrow, I am going to try this: Getting And Building MPICH (which with first attempt failed to work in the autogen.sh part).
EDIT_1:
I couldn't get it to work, will try a combination of the two tutorials and report back. I did a configure and then the make from the other tutorial, failed too.
EDIT_2
This may shade some light about where it got installed (by following the first tutorial):
root#pythagoras:/home/gsamaras/mpich-3.1.4# which mpiexec
/usr/local/bin/mpiexec
root#pythagoras:/home/gsamaras/mpich-3.1.4# which mpirun
/usr/local/bin/mpirun
You installed into /usr/local, which is an OK way to do things. The README instructions you followed suggests another way which will not require administrative privileges.
I like to install into /home/robl/soft/mpich-whatever , so I can have different compilers, versions, configurations, etc. such flexibility is probably overkill for you, but it's one strategy.
To your question:
root#pythagoras:/home/gsamaras/mpich-3.1.4# mpich2version
bash: mpich2version: command not found
First, the command is now mpichversion, not mpich2version -- it's possible you were following an old tutorial.
Second, your shell might not know about the newly installed binaries. hash -r (at least on bash and tcsh) will tell the shell "forget about what you think you know about my file system and look harder".
I found this mpich-3.0.4-README, who seems to provided the solution.
Long story short, it says (it assumes you want to build 3.0.4 version, I did it with 3.1.4 (available here)):
tar xzf mpich-3.0.4.tar.gz
cd mpich-3.0.4
// you might want to disable fortran compiler (see the README I linked above)
./configure --prefix=/home/<USERNAME>/mpich-install 2>&1 | tee c.txt
make 2>&1 | tee m.txt
make install 2>&1 | tee mi.txt
PATH=/home/<USERNAME>/mpich-install/bin:$PATH ; export PATH
which mpicc
// should return something reasonable (with your directory)
mpiexec -n 2 ./examples/cpi
Now, the option with the machinefile does not work, because ssh needs a password, but that's another question.
I want to check in a script if PostgreSQL is installed or not on Linux and print the result.
Any suggestions on how to do the check?
What about trying the which command?
If you were to run which psql and Postgres is not installed there appears to be no output. You just get the terminal prompt ready to accept another command:
> which psql
>
But if Postgres is installed you'll get a response with the path to the location of the Postgres install:
> which psql
/opt/boxen/homebrew/bin/psql
Looking at man which there also appears to be an option that could help you out:
-s No output, just return 0 if any of the executables are found, or
1 if none are found.
So it seems like as long as whatever scripting language you're using can can execute a terminal command you could send which -s psql and use the return value to determine if Postgres is installed. From there you can print that result however you like.
I do have postgres installed on my machine so I run the following
> which -s psql
> echo $?
0
which tells me that the command returned 0, indicating that the Postgres executable was found on my machine.
Here's the information about using echo $?
We can simply write:
psql --version
output show like:
psql (PostgreSQL) 11.5 (Ubuntu 11.5-1.pgdg18.04+1)
If it is debian based.
aptitude show postgresql | grep State
But I guess you can just try to launch it with some flag like --version, that simply prints some info and exits.
Updated using "service postgres status". Try:
service postgres status
if [ "$?" -gt "0" ]; then
echo "Not installed".
else
echo "Intalled"
fi
There is no single simple way to do it, because PostgreSQL might be installed and set up in many different ways:
Installed from source in a user home directory
Installed from source into /opt or /usr/local, manually started or started by an init script
Installed from distributor rpm / deb packages and started via init script
Installed from 3rd party rpm / deb packages and started via init script
Installed from packages but not set to start
Client installed, connecting to a server on a different computer
Installed and running but not on the default PATH or default port
You can't rely on psql being on the PATH. You can't rely on there being only one psql on the system (multiple versions might be installed in different ways). You can't do it based on port, as there's no guarantee it's on port 5432, or that there aren't multiple versions.
Prompt the user and ask them.
There is no straightforward way to do this. All you can do is check with the package manager (rpm, dpkg) or probe some likely locations for the files you want. Or you could try to connect to a likely port (5432) and see if you get a PostgreSQL protocol response. But none of this is going to be very robust. You might want to review your requirements.
If you are running Debian Linux (or derivative) and if you have a postive return with > which psql, then simply type psql -V (capital "V") and you will get a return like: psql (PostgreSQL) 9.4.8
And if everything else fails from these great choice of answers, you can always use "find" like this. Or you may need to use sudo
If you are root, just type $$> find / -name 'postgres'
If you are a user, you will need sudo priv's to run it through all the directories
I run it this way, from the / base to find the whole path that the element is found in. This will return any files or directories with the "postgres" in it.
You could do the same thing looking for the pg_hba.conf or postgresql.conf files also.
For many years I used the command:
ps aux | grep postgres
On one hand it is useful (for any process) and gives useful info (but from process POV). But on the other hand it is for checking if the server you know, you already installed is running.
At some point I found this tutorial, where the usage of the locate command is shown. It looks like this command is much more to the point for this case.
aptitude show postgresql | grep Version worked for me
Go to bin directory of postgres db such as /opt/postgresql/bin & run below command :
[...bin]# ./psql --version
psql (PostgreSQL) 9.0.4
Here you go . .
You may also check in /opt mount in following path /opt/PostgresPlus/9.5AS/bin/
Well, all answersabove are good but not in all cases.
Basically check the folder /etc/postgresql/
in most cases there will be one subfolder eg. /etc/postgresql/11/ (or /etc/postgresql/12) which means that you have installed 11 (or 12) version, however in many cases you may have many of such subfolders, so having them all means that all those versions had been ever installed and could be in use ... so be aware of this important trace.
ps using Ubuntu 18.04
I am creating an RPM. This RPM will be packed with the CentOS ISO and will install when CentOs is installed. This can also be installed using normal rpm installation method. But rpm installation need to behave differently if it is installed from ISO and installed by rpm normal installation method. So, the question is how do I know whether the system is currently installing the ISO.
Thanks in advance.
You could check if /dev/cdrom is mounted and if the /mnt/cdrom contains the installation disc in the %pre /%post scripts.
Strictly speaking, RPMs should be agnostic to how they are installed, so the chances are if you need this in the RPM it's probably a flawed design and what you are trying to do can be done in some other way.
I would suggest looking at anaconda / kickstart scripts.
Definitely a flawed design.
There should never be any user interaction with an RPM install which is what I bet you are trying to do.
If you are installing from a live OS, you can check the existence of /dev/live or liveimg in kernel command line,
i.e.
[[ $(grep -c liveimg /proc/cmdline) != 0 ]] || [ -b readlink -f /dev/live ]