dnf and yum show different updates

Problem

I have started to use dnf in Fedora 20 more than yum. I do miss drpm and yum ps when using dnf but it works just fine. Today, I ran into a problem where yum and dnf saw different updates.

root @ codeghar [~] $ yum check-update
Loaded plugins: langpacks, ps, refresh-packagekit
updates/20/x86_64/metalink                                          |  16 kB  00:00:00     
updates                                                             | 4.6 kB  00:00:00     
updates/20/x86_64/primary_db                                        | 7.2 MB  00:00:02     
(1/2): updates/20/x86_64/updateinfo                                 | 660 kB  00:00:00     
(2/2): updates/20/x86_64/pkgtags                                    | 887 kB  00:00:05     

NetworkManager.x86_64                       1:0.9.9.0-28.git20131003.fc20           updates
NetworkManager-glib.x86_64                  1:0.9.9.0-28.git20131003.fc20           updates
NetworkManager-openvpn.x86_64               1:0.9.9.0-0.1.git20140128.fc20          updates
NetworkManager-openvpn-gnome.x86_64         1:0.9.9.0-0.1.git20140128.fc20          updates
anaconda.x86_64                             20.25.16-1.fc20                         updates
anaconda-widgets.x86_64                     20.25.16-1.fc20                         updates
clutter.x86_64                              1.16.2-3.fc20                           updates
curl.x86_64                                 7.32.0-4.fc20                           updates
glibc.x86_64                                2.18-12.fc20                            updates
glibc-common.x86_64                         2.18-12.fc20                            updates
glibc-devel.x86_64                          2.18-12.fc20                            updates
glibc-headers.x86_64                        2.18-12.fc20                            updates
kernel.x86_64                               3.12.9-301.fc20                         updates
kernel-debug-devel.x86_64                   3.12.9-301.fc20                         updates
kernel-devel.x86_64                         3.12.9-301.fc20                         updates
kernel-headers.x86_64                       3.12.9-301.fc20                         updates
kernel-modules-extra.x86_64                 3.12.9-301.fc20                         updates
libcurl.x86_64                              7.32.0-4.fc20                           updates
pango.x86_64                                1.36.1-2.fc20                           updates


root @ codeghar [~] $ dnf check-update

NetworkManager.x86_64                   1:0.9.9.0-28.git20131003.fc20               updates
NetworkManager-glib.x86_64              1:0.9.9.0-28.git20131003.fc20               updates
clutter.x86_64                          1.16.2-3.fc20                               updates
glibc.x86_64                            2.18-12.fc20                                updates
glibc-common.x86_64                     2.18-12.fc20                                updates
glibc-devel.x86_64                      2.18-12.fc20                                updates
glibc-headers.x86_64                    2.18-12.fc20                                updates
pango.x86_64                            1.36.1-2.fc20                               updates

Solution

There’s a forum post (dnf and yum seeing different updates) and one solution was to clear the caches.

root @ codeghar [~] $ yum clean expire-cache
Loaded plugins: langpacks, ps, refresh-packagekit
Cleaning repos: fedora updates
2 metadata files removed


root @ codeghar [~] $ dnf clean expire-cache
Cleaning repos: fedora updates
The enabled repos were expired

I then ran check-update on both yum and dnf and that solved the problem. dnf check-update needed to be run twice but it was no big deal.

root @ codeghar [~] $ dnf check-update
Error: Problem with repo 'updates': Cannot prepare internal mirrorlist: Curl error: Timeout was reached for https://mirrors.fedoraproject.org/metalink?repo=updates-released-f20&arch=x86_64


root @ codeghar [~] $ dnf check-update
Fedora 20 - x86_64 - Updates                               3.2 MB/s |  15 MB     00:04    

