After repeated attempts and trying to google this issue I'm stuck and am looking for help from my fellow stackers.
Following the wiki from tcadmin I have to run the following commands
wget http://www.tcadmin.com/installer/mono-2.11.4-i386.rpm
yum -y install mono-2.11.4-i386.rpm --nogpgcheck
/opt/mono-2.11.4/bin/mozroots --import --sync --quiet
/opt/mono-2.11.4/bin/mono --aot -O=all /opt/mono-2.11.4/lib/mono/2.0/mscorlib.dll
for i in /opt/mono-2.11.4/lib/mono/gac/*/*/*.dll; do /opt/mono-2.11.4/bin/mono --aot -O=all $i; done
when I get to the yum part it fails and outputs this error.
file / from install of mono-2.11.4-bi.x86_64 conflicts with file from package filesystem-3.2-18.el7.x86_64
Most sites and places suggest using an override or force command but this sounds stupid and will probably cause issues down the road for myself and the system.
I have flagged a ticket with the company that supplies the wiki about this issue but I'm yet to have a reply.
Another suggestion was to extract the rpm and move the files one by one but this is quite time consuming..
The ticket was responed to with the following;
It is safe to force install because all files are placed in /opt/mono-2.11.4 but there is a bug with mono on centos 7 that prevents tcadmin from working correctly.
For anyone else who happens upon this thread, I'm pleased to report that while I didn't encounter this error installing mono (that was a whole other process) I did encounter it while trying to install TCAdmin itself, but I was able to complete the installation of TCAdmin on CentOS 7 after using rpmrebuild to modify the spec.
Simply install rpmrbebuild, run rpmrebuild -pe {packagename}.rpm, scroll down to the %files section and remove the lines for any offending directories (in my case, the '/' and '/home' directories), save and quit, press y, and note the result location. In my case, it was /root/rpmbuild/RPMS/noarch/{packagename}.rpm.
Traverse to that directory and run yum -y install ./{packagename.rpm and it will install without a hitch.
The same should also apply to any other packages that return the conflicts with filesystem error. Just adjust the package names in the above examples accordingly.
*Thanks to the venerable Ahmad Samir for pointing me in the right direction with his post in this thread.
I had the same issue trying to install Fluentd agent on CentOS 7:
(venv)[user#machine01 tmp]$ sudo rpm -ivh td-agent-2.1.1-0.x86_64.rpm
warning: td-agent-2.1.1-0.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID a12e206f: NOKEY
Preparing... ################################# [100%]
file /opt from install of td-agent-2.1.1-0.x86_64 conflicts with file from package filesystem-3.2-18.el7.x86_64
I wouldn't say that downgrading your whole OS is the solution. Maybe an elegant workaround would be to rebuild the .rpm file in order to avoid those file systems which are making conflicts. You can do this by modifying the spec file with rpmrebuild command.
However, if you trust the software you are about to install or you want to try if works no matter what, then an easier (and faster) workaround is to force the rpm installation. That's what I did ...
(venv)[user#machine01 tmp]$ sudo rpm -ivh --force td-agent-2.1.1-0.x86_64.rpm
warning: td-agent-2.1.1-0.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID a12e206f: NOKEY
Preparing... ################################# [100%]
Updating / installing...
1:td-agent-2.1.1-0 ################################# [100%]
adding 'td-agent' group...
adding 'td-agent' user...
Installing default conffile...
prelink detected. Installing /etc/prelink.conf.d/td-agent-ruby.conf ...
Configure td-agent to start, when booting up the OS...
...and it worked for me
(venv)[user#machine01 tmp]$ sudo systemctl start td-agent.service
(venv)[user#machine01 tmp]$ sudo systemctl status td-agent.service
td-agent.service - LSB: td-agent's init script
Loaded: loaded (/etc/rc.d/init.d/td-agent)
Active: active (running) since vie 2014-12-12 09:34:09 CET; 4s ago
Process: 17178 ExecStart=/etc/rc.d/init.d/td-agent start (code=exited, status=0/SUCCESS)
...
Hope it helps
This is an inherent issue with centos 7.
Going back to centos 6 fixed it.
Related
I'm trying to force rpm to follow a given install order and it is not working as expected. The Requires clause I added is not being respected.
I am doing a bare-metal Linux installer (openSUSE 42.2-based). A whole system -- hundreds of packages -- are installed with one RPM command (using --root). I am having problems with three packages -- pam-config, pam-script, and openssh. The pam-config %post scriptlet tries to modify files contained in pam-script and openssh but is installed, by default, before them. It does not have dependencies by default, so, having the source, I rectified that by adding:
Requires: pam-script
Requires: openssh
to pam-config.spec. (I also tried Prereq: with same results.) As expected, with this change, it switches the ordering for pam-script and that error goes away. But it steadfastly refuses to change the order of installation for openssh, which is installed two packages after pam-config. [Openssh is dependent on coreutils and shadow (pwdutil), both of which are already installed at this point. It's also dependent (PreReq) on a mysterious macro, %{fillup_prereq}.]
Everything else installs (and runs) just fine, but I would like to understand better how rpm works. I thought if I used Required: to specify openssh in pam-config, that openssh would invariably be installed before pam-config. It worked for pam-script.
rpm -qp --requires on the .rpm file shows openssh. I repeated the install with the -vv option instead of -v. I can see the Requires: for openssh listed just the same as pam-script (YES (added provide)). I see a pam-config-0.91xxx -> openssh-7.2p2xxx listed under SCC #8: 11 members (100 external dependencies). I see the install of pam-config, which has no dependency information and nothing remarkable except for the %post scriptlet command that generates the error (pam-config --service sshd --delete --listfile). What other kind of things should I be looking at to debug this? What are these SCCs? Am I missing something about Requires? Or is there something obscure I may have overlooked, like circular, indirect, or hidden dependencies (I've checked for that, but ruled it out)? I've looked at several RPM tutorials and done a number of web searches and come up empty.
UPDATE: It appears that unlike pam-script, openssh is caught up in a mutual-dependency critical section. Here is the order of the packages actually being installed:
ruby2.1-rubygem-ruby-dbus-0.9.3-4.3.x86_64.rpm
pam-script-1.1.6-1.os42.gb01.x86_64.rpm
suse-module-tools-12.4-3.2.x86_64.rpm
kmod-17-6.2.x86_64.rpm
kmod-compat-17-6.2.x86_64.rpm
libcurl4-7.37.0-15.1.x86_64.rpm
pam-config-0.91-1.2.os42.gb01.x86_64.rpm
systemd-sysvinit-228-15.1.x86_64.rpm
krb5-1.12.5-5.13.x86_64.rpm
openssh-7.2p2-6.1.SBC.os42.gb01.x86_64.rpm
dracut-044-12.1.x86_64.rpm
systemd-228-15.1.x86_64.rpm
If I stage an installation on a production system and stop just before pam-config, it complains about being dependent on krb5, which is in the future! If I stop at ruby, it works. If I stop at pam-script, it works. If I stop at suse-module-tools, it complains about dependencies on dracut. So I'm wondering if RPM abandons its ordering principle within a mutual-dependency critical section, or if there is a dependency I haven't uncovered yet. I am using rpm -q --requires and rpm -q --provides to work this out. Stay tuned.
You can add more explicit sub-fields to the Requires tag, e.g. Requires(post): openssh-server or Requires(pre,post): openssh-server.
A single RPM transaction isn't really atomic, but is treated that way. Without this additional information, it just ensures that the packages are installed by the end of this transaction, which is "good enough" most of the time.
Another option is to put the required configuration into a %triggerin stanza, which I believe only executes once both packages are installed.
I wanted to install msttfonts on CentOS 7. Following this guide everything goes fine, until I got to run the command:
# rpmbuild -bb msttcorefonts-2.5-1.spec
The system then throws this message:
cabextract is needed by msttcorefonts-2.0-1.noarch
It is pretty obvious that I've to install cabextract, so I did. By Downloading source from here, extracting, and then ./config... make... make install... (you know guys: all the routine). And I confirm the installation was successful with
# cabextract --version
Which answers with
cabextract version 1.6
So, I go back with my command rpmbuild... But the system stills answer me
cabextract is needed by msttcorefonts-2.0-1.noarch
And now, the questions:
What I'm doing wrong? Do I need to reboot the server? Is there a kind of command to tell the server "hey! this cabextract thing is already installed"?
... and well, while I was writting this question, I could resolve it thanks to this post. So I just leave this question just for further reference.
Thanks in advance.
You need to install the cabextract package (by running yum install cabextract).
The message you are seeing is a dependency error: the msttcorefonts-2.5-1.spec file lists a dependency on cabextract, but because you have installed it from source there is no information about it in the local packages database.
I try to build a debian package which to replace the lirc initial script
I have been referenced Building a preconfigured debian package, How to use dpkg-divert to temporarily remove/replace symlink when package is installed? and Debian Policy Manual Appendix G
But it has the problem with removes the package.
Here is the install prompt and it can be installed successfully
Setting up mylirctest (0.0.1) ...
Configuration file '/etc/init.d/lirc'
==> Deleted (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
The default action is to keep your current version.
*** lirc (Y/I/N/O/D/Z) [default=N] ? Y
Installing new version of config file /etc/init.d/lirc ...
Processing triggers for ureadahead (0.100.0-16) ...
There is the problem when progress my package
(Reading database ... 148259 files and directories currently installed.)
Removing mylirctest (0.0.1) ...
Removing 'diversion of /etc/init.d/lirc to /etc/init.d/lirc.disable by mylirctest'
dpkg-divert: error: rename involves overwriting `/etc/init.d/lirc' with
different file `/etc/init.d/lirc.disable', not allowed
dpkg: error processing package hdstation (--purge):
subprocess installed post-removal script returned error exit status 2
Errors were encountered while processing:
mylirctest
Here is my preinst file:
#/bin/sh
set -e
dpkg-divert --package mylirctest --add --rename --divert /etc/init.d/lirc.disable /etc/init.d/lirc
The postrm
#!/bin/sh
set -e
dpkg-divert --package mylirctest --remove --rename --divert /etc/init.d/lirc.disable /etc/init.d/lirc
Is there any wrong with my postrm?
And How can I disable the prompt message when install my deb package?
Many thanks
It's a year old question, but I've faced the same issue and fixed it, so here is the answer in case someone need it:
To properly restore the file using dpkg-divert in postrm you have to delete current file first, like this:
#!/bin/sh
set -e
rm /etc/init.d/lirc
dpkg-divert --package mylirctest --remove --rename --divert /etc/init.d/lirc.disable /etc/init.d/lirc
There is a major update available in the Debian experimental channel. It's a breaking update with completely new configuration. That said, the old lirc packaging bug exposed here should be fixed in the updated package (0.9.4b)
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 have a problem with installing old software developed in 1995 for Linux.
My operating system is Cent Os. and I got some errors as below when I tried to follow the program instruction. I still do not know what the problems are....
sometimes the clock skew error messages show up but frequently it does not come up.
Waiting for expert's help
igrf]$ make
make: Warning: File igrf' has modification time 98 s in the future
make:igrf' is up to date.
make: warning: Clock skew detected. Your build may be incomplete.
igrf]$ make install
make: Warning: File igrf' has modification time 94 s in the future
install -c /home/hj/master/mag/bin -m 755 ./igrf
install: omitting directory/home/hj/master/mag/bin'
make: * [install] Error 1
Thanks!!
I installed the old version of libpcap-1.0.0 on Ubuntu 18.04 from the source, but this was not successful, as it does not fit my version of Ubuntu and gives a make error: *** [install] Error 1.
Instead this tar.gz archive i used the usual command in the terminal:
sudo apt install libpcap-dev # the problem is solved
It is possible that there is incompatibility of archives to new versions of Ubuntu.
It is also possible to find missing dependencies, check this:
IMPORTANT: There is enough information about this error; please do not post anything unless there is a specific review!
make install --touch
What can i do to help find dependencies. All of these workarounds are specific to one configuration or another. Therefore, it makes sense to track other issues as a separate bug instead of continuing to use one bug report for each issue. To make sure we focus on bugs that affect testers, Q_A_ asks reporters to feel free to post fixes and commits. The answer was very focused on the lack of specific dependencies. It will automatically collect and attach updated debug information to your report. Please add them for the feisty to help muffle the compilation issue. Maybe even backport fixes for the dapper and edgy ones?
Initially when compiling mongoose i used the helper:
make --touch
и был вывод:
touch vc98
touch vc2017
touch mingw
touch mingw++
touch linux
touch fuzzer
touch fuzz
Then i installed the missing dependencies:
sudo apt install fuzz libfuzzer-10-dev ocaml-mingw-w64-x86-64 vc-dev
...and still not all, then i had to use install (using reportdependencies the current behavior is unexpected and unsatisfactory):
I have output for mongoose:
touch linux-libs
touch install
Reportdependencies doesn't handle this very well.
In this case, linux-libs (install is omitted) points to some missing libraries. And this:
sudo apt install liblinux-pid-perl
I had an equivalent problem in the past. It is tied to the timestamps of (some) files. You should try to use the command "touch" on the concerned files. This will update the time stamps of those files.
I hope this will make the trick.