Showing posts with label Fedora Linux. Show all posts
Showing posts with label Fedora Linux. Show all posts

Wednesday, February 19, 2025

Runing dnf package manager on Linux with small memory

Running dnf package manager can sometimes be difficult on Linux hosts with small memory. I observed on a Rocky Linux 9 with 1 GB RAM after enabled epel, and dnf install would sometimes be killed due to OOM.

To address this issue, we can create and enable a swap space:

$ sudo dd if=/dev/zero of=/swapfile count=1024 bs=1MiB
$ sudo chmod 600 /swapfile
$ sudo mkswap /swapfile
$ sudo swapon /swapfile
$ sudo dnf update

Once done, we then turn off the swap space:

$ sudo swapoff /swapfile

Reference

This idea come from this Stackoverflow post

 

 

 

 

 

Wednesday, January 25, 2023

Disabling Linux Boot Splash Window

Most Linux systems use Plymouthd to display the Splash scren during boot. If you are running the computer as a server and do not log in from the console, the Plymouthd can sometimes bring more trouble than it is worth. For one, to display the Splash window, Plymouthd needs to interact with the driver of the graphics adapter in the system, and if there is an issue here, the system will not boot successfully. Since the server's console may not be conveniently accessed, this can be a real inconvenience.

To remove it on Linux systems like Fedora and Redhat, we can do the following,


sudo grubby --update-kernel=ALL --remove-args="quiet"
sudo grubby --update-kernel=ALL --remove-args="rhgb"
# directly edit /etc/default/grub and add "rd.plymouth=0 plymouth.enable=0" to GRUB_CMDLINE_LINUX
vi /etc/default/grub
sudo grub2-mkconfig -o /etc/grub2.cfg
sudo dnf remove plymouth

Wednesday, January 18, 2023

More Space Needed on Root File System When installing CUDA Kit

Following the instruction on Nivdia's site, I was setting up CUDA Kit on a Fedora Linux host, and encountered a problem that the installation process failed due to not encough free space on the root file system, as indicated by the error message below


$ sudo dnf -y install cuda
...
Running transaction check
Transaction check succeeded.
Running transaction test
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Transaction test error:
  installing package cuda-nvcc-12-0-12.0.76-1.x86_64 needs 67MB more space on the / filesystem
  installing package cuda-gdb-12-0-12.0.90-1.x86_64 needs 84MB more space on the / filesystem
  installing package cuda-driver-devel-12-0-12.0.107-1.x86_64 needs 85MB more space on the / filesystem
  installing package cuda-libraries-devel-12-0-12.0.0-1.x86_64 needs 85MB more space on the / filesystem
  installing package cuda-visual-tools-12-0-12.0.0-1.x86_64 needs 85MB more space on the / filesystem
  installing package cuda-documentation-12-0-12.0.76-1.x86_64 needs 85MB more space on the / filesystem
  installing package cuda-demo-suite-12-0-12.0.76-1.x86_64 needs 98MB more space on the / filesystem
  installing package cuda-cuxxfilt-12-0-12.0.76-1.x86_64 needs 99MB more space on the / filesystem
  installing package cuda-cupti-12-0-12.0.90-1.x86_64 needs 210MB more space on the / filesystem
  installing package cuda-cuobjdump-12-0-12.0.76-1.x86_64 needs 210MB more space on the / filesystem
  installing package cuda-compiler-12-0-12.0.0-1.x86_64 needs 210MB more space on the / filesystem
  installing package cuda-sanitizer-12-0-12.0.90-1.x86_64 needs 248MB more space on the / filesystem
  installing package cuda-command-line-tools-12-0-12.0.0-1.x86_64 needs 248MB more space on the / filesystem
  installing package cuda-tools-12-0-12.0.0-1.x86_64 needs 248MB more space on the / filesystem
  installing package cuda-toolkit-12-0-12.0.0-1.x86_64 needs 248MB more space on the / filesystem
  installing package cuda-12-0-12.0.0-1.x86_64 needs 248MB more space on the / filesystem
  installing package cuda-12.0.0-1.x86_64 needs 248MB more space on the / filesystem

Error Summary
-------------
Disk Requirements:
   At least 248MB more space needed on the / filesystem.
...
$

It turns out that CUDA is installed at the /usr/local directory, and indeed, the free space on / is low. The solution to this problem is to mount the /usr/local directory to a file system that has sufficient disk space. The following steps illustrates this solultion, provided that the file system mounted at /disks/disk1 has sufficient space