NetworkManager.x86_64                       1:0.9.9.0-28.git20131003.fc20           updates
NetworkManager-glib.x86_64                  1:0.9.9.0-28.git20131003.fc20           updates
NetworkManager-openvpn.x86_64               1:0.9.9.0-0.1.git20140128.fc20          updates
NetworkManager-openvpn-gnome.x86_64         1:0.9.9.0-0.1.git20140128.fc20          updates
anaconda.x86_64                             20.25.16-1.fc20                         updates
anaconda-widgets.x86_64                     20.25.16-1.fc20                         updates
clutter.x86_64                              1.16.2-3.fc20                           updates
curl.x86_64                                 7.32.0-4.fc20                           updates
glibc.x86_64                                2.18-12.fc20                            updates
glibc-common.x86_64                         2.18-12.fc20                            updates
glibc-devel.x86_64                          2.18-12.fc20                            updates
glibc-headers.x86_64                        2.18-12.fc20                            updates
kernel.x86_64                               3.12.9-301.fc20                         updates
kernel-debug-devel.x86_64                   3.12.9-301.fc20                         updates
kernel-devel.x86_64                         3.12.9-301.fc20                         updates
kernel-headers.x86_64                       3.12.9-301.fc20                         updates
kernel-modules-extra.x86_64                 3.12.9-301.fc20                         updates
libcurl.x86_64                              7.32.0-4.fc20                           updates
pango.x86_64                                1.36.1-2.fc20                           updates

root @ codeghar [~] $ yum check-update
Loaded plugins: langpacks, ps, refresh-packagekit
fedora/20/x86_64/metalink                                           |  18 kB  00:00:00     
updates/20/x86_64/metalink                                          |  16 kB  00:00:00     

NetworkManager.x86_64                       1:0.9.9.0-28.git20131003.fc20           updates
NetworkManager-glib.x86_64                  1:0.9.9.0-28.git20131003.fc20           updates
NetworkManager-openvpn.x86_64               1:0.9.9.0-0.1.git20140128.fc20          updates
NetworkManager-openvpn-gnome.x86_64         1:0.9.9.0-0.1.git20140128.fc20          updates
anaconda.x86_64                             20.25.16-1.fc20                         updates
anaconda-widgets.x86_64                     20.25.16-1.fc20                         updates
clutter.x86_64                              1.16.2-3.fc20                           updates
curl.x86_64                                 7.32.0-4.fc20                           updates
glibc.x86_64                                2.18-12.fc20                            updates
glibc-common.x86_64                         2.18-12.fc20                            updates
glibc-devel.x86_64                          2.18-12.fc20                            updates
glibc-headers.x86_64                        2.18-12.fc20                            updates
kernel.x86_64                               3.12.9-301.fc20                         updates
kernel-debug-devel.x86_64                   3.12.9-301.fc20                         updates
kernel-devel.x86_64                         3.12.9-301.fc20                         updates
kernel-headers.x86_64                       3.12.9-301.fc20                         updates
kernel-modules-extra.x86_64                 3.12.9-301.fc20                         updates
libcurl.x86_64                              7.32.0-4.fc20                           updates
pango.x86_64                                1.36.1-2.fc20                           updates

The Importance of a Pleasurable User Experience

I’ve been thinking of getting myself a Raspberry Pi and configuring it to be my home network wireless gateway. While researching all the hardware pieces to get I thought I should try to decide on a Linux distribution. That quest prompted this post.

I’ve been using Fedora 19 with KDE for a good while now in an ESX VM. It does all the things I need and then some. But beyond that it’s been a pleasure working with it. I love the organized output yum provides. Other features like delta rpms and yum ps are also useful and just nice. I find the systemd user experience to be fantastic. It’s easy and simple to use. SELinux hasn’t bothered me so far. I can’t wrap my head around firewalld just yet but it stays out of my way as well. Fedora’s policy of sticking to upstream defaults means I get a purer upstream experience in an integrated distro. This is not always a good thing because KDE really has cumbersome or missing default settings. But once set up properly, KDE just runs and runs. I am in a Windows environment at work and RDP is just natural to use. Fedora 19 with KDE runs well enough over RDP using the xrdp package. I do get some harmless(?) error messages when first logging in over RDP but my work continues unabated.

With the release of Fedora 20 Beta I decided to give GNOME a try. My first impression is that it has a really good design for the shell, albeit on the minimalist side, and has great keyboard shortcuts. Some default settings don’t make sense to me but exploring gsettings has fixed some of the ones I care about. For the kind of work I do I have found GNOME Shell 3.10 to be an absolute pleasure to work with. It stays out of my way and I can focus on the things that really matter. Unlike all the hoopla about “power users” disliking GNOME Shell’s minimalism I found it to be very refreshing.

