I want to update to PHP 8.1 in my old Centos 8.5.2111 server. But I'm unable to install Remi repository. I get the following:
othing provides (redhat-release >= 8.7 or centos-stream-release >= 8) needed by remi-release-8.7-2.el8.remi.noarch
[xxxxx#yyyy ~]$ cat /etc/redhat-release
CentOS Linux release 8.5.2111
[xxxxx#yyyy ~]$ sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm https://dl.fedoraproject.org/pub/epel/epel-next-release-latest-8.noarch.rpm
Last metadata expiration check: 0:36:51 ago on XXX yy Feb 2023 12:07:52 AM CET.
epel-release-latest-8.noarch.rpm 53 kB/s | 24 kB 00:00
epel-next-release-latest-8.noarch.rpm 30 kB/s | 11 kB 00:00
Package epel-release-8-18.el8.noarch is already installed.
Package epel-next-release-8-18.el8.noarch is already installed.
Dependencies resolved.
Nothing to do.
Complete!
[xxxxx#yyyy ~]$ sudo dnf install https://rpms.remirepo.net/enterprise/remi-release-8.rpm
Last metadata expiration check: 0:37:07 ago on XXX yy Feb 2023 12:07:52 AM CET.
remi-release-8.rpm 247 kB/s | 31 kB 00:00
Error:
Problem: conflicting requests
- nothing provides (redhat-release >= 8.7 or centos-stream-release >= 8) needed by remi-release-8.7-2.el8.remi.noarch
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
Maybe I missing something?
The message seems clear.
You need to update to the latest version of the OS, as explained in the FAQ. Older versions are insecure and unsupported, and their support in 3rd party repository is not sustainable.
You can choose to switch to
CentOS Stream 8, see https://www.centos.org/centos-stream/ with migration tools
RHEL 8.7, see https://www.redhat.com/en/blog/new-year-new-red-hat-enterprise-linux-programs-easier-ways-access-rhel
Alma Linux 8.7 see https://almalinux.org/ with migration tools
Rocky Linux 8.7 https://rockylinux.org/ with migration tools
Any other RHEL clone
Related
I'm using
Linux archbios 5.13.6-arch1-1 #1 SMP PREEMPT Thu, 29 Jul 2021 00:21:06 +0000 x86_64 GNU/Linux
operating system.
My problem comes after following the sublime official instructions for Arch. After these steps from sublime official docs, I just need to upgrade the sublime
sudo pacman -Syu sublime-text
I don't understand from where comes this error
sudo pacman -Syu sublime-text
:: Synchronizing package databases...
core 136.1 KiB 340 KiB/s 00:00 [##########################] 100%
extra 1566.4 KiB 3.00 MiB/s 00:01 [##########################] 100%
community 5.6 MiB 3.16 MiB/s 00:02 [##########################] 100%
multilib 149.8 KiB 1248 KiB/s 00:00 [##########################] 100%
sublime-text is up to date
:: Starting full system upgrade...
error: failed to prepare transaction (package architecture is not valid)
:: package sublime-text-4113-1-aarch64 does not have a valid architecture
I've checked /etc/pacman.conf
#SigLevel = Optional TrustAll
#Server = file:///home/custompkgs
[sublime-text]
Server = https://download.sublimetext.com/arch/stable/x86_64
Not quit sure, maybe problem is that when you type
pacman -Syu sublime-text // it takes default version for "sublime-text-4113-1-aarch64
but with yay and mention from where works,
yay -S aur/sublime-text-4
with this command it just works
I think I pasted the wrong version into the commandline and now have aarch64 errors also.
Removed the URL reference to aarch64 in the pacman.conf file which fixed half the problem.
Moved the var/lib/pacman/sync files into a backup directory. Re-ran the command:
sudo pacman -Syu sublime-text
FINALLY worked.
I can confirm Lord High Fixer's solution worked for me as well. I accidentally picked the wrong channel for aarch64 at first, then even after removing that channel from /etc/pacman.conf, I would continue getting the "package sublime-text-4113-1-aarch64 does not have a valid architecture" error.
I created a 'backup folder' in /var/lib/pacman/sync and moved sublime-text.db and sublime-text.db.sig into the folder. Ran pacman -Syu sublime-text and it installed correctly.
I have installed and used screen many times on several different operating systems. Recently I installed it on a NetBSD-8.0 virtual machine.
$ sudo pkgin install screen
calculating dependencies...done.
1 package to install:
screen-4.8.0nb1
0 to refresh, 0 to upgrade, 1 to install
0B to download, 1098K to install
proceed ? [Y/n] Y
installing screen-4.8.0nb1...
screen-4.8.0nb1: setting permissions on /usr/pkg/bin/screen-4.8.0 (o=root, g=wheel, m=4511)
screen-4.8.0nb1: adding /usr/pkg/bin/screen to /etc/shells
screen-4.8.0nb1: registering info file /usr/pkg/info/screen.info
===========================================================================
$NetBSD: MESSAGE,v 1.5 2005/12/28 17:53:24 reed Exp $
[snip]
===========================================================================
pkg_install warnings: 0, errors: 0
reading local summary...
processing local summary...
marking screen-4.8.0nb1 as non auto-removable
However, when I went to use it, I got an immediate failure.
$ uname -mrs
NetBSD 8.0 amd64
$ ls -l /usr/pkg/bin/screen
lrwxr-xr-x 1 root wheel 12 Apr 6 02:50 /usr/pkg/bin/screen -> screen-4.8.0
$ groups
users wheel
$ screen
poll: Invalid argument
This problem persists even when I first remove, then reinstall the screen package. Any suggestions as to what's wrong?
My guess is that the system used to build binary packages for 8.0 (as of the 8.0_2020Q1 pkgsrc release) is no longer quite compatible with the NetBSD-8.0 release. It is likely running on a newer release, inside a chroot(8) sandbox.
I would recommend using NetBSD-9.0 instead, as that is the latest NetBSD release, or NetBSD-8.2, as that is the latest release in the netbsd-8 branch. Using the latest NetBSD and pkgsrc releases provides better coverage against unpatched vulnerabilities.
However, if you want to keep using NetBSD-8.0, you can get a working screen(1) from the 8.0_2019Q4 pkgsrc release. To have pkgin(1) pull from that release, edit the /usr/pkg/etc/pkgin/repositories.conf file to use this repository URL:
http://ftp.NetBSD.org/pub/pkgsrc/packages/NetBSD/amd64/8.0_2019Q4/All
There is currently likely just one line in the file that is not commented out, and it points to a URL with just 8.0 in it (which on the server is a symbolic link to the latest pkgsrc release). Just replace that line, or comment it out and add the above line.
Then remove and re-install screen:
sudo pkgin remove screen && sudo pkgin install screen
This is my current version of Apache:
httpd -V
Server version: Apache/2.4.6 (CentOS)
Server built: Apr 24 2019 13:45:48
Server's Module Magic Number: 20120211:24
Server loaded: APR 1.4.8, APR-UTIL 1.5.2
Compiled using: APR 1.4.8, APR-UTIL 1.5.2
Architecture: 64-bit
Server MPM: prefork
threaded: no
forked: yes (variable process count)
I am using CentOS 7; when I try to update Apache, it says there are no upgrades. I know the latest version is 2.4.39: mine is 2.4.6.
I would recommend looking at RHEL's security backports page. It explains the process RH uses to update version numbers. Basically, even though your httpd -V says 2.4.6, RH may have updated the features and fixed issues from the CVE without updating the version number. Run rpm -q --changelog httpd | grep CVE-yyyy-nnnn, filling in yyyy-nnnn with a recent timestamp from the CVE list, and see if your version has received those updates.
Alternatively, you may not have the latest CentOS version, which may not have the updated list of software. Run yum update to be sure you have the latest version.
I am trying to install trafodion on Hortonworks 2.2 virtual machine.The following are the machine configurations.
Hotonwork 2.2 virual machine
HBase version 0.98.
Centos version.
I have tried following steps to install trafodion.
1) I have downloaded
log4c++ RPM
Trafodion Installer
Trafodion Server
2)mkdir $HOME/trafodion
mkdir $HOME/trafodion/downloads
cd $HOME/trafodion/downloads
3) yum install to install the log4c++ RPM
4)cd $HOME/trafodion/downloads
tar -zxf apache-trafodion-installer-1.3.0-incubating-bin.tar.gz -C $HOME/trafodion
5)cd $HOME/trafodion/installer
cp trafodion_config_default my_config and Edit Configuration File.
6)cd $HOME/trafodion/installer
./trafodion_install --accept_license --config_file my_config
When running installation I obtain following message.
home/trafodion/traf
****INFO: Copying over sqenvcom.sh
***INFO: untarring build file /usr/lib/trafodion/apache-trafodion-1.3.0-incubating-bin/trafodion_server-1.3.0.tgz to home/trafodion/traf
***ERROR: SQ config file cannot be found (home/trafodion/traf/sql/scripts/sqconfig).
***ERROR: Error while running traf_start.
***ERROR: Setup not complete, review logs.
***ERROR: Exiting....
I don't understand why is it saying that. I have defined all configurations in myconfig file.
Any help is appreciated.
See also the discussion on the Trafodion dev mailing list on Apr. 21. Here is the answer Amanda gave on that list:
Amanda Moran via trafodion.incubator.apache.org Apr 22 (4 days ago)
to dev Hi there Devidas-
If you are on a single node instance SQCONFIG should equal "". This
will signal the installer to go grab our standard file located in
$SQ_ROOT/sql/scripts.
Thanks!
Amanda
I'm trying to compile the latest stable (2.8.19) version of Redis. Build is successfull as well as all tests, but unexpectedly server runs on 32bit arch.
Log entries:
# Warning: 32 bit instance detected but no memory limit set. Setting 3 GB maxmemory limit with 'noeviction' policy now.
Redis 2.8.19 (00000000/0) 32 bit
Running in stand alone mode
Port: 6582
PID: 2381
Redis-cli INFO display arch_bits:32. Previous instance (version 2.4.6) works well on arch_bits 64, but I don't know which way it was installed.
OS version info:
root:~# uname -a
Linux localhost 2.6.32-5-amd64 #1 SMP Tue Mar 8 22:49:26 UTC 2011 x86_64 GNU/Linux
root:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 6.0.1 (squeeze)
Release: 6.0.1
Codename: squeeze
root:~# arch
x86_64
What are the ways to fix this issue and run latest redis as 64bit?
UPD
Despite above commands output, dpkg --print-architecture returns i386 and all packages in system are all or i386. Only redis-server 2.4.*, installed as a package, is strangely ia64.
What can I do in this situation? The server was setup long time ago by another person, and I is still too newbie in Unix.
It seems, my server needs a full migration from 32 to 64-bit architeture.
Current task solved by downloading compiled 64-bit DEB-package and installing it manually.