Type your search keyword, and press enter

Upgrade CentOS 6 to 7 with Upgrade Tools

Your ads will be inserted here by

Easy Plugin for AdSense.

Please go to the plugin admin page to
Paste your ad code OR
Suppress this ad slot.

I decided to try the upgrade process from EL 6 to 7 on the servers I used in my previous blog post “Windows (CIFS) fileshares using GlusterFS and CTDB for Highly available data”

Following the instructions here I found the process fairly painless. However there were 1 or two little niggles which caused various issues which I will detail here.

The servers were minimal CentOS 6.5 installs, with Gluster volumes shared via CTDB. The extra packages installed had mostly come from the EPEL or Glusterfs repositories, and I believe this is where the issues arise – third party repositories.

My initial attempt saw me running:

preupg -l

which gave me the output: CentOS6_7

This meant that I had CentOS 6 to 7 upgrade content available to me, this could now be utilised by running:

preupg -s CentOS6_7

Which then ran through the preupgrade checks and produced the report of whether my system could, or should, be upgraded.

The results came back with several informational items, but more importantly 4 “needs_action” items.

These included “Packages not signed by CentOS”, “Removed RPMs”, “General” and “Content for enabling and disabling services based on CnentOS 6 system”

Firing up links and pointing it at the output preupgrade/result.html file I took a deeper look into the above details.

“Packages not signed by CentOS” as expected covered the third party installed applications, in my case the glusterfs rpms and the epel-release, which were to be expected. The other sections didn’t present any great worries so I pressed on with the upgrade:

centos-upgrade-tool-cli --network 7 --instrepo=http://mirror.centos.org/centos/7/os/x86_64/

running this takes the data from the previous report and runs an upgrade process based on it. Interestingly the first part of the process (redhat_upgrade_tool.yum) checks out the yum repos that are configured and EPEL “seems OK” whereas the glusterfs-epel ones don’t. This called for a little more investigation, as on my first upgrade trial run these packages failed to upgrade, luckily I took a snapshot of the machine before upgrading so could try again.

Strangely, even though the $basearch and $releasever variables were used in the config file, manually changing the $releasever to 7 (as $releasever translates to 7.0) seemed to do the trick. I manually edited the EPEL file too as this contained epel-6 in the url. After this I also noticed that the gluster services were no longer listed in the INPLACERISK: HIGH categories but had been moved to the MEDIUM.

Continue with upgrade [Y/N]?.

Your ads will be inserted here by

Easy Plugin for AdSense.

Please go to the plugin admin page to
Paste your ad code OR
Suppress this ad slot.

yes please!

The upgrade tool then goes through the process of downloading the boot images and packages ready for the upgrade, for some reason I got a message about the CentOS 7 GPG key being listed but not installed, so while I hunted out the key to import I re-ran the upgrade tool with the –nogpgcheck switch to skip that check. The tool finished successfully then and then prompted me with:

Finished. Reboot to start upgrade.

Ok then, here goes….

Bringing up the console to that machine showed me it booting into the images it downloaded in preparation for the upgrade. Mostly a screen of RPM package updates and reconfiguration. The update completed fairly quickly then automatically rebooted.

As mentioned above this was the second attempt at an upgrade on this machine, the first time it was upgraded I was prompted with the emergengy login screen after reboot. This turned out, strangely, to be that the glusterfs packages hadn’t been upgraded so I logged onto the console brought up eth0 and ran yum update. After a reboot I was faced with a working system.

The second attempt I managed to ensure the gluster packages were included in the upgrade so after crossing fingers the reboot ended with a login prompt. Great News!

The only issues I faced were Gluster volumes not mounting at boot time, but I’m sure this is a systemd configuration which can be easily rectified and really don’t change the success of the upgrade process.

All in all, good work from the Red Hat and CentOS teams, happy with the upgrade process. It’s not too far removed from Fedup in Fedora of which I’m sure it’s based.

Update: The issues I faced with my gluster volumes not mounting locally were resolved by adding the _netdev directive after defaults in fstab e.g.:

localhost:data1 /data/data1 glusterfs defaults,_netdev 0 0

All that was occurring was systemd was trying to mount the device as a local filesystem, which would try to run before the glusterd service had started. Adding this option delayed the mounting until all network-target was complete essentially.

The other issue that became apparent after I resolved the gluster mounting issue was the CTDB service not running once boot had completed, this was due to the CTDB service trying to start before filesystems were active, I modified the ctdb.service file to ensure that it only started after gluster had started which seemed to be enough. I guess that getting it to start after the filesystems had mounted would be better but for now it works. To do this I modified the  /usr/lib/systemd/system/ctdb.service file and changed the line:

After=network.target

in the [Unit] section to

After=network.target glusterd.service

 

Installing dig on a CentOS or Red Hat machine

Gone are the days where we install nslookup for DNS resolution testing, the new(ish) kid on the block is dig. Although maybe not installed by default, it can be installed quite easily from yum, however it comes bundled with a number of tools so the package name isn’t all that obvious.

[root@server ~]# yum install bind-utils

Will do the trick, now how to use it?

[root@server ~]# dig @nameserver address.com

replace nameserver with your dns nameserver of choice, for example:

[root@server ~]# dig @8.8.8.8 google.com

will use Googles DNS server to resolve google.com

Why I’m uninstalling Ubuntu

I wouldn’t normally write about this kind of move, but I’m in a position where I feel I have to. A little over a year ago I made a decision to move from Fedora to Ubuntu, it wasn’t a decision that was easy after all I have been using Fedora since its first release, and Red Hat since around version 5. Needless to say I was (and still am at heart) a die hard Red Hat fan. There seemed at the time to be a draw to Ubuntu, I was feeling a buzz around the community there that I wasn’t really seeing with Fedora (although I don’t think I was looking), a lot was going on around the Unity project – whether good or bad, it was still going on. So I jumped right in, installing the latest release 11.10 I think it was, joined the forums/wiki/launchpad etc and started filing bugs and generally making a nuisance of myself.

All was good, I really felt like I was a part of something, even went as far as installing the latest test release (as I still am) and it really is a great distro. Unity took me a bit of convincing, but how most things just integrated was brilliant. I even gave a small donation when they asked.

So what went wrong? Well around a year later, I’m still running the latest testing release and still like the distro as a whole. Unity has broken (something in my profile) so I’ve reverted back to Gnome 3 which I’m quite happy with, but thats not the issue. The issue can probably only be described as politics and game playing. Now the Amazon thing didn’t really bother me too much, I kind of understand the reasoning behind that (besides, I uninstalled it) the donations thing was probably an unfortunate mistake. What isn’t a mistake however is taking people for a ride, both community members and the gen-pop.

So lets look at the madness behind Mir, a while ago it was announced that Wayland was to be integrated into a future release of Ubuntu, yet recently it was announced that they would be using their own product MIR. Did the Ubuntu community know about this? It seems not, but yet they have been working on it for over 8 months. Not community spirited if you ask me. I can kind of understand where they are going with Mir, so they can use it across all the devices they want to take over, but still… I just dislike the fact they have done wonderful things for Linux in bringing it to the masses, then deviate from the whole ethos of open source.

Another thing which disappoints me is the whole hoohar around the devices thing, showing what can only be described as a skin for Android really at large conferences just really proves who/where they are trying to be. If only they would stop with the big WOW factor announcements which don’t really have any substance and push for better software in the community, perhaps adopting a business model similar to Red Hat as it seems to have done OK for them.

On a more positive note, I’m quite glad to go back to Fedora, things are looking fantastic there and upstream which is where my heart truely lies!