Coming back to Raspberry Pi, I’m quite comfortable with Fedora these days. In fact, when I use CentOS 6.4 I miss a lot of the things I’ve gotten used to in Fedora. So my first choice for RPi is Fedora, or Pidora, the spin specially made for it. The downside is that Pidora is tracking Fedora 18 and I want something new. I had hoped Fedora 20 would support RPi out of the box but can’t find any information on it.

My second option for RPi is Raspbian, a spin of Debian. Having gotten used to yum and systemd I find apt-get/aptitude and /etc/init.d to be far less pleasurable to work with. They get the job done equally well but I don’t like using them all that much. It’s just a matter of preference. I tried to dabble with creating deb and rpm packages and my initial take was that rpm is easier to create and manage. I’ll keep Raspbian as a second option for my RPi because I have experience with Debian. But I’d also like the Debian project to focus a bit more on making their tools more “fun” to use. Adopting systemd will be a good first step.

Ubuntu isn’t an option for RPi since they don’t support it just yet. I installed Ubuntu 13.10 in a VM to see how much it has changed since 12.04. I have to say the first thing I did was disable online searches in Dash, remove the Amazon icon from the launcher, and enable workspaces. These three things mean that Unity is no longer the same pleasurable experience it was in 12.04. Having used GNOME Shell 3.10 I missed the HUD but Unity’s “feature” of hiding the menu items became annoying quickly. It wasn’t so when I used 12.04 but KDE and GNOME Shell have made me realize you don’t really need to hide menu items even if you have HUD.

Ubuntu also has the issue of Upstart. It’s great to be able to use start/stop commands but not all services recognize them. I have to use start/stop, /etc/init.d, or service to start or stop my services. There’s no single method to do so. Enabling and disabling services is also cumbersome. I also dislike the policy of starting services right after installing or upgrading. Given these issues I find Ubuntu to not be a pleasurable experience anymore.

openSUSE 13.1 released today and it has some great things going for it. I haven’t tried it out but it’s because of one main thing: YaST. At the core of my being I find YaST to be a redundant tool for a lot of things, especially networking, firewall, and package management. I’d be very happy to skip YaST and just use CLI tools to manage most core things. I find those tools to provide a better experience than YaST’s CLI. I asked Jos Poortvliet, openSUSE’s community manager, on Twitter whether YaST was necessary and he said it wasn’t. I’ll take his word and try out openSUSE again, especially since they have a special build for RPi. I’ll revise my stance and make openSUSE my first choice for RPi. Maybe YaST will be helpful in creating my wireless gateway.

I also tried out Arch for the first time. It took me about 3-4 hours to make a customized list of steps to do a UEFI install as well as a BIOS install in a VM. I can say with all honesty that it wasn’t hard to install Arch at all since the wiki is so helpful. The wiki could be better but it’s still very useful. I thought that Arch’s simplicity and DIY nature would be a perfect fit for my RPi. I can install only the things I need and nothing more. I was excited.

And as I configured my VM further I realized I really have to do everything myself. Even the useradd command needs all the flags, compared to Fedora where you just provide the username. This brought me to my first crossroads: do I really want to create my own distro (so to speak) or have fun with setting up a wireless gateway? I think I’ll choose the latter. I want a distro to work out of the box which I can then use to do things other than creat emy own version of a Linux distro. Arch is a pleasure to use if you want to learn Linux but a burden if you want to use Linux to build something. I also feel like I want to go beyond re-inventing the wheel every time I do a new install, instead I want to build on top of the thousands of hours volunteers have spent building a solid distro, be it Fedora, openSUSE, Ubuntu, Debian, or whatever. I want to build a solution not a distro. I’ll still keep Arch as a candidate for my RPi because its simplicity is a very compelling factor.

So there you have it. I have tried to describe a pleasurable user experience by intertwining reviews of different distros with my needs for a wireless gateway using RPi. I find Fedora to be the most pleasurable distro today. It represents the hard work of a lot of upstream contributors in a package that’s friendly. It may not be the distro for new users but if I’m setting up a system for someone new to Linux, and I had to provide support for it, I’d use Fedora. For my RPi I’ll use openSUSE, Pidora, Raspbian, and Arch in that order. I’ll stop when I find the most pleasurable distro for that use case.

GNOME 3.10 Post Install Customization