sudo mkdir /disks/disk1/local
sudo rsync -azvf /usr/local/* /disks/disk1/local/
sudo rm -r/usr/local
sudo mkdir /usr/local
sudo mount --bind /disks/disk1/local /usr/local
sudo cp /etc/fstab /etc/fstab.bu
su -c "echo \
  '/disks/disk1/local /usr/local none defaults,bind,nofail,x-systemd.device-timeout=2 0 0' \
  >> /etc/fstab"

Tuesday, January 17, 2023

Installing Missing LaTeX Packages?

I recently discovered that I can easily install missing LaTeX packages on Fedora Linux, that is, via


sudo dnf install 'tex(beamer.cls)' 
sudo dnf install 'tex(hyperref.sty)' 

Can we do the similar on Debian/Ubuntu distributions?

Reference

  1. https://docs.fedoraproject.org/en-US/neurofedora/latex/

Saturday, October 2, 2021

Dealing with "error: unpacking of archive failed" when upgrading Fedora Linux

I am upgrading a Fedora Linux system. A necessary step is to bring the system up-to-date. For this, I issue the command,

sudo dnf upgrade --refresh

However, the upgrade fails with an error message that complains about "unpacking of archive failed ... cpio: File from package already exists as a directory in system". Below is an exerpt of the error message,


$ sudo dnf upgrade --refresh
Docker CE Stable - x86_64                       110 kB/s | 3.5 kB     00:00
Fedora 32 openh264 (From Cisco) - x86_64        3.4 kB/s | 990  B     00:00
Fedora Modular 32 - x86_64                      146 kB/s |  12 kB     00:00
Fedora Modular 32 - x86_64 - Updates             69 kB/s |  12 kB     00:00
Fedora 32 - x86_64 - Updates                    122 kB/s |  12 kB     00:00
Fedora 32 - x86_64                              120 kB/s |  12 kB     00:00
Dependencies resolved.
================================================================================
 Package                 Arch     Version                       Repo       Size
================================================================================
Upgrading:
 filesystem              x86_64   3.14-2.fc32                   fedora    1.1 M
 gawk                    x86_64   5.0.1-7.fc32                  fedora    1.2 M
 npm                     x86_64   1:6.14.12-1.12.22.1.1.fc32    updates   3.3 M
 python3-numpy           x86_64   1:1.18.4-2.fc32               updates   4.4 M
 texlive-texlive.infra   noarch   7:20200327-21.fc32            updates   279 k

Transaction Summary
================================================================================
Upgrade  5 Packages

Total download size: 10 M
Is this ok [y/N]: y
Downloading Packages:
(1/5): texlive-texlive.infra-20200327-21.fc32.n 630 kB/s | 279 kB     00:00
(2/5): npm-6.14.12-1.12.22.1.1.fc32.x86_64.rpm  4.7 MB/s | 3.3 MB     00:00
(3/5): filesystem-3.14-2.fc32.x86_64.rpm        3.1 MB/s | 1.1 MB     00:00
(4/5): python3-numpy-1.18.4-2.fc32.x86_64.rpm   3.6 MB/s | 4.4 MB     00:01
(5/5): gawk-5.0.1-7.fc32.x86_64.rpm             2.0 MB/s | 1.2 MB     00:00
--------------------------------------------------------------------------------
Total                                           6.6 MB/s |  10 MB     00:01
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Running scriptlet: filesystem-3.14-2.fc32.x86_64                          1/1
  Preparing        :                                                        1/1
  Upgrading        : filesystem-3.14-2.fc32.x86_64                         1/10
Error unpacking rpm package filesystem-3.14-2.fc32.x86_64
  Upgrading        : gawk-5.0.1-7.fc32.x86_64                              2/10
error: unpacking of archive failed on file /usr/tmp: cpio: File from package already exists as a directory in system
error: filesystem-3.14-2.fc32.x86_64: install failed

Error unpacking rpm package gawk-5.0.1-7.fc32.x86_64
  Upgrading        : texlive-texlive.infra-7:20200327-21.fc32.noarch       3/10
error: unpacking of archive failed on file /usr/libexec/gawk: cpio: File from package already exists as a directory in system
error: gawk-5.0.1-7.fc32.x86_64: install failed

Error unpacking rpm package texlive-texlive.infra-7:20200327-21.fc32.noarch
  Upgrading        : python3-numpy-1:1.18.4-2.fc32.x86_64                  4/10
error: unpacking of archive failed on file /usr/share/perl5/TeXLive: cpio: File from package already exists as a directory in system
error: texlive-texlive.infra-7:20200327-21.fc32.noarch: install failed

Error unpacking rpm package python3-numpy-1:1.18.4-2.fc32.x86_64
  Upgrading        : npm-1:6.14.12-1.12.22.1.1.fc32.x86_64                 5/10
error: unpacking of archive failed on file /usr/include/numpy: cpio: File from package already exists as a directory in system
error: python3-numpy-1:1.18.4-2.fc32.x86_64: install failed

Error unpacking rpm package npm-1:6.14.12-1.12.22.1.1.fc32.x86_64
  Verifying        : npm-1:6.14.12-1.12.22.1.1.fc32.x86_64                 1/10
  Verifying        : npm-1:6.14.8-1.12.19.0.1.fc31.x86_64                  2/10
  Verifying        : python3-numpy-1:1.18.4-2.fc32.x86_64                  3/10
  Verifying        : python3-numpy-1:1.17.4-2.fc31.x86_64                  4/10
  Verifying        : texlive-texlive.infra-7:20200327-21.fc32.noarch       5/10
  Verifying        : texlive-texlive.infra-7:20190410-8.fc31.noarch        6/10
  Verifying        : filesystem-3.14-2.fc32.x86_64                         7/10
  Verifying        : filesystem-3.12-2.fc31.x86_64                         8/10
  Verifying        : gawk-5.0.1-7.fc32.x86_64                              9/10
  Verifying        : gawk-5.0.1-5.fc31.x86_64                             10/10

Failed:
  filesystem-3.12-2.fc31.x86_64
  filesystem-3.14-2.fc32.x86_64
  gawk-5.0.1-5.fc31.x86_64
  gawk-5.0.1-7.fc32.x86_64
  npm-1:6.14.8-1.12.19.0.1.fc31.x86_64
  npm-1:6.14.12-1.12.22.1.1.fc32.x86_64
  python3-numpy-1:1.17.4-2.fc31.x86_64
  python3-numpy-1:1.18.4-2.fc32.x86_64
  texlive-texlive.infra-7:20190410-8.fc31.noarch
  texlive-texlive.infra-7:20200327-21.fc32.noarch

Error: Transaction failed
$

As it complains that it can not write to the path indicated in the error message, such as, /usr/include/numpy because the directory already exists. To address this, I come out the following solution, i.e., to rename the directory or file that the error message complains about. For instance, we do these,


sudo mv /usr/tmp /usr/tmp.bu
sudo mv /usr/libexec/gawk /usr/libexec/gawk.bu
sudo mv /usr/share/perl5/TeXLive /usr/share/perl5/TeXLive.bu
sudo mv /usr/include/numpy /usr/include/numpy.bu

Then do upgrade again, as in,

sudo dnf upgrade --refresh

After this, don't forget to remove the backup files or directories, such as,


sudo rm -rf /usr/tmp.bu
sudo rm -rf /usr/libexec/gawk.bu
sudo rm -rf /usr/share/perl5/TeXLive.bu
sudo rm -rf /usr/include/numpy.bu

Dealing with Complexities

The above solutions work for some packages. However, there are two complexities. 

  1. Some packages has more than one or two files or directories that cause cpio to fail. The sympotom is that we would encounter the similar error. The solution is obvious, just to rename the file or the directory that causes the problem until we can successfully upgrade the package.
  2. Sometimes, the error message does not indicate which file or the directory causes the problem, such as, the example below,
$ sudo dnf upgrade --refresh
[sudo] password for hchen:
Docker CE Stable - x86_64                        38 kB/s |  13 kB     00:00
Fedora 33 - x86_64                               11 MB/s |  72 MB     00:06
Fedora 33 openh264 (From Cisco) - x86_64        1.4 kB/s | 2.5 kB     00:01
Fedora Modular 33 - x86_64                      3.1 MB/s | 3.3 MB     00:01
Fedora 33 - x86_64 - Updates                     12 MB/s |  30 MB     00:02
Fedora Modular 33 - x86_64 - Updates            2.8 MB/s | 3.2 MB     00:01
Last metadata expiration check: 0:00:01 ago on Sat 02 Oct 2021 09:14:19 PM EDT.
Dependencies resolved.
================================================================================
 Package   Architecture Version                             Repository     Size
================================================================================
Upgrading:
 npm       x86_64       1:6.14.15-1.14.17.6.1.fc33          updates       3.3 M

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

Total download size: 3.3 M
Is this ok [y/N]: y
Downloading Packages:
npm-6.14.15-1.14.17.6.1.fc33.x86_64.rpm         6.2 MB/s | 3.3 MB     00:00
--------------------------------------------------------------------------------
Total                                           4.0 MB/s | 3.3 MB     00:00
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Running scriptlet: npm-1:6.14.15-1.14.17.6.1.fc33.x86_64                  1/1
  Preparing        :                                                        1/1
  Upgrading        : npm-1:6.14.15-1.14.17.6.1.fc33.x86_64                  1/2
Error unpacking rpm package npm-1:6.14.15-1.14.17.6.1.fc33.x86_64
  Verifying        : npm-1:6.14.15-1.14.17.6.1.fc33.x86_64                  1/2
  Verifying        : npm-1:6.14.8-1.12.19.0.1.fc31.x86_64                   2/2

Failed:
  npm-1:6.14.8-1.12.19.0.1.fc31.x86_64   npm-1:6.14.15-1.14.17.6.1.fc33.x86_64

Error: Transaction failed
$

One solution is to download the rpm package, and attempt to upgrade it using rpm. In this way we can observe which file and directory that have caused the problem. For instance, we first download the npmpackage,


sudo dnf download npm

Then we attempt to install it,


$ sudo rpm -U -i -v -h npm-6.14.15-1.14.17.6.1.fc33.x86_64.rpm
Verifying...                          ################################# [100%]
Preparing...                          ################################# [100%]
Updating / installing...
   1:npm-1:6.14.15-1.14.17.6.1.fc33   ################################# [ 50%]
error: unpacking of archive failed on file /usr/lib/node_modules/npm/docs: cpio: File from package already exists as a directory in system
error: npm-1:6.14.15-1.14.17.6.1.fc33.x86_64: install failed
error: npm-1:6.14.8-1.12.19.0.1.fc31.x86_64: erase skipped
$

which shows that the /usr/lib/node_modules/npm/docs directory is the culprit. We need to rename it following the approach discussed in the above


sudo mv /usr/lib/node_modules/npm/docs /usr/lib/node_modules/npm/docs.bu

After that, we can upgrade the package, for instance,


$ sudo rpm -U -i -v -h npm-6.14.15-1.14.17.6.1.fc33.x86_64.rpm
Verifying...                          ################################# [100%]
Preparing...                          ################################# [100%]
Updating / installing...
   1:npm-1:6.14.15-1.14.17.6.1.fc33   ################################# [ 50%]
Cleaning up / removing...
   2:npm-1:6.14.8-1.12.19.0.1.fc31    ################################# [100%]
$ sudo dnf upgrade --refresh
Docker CE Stable - x86_64                        22 kB/s | 3.5 kB     00:00
Fedora 33 - x86_64                               47 kB/s |  13 kB     00:00
Fedora 33 openh264 (From Cisco) - x86_64        9.7 kB/s | 990  B     00:00
Fedora Modular 33 - x86_64                      121 kB/s |  12 kB     00:00
Fedora 33 - x86_64 - Updates                     95 kB/s |  11 kB     00:00
Fedora 33 - x86_64 - Updates                    496 kB/s | 430 kB     00:00
Fedora Modular 33 - x86_64 - Updates             49 kB/s |  11 kB     00:00
Dependencies resolved.
Nothing to do.
Complete!
$

Wednesday, May 5, 2021

Installing Python from source on a Fedora Linux system

I have a need to install a new version of Python on a dated Fedora Linux system (Fedora 31). Here is the steps that I followed,


# install neccessary packages to build Python from source
sudo dnf install gcc openssl-devel bzip2-devel libffi-devel zlib-devel

# download Python source package. You may select a different version you wish 
# to download by browsing https://www.python.org/ftp/python/
wget https://www.python.org/ftp/python/3.9.5/Python-3.9.5.tgz

# extract the files from the package
tar xzf Python-3.9.5.tgz

# go to the directory where the extracted files are
cd Python-3.9.5

# enable optimization
sudo ./configure --enable-optimizations

# compile and install to /usr/local
sudo make altinstall

# show the version of the active Python
python --version

# add the newly installed Python to alternatives (I already have a Python2 Python3.7)
sudo alternatives --install /usr/bin/python python /usr/local/bin/python3.9 3

# config alternatives and select 3 as the active Python
sudo alternatives --config python

# check the version of the active Python
python --version

Tuesday, October 22, 2019

Using tuned to Configure PostgreSQL Database Management System

Tuned is a profile-based system tuning tool for dynamic and static tuning of system settings. I find it very useful even if for configuring system settings. Tuned comes from recent release of Fedora Linux distribution. The following steps are just to make sure that we have the tuned package in the system, and start and enable the tuned service.

sudo dnf install tuned
sudo systemctl start tuned
sudo systemctl enable tuned

Below are a few steps to show how we use tuned to manually adjust system settings (or static-tuning):

  • Listing existing profiles
    
    tuned-adm list
    

  • To activate a profile or to reactivate a profile after you have revised it,
    
    sudo tuned-adm active postgresql
    

    In this example, we have created a profile of our own to tune the system for running PostgreSQL Database Management System.
To create such a profile, follow the steps:
  1. Create a directory at /etc/tuned, e.g., if we wish to have a profile called postgresql, we create the directory postgresql at /etc/tuned,
    
    sudo mkdir /etc/tuned/postgresql
    

  2.  Create a profile at the directory you created, e.g., create tuned.conf at /etc/tuned/postgresql. The following is an example profile for PostgreSQL
    
    $ cat /etc/tuned/postgresql/tuned.conf
    #
    # tuned configuration
    #
    
    [main]
    summary=Optimize for running PostgreSQL inside a virtual guest
    
    [cpu]
    governor=performance
    energy_perf_bias=performance
    min_perf_pct=100
    
    [disk]
    readahead=>4096
    
    [sysctl]
    vm.dirty_ratio = 2
    vm.dirty_background_ratio=1
    vm.overcommit_memory=2
    vm.swappiness = 0
    vm.nr_hugepages=1192
    
    [vm]
    transparent_hugepages=never
    
    

    This profile basically sets the system to use 2MB hugepages for PostgreSQL. It is worth nothing that in the PostgreSQL's $PGDATA/postgresql.conf configuration file, we have these lines:
    
    shared_buffers = 2GB
    huge_pages = on
    

    Since shared buffers is 2GB/(hugepage size) = 2GB/2MB = 1024 pages, the vm.nr_hugepages (the number of reserved hugepages) cannot be less than 1024 pages plus additional pages for the process itself and others; otherwise, PostgreSQL will fail to start.

Thursday, October 17, 2019

Limiting Number of Old Kernels in Fedora Linux

As we upgrade/update Linux systems, such as, Fedora Linux, we will see the old kernels accumulate in the system. Since these kernel images are in the Boot partition that is often small, the Boot partition can run out of space. We may remove these old kernel images if we are certain the new kernel installed via the upgrade/update process works fine. In the past, I did it manually (since I didn't know better). In fact, we can do it automatically by configuring the system to allow a number of kernels in the system.

For this, in Fedora Linux, we can add a line to /etc/dnf.conf, such as,

installonly_limit=2

which limits the number of installed kernels to 2. When we perform a dnf upgrade, the system shall remove the old kernel images exceeding the limit. By the way, for a Linux distribution utilizing YUM, adding the same line to /etc/yum.conf will have the same effect.

Monday, August 14, 2017

Setting up no-ip Service on Fedora Linux 26

It is simple to set up the no-ip dynamic DNS service. The steps are as follows,

$ sudo yum install noip
$ sudo noip2 -C
$ sudo systemctl enable noip.service
$ sudo systemctl start noip.service

In the above, the first step is to install the noip client, the second step is to configure the noip client, the third step is to enable the noip service, and the last step is to start the service. Since the service is enabled, when the system is rebooted, the noip service will be automatically started. One important reminder, do not forget to create your domain name at noip.

Tuesday, December 2, 2014

A Shell Script to Setup Redmine on Fedora Linux

The steps to install and configure Redmine on Fedora Linux 20 are quite lengthy. To simplify the installation and configuration of the Redmine and the Fedora Linux system, I created a shell script to automate the process. The script is available at GitHub.

Below is a typical use case of the script.

# bring Fedora Linux up-to-date
sudo yum -y update


# download instredmine.sh
wget https://raw.githubusercontent.com/graychan/notes/master/redmine/instredmine.sh

# choose database password by editing the script
# vi instredmine.sh

# make the script executable and run the script
chmod +x ./instredmine.sh
sudo ./instredmine.sh

# allow incoming connections to TCP port 80 through firewall
sudo firewall-cmd --zone=public --add-port 80/tcp 
sudo firewall-cmd --permanent --zone=public --add-port 80/tcp
Then, point a browser to the Redmine host. Log in as admin with the initial password admin, and change the admin user's password to a different one.

Monday, December 1, 2014

Installing Redmine (2.6.0) on Fedora Linux (Fedora Linux 20)

I have been running Redmine in Fedora Linux from Fedora Linux 16 to Fedora Linux 20. The instruction I am using to install and upgrade Redmine is from a Redmine's wiki page. In this post, I would like to first briefly document the steps to install Redmine on Feodra Linux, at present Fedora Linux 20, integrate Redmine with the Apache HTTP server, and then discuss a few issues that we would probably need to deal with when upgrading Fedora Linux and  in turn when upgrading Redmine.

Note that the process described below can be automated by a shell script I wrote. See this post for more detail.

Installing Redmine on Fedora Linux 20

The instruction is generally a copy of a Redmine's wiki page with more detailed steps on Fedora Linux and with intention to answer the questions raised in the page here.

Meeting Prerequisites

Before we begin, we will make sure that the Fedora Linux systems has the following software installed,
  • Ruby and Ruby bundler
  • Apache HTTP Server
  • Phusion Passenger.
    Although Redmine can run as a standalone server, it is recommended to integrate it with a HTTP server. One may use Phusion Passenger, FCGI or a Rack server (Unicorn, Thin, Puma, hellip;) to integrate with the Apache HTTP Server. In this post, we use Phusion Passenger.
  • PostgreSQL database server and PostgreSQL development package.
    Among two relational database management system that Redmine supports, MySQL and PostgreSQL, I personally prefer PostgreSQL to MySQL as a result that PostgreSQL's license is less restricted than MySQL's.
  • The GNU C complier. 
  • The image display and manipulation tool ImageMagick and its development package
  • The non-interactive network downloader wget
  • The archiver tool tar
In addition, we assume that a user has an username what is in the "Administrator" group, i.e., the user can switch to user "root" using via <code>sudo</code>.

In this section, we show the steps to meet the prerequisites. If the prerequisites are already met, the following steps are expected not to have any impact on the system.
  1. Installing Ruby and Ruby bundler.
    
      # install the Ruby package
      sudo yum install ruby
    
      # install the Ruby development package
      sudo yum install ruby-devel
    
      # install Ruby's bundler
      sudo yum install rubygem-bundler
      
  2. Installing Apache HTTP Server.
    
      # install the Apache HTTP Server
      sudo yum install httpd
    
      # enable the HTTPD service at system boot time
      sudo systemctl enable httpd.service
    
      # start the HTTPD service
      sudo systemctl start httpd.service
      
  3. Installing Phusion Passenger for Apache HTTP Server.
    
      sudo yum install mod_passenger
      
  4. Installing PostgreSQL database server and PostgreSQL development package.
    
      # install the PostgreSQL database server package
      sudo yum install postgresql-server postgresql-devel
    
      # enable postgresql's start during the boot using following command
      sudo systemctl enable postgresql.service
    
      # initialize the postgresql database
      sudo postgresql-setup initdb
    
      # start the postgresql service. 
      sudo systemctl start postgresql.service
      
  5. Installing the GNU C complier.
    
      sudo yum install gcc
        
  6. Installing the image display and manipulation tool ImageMagick
    
      sudo yum install ImageMagick ImageMagick-devel 
      
  7. Installing the non-interactive network downloader wget.
    
      sudo yum install wget
      
  8. Install the archiver tool tar.
    
      sudo yum install tar
      
  9. Install a few additional packages to work with subversion.
    
      yum install perl-DBI perl-Digest-SHA mod_dav_svn
      

Installing Redmine

  1. Download and extract Redmine source.

    The URL of Redmine sources are available in this page.

    Assume that we are to download Redmine 2.6.0 (released on 2014-10-21) and plan to install it at the directory /var/www/redmine.
    
      cd /var/www/
      sudo wget -q http://www.redmine.org/releases/redmine-2.6.0.tar.gz
      sudo tar -xzf redmine-2.6.0.tar.gz
      
    We can now verify that we have successfully downloaded and extracted the Redmine source.
    
      $ ls -l redmine-2.6.0
      total 76
      drwxrwxr-x. 7 1000 1000 4096 Oct 21 15:13 app
      drwxrwxr-x. 5 1000 1000 4096 Oct 21 15:13 config
      -rw-rw-r--. 1 1000 1000  160 Oct 21 15:13 config.ru
      -rw-rw-r--. 1 1000 1000  240 Oct 21 15:13 CONTRIBUTING.md
      drwxrwxr-x. 3 1000 1000 4096 Oct 21 15:13 db
      drwxrwxr-x. 2 1000 1000 4096 Oct 21 15:13 doc
      drwxrwxr-x. 5 1000 1000 4096 Oct 21 15:13 extra
      drwxrwxr-x. 2 1000 1000 4096 Oct 21 15:13 files
      -rw-rw-r--. 1 1000 1000 3555 Oct 21 15:13 Gemfile
      drwxrwxr-x. 8 1000 1000 4096 Oct 21 15:13 lib
      drwxrwxr-x. 2 1000 1000 4096 Oct 21 15:13 log
      drwxrwxr-x. 2 1000 1000 4096 Oct 21 15:13 plugins
      drwxrwxr-x. 7 1000 1000 4096 Oct 21 15:13 public
      -rw-rw-r--. 1 1000 1000  275 Oct 21 15:13 Rakefile
      -rw-rw-r--. 1 1000 1000  205 Oct 21 15:13 README.rdoc
      drwxrwxr-x. 2 1000 1000 4096 Oct 21 15:13 script
      drwxrwxr-x. 9 1000 1000 4096 Oct 21 15:13 test
      drwxrwxr-x. 8 1000 1000 4096 Oct 21 15:13 tmp
      drwxrwxr-x. 2 1000 1000 4096 Oct 21 15:13 vendor
      
  2. Creating an empty database and accompanying user for Redmine.

    We now create a PostgreSQL database for Redmine. In the commands below, we assume the password is "my_password" for demonstration and should choose a more thoughtful one.

    Also, we also name the database for Redmine as "redmine". It does not have to be and can be any valid PostgreSQL database name.
    
      # switch to user postgres
      sudo su - postgres
    
      # create database role redmine
      echo \
        "CREATE ROLE redmine LOGIN ENCRYPTED
         PASSWORD 'my_password' NOINHERIT VALID UNTIL 'infinity';" | \
        psql
    
      # create database named redmine for Redmine
      echo \
        "CREATE DATABASE redmine WITH ENCODING='UTF8' OWNER=redmine;" | \
        psql
    
      # edit PostgreSQL Client Authentication Configuration File
      sed -e \
        "/host.*all.*all.*::1\/128.*ident/i host redmine redmine ::1/128 md5" \
        --in-place=.bu /var/lib/pgsql/data/pg_hba.conf  
    
      # restart PostgreSQL database server
      sudo systemctl restart postgresql.service
    
      # exit from user postgres
      exit
      
    The change to the PostgreSQL client authentication configuration file, by default at /var/lib/pgsql/data/pg_hba.conf is necessary to Redmine to establish a connection to the database. The working configuration depends on a few factors and can be an issue. More discussion is available. However, the above configuration works on a Fedora Linux distribution with IPv6 enabled, which is the default setting.
  3. Configuring database connection.

    We will follow the instruction of Step 3 in the Redmine wiki page. We will copy ${REDMINE}/config/database.yml.example to ${REDMINE}/config/database.yml and edit the file in order to configure the database settings for "production" environment. In this example, ${REDMINE} is /var/www/redmine-2.6.0.

    With the PostgreSQL database parameters used in the above step, the "production" section of ${REDMINE}/config/database.yml should be replaced as follows,
    
      production:
        adapter: postgresql
        database: redmine
        host: localhost
        username: redmine
        password: my_password
        encoding: utf8
      
    If you do not wish to use the MySQL database management system at all, comment out any sections that refers to the MySQL database management system in the configuration file. In this post, we assume that you do not use the MySQL database management system and your system many not have the MySQL client library and development head files installed. To make the point clear, we list the content of a desired database configuration file as follows,
    
      $ cat ${REDMINE}/config/database.yml
      production:
        adapter: postgresql
        database: redmine
        host: localhost
        username: redmine
        password: my_password
        encoding: utf8  
      
    where ${REDMINE} is /var/www/redmine-2.6.0 in this example. More discussion on potential dependency issue caused by the configuration file is available.
  4. Installing Redmine Ruby dependencies using the Ruby Dependency Management tool bundle.

    Following the generic instruction in the Redmine wiki page, We shall install Redmine's ruby dependencies using bundle.

    There are some subtle issues to install Redmine's Ruby dependencies using the tool. We use a workaround to circumvent the issues, that is, we run bundle under a non-root user with login permission and specify the path in which the dependencies will be installed. In this example, we assume that the non-root username is your username foouser and the directory to install the dependencies is ${REDMINE}/.bundle/ruby where ${REDMINE} is /var/www/redmine-2.6.0 in this example. Replace foouser with your actual username.
    
      # give your user userfoo read and write permission to ${REDMINE}
      sudo chown -R userfoo ${REDMINE}
    
      # make sure that the working directory is ${REDMINE}
      # in this example, ${REDMINE} is /var/www/redmine-2.6.0
      cd ${REDMINE} 
     
      # install Redmine's Ruby dependencies 
      /usr/bin/bundle install \
          --path /var/www/redmine-2.6.0/.bundle \
          --without development test
      
    If success, the output of the above steps will be something similar to the following,
    
      $ /usr/bin/bundle install \
          --path /var/www/redmine-2.6.0/.bundle \
          --without development test
      Fetching gem metadata from https://rubygems.org/.........
      Resolving dependencies...
      Using rake 10.4.0
      Using i18n 0.6.11
      ......
      Your bundle is complete!
      Gems in the groups development and test were not installed.
      It was installed into ./.bundle
      Post-install message from rdoc:
      Depending on your version of ruby, you may need to install ruby rdoc/ri data:
    
      <= 1.8.6 : unsupported
       = 1.8.7 : gem install rdoc-data; rdoc-data --install
       = 1.9.1 : gem install rdoc-data; rdoc-data --install
      >= 1.9.2 : nothing to do! Yay!
      ......
      
    Since on Fedora Linux 20, the version of Ruby is 2.0 or higher, there is nothing else to do for the Ruby dependencies.

    During the above process, a configuration file ${REDMINE}/.bundle/config will be created. The following shows an example of the configuration file created during the process.
    
      $ cat ${REDMINE}/.bundle/config
      ---
      BUNDLE_PATH: /var/www/redmine-2.6.0/.bundle
      BUNDLE_WITHOUT: development:test
      BUNDLE_DISABLE_SHARED_GEMS: '1'
      
    The configuration file informs Redmine where the Ruby dependencies is as indicated by the BUNDLE_PATH variable in the configuraiton file.
  5. Generating session store secret.

    We simply follow the instruction in the Redmine wiki page. Note that in this example, ${REDMINE} is /var/www/redmine-2.6.0.
    
      /usr/bin/bundle exec \
          "${REDMINE}/.bundle/ruby/bin/rake generate_secret_token"
      
  6. Loading Redmine database default data set.

    Again, we simply follow the instruction in the Redmine wiki page.
    
      /usr/bin/bundle exec "RAILS_ENV=production rake db:migrate"
      
  7. Setting up file system permissions.
    Again, we simply follow the instruction in the Redmine wiki page. However, there is a minor deviation since we set up Redmine using your username. We will make necessary changes to integrate it with the Apache HTTP Server in next section. Again ${REDMINE}$ in this example is /var/www/redmine-2.6.0.
    
      mkdir -p ${REDMINE}/tmp ${REDMINE}/tmp/pdf ${REDMINE}/public/plugin_assets
      chmod 755 ${REDMINE}/tmp ${REDMINE}/tmp/pdf ${REDMINE}/public/plugin_assets
      
    Again, in this example, ${REDMINE} is /var/www/redmine-2.6.0.
  8. Testing the Redmine installation.

    We follow the instrucion in the Redmine wiki page.
    
      $ ruby script/rails server webrick -e production
      => Booting WEBrick
      => Rails 3.2.19 application starting in production on http://0.0.0.0:3000
      => Call with -d to detach
      => Ctrl-C to shutdown server
      [2014-11-30 19:05:45] INFO  WEBrick 1.3.1
      [2014-11-30 19:05:45] INFO  ruby 2.0.0 (2013-11-22) [x86_64-linux]
      [2014-11-30 19:05:45] INFO  WEBrick::HTTPServer#start: pid=6454 port=3000
      
    Pointing a browser to http://localhost:3000, you will see Redmine's welcome page, which indicates that Redmine runs OK. However, as indicated in the Redmine wiki page, this is not intended means of running Redmine.

Changing Redmine Admin User's Initial Password

Redmine's has an Admin user "admin" with initial password "admin". Before we make the Redmine available to the outside world, we should change the password of the Admin user "admin". When we test the Redmine in previous step, log in as admin and reset the password.

Integrating Redmine with Apache HTTP Server via Phusion Passenger


    We shall integrate Redmine with the Apache HTTP Server via Phusion Passenger. Fedora Linux by default has SeLinux enabled. SeLinux can be a source of problems. We will defer configuration for SeLinux in next section. Then, we will temporarily disable SeLinux.

  1. Temporarily disabling SeLinux
    
      sudo setenforce false
      
  2. Change Redmine installaiton's ownership
    To create a workaround to install Redmine's Ruby dependencies using bundle, we changed the ownership of the Redmine installation to your username. We now change the ownership to the user as whom the Apache HTTP Server, i.e., user apache is running and remove access to the installation from any users but user apache and group apache.
    
      sudo chown -R apache:apache ${REDMINE}
      sudo chmod o-rwx ${REDMINE}
      
    Note that ${REDMINE} is /var/www/redmine-2.6.0 in this example.
  3. Configuring the Phusion Passenger module to integrate Redmine with the Apache Web server.

    When the Phusion Passenger module package is installed, an Apache HTTP Server configuration file will be installed at /etc/httpd/conf.d/. The configuration file is /etc/httpd/conf.d/passenger.conf. We will append the following lines to the configuration file.
          
          <VirtualHost *:80>
            SetEnv GEM_HOME /var/www/redmine-2.6.0/.bundle/ruby
            ServerName localhost.localdomain
            DocumentRoot /var/www/redmine-2.6.0/public
            <Directory /var/www/redmine-2.6.0/public>
              AllowOverride all
              Options -MultiViews
            </Directory>
          </VirtualHost>
          
    In the above, the environment variable GEM_HOME is important. Without its pointing to the location of the Gem files installed by bundle, i.e., /var/www/redmine-2.6.0/.bundle/ruby, Redmine will complains that it cannot find the required Gem files. More discussion on this issue is available.

Configuring SeLinux for Redmine

Redmine has a wiki page Redmine, Phusion Passenger, Ruby Enterprise Edition, Apache and ... SELinux that is our beginning point. Fedora Linux 20 has a SeLinux policy module that properly set up SeLinux permissions for Phusion Passenger, which makes the steps simpler than the Redmine's wiki page. The following steps is a minor revision of the RedmineAndSELinux script in the Redmine wiki page.


  APACHE_USER=apache
  REDMINE=/var/www/redmine-2.6.0
  GEM_HOME=${REDMINE}/.bundle

  # Base permissions.
  sudo chown -R ${APACHE_USER}:${APACHE_USER} ${REDMINE}
  sudo chmod -R u=rw,g=r,o-rwx ${REDMINE}
  sudo chmod -R ug+X ${REDMINE}
  sudo chcon -R -u system_u -t httpd_sys_content_t ${REDMINE}

  # Writable directories.
  sudo chown -R ${APACHE_USER}:${APACHE_USER} ${REDMINE}/log
  sudo chcon -R -t httpd_log_t ${REDMINE}/log

  sudo chown -R ${APACHE_USER}:${APACHE_USER} ${REDMINE}/tmp
  sudo chcon -R -t httpd_tmpfs_t ${REDMINE}/tmp

  sudo chown -R ${APACHE_USER}:${APACHE_USER} ${REDMINE}/files
  sudo chcon -R -t httpd_sys_script_rw_t ${REDMINE}/files

  sudo chown -R ${APACHE_USER}:${APACHE_USER} ${REDMINE}/public/plugin_assets
  sudo chcon -R -t httpd_sys_script_rw_t ${REDMINE}/public/plugin_assets

  # Set permission to the shared objects used by Ruby GEM files
  sudo find -P ${GEM_HOME} -type f -name "*.so*" -exec chcon -t lib_t {} \;

  # enable SeLinux
  sudo setenforce 1

  # allow Apache to connect to database
  sudo setsebool -P httpd_can_network_connect_db 1

  # restart the Apache HTTP Server
  sudo systemctl restart httpd.service
  
Alternatively, you may download and execute the shell script selinuxforredmine.sh at Github, for instance,

  sudo ./selinuxforredmine.sh /var/www/redmine-2.6.0
  sudo setenforce 1
  sudo systemctl restart httpd.service
  

Configuring Firewall

To allow the outside world to connect to the Redmine instance on the Fedora Linux system, we will have to configure the firewall to allow incoming connection at TCP port 80. One of my previous post discusses how we can add an allowed port in Fedora's firewalld.

This is final step, we are now done.



Common Issues During Redmine Installation on Fedora Linux

Authentication with PostgreSQL Database

In the above, the PostgreSQL client authentication configuration file works for a Fedora Linux system with IPv6 enabled since ::1/128 is an IPv6 address. IPv6 is enabled on Fedora Linux 20 by default.

If the IPv6 is disabled, then the line to be added to the configuration file, by default at /var/lib/pgsql/data/hg_hba.conf should be,

  host    redmine    redmine    127.0.0.1/32  md5
  
Be aware that the order of such configuration lines in the configuration file matters. The line must appear before a more generic configuration line, as such, the segment of the configuration upon addition of the line should resemble the following,

  host    redmine    redmine    127.0.0.1/32  md5
  host    all        all        127.0.0.1/32  ident
  
If you place the line after the more generic configuration line, the more restrictive line wil have no effect. For instance, the segment of configuration is as follows, a database client program will attempt to connect to the datbase using the "ident" method and fail to establish the connection.

  host    all        all        127.0.0.1/32  ident
  host    redmine    redmine    127.0.0.1/32  md5
  

Potential Dependency Issues Caused by database.yml

The configuration file ${REDMINE}/config/database.yml specifies what database management system and databases that Redmine relies on. For instance, the configuration file has a section as follows,

  development:
    adapter: mysql2
    database: redmine_development
    host: localhost
    username: root
    password: ""
    encoding: utf8
  
The configuration file creates a dependency on the MySQL database management system and the Ruby Dependency Management Tool bundle will attempt to install the MySQL Gem file. If the system does not have required the MySQL client library and the MySQL development header files, the bundle installation process will fail as shown in the example below,

$ /usr/bin/bundle install \
  --path /var/www/redmine-2.6.0/.bundle \
  --without development test
Fetching gem metadata from https://rubygems.org/.........
Resolving dependencies...
Using rake 10.4.0
Using i18n 0.6.11
Using multi_json 1.10.1
......
Using jquery-rails 3.1.2

Gem::Installer::ExtensionBuildError: ERROR: Failed to build gem native extension.

    /usr/bin/ruby extconf.rb
checking for ruby/thread.h... yes
checking for rb_thread_call_without_gvl() in ruby/thread.h... yes
......
checking for mysql_query() in -lmysqlclient... no
......
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers.  Check the mkmf.log file for more details.  You may
need configuration options.

Provided configuration options:
        --with-opt-dir
          .....
        --without-mysqlclientlib
        --with-mygcclib
        --without-mygcclib
        --with-mysqlclientlib
        --without-mysqlclientlib


Gem files will remain installed in /var/www/redmine-2.6.0/.bundle/ruby/gems/mysql2-0.3.17 for inspection.
Results logged to /var/www/redmine-2.6.0/.bundle/ruby/gems/mysql2-0.3.17/ext/mysql2/gem_make.out

An error occurred while installing mysql2 (0.3.17), and Bundler cannot continue.
Make sure that `gem install mysql2 -v '0.3.17'` succeeds before bundling.
  
The existence of such a dependency is a fact. Therefore, the error remains even if you instruct bundle explicitly not to install MySQL Gem files, e.g.,

  $ /usr/bin/bundle install \
    --path /var/www/redmine-2.6.0/.bundle \
    --without development test mysql mysql2
  

Using Ruby Dependency Management Tool

We install Redmine's ruby dependencies using bundle. The instruction in the Redmine wiki page is a generic description that some appear to be confused with what to do.

In the Redmine's wiki page, The Ruby bundle is installed via gem as in gem install bundler. However, it will install it in your local directory unless you run gem as root. When you install it as root, i.e., sudo gem install bundler. The bundler will be located in /usr/local. You will to make sure that /usr/local/bin in your search path. In the step above, I simplify it by installing Fedora Linux's bundler package, and then bundle will be in /usr/bin.

We need to first identify a user under whom the Redmine's ruby dependencies should be installed. In this post, we assume that we will integrate Redmine with the Apache web server. Then the user under whom Redmine's ruby dependencies should be installed is the user apache since in Fedora Linux, the Apache web server is run under user apache.

The challenge is that in a typical Fedora Linux installation, you cannot switch to user apache since the user is created without the login permission. Furthermore, if you attempt to install the Redmine's ruby dependencies under user root, you will observe an error as shown below,

  $ sudo bundle install --without development test
  Don't run Bundler as root. Bundler can ask for sudo if it is needed, and
  installing your bundle as root will break this application for all 
  non-root users on this machine.
  Could not locate Gemfile
  
In the above, we use a workaround. Assume that your username is userfoo. We install Redmine's ruby dependencies under the username userfoo at a specific directory, in this example, ${REDMINE}/.bundle/ruby. Again, ${REDMINE} is /var/www/redmine-2.6.0.

Locating Gem Files

You may install Gem files to any directory using bundle. However, you will set the value of environmental variable GEM_HOME to the directory. In the above, we set the environment variable in the Apache HTTP Server's configuration file /etc/httpd/conf.d/passenger.conf. For instance, if we comment out the SetEnv line from the configuration file, we will observe an error with the error messages as follows,

  You have already activated rake 10.0.4, but your Gemfile requires rake 10.4.0. 
  Prepending `bundle exec` to your command may solve this. (Gem::LoadError)
  /usr/share/gems/gems/bundler-1.7.6/lib/bundler/runtime.rb:34:in `block in setup'
  /usr/share/gems/gems/bundler-1.7.6/lib/bundler/runtime.rb:19:in `setup'
  /usr/share/gems/gems/bundler-1.7.6/lib/bundler.rb:121:in `setup'
  ......
  
The effect of the environment variable can be demonstrated using the two examples below, one without the environment variable's value being set, one with the value being set.

  $ gem env
  RubyGems Environment:
  - RUBYGEMS VERSION: 2.1.11
  - RUBY VERSION: 2.0.0 (2013-11-22 patchlevel 353) [i386-linux]
  ......
  - GEM PATHS:
     - /home/foouser/.gem/ruby
     - /usr/share/gems
     - /usr/local/share/gems
  ......
  $ gem list
  
Note the above, GEM PATHS do not include the directory /var/www/redmine-2.6.0/.bundle/ruby. Then, Ruby will not be able to locate the Gem files installed using bundle.

   $ gem list

   *** LOCAL GEMS ***

   bigdecimal (1.2.0)
   bundler (1.7.6)
   daemon_controller (1.1.8)
   io-console (0.4.2)
   json (1.7.7)
   net-http-persistent (2.9.4)
   passenger (4.0.18)
   psych (2.0.0)
   rack (1.5.2)
   rake (10.0.4)
   rdoc (4.0.1)
   thor (0.18.1)
   
We see from the above that the activated Rake is of version 10.0.4 that is indicated in the error message shown above. However, we will observe different results if we set the GEM_HOME directory to the directory where we install Gem files using bundle.

   $ GEM_HOME=/var/www/redmine-2.6.0/.bundle/ruby gem env
   RubyGems Environment:
   ......
   - GEM PATHS:
     - /var/www/redmine-2.6.0/.bundle/ruby
     - /home/foouser/.gem/ruby
     - /usr/share/gems
     - /usr/local/share/gems
   .....
   
Now /var/www/redmine-2.6.0/.bundle/ruby is in GEM PATHS.

   $ GEM_HOME=/var/www/redmine-2.6.0/.bundle/ruby gem list

   *** LOCAL GEMS ***

   actionmailer (3.2.19)
   ......
   rake (10.4.0, 10.0.4)
   ......
   
We now see that the Gem files installed using bundle are listed. It also shows that it finds two version of Rake.

Saturday, November 29, 2014

No Space in /boot and Removing Old Kernels

A practice that Linux distributions recommends is to put Linux kernel images in a separate partition that is mounted at /boot. It is a common problem that the /boot partition becomes full, which prevent any new kernel images from being installed to copied to the partition. To resolve this problem, there are commonly two solutions.
  • Solution 1. Increasing the size of the /boot partition.
  • Solution 2. Removing old kernel images from the /boot partition.
This post discusses Solution 2. Previously I took a note how we may remove old kernel images and packages from Ubuntu Linux (or any Debian-based Linux distributions). In this post, I would like to take a note on removing old kernel images and packages from Fedora Linux (or any Redhat Linux-based systems). I have been used two methods that lead to the same results. I would recommend the second method for simplicity. However, if you want to know what packages and images are removed, you may want to use the first method.
  • Using rpm.
    1. First determine what Linux kernel images are present in the /boot partition.
      
             $ ls /boot/vmlinu*
             /boot/vmlinuz-3.14.23-100.fc19.x86_64
             /boot/vmlinuz-3.17.3-200.fc20.x86_64
             

      The above shows that we have two Linux kernels present in the /boot partition. Now we want to make room in the /boot partition. Once we make sure that we can boot from the /boot/vmlinuz-3.17.3-200.fc20.x86_64, we can remove the old kernel image and associated kernel package.
    2. We now find out what packages that we need to uninstall to remove the old kernel package, in this case, /boot/vmlinuz-3.14.23-100.fc19.x86_64.
      
             $ rpm -qa | grep 3.14.23
             kernel-devel-3.14.23-100.fc19.x86_64
             kernel-3.14.23-100.fc19.x86_64
             
    3. From the above, we can now remove the two packages.
      
             $ sudo rpm -evh \
                    kernel-devel-3.14.23-100.fc19.x86_64 \
                    kernel-3.14.23-100.fc19.x86_64
             

      Alternatively, we can also use yum to remove the two packages.
      
             sudo yum remove \
                    kernel-devel-3.14.23-100.fc19.x86_64 \
                    kernel-3.14.23-100.fc19.x86_64
             
  • Using the yum-utils package.
    1. We first install the yum-utils package.
      
              sudo yum install yum-utils
              
    2. The yum-utils package has a tool called package-cleanup. We now use it to remove old kernel images and associated packages, which is done by specifying the number of kernel images that we would like to keep in the system. In this example, we would like to keep only one kernel image. Then, we issue the following command,
      
              sudo package-cleanup --oldkernels --count=1
              
    I learned the method of using yum-utils from a web post here, which also discusses how you may configure the system to always keep a given number of kernel images and associated packages.

Upgrading Fedora Linux using Fedup: Key is not Trusted by RPM

When I attempted to upgrade Fedora Linux using FedUp, I encountered an error that basically complains that fedup could not authenticate the downloaded Fedora Linux image because it did not have the public key to verity the image's GPG signature. In the error log, by default in /var/log/fedup.log, the error message resembles the following format,

             ......
[   152.927] (II) fedup.yum:check_keyfile() 
             checking keyfile /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-19-x86_64
[   152.991] (DD) fedup.yum:check_keyfile() 
             keyfile owned by package fedora-release-0:18-6
[   152.992] (DD) fedup.yum:check_keyfile() 
             package was signed with key de7f38bd
[   152.992] (II) fedup.yum:check_keyfile() 
             REJECTED: key de7f38bd is not trusted by rpm
[   152.997] (II) fedup:message() Downloading failed: 
             could not verify GPG signature: No public key
             ......

The above example corresponds to the result of upgrading to Fedora Linux 19. In the error message, the key will be different if we upgrade to a different version of Fedora Linux. However, if the system is missing the public key for the GPG signature of the Linux image that we are upgrading to, the same error will occur and the error message will be the same except the value of the public key. To resolve the problem, we need to manually import the public key to the GPG signature of the Linux image. The public keys to GPG signatures of the Linux images of various version of Fedora Linux are available at the following URL

           https://fedoraproject.org/keys

Since it is Fedora Linux 19 whose public key is not present in the system, we shall first locate the public key from the above page as illustrated below,


From the page, we can see that the primary public key is available in two URLs, one at the Fedora Project's website and the other at the gngpg.net website. We can import the key from either URL. The following shows that we import the public key from the Fedora Project's website.

rpm --import https://fedoraproject.org/static/BA094068.txt

Once we finish importing the public key, we can rerun fedup and the error should go away. The above method should work for other versions of Fedora Linux.