While installing hdf5 I got this error :

# yum install hdf5.x86_64
Last metadata expiration check: 1:05:47 ago on Tue 14 Jan 2020 01:27:49 PM CET.
Error:
 Problem: conflicting requests
  - nothing provides libsz.so.2()(64bit) needed by hdf5-1.10.5-4.el8.x86_64
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

As it turns out, I’m not the only one. Turns out that installing epel-release does not cut it any longer; You need to install the PowerTools repo:

dnf config-manager --set-enabled PowerTools
yum update

After that; It installed fine :

 yum install hdf5.x86_64                                      Last metadata expiration check: 0:00:09 ago on Tue 14 Jan 2020 02:37:30 PM CET.
Dependencies resolved.
==========================================================================================
 Package              Arch            Version                   Repository           Size
==========================================================================================
Installing:
 hdf5                 x86_64          1.10.5-4.el8              epel                2.1 M
Installing dependencies:
 libgfortran          x86_64          8.2.1-3.5.el8             BaseOS              636 k
 libquadmath          x86_64          8.2.1-3.5.el8             BaseOS              167 k
 libaec               x86_64          1.0.2-3.el8               PowerTools           39 k

Transaction Summary
==========================================================================================
Install  4 Packages

Total download size: 3.0 M
Installed size: 12 M
Is this ok [y/N]: y
Downloading Packages:
(1/4): libaec-1.0.2-3.el8.x86_64.rpm                      1.4 MB/s |  39 kB     00:00
(2/4): libquadmath-8.2.1-3.5.el8.x86_64.rpm               4.0 MB/s | 167 kB     00:00
(3/4): libgfortran-8.2.1-3.5.el8.x86_64.rpm               8.2 MB/s | 636 kB     00:00
(4/4): hdf5-1.10.5-4.el8.x86_64.rpm                        11 MB/s | 2.1 MB     00:00
------------------------------------------------------------------------------------------
Total                                                     938 kB/s | 3.0 MB     00:03
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                                  1/1
  Installing       : libaec-1.0.2-3.el8.x86_64                                        1/4
  Installing       : libquadmath-8.2.1-3.5.el8.x86_64                                 2/4
  Running scriptlet: libquadmath-8.2.1-3.5.el8.x86_64                                 2/4
  Installing       : libgfortran-8.2.1-3.5.el8.x86_64                                 3/4
  Running scriptlet: libgfortran-8.2.1-3.5.el8.x86_64                                 3/4
  Installing       : hdf5-1.10.5-4.el8.x86_64                                         4/4
  Running scriptlet: hdf5-1.10.5-4.el8.x86_64                                         4/4
  Verifying        : libgfortran-8.2.1-3.5.el8.x86_64                                 1/4
  Verifying        : libquadmath-8.2.1-3.5.el8.x86_64                                 2/4
  Verifying        : libaec-1.0.2-3.el8.x86_64                                        3/4
  Verifying        : hdf5-1.10.5-4.el8.x86_64                                         4/4

Installed:
  hdf5-1.10.5-4.el8.x86_64                    libgfortran-8.2.1-3.5.el8.x86_64
  libquadmath-8.2.1-3.5.el8.x86_64            libaec-1.0.2-3.el8.x86_64

Complete!

As its written in the extra note’s :

NOTE for CentOS 8 users
EPEL packages assume that the 'PowerTools' repository is enabled.
You can do this with: dnf config-manager --set-enabled PowerTools
NOTE for CentOS users
You can install EPEL by running yum install epel-release. 
The package is included in the CentOS Extras repository, enabled by default.

I got this seemingly wrong error message from Centos 8 Linux shell :

[[email protected] httpd]# ll
total 566
drwxrwxr-x  3 svennd svennd      3 Dec 11 16:23 apps
drwxrwxr-x 20 svennd svennd      20 Dec 11 16:23 exts
drwxrwxr-x  4 svennd svennd      10 Dec 11 16:23 lib
lrwxrwxrwx  1 svennd svennd      8 Dec 11 16:23 tclsh -> tclsh8.4
-rwxrwxr-x  1 svennd svennd      781385 Dec 11 16:23 tclsh8.4
drwxrwxr-x  3 svennd svennd      5 Dec 11 16:23 work
[[email protected] httpd]# ./tclsh8.4
bash: ./tclsh8.4: No such file or directory