With the release of Fedora 20 Beta I thought I’d give GNOME a try after having used KDE in Fedora 19. Although I’m still learning my way across the desktop environment, a few things struck with me immediately.

The GNOME design is minimal, to say the least. They have disabled a lot of features by default and some of them really bugged me. On the other hand, there were more default settings (especially keyboard shortcuts) than I found in KDE. Your best friends in GNOME are gsettings, gnome-tweak-tool, and dconf-editor, if you want to customize GNOME Shell. I’m finding out that they may not be enough, though.

Anyways, the things that I changed right away were:

• Show date in the top bar/panel
  gsettings set org.gnome.desktop.interface clock-show-date true
• Show seconds in the top bar/panel
  gsettings set org.gnome.desktop.interface clock-show-seconds true
• Show logout option
  gsettings set org.gnome.shell always-show-log-out true
• Open File dialog should show home directory not recent files. The default value is ‘recent’.
  gsettings set org.gtk.Settings.FileChooser startup-mode 'cwd'
  Relevant file is /usr/share/glib-2.0/schemas/org.gtk.Settings.FileChooser.gschema.xml

You may also want to install gnome-tweak-tool and dconf-editor.

su -c 'yum install gnome-tweak-tool dconf-editor'

These are GUI tools to help you customize the Shell. If you want to stick with CLI then run gsettings list-recursively and explore all the available options.

The sorry state of services in Ubuntu

Read the post How do I choose which way to enable/disable, start/stop, or check the status of a service?. Compare that with systemctl enable/disable/start/stop/status service and tell me, for a user, which is easier?

Yes, with juju charms individual services don’t matter as much. But some of us are not running clouds. We still use a handful of computers, physical and virtual. I would rather let my computer handle services for me. I’d rather not sit there trying to determine which command to use to perform a simple function.

Ubuntu has invested a lot in Upstart and has every right to stick with it. But is it too much to ask for Canonical/Ubuntu to move all services to Upstart? That way at least we don’t have SysV and Upstart running alongside each other and causing this mess. Even Fedora hasn’t moved a lot of services, especially xinetd-based, to systemd but they are still much farther along in a couple years than Ubuntu has been so far. Where’s the inclination of the Ubuntu community and Canonical to not leave things half done?

If Upstart is the future then be done with the migration so you can move on to some other aspect of the system. Add the simple features we all need. So far it appears Ubuntu and Canonical start something innovative and then leave it unfinished to chase something else. They need to fix this culture so that technical users can use a great distribution with fewer headaches.

KDE Post Install Changes

I’ve started using KDE on Fedora 18 and there were a few annoyances I needed to deal with. They are listed in this post.

Enable Trackpad Clicking

Fedora tries to not change the default settings for upstream projects. KDE, by default (it appears), disables clicking from the Trackpad. It’s a quick fix. Read How to enable touchpad click.

An alternative method, that works for only one user at a time, is this:

Open System Settings > Input Devices (under Hardware) > Touchpad > Tapping. Check/enable “Enable Tapping”. Apply changes.

Open the file ~/.kde/share/config/kcmtouchpadrc and change TapButton1=0 to TapButton1=1. Log out and log back in. Clicking through Touchpad/Trackpad should now work.

Hat tip: Re: KDE touchpad mouse click not working

Disable Software Update Checking from Apper

I like to do my software management from the command line. Most times Apper interferes with this. So I disable a service that checks for updates.

Open System Settings > Startup and Shutdown (under System Administration) > Service Manager. In the list for “Startup Services” disable/uncheck and stop Apper Monitor. Apply your changes.

Install Fedora to USB Drive

I have been looking for a notebook to run Fedora for a while. But due to certain personal limitations I haven’t been able to dedicate a notebook only to it. So the next best thing was to create a Fedora installation on a USB pendrive and boot off it. A USB stick is easy to carry around and is great for quickly booting a computer into your customized OS environment.

There are two ways to accomplish this. One is to create a Live USB with persistent storage and the other is to install to USB drive just like you would to a hard drive. After spending about two days trying out various ways to first install and then use it, I prefer to do a complete installation over a Live USB. In this post I’ll discuss how to do both.

Edit: See Felipe’s comment below for caveats when using a USB drive in this manner.

Things You’ll Need

I had either a Windows or a Mac available. My instructions were created and tested on a Windows machine.

