Failed to start zabbix3.0 in centos7 - zabbix

I met a issue when I install zabbix3.0 by packages on centos7.
When I done on mysql , php , apache and configuration in zabbix.conf.
I run systemctl start zabbix-server.service.It didn't work!and show :
Job for zabbix-server.service failed. See 'systemctl status zabbix-server.service' and 'journalctl -xn' for details.Then , my colleague told me to install trousers and gnutls,and then ,zabbix-server worked.What is the use of these two software?If they are necessary,Why not put them in the package of zabbix?

You won't start Zabbix Server 3.0 on CentOS 7 because you don't have "Disabled" SELinux.
You can disabled SELinux right here: /etc/selinux/config.
After that, you must reboot your server with reboot or shutdown -r now.
After reboot, confirm that the getenforce command returns Disabled.

Most likely, you didn't install those packages, but upgraded them. They are linked in through the Jabber/XMPP support.
This was a bug in RedHat packages that took some time to resolve, see this bugreport : https://bugzilla.redhat.com/show_bug.cgi?id=1071171
And this is the Zabbix issue tracking the same problem : https://support.zabbix.com/browse/ZBX-7790

Related

Failed to install ROCm on Ubuntu 20.04 [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
Improve this question
I would like to set up AMD Radeon for Deep Learning on Ubuntu. The main libraries for my work are keras and pytorch. I followed strictly on ROCm installation guideline here but failed at the 3rd step with the command sudo apt install rocm-dkms. Error messages were shown as follows.
Setting up dkms (2.8.1-5ubuntu1) ...
Setting up hip-rocclr (4.0.20496.5685.40000-23) ...
Setting up rock-dkms (1:4.0-23) ...
Loading new amdgpu-4.0-23 DKMS files...
Building for 5.8.0-41-generic
Building for architecture x86_64
Building initial module for 5.8.0-41-generic
Error! Bad return status for module build on kernel: 5.8.0-41-generic (x86_64)
Consult /var/lib/dkms/amdgpu/4.0-23/build/make.log for more information.
dpkg: error processing package rock-dkms (--configure):
installed rock-dkms package post-installation script subprocess returned error
exit status 10
Setting up g++-9 (9.3.0-17ubuntu1~20.04) ...
Setting up g++ (4:9.3.0-1ubuntu2) ...
update-alternatives: using /usr/bin/g++ to provide /usr/bin/c++ (c++) in auto mo
de
Setting up build-essential (12.8ubuntu1.1) ...
dpkg: dependency problems prevent configuration of rocm-dkms:
rocm-dkms depends on rock-dkms; however:
Package rock-dkms is not configured yet.
dpkg: error processing package rocm-dkms (--configure):
dependency problems - leaving unconfigured
Setting up gcc-multilib (4:9.3.0-1ubuntu2) ...
No apport report written because the error message indicates its a followup erro
r from a previous failure.
Setting up g++-9-multilib (9.3.0-17ubuntu1~20.04) ...
Setting up g++-multilib (4:9.3.0-1ubuntu2) ...
Processing triggers for sgml-base (1.29.1) ...
Setting up x11proto-dev (2019.2-1ubuntu1) ...
Setting up libxau-dev:amd64 (1:1.0.9-0ubuntu1) ...
Processing triggers for libc-bin (2.31-0ubuntu9.2) ...
Processing triggers for man-db (2.9.1-1) ...
Setting up libxdmcp-dev:amd64 (1:1.1.3-0ubuntu1) ...
Setting up x11proto-core-dev (2019.2-1ubuntu1) ...
Setting up libxcb1-dev:amd64 (1.14-2) ...
Setting up libx11-dev:amd64 (2:1.6.9-2ubuntu1.1) ...
Setting up libglx-dev:amd64 (1.3.2-1~ubuntu0.20.04.1) ...
Setting up libgl-dev:amd64 (1.3.2-1~ubuntu0.20.04.1) ...
Setting up mesa-common-dev:amd64 (20.2.6-0ubuntu0.20.04.1) ...
Setting up rocm-opencl-dev (3.6Beta-17-g875c1f8-rocm-rel-4.0-23) ...
Settin XT g up rocm-clang-ocl (0.5.0.64-rocm-rel-4.0-23-50fb51a) ...
Setting up rocm-utils (4.0.0.40000-23) ...
Setting up rocm-dev (4.0.0.40000-23) ...
Processing triggers for libc-bin (2.31-0ubuntu9.2) ...
Errors were encountered while processing:
rock-dkms
rocm-dkms
E: Sub-process /usr/bin/dpkg returned an error code (1)
My kernel version is 5.8.0-41-generic. My VGA card is Gigabyte Radeon RX6900 XT. My CPU is AMD Ryzen 9 3900 XT. I tried several solutions suggested in previous posts but it did not solve my problem. May I have your suggestions to fix this.
I've been having the same issue as well. The only way I found to fix it is to roll back to the 5.6.0-1042-oem kernel. The AMD drivers don't seem to support any kernel past this one.
Edit: This is also a way to get the amdgpupro drivers to install without a problem.
WARNING: I'm writing all this after the fact and i might have missed a step or something along the way. Please be very careful especially with trying to remove kernels and when working in your boot directory. If you're uncomfortable with the idea of wrecking your system you can always set grub's default selection which is a lot safer than removing an initramfs.
Here's how I got RocM working
sudo apt install linux-image-5.6.0-1042-oem linux-headers-5.6.0-1042-oem && reboot
Make sure you boot into the 5.6 kernel by accessing the Ubuntu advanced options in grub.
sudo apt remove linux-image-5.8.0-41-generic linux-headers-5.8.0-41-generic && sudo apt autoremove && reboot
Again you'll have to reboot into 5.6 through the advanced options. (Hold the shift key after BIOS finishes loading to get the Ubuntu Advanced Options menu.) After you're back in it's a good idea to set your headers and image as held back because a kernel update will most likely break RocM.
sudo apt-mark hold linux-image-generic linux-headers-generic
Now we're going to try and flush out the 5.8 kernel. Start by flushing out the temporary files.
sudo rm -rv ${TMPDIR:-/var/tmp}/mkinitramfs-*
Now list all of the kernels installed.
dpkg -l | tail -n +6 | grep -E 'linux-image-[0-9]+'
And try to remove the 5.8 kernel. Do this for any kernel you have above the 5.6 one we installed.
sudo update-initramfs -d -k 5.8.0-41-generic
Now the initramfs, Systemmap, and config are still present in the boot dir so we need to clear those out to get grub working properly again.
cd /boot/
sudo rm vmlinuz-5.8.0-41-generic System.map-5.8.0-41-generic config-5.8.0-41-generic
Now you should be finally ready to update grub
sudo update-grub && reboot
Now when you load back in you should be able to install RocM
sudo apt install rocm-dkms
As per the official notes in this link, AMD ROCm platform is designed to support Ubuntu 20.04.1 (5.4 and 5.6-oem) and 18.04.5 (Kernel 5.4).
So kernel version 5.8 is not supported. However, downgrading is an option but instead of rushing to that, you can simply boot into an older version of kernel.
Try following steps:
Restart your computer,
Wait for the grub menu to open (how to open grub menu: link).
Select advanced options for ubuntu
Select an alternate kernal from the list shown.

Gnome Boxes on Fedora 33 fails to open

I attempt to load gnome-boxes from the terminal (I'm running Fedora 33) and get the following error
$ gnome-boxes
(gnome-boxes:3194): Gtk-WARNING **: 12:34:57.343: GtkFlowBox with a model will ignore sort and filter functions
(gnome-boxes:3194): Gtk-WARNING **: 12:34:57.344: GtkListBox with a model will ignore sort and filter functions
(gnome-boxes:3194): Boxes-WARNING **: 12:34:57.904: libvirt-machine.vala:83: Failed to disable 3D Acceleration
(gnome-boxes:3194): Boxes-WARNING **: 12:34:57.913: libvirt-broker.vala:70: Failed to update domain 'fedora33-wor-2': Failed to set domain configuration: XML error: Invalid PCI address 0000:04:00.0. slot must be >= 1
(gnome-boxes:3194): Boxes-CRITICAL **: 12:34:57.916: boxes_vm_importer_get_source_media: assertion 'self != NULL' failed
Segmentation fault (core dumped)
My system:
$uname -a
Linux localhost.localdomain 5.9.16-200.fc33.x86_64 #1 SMP Mon Dec 21 14:08:22 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
I don't whether it's related but I recently updated from kernel 5.9.11 directly to 5.9.16 (haven't used the PC in question for some weeks) and before gnome-boxes was working as normal.
Please advise how I can restore gnome-boxes - I have some virtual machines that I need to access...
I faced this issue when I force stopped Gnome-Boxes while cloning a VM.
Deleting the conflicting VM will resolve your issue(in your case 'fedora33-wor-2').
To delete the VM in fedora, install "libvirt-client" which provides "virsh" using the command
dnf install libvirt-client
then double check the available VM's using
virsh list --all
Delete the VM using command,
virsh undefine VM_Name
#channel-fun solved the problem of staring up gnome-boxes.
But the real problem is in cloning procedure. The XML describing the new machine is malformed.
virt-clone --original fedora33-ser --auto-clone
works properly.
I know this is an old thread, but I had the same problem recently.
I shut down gnome boxes whilst it was cloning a vm, and shutdown the machine.
I then couldn't open boxes, as it would just crash.
I was able to delete the VM itself, and then deleted the XML file associated with it.
To delete the VM itself, go to :
$HOME/.var/app/org.gnome.Boxes/data/gnome-boxes/images (which in my case is a symbolic link to a data drive)
and delete the VM with the name that you were cloning to (or safer, just move it somewhere).
To delete the XML file associated with it:
$HOME/.var/app/org.gnome.Boxes/config/libvirt/qemu/
and delete (or safer move) the file that is named VM_NAME.xml.
Then boxes should open ok, at least it worked for me.
Extending on Channel Fun's answer for Ubuntu repos the package is libvirt-clients (note the plural s):
sudo apt install libvirt-clients
Check the available VM's using:
virsh list --all
Delete the VM using:
virsh undefine VM_Name
If you receive the error:
error: Refusing to undefine while domain managed save image exists
Then you can explicitly remove that also using the --managed-save flag:
virsh undefine VM_Name --managed-save

KVMs not running after qemu-kvm upgrade in CentOS 8.1, RHEL 8.1

This is the error i encountered when i updated my CentOS 8.1/RHEL 8.1 machines and all the KVMs are showing the error below:
error: internal error: process exited while connecting to monitor: 2020-06-09T12:41:10.410896Z qemu-kvm: -machine pc-q35-rhel8.1.0,accel=kvm,usb=off,vmport=off,smm=on,dump-guest-core=off: unsupported machine type
Use -machine help to list supported machines
Note: The problem states the machine type Q35 is not well stated/configured in your virtual Kernel based machines RUNNING on RHEL 8/ CentOS 8
[Step 1:] cat /etc/libvirt/qemu/*.xml | grep \<name&apos;\| machine&apos;
This will list the machine type in all of the KVMs installed.
[Output Snippet]
machine pc-q35-rhel8.1.0
[Step 2:] cd /etc/libvirt/qemu; ll
This will list all the xml files in connection with your KVMs
[Step 3:] At /etc/libvirt/qemu Use virsh edit <KVM file> ###Don&apos;t include .xml###
Navigate to machine
[Output Snippet]
<os>
<type arch=&apos;x86_64&apos; machine=&apos;pc-q35-rhel8.1.0&apos;>hvm</type>
<loader readonly=&apos;yes&apos; secure=&apos;yes&apos; type=&apos;pflash&apos;>/usr/share/OVMF/OVMF_CODE.secboot.fd</loader>
<nvram>/var/lib/libvirt/qemu/nvram/Loadbalancer_VARS.fd</nvram>
<boot dev=&apos;hd&apos;/>
</os>
Change machine=&apos;pc-q35-rhel8.1.0&apos; to machine=&apos;q35&apos;
shift + zz to save and quit
[Step 4:]
systemctl restart libvirtd && systemctl status -l libvirtd
virsh list --all
virsh start --domain <KVM>
Check the status of your running KVMs
virsh list --state-running
Now the issue should be resolved and your KVMs should be humming away.
Note though if head back in and check on the configuration xml file with virsh edit, you&apos;ll note that q35 converts to pc-q35-rhel7.6.0 automatically.
But this shouldn&apos;t be an issue.
Cheers :)

PDO Exception : Could not find driver. [duplicate]

Does the MySQL-server and PHP5-MySQLi version have to match in order for a connection to be possible? I'm currently receiving the error below: I am running BSD.
"Fatal error: Uncaught exception 'PDOException' with message 'could not find driver'..."
Here is the the connection info:
$info = "mysql:dbname=myDB;host=localhost";
$user = "dbUser";
$pw = "somePW";
return(new PDO($info, $user, $pw));
Here is my MySQL information:
mysql-server-5.5.24
php5-mysqli-5.4.3
I had this same issue on my CentOS install. I had tried to install imagick and hosed my install. When I removed all of my php files and reinstalled something wasn't working right.
I ran:
yum install php-pdo
yum install php-pdo_mysql
After doing those two lines I ran
service httpd restart
and everything came back up and running.
PDO uses database specific drivers to connect to database systems. It looks like you are missing the pdo_mysql driver that is required to connect to a MySQL database. There is some details on installing the driver on the pdo_mysql manual page, or there may be a BSD package that you can use (I am afraid I'm not familiar enough with BSD to offer specific advice).
Thanks to zerkms and John C for pointing me in the right direction. Below are the commands I used to install the driver:
#cd /usr/ports/databases/php5-pdo_mysql
#make install clean
#apachectl restart

libvirt error when trying to 'hot' attach-disk on guest with "Channel qemu-ga"

I have KVM virtual machine running CentOS 7 as guest OS. I'm trying to attach an additional disk to it on the run (without shutting it down) using this command:
$ sudo virsh attach-disk centos --source /var/lib/libvirt/images/newdisk.img --target sdb --persistent
But receive an error:
error: Failed to attach disk
error: internal error: cannot update AppArmor profile 'libvirt-d2e7bbb8-c7b3-44ec-b0ea-27539e0df732'
If I do the same with Debian guest - everything is ok.
What is difference, how to solve that?
UPDATE:
I have a comment!
I compared two VM's xml and saw that CentOS have QEMU-agent in his configuration:
<channel type="unix">
<source mode="bind" path="/var/lib/libvirt/qemu/channel/target/centos_auto.org.qemu.guest_agent.0"></source>
<target name="org.qemu.guest_agent.0" type="virtio"></target>
<address bus="0" controller="0" port="1" type="virtio-serial"></address>
</channel>
Then I removed "channel qemu-ga", restarted VM and checked "hot add" feature. It worked.
I tested it on other VMs (CentOS, Fedora, Debian) and saw the same.
As a result:
If enable qemu-agent i cannot use hot plug.
If use "hot plug" i must forget about agent.
Is it my mistake in configuration or these features can't work together?
Host-OS: Ubuntu 15.10
QEMU emulator: now 2.4.92 (tested 2.3 and 2.4.1)
VMM: 1.3.0
This is a clear bug in the apparmor security driver for libvirt. The existence of the QEMU guest agent config in the XML should have no impact on ability to hotplug disks to a guest. This bug should be reported to the libvirt upstream, or Ubuntu bug trackers.