Q: MariaDB Installation Problem on Fedora 30 - mysql

I need to install MariaDB and i follow the official Fedora Wiki instructions but i couldn't manage to do a proper installatiın though. So, first i run dnf install mariadb mariadb-server command (under root) and the return is
Package mysql-community-client-8.0.17-1.fc30.x86_64 is already installed.
Package mysql-community-server-8.0.17-1.fc30.x86_64 is already installed.
Dependencies resolved.
Nothing to do.
Complete!
So i try to enable/start mariadb with systemctl start mariadb and then the return is
Failed to start mariadb.service: Unit mariadb.service not found.
I installed other essential packages like php, httpd, mysql etc. and i need to install LAMP too but I get this MariaDB error. Could you show me the way?

It happens because mysql-community packages are configured to obsolete mariadb packages.
The approach below might be not the most optimal, everyone is easy to pitch in to simplify it.
First of all, if you have mysql-community-* packages installed, you probably have MySQL Community repo configured. Search your /etc/yum.repo.d for it and remove it from there:
$ grep -ri community /etc/yum.repos.d/*
/etc/yum.repos.d/mysql.repo:[mysql80-community]
/etc/yum.repos.d/mysql.repo:name=MySQL 8.0 Community Server
/etc/yum.repos.d/mysql.repo:baseurl=http://repo.mysql.com/yum/mysql-8.0-community/fc/$releasever/$basearch/
sudo mv /etc/yum.repos.d/mysql.repo /tmp/
Then, check which exactly mysql-community-* packages you have:
$ rpm -qa | grep mysql-community
mysql-community-server-8.0.17-1.fc30.x86_64
mysql-community-libs-8.0.17-1.fc30.x86_64
mysql-community-client-8.0.17-1.fc30.x86_64
mysql-community-common-8.0.17-1.fc30.x86_64
The easiest way to get rid of them is just to remove them by dnf. But it needs to be done very carefully, because if they have been there for a while, you probably have other packages depending on them. So, when you run the remove command, make sure that you don't have an auto-yes (-y option), and examine the output before agreeing to uninstall. It might look somewhat like this:
$ sudo dnf remove mysql-community*
Dependencies resolved.
===================================================================================================================================================================================
Package Architecture Version Repository Size
===================================================================================================================================================================================
Removing:
mysql-community-client x86_64 8.0.17-1.fc30 #mysql80-community 66 M
mysql-community-common x86_64 8.0.17-1.fc30 #mysql80-community 8.3 M
mysql-community-libs x86_64 8.0.17-1.fc30 #mysql80-community 7.5 M
mysql-community-server x86_64 8.0.17-1.fc30 #mysql80-community 128 M
Removing dependent packages:
perl-DBD-MySQL x86_64 4.050-2.fc30 #fedora 367 k
Removing unused dependencies:
Note the section Removing dependent packages. I added only one package to make an example, but in your case it can be much longer and scarier. If you do have the section and don't know if you can safely remove all its contents, it maybe be better not to do it (just yet). Abort the operation.
Is this ok [y/N]: n
Operation aborted.
Instead, you can try to replace mysql-community packages with MariaDB. There is dnf option --allowerasing which seems to do the trick, but you need to specify package names with versions to work around mysql obsoleting (replace the version in the command with the actual version available by the time you are doing it):
$ sudo dnf install --allowerasing --setopt=install_weak_deps=False mariadb-server-10.3.17 mariadb-10.3.17
Last metadata expiration check: 0:07:18 ago on Mon 07 Oct 2019 02:25:32 PM UTC.
Dependencies resolved.
===================================================================================================================================================================================
Package Architecture Version Repository Size
===================================================================================================================================================================================
Installing:
mariadb x86_64 3:10.3.17-1.fc30 updates 5.9 M
mariadb-server x86_64 3:10.3.17-1.fc30 updates 17 M
Installing dependencies:
mariadb-common x86_64 3:10.3.17-1.fc30 updates 36 k
mariadb-connector-c-config noarch 3.1.3-1.fc30 updates 12 k
mariadb-errmsg x86_64 3:10.3.17-1.fc30 updates 205 k
mysql-selinux noarch 1.0.0-8.fc30 fedora 35 k
psmisc x86_64 23.1-5.1.fc30 fedora 133 k
Removing dependent packages:
mysql-community-client x86_64 8.0.17-1.fc30 #mysql80-community 66 M
mysql-community-server x86_64 8.0.17-1.fc30 #mysql80-community 128 M
Transaction Summary
Now nothing is removed as dependencies, apart from mysql-community, which was the goal.
The option --setopt=install_weak_deps=False is not strictly necessary, but without it dnf installs many packages which you probably don't need. You can run without the option to see the difference.
After you have replaced the server and client packages, you can check what else you have left from MySQL community server, and try to remove remaining packages if you want:
$ rpm -qa | grep mysql-community
mysql-community-libs-8.0.17-1.fc30.x86_64
mysql-community-common-8.0.17-1.fc30.x86_64
$ sudo dnf remove mysql-community-libs mysql-community-common
Dependencies resolved.
===================================================================================================================================================================================
Package Architecture Version Repository Size
===================================================================================================================================================================================
Removing:
mysql-community-common x86_64 8.0.17-1.fc30 #mysql80-community 8.3 M
mysql-community-libs x86_64 8.0.17-1.fc30 #mysql80-community 7.5 M
Transaction Summary
Now it seems safe, no dependencies anymore.
There is one catch I can think of. If you don't know why mysql-community was installed in the first place, it's possible that you have something which requires exactly it, and won't be satisfied with MariaDB replacing it. Then it probably won't allow you to replace the packages. But I can't guess what it could be, so it's up to you to try and see. I suppose it will show up in dnf output which you examine before confirmation.

Related

Getting gfortran 10 from Fedora 31

I tried to install gfortran 10 from Fedora 31.
Follow https://fortran-lang.org/learn/os_setup/install_gfortran
sudo dnf install gcc-gfortran leads to gfortran 9
I tried to download from https://fedora.pkgs.org/33/fedora-x86_64/gcc-gfortran-10.2.1-3.fc33.x86_64.rpm.html
the download link file leads to Failed to install file, not supported from graphic interface :(
or bash: ./gcc-gfortran-10.2.1-9.fc33.x86_64.rpm: cannot execute binary file: Exec format error from terminal with root.
Is there any way to install gfortran-10 from Fedora?
Thanks!
You can of course always compile GCC from source, it is not that hard and the script for getting the prerequisites is included (./contrib/download_prerequisites).
The easiest way is to download one of the snapshots https://gcc.gnu.org/snapshots.html and follow the instructions. You do not even have to have admin rights, you can do it privately in your home directory.
Check whether there is a repository with additional GCC versions for your distro. For example, on my OpenSuSE, I have packages for GCC 7, 8, 9, 10 and 11. And they can be installed concurrently.
Regarding:
bash: ./gcc-gfortran-10.2.1-9.fc33.x86_64.rpm: cannot execute binary file: Exec format error
You cannot run a rpm file in bash, you have to install it using rpm -i or using your higher level package manager.
The file you downloaded is an RPM package, not an executable. You would normally install it with dnf install ./gcc-gfortran-10.2.1-9.fc33.x86_64.rpm from the command line. However, that package is for Fedora Linux 33, and you're running 31. Occasionally this works, but generally installing packages from new releases on older releases isn't supported.
If, for some reason you can't upgrade to Fedora Linux 33 for your whole system, one approach is to use the toolbox utility to make a containerized workspace using a F33 container image. Then, you can install the version of gfortran you want into that (with dnf install gcc-gfortran).
You could also use F34 (out tomorrow) but note that that has gcc 11.

Wireguard refuses to run on Fedora 31: protocol not supported

I recently install wireguard-tools and restarted my machine several times. However, it will simply not run. I get this error every time:
Warning: `/etc/wireguard/myprovider.conf' is world accessible
[#] ip link add myprovider type wireguard
Error: Unknown device type.
Unable to access interface: Protocol not supported
[#] ip link delete dev myprovider
Cannot find device "provider"
I then ran dkms status and it came up entirely blank, even after a restart. Looking online, it doesn't seem like anyone else's dkms went blank. My kernel version is 5.5.13-200.fc31.x86_64, which is the latest I can go to. I've tried the general advice of cleaning packages, updating and then reinstalling wireguard but it has not worked. What should I do from here? Does this require a reinstall of the whole OS?
What does modinfo wireguard show?
Wireguard is included Linux 5.6 and higher. On your 5.5 kernel you'll need to install the a kernel module.
I'm a Debian user, but on fedora this should work:
$ sudo dnf copr enable jdoss/wireguard
$ sudo dnf install wireguard-dkms wireguard-tools
wireguard-tools only install's the tools, wireguard-dkms the kernel module, this will do the actual work.
reference
I solved it by upgrading wireguard :
sudo apt-get upgrade wireguard
Here is the terminal results:
(...)
Preparing to unpack .../92-wireguard-dkms_1.0.20200520-0ppa1~18.04_all.deb ...
-------- Uninstall Beginning --------
Module: wireguard
Version: 1.0.20200401
Kernel: 5.3.0-46-generic (x86_64)
-------------------------------------
Status: Before uninstall, this module version was ACTIVE on this kernel.
wireguard.ko:
- Uninstallation
- Deleting from: /lib/modules/5.3.0-46-generic/updates/dkms/
- Original module
- No original module was found for this module on this kernel.
- Use the dkms install command to reinstall any previous module version.
depmod...
DKMS: uninstall completed.
-------- Uninstall Beginning --------
Module: wireguard
Version: 1.0.20200401
Kernel: 5.3.0-51-generic (x86_64)
-------------------------------------
Status: Before uninstall, this module version was ACTIVE on this kernel.
wireguard.ko:
- Uninstallation
- Deleting from: /lib/modules/5.3.0-51-generic/updates/dkms/
- Original module
- No original module was found for this module on this kernel.
- Use the dkms install command to reinstall any previous module version.
depmod...
DKMS: uninstall completed.
------------------------------
Deleting module version: 1.0.20200401
completely from the DKMS tree.
------------------------------
Done.
(...)
Then sudo wg-quick up {conf_name} worked again.

Remove CUDA 10.0 and install CUDA 9.2 on Ubuntu 18.04

I'm trying to install TensorFlow-gpu, so I need the CUDA toolkit 9.2.
Unfortunately I installed CUDA 10 and then realized that.
How can I easily remove CUDA 10.0 and install CUDA 9.2, without touching the drivers (since I have Ubuntu 18 I would like to maintain the latest video drivers)?
I already tried to simple install CUDA 9.2 from .deb (network) file, it says
dpkg: error processing archive cuda-repo-ubuntu1710_9.2.148-1_amd64.deb (--install):
trying to overwrite '/etc/apt/sources.list.d/cuda.list', which is also in package cuda-repo-ubuntu1804 10.0.130-1
I already tried to simple install CUDA 9.2 from .run file as described here, it says
Not enough space on parition mounted at /tmp.
Need 2895511552 bytes.
Disk space check has failed. Installation cannot continue.
+1 to installing a stand-alone CUDA-9.2 in a separate dir using .run installer. That should work.
You can specify an alternative location for the temporary files using --tmpdir=... option when you run the .run installer.
I solved this issue as follow :
sudo apt-get purge nvidia*
sudo apt-get autoremove
sudo apt-get autoclean
sudo rm -rf /usr/local/cuda-10.0
This will remove cuda-10.0 and then you can install cuda-9.2 as you want
I have solved the problem using #Cs20 answer and doing:
sudo dpkg -P <package name>
in this case <package name> is cuda-repo-ubuntu1804

Can I bypass installing glibc.i686 as a dependency when I already have the x86_64 version?

I'm trying to install Atom from the official RPM provided. libXss.so.1 is a dependency and tries to install the 32-bit version of glibc when I already have the 64-bit version. It then conflicts with the 2.23.1-7 older version of glibc that I already have.
So where do I go from here? I'm guessing that there is a bugfix somewhere in libXss. libXss tries to install i686 arch for all it's dependencies.
I'm using Fedora 24 x86_64
Terminal Output
sudo rpm -ivh atom.x86_64.rpm
error: Failed dependencies:
libXss.so.1 is needed by atom-1.13.0-0.1.x86_64
sudo dnf install libXss.so.1
Error: Transaction check error:
file /usr/share/doc/glibc/NEWS from install of glibc-2.23.1-11.fc24.i686 conflicts with file from package glibc-2.23.1-7.fc24.x86_64
sudo dnf install glibc-2.23.1-11.fc.24.x86_64
Package glibc-2.23.1-11.fc24.x86_64 is already installed, skipping.
Dependencies resolved.
Nothing to do.
Complete!
Secondary/Unimportant Question
Do I need glibc-2.23.1-7.fc24.x86_64 when I already have glibc-2.23.1-11.fc24.x86_64? I see that I have both installed yet I have no conflict problems.
edit
I gave up and decided to install from the copr repo
sudo dnf copr enable mosquito/atom
sudo dnf install atom
Error: Transaction check error:
file /usr/lib64/libkadm5clnt_mit.so.10.0 from install of libkadm5-1.14.4-4.fc24.x86_64 conflicts with file from package krb5-libs-1.14.1-6.fc24.x86_64
file /usr/lib64/libkadm5srv_mit.so.10.0 from install of libkadm5-1.14.4-4.fc24.x86_64 conflicts with file from package krb5-libs-1.14.1-6.fc24.x86_64
What is going on?
Can I bypass installing glibc.i686 as a dependency when I already have the x86_64 version?
Not if you need to install 32-bit software — you'll need the 32-bit libs for that. 64-bit libraries aren't supersets of the 32-bit ones.
I'm trying to install Atom from the official RPM provided. libXss.so.1 is a dependency and tries to install the 32-bit version of glibc when I already have the 64-bit version. It then conflicts with the 2.23.1-7 older version of glibc that I already have.
This is a frequent problem. Installing 32-bit versions of packages without updating to the latest versions of the main 64-bit packages is not supported. Upgrade first, then install.
Do I need glibc-2.23.1-7.fc24.x86_64 when I already have glibc-2.23.1-11.fc24.x86_64? I see that I have both installed yet I have no conflict problems.
This can happen if there's an interrupted upgrade transaction. You should be able to dnf remove glibc-2.23.1-7.fc24.x86_64 safely. If that gives you errors, time to stop and make sure nothing else is wrong. Or, you can really just ignore it — next time a new glibc update comes out, it should replace both.
I gave up and decided to install from the copr repo
The errors you see here are actually the same root problem as trying to install 32-bit packages without updating first. RPMs can share files, as long as they are completely identical. That's true in matched versions of the various kerberos packages, but not true if there's a mismatch, and the dependency information doesn't handle this. So, again upgrade to latest packages before installing new ones.

Can't install driver for mysql for tarantool

Use tarantool version:Tarantool 1.6.8-586-g504e151
Installed from epel.
I want install driver for mysql, try this instruction on github: https://github.com/tarantool/mysql
git clone mysql.git tarantool-mysql - OK
cd tarantool-mysql -OK
cmake . -DCMAKE_BUILD_TYPE=RelWithDebugInfo - FAIL ON THIS STEP
cmake . -DCMAKE_BUILD_TYPE=RelWithDebugInfo
-- The C compiler identification is GNU 4.4.7
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- INCLUDE_DIR TARANTOOL_INCLUDE_DIR-NOTFOUND
-- PREFIX
CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:108
(message):
Could NOT find TARANTOOL (missing: TARANTOOL_INCLUDE_DIR)
Call Stack (most recent call first):
/usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:315 (_FPHSA_FAILURE_MESSAGE)
cmake/FindTarantool.cmake:29 (find_package_handle_standard_args)
CMakeLists.txt:11 (find_package)
How i can specify TARANTOOL dir?
I also tried to install via luarocks but it was also unsuccessful:
luarocks install
https://raw.githubusercontent.com/tarantool/mysql/master/mysql-scm-1.rockspec --local
Using https://raw.githubusercontent.com/tarantool/mysql/master/mysql-scm-1.rockspec... switching to 'build' mode
Error: Could not find expected file mysql/mysql.h, or mysql/mysql.h for MYSQL -- you may have to install MYSQL in your system and/or pass MYSQL_DIR or MYSQL_INCDIR to the luarocks command. Example: luarocks install mysql MYSQL_DIR=/usr/local
P.P.S.
yum install libmysqlclient-dev tarantool-dev
467 packages excluded due to repository priority protections
Setting up Install Process
No package libmysqlclient-dev available.
No package tarantool-dev available.
Error: Nothing to do
libmysqlclient-dev is the appropriate name on Ubuntu, but since you mention epel I'll guess you might want to try install mysql-devel instead. (Different distros, different naming conventions.)
On my machine "cmake . -DMYSQL_INCLUDE_DIR=mysql-include-directory" seems to work but is undocumented. However, if you install to the default directory, you shouldn't need that. Sometimes "mysql_config --include" will tell you where mysql.h is.
The Tarantool manual suggests that first you should install tarantool-dev on Ubuntu
http://tarantool.org/doc/book/app/d-plugins.html
but again I'm guessing you want a more epel-friendly package like this one:
https://pkgs.org/centos-7/epel-x86_64/tarantool-devel-1.6.8.530-2.el7.x86_64.rpm.html
-- you'll notice that it has files for "/usr/include/tarantool".