It’s there right ? So let’s check whats going on with this “No such file”.

[[email protected] httpd]# file tclsh8.4
tclsh8.4: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.9, with debug_info, not stripped

The issue is in the 32-bit information you get here, all modern Linux distributions (here Centos 8) are 64-bit; By default they don’t come with 32-bit library’s; You could try to find out what is going on by using ldd & strace. 

But in this case it gave little information :

[[email protected] httpd]# ldd ./tclsh8.4
        not a dynamic executable

The solution is to install glibc for i686 (32 bit);

yum install glibc-devel.i686

And voila, magically the error disappeared and I could run this piece of ancient history.

If you installed ipmitools, you can change the IP address source from static to DHCP or otherwise.

To change to DHCP :

ipmitool lan set 1 ipsrc dhcp

Check what is now setup :

ipmitool lan print

example :

[[email protected]~]# ipmitool lan print
Set in Progress         : Set Complete
Auth Type Support       : NONE MD2 MD5 PASSWORD
Auth Type Enable        : Callback : MD2 MD5 PASSWORD
                        : User     : MD2 MD5 PASSWORD
                        : Operator : MD2 MD5 PASSWORD
                        : Admin    : MD2 MD5 PASSWORD
                        : OEM      : MD2 MD5 PASSWORD
IP Address Source       : DHCP Address
IP Address              : -ethernet-
Subnet Mask             : 255.255.0.0
MAC Address             : -mac-
SNMP Community String   : public
IP Header               : TTL=0x00 Flags=0x00 Precedence=0x00 TOS=0x00
BMC ARP Control         : ARP Responses Enabled, Gratuitous ARP Disabled
Default Gateway IP      : -gateway-
Default Gateway MAC     : 00:00:00:00:00:00
Backup Gateway IP       : 0.0.0.0
Backup Gateway MAC      : 00:00:00:00:00:00
802.1q VLAN ID          : Disabled
802.1q VLAN Priority    : 0
RMCP+ Cipher Suites     : 1,2,3,6,7,8,11,12
Cipher Suite Priv Max   : XaaaXXaaaXXaaXX
                        :     X=Cipher Suite Unused
                        :     c=CALLBACK
                        :     u=USER
                        :     o=OPERATOR
                        :     a=ADMIN
                        :     O=OEM
Bad Password Threshold  : 0
Invalid password disable: no
Attempt Count Reset Int.: 0
User Lockout Interval   : 0

Thanks to this IBM documentation.

I got this weird error;

Warning: mysql_connect(): Headers and client library minor version mismatch. Headers:50162 Library:50524
Filename: mysqli/mysqli_driver.php

After checking PHP seems there was a different version of MariaDB installed; 5.5 vs 10.1;

php -i |grep API
Server API => Command Line Interface
PHP API => 20160303
Zend Extension Build => API320160303,NTS
PHP Extension Build => API20160303,NTS
MHASH API Version => Emulated Support
Client API library version => 10.1.23-MariaDB
Client API header version => 5.5.52-MariaDB
Client API version => 10.1.23-MariaDB
Phar API version => 1.1.1

To fix it I installed ‘mysql native driver’ instead of the MySQL lib what is mysqlnd ? See this writeup by ulf-wendel.

fix :

yum remove php71w-mysql
yum install php71w-mysqlnd

[[email protected] /]# service php-fpm restart
Redirecting to /bin/systemctl restart php-fpm.service
[[email protected] /]#

See also stackoverflow and MySQL explanation.

This is a mount issue, that I haven’t faced lately anymore; It was however in my drafts for so long; I might as wel write it up;