• VirtualBox
• USB drive; mine was 32GB
• Fedora Live CD; I used Fedora 18 KDE version
• Computer capable of booting from USB drive

I used VirtualBox and a Fedora VM to install Fedora to my USB stick. The same setup can be used to install Live USB and a full installation.

Install Fedora in a VM. Make sure to assign at least 2 GB of memory to the VM. This is very important. If you assign less then during installation your VM may become unresponsive and your installation will remain incomplete.

Install gParted as it will help you to format and resize the USB drive quickly.

su -c 'yum install gparted'

Install as Live USB

Insert the USB drive in your machine. Start your VM and attach two things to it: the Fedora ISO file and the USB drive. Open gParted and unmount the USB drive (it was identified as /dev/sdb1 in my VM). Create a single partition and format it as ext4.

Install livecd-tools package on your VM. It’ll give you the livecd-iso-to-disk command we’ll use later.

su -c 'yum install livecd-tools'

Now you’re ready to install. But before you proceed, there are a few caveats with data persistence.

• Any changes you make, either new data or updates, will increase the usage of the disk, with space eventually running out.
• The size of the live-rw partition, on which / is mounted, may only be 3GB. You’ll need an overlay to add more space.
• Even though I created a 25GB data persistence overlay, I ran out of space when I updated Fedora on the USB drive after installation. I don’t know why.
• You should not upgrade your kernel on the USB stick, ever! Seriously, once you are done with everything and you are running your Live USB, DO NOT upgrade your kernel. To prevent kernel upgrades, add the line exclude=kernel* to /etc/yum.conf file.

Because of these issues I did a complete installation and not a Live USB. Nevertheless, the next step is to run the command on your VM to create Live USB.

su -c 'livecd-iso-to-disk --overlay-size-mb 25000 --unencrypted-home --delete-home Fedora-18-x86_64-Live-KDE.iso /dev/sdb1'

Here I created a 25GB overlay for data persistence. I specifically created an unencrypted home for ease of use. I also deleted any previous /home partition if there was any (although since we used gParted to create a single partition that shouldn’t be the case).

If you want a separate partition for /home, divide the 25GB between overlay and /home.

su -c 'livecd-iso-to-disk --overlay-size-mb 15000 --home-size-mb 10000 --unencrypted-home --delete-home Fedora-18-x86_64-Live-KDE.iso /dev/sdb1'

This will take some time to complete. When you are done, shutdown the VM and you are ready to boot from your USB drive.

Once you’re using your USB drive, the regular df -h will give you incorrect information about the space used by live-rw. Instead use dmsetup status live-rw to get more accurate information.

Install as Hard Drive

In this scenario you don’t need to install a Fedora VM. You just need the Fedora ISO and the USB stick attached to a VM. When you start the VM boot from the ISO and start the installer. Instead of installing to a virtual hard drive of your VM, choose the USB drive as your installation destination. Perform a regular install. Again, it’s important to assign at least 2GB memory to the VM for a successful install. Once the installation is complete shutdown the VM and you’re ready to boot from your USB.

You can use this installation just like you would on a hard drive. You can update Fedora as much as you like, although it took approximately 12 hours to run my first update. Yeah, it can be really slow. But if you run regular updates afterwards it shouldn’t be that long.

Hat Tip

The only resource you need for detailed information is How to create and use Live USB.

Use Private Certificate Authority to Sign Certificate Signing Request on Linux

I’ll assume that you created a private CA using my tutorial. I also make the following assumptions before proceeding with the tutorial.

• OpenSSL has been installed
• CA private key is in /home/cg/myca/private/
• CA root certificate is in /home/cg/myca/certs/
• CA’s config file, caconfig.cnf, is in /home/cg/myca/conf/
• serial is in /home/cg/myca/
• index.txt is in /home/cg/myca/

Copy CSR

You should copy/download the CSR to /home/cg/myca/csr/ directory.

Sign CSR

Then run the following command to sign it.

openssl x509 -days 3650 -CA certs/crt.ca.cg.pem -CAkey private/key.ca.cg.pem -req -in csr/csr.server1.pem -outform PEM -out certs/crt.server1.pem -CAserial serial

You’ll be asked to provide the passphrase for the CA root certificate key. The final file, crt.server1.pem, is to be sent to the person who initiated the CSR. This is the final certificate they’ll use.