linux_raid_member is a filesystem that is part of a software RAID meaning you need at least two disks to read the data in a “normal” state. So it largely depends on what RAID level was setup and how many disks where involved.  Most common RAID types are 0, 1, 5, 6, 10. RAID 0, you need all disks, RAID 1 you could access the data with only half of all the disks, with RAID 5, you need all disks – 1; raid 6 you need all disk -2; raid 10 you need half of all disks, but you need the full set.

You might not know what kind of RAID level was picked, lucky you can examine that from the metadata, using mdadm :

# mdadm --examine /dev/sdc1
          Magic :
        Version : 
    Feature Map :
     Array UUID : 
           Name : 
  Creation Time : 
     Raid Level : raid1
   Raid Devices : 2

- snap -

This learns us that there where only 2 devices and the level was RAID 1; meaning all data is on both disks, and should be equal !

We can start the raid again using mdadm :

mdadm --assemble --run /dev/md0 /dev/sdc1 --force

note that we need to use force as mdadm will rightfully complain about the raid being degraded (its missing a disk).

This should generate /dev/md0 which we can mount normally :

mount /dev/md0 /mnt/external_disk

useful “cheat sheet ” for mdadm by ducea

Library missing during install of MongoDB :

gssapi/gssapi.h: No such file or directory

On Centos 7.6 it gets fixed by :

yum install krb5-devel.x86_64

krb5 is a development package for kerberos, a network authentication system;

Kerberos is a network authentication system. The krb5-devel package contains the header files and libraries needed for compiling Kerberos 5 programs. If you want to develop Kerberos-aware programs, you'll need to install this package.

A quick fix for a weird issue that in Proxmox unprivileged container fails to install filesystem update on Centos 7 :

[[email protected] ~]# yum install filesystem
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: ftp.belnet.be
 * extras: ftp.belnet.be
 * updates: ftp.belnet.be
Resolving Dependencies
--> Running transaction check
---> Package filesystem.x86_64 0:3.2-21.el7 will be updated
---> Package filesystem.x86_64 0:3.2-25.el7 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

===================================================================================================================================================================================================================
 Package                                              Arch                                             Version                                                Repository                                      Size
===================================================================================================================================================================================================================
Updating:
 filesystem                                           x86_64                                           3.2-25.el7                                             base                                           1.0 M

Transaction Summary
===================================================================================================================================================================================================================
Upgrade  1 Package

Total download size: 1.0 M
Is this ok [y/d/N]: y
Downloading packages:
Delta RPMs disabled because /usr/bin/applydeltarpm not installed.
filesystem-3.2-25.el7.x86_64.rpm                                                                                                                                                            | 1.0 MB  00:00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Updating   : filesystem-3.2-25.el7.x86_64                                                                                                                                                                    1/2
Error unpacking rpm package filesystem-3.2-25.el7.x86_64
error: unpacking of archive failed on file /sys: cpio: chown
  Verifying  : filesystem-3.2-25.el7.x86_64                                                                                                                                                                    1/2
filesystem-3.2-21.el7.x86_64 was supposed to be removed but is not!
  Verifying  : filesystem-3.2-21.el7.x86_64                                                                                                                                                                    2/2

Failed:
  filesystem.x86_64 0:3.2-21.el7                                                                           filesystem.x86_64 0:3.2-25.el7

Complete!

The fix, thanks to this post :

echo "%_netsharedpath /sys:/proc" >> /etc/rpm/macros.dist

and tada :

Updated:
  filesystem.x86_64 0:3.2-25.el7

Today, I had a new issue, a server blankly refused to reboot/shutdown.

[[email protected] ~] reboot -h now
Failed to start reboot.target: Connection timed out
See system logs and 'systemctl status reboot.target' for details.
Failed to open /dev/initctl: No such device or address
Failed to talk to init daemon.

I first tried :

[[email protected] ~]# systemctl --force reboot
Failed to execute operation: Activation of org.freedesktop.systemd1 timed out

which failed, so I had to get the big guns : systemctl --force --force reboot

[[email protected] ~]# systemctl --force --force reboot
Rebooting with argument 'now'.
packet_write_wait: Connection to 10.1.255.253 port 22: Broken pipe

As you see that restarted the server; weird issue, solved thanks to Luke