Installing CentOS 7 Prerelease on VMWare

Hi,

if you haven't heard the news: A prerelease of CentOS 7 is out. This is important, because:

1. CentOS 7 is a major release and will be the base of the Linux Distro that people like me will be using in the next years on servers. (Yes, I do know about Ubuntu 14.04 LTS, OpenSUSE Whatever, Debian Something, etc. However, that is most likely not what I will be using. Logically, so won't do people like me. End of discussion.)
2. Quite a few things have changed since CentOS 6. In particular, much has been adopted from recent Fedora versions: 
1.  The new Anaconda Installer. (I am personally not overly happy with it. The old one worked quite well for me, but I had my share of trouble with the new one. In particular, I am less than enthusiastic about how Disk Partitioning works nowadays. OTOH, this version of Anaconda (the one distributed with the CentOS 7 Prerelease) is a step forward in that aspect. Perhaps, more people like me had similar trouble.)
2.  GNOME 3: Well, this one will definitely be the cause of a major uproar on the Red Hat Continent. I readily admit that I was one of the people who initially went with MATE as a GNOME 2 replacement, so as to avoid GNOME 3. However, in the meantime, I've learned to live with it and can even appreciate some features like the enhanced keyboard control. The one thing I am still missing is the pictures screenblanker, though. I learned to live with xscreensaver, although this still smells like a very ugly hack.) Like it, or not, people like me (c) will have to face it.
3.  This prerelease was published not even one weak after the release of RHEL 7. Compare that to the months we had with some minor versions of CentOS 6. So, we benefit from Red Hat adopting CentOS. Good news!

So, what is this posting about?

•  I won't cover generic aspects of installing CentOS, or Fedora. I'll assume that you have installed either of which before and have a rough idea of what I am talking about. In particular, I assume that you know what a network installation is, because right now this is the only installation method available through an ISO image. (Forget "Live DVD", or whatever else you have hoped for.)
• I will, hovever, concentrate on installing this very special prerelease version, because it is not quite like installing an official version. (Neither is it overly complex, though.) Hopefully, I'll also cover what has changed since version 6.

 If that is interesting for you: Read on. If not: I am sorry! Google (Planet Apache, or whatever else brought you here, did wrong and is to blame).

So, what's to do?
Download the ISO Image from http://buildlogs.centos.org/centos/7/os/x86_64-20140614/images/boot.iso and save it, for example as "centos7-netinstall.iso".

1. Create a new VM (My Parameters were "I will install the operating system later.", "Guest operating system=Linux", Version="CentOS 64-bit", Maximum disk size=30GB, Memory=3072GB. Everything else was as suggested by VMWare Player 6.0.2 build-1744117.
2. Select Virtual Machine Settings, CD/DVD (IDE). Enable "Connect at power on" and "Use ISO Image file". Select the file you downloaded in step 1.
3. Start up the created VM. From the boot menu, select "Install CentOS 7". (You may as well test the media, but you did check the MD5 Sum anyways, did you? :-) At least, you know the difference... (Remember that "won't cover generic aspects" above?)
4. Hopefully, the Anaconda graphical installer will come up. (At least, it does so on a VMWare machine. I'd never hope so on a machine with an NVIDIA or AMD graphics card. Don't expect me to help you with that crap.  I'm all with Linus on that. :-)
5. Select your language (Safe choice is, of course,"English-US").
6. Anaconda will notify that  this is prerelease, unstable software. You knew that anyways, so click on "I want to proceed."
7. The Anaconda "Installation Summary" screen will come up. This will be an unknown thing (Remember: New Anaconda) for a lot of people, so here's a screenshot:
   
   
   
   
   The important thing to keep in mind is the order of the following steps.
8.  Start with the Keyboard. (You're likely to use that in the following steps.) Click on "Keyboard" (Not the small keyboard icon, but the big icon, or the word.) Click on the "+" sign, and select your favourite keyboard layout. (In my case "German, Germany, Eliminate dead keys".) Remove any unwanted layout by clicking on it, and clicking on the "-" sign. Finish by clicking on "Done" in the upper left corner. (Who the heck came up with that? Anyways, remember the location.)
9. The next thing you're gonna need is the network. (Most likely, you are currently "Not Connected".) Click on "Network & Hostname". Click on "Off" in the upper right corner to enable networking. Enter a meaningful host name. (I choose "c7wm96.mcjwi01.eur.ad.sag". Avoid "localhost.localdomain".) Click on "Done". (Upper left corner, remember?)
10. Now we can edit "Date & Time", aka time zone. I choose "Europe/Berlin".
11. If you need that (You don't, really...), click on "Language Support" and select additional languages.
12. The most obvious trap is the "Installation Source" (Hopefully, it won't be in the official releases, which will select an URL automatically): Click on that, enable "On the network", and enter the URL buildlogs.centos.org/centos/7/os/x86_64-20140614/. If you need to use an HTTP Proxy, click on "Proxy setup". Enter your proxy host name and port (in my case "httpprox.hq.sag:8080") Click on "Add". Click on "Done". Wait a few seconds until you see "Downloading package metadata", or the like. If you do see something like "Error setting up Base Repository", changes are that the URL is wrong. Fix it, and retry. Wait a few seconds more until downloading the package data and checking for dependencies has finished.
13. Next, go to "Software Selection". The default is "Minimal Install". This is fine, if you are happy with a server that has no X11 enabled. I choose "Server with GUI" instead, to make my colleagues happy. On the right hand side, you can choose to have KDE installed addizionally. (AFAIK, no support for MATE, Cinnamon, LXDE, whatever. No idea, whether that will come.) You might wish to deselect LibreOffice, if you manage to do that. Click on "Done". Wait a few seconds until the message "Checking for software dependencies" disappears.
14. Another, somewhat difficult step is the "Installation Destination". Click on that. If you need "Custom Partitioning", enable "I will configure partitioning." below. (The default is "Automatically configure partitioning.", The presence of this option is what has changed since Fedora 20, and I consider this to be a major improvement.) Click on "Done", even if you're actually not. If the window for "Manual Partitioning" appears, select your desired partition type ("Standard Partition", "BTRFS", "LVM") and add a few partitions by clicking on the "+" button. I create the following partitions (in that order):
1. /boot with a Capacity of 500MB.
2. Swap with a Capacity of 6GB. (I need that much, because the Oracle Installer wants 8GB of physical memory, but accepts Swap as a replecement.)
3. / with a Capacity of 8 GB.
4. /home with a Capacity of 16.21GB
Click on "Done". Click on "Accept Changes". If no error messages can be seen on the "Installation Summary" screen, then you have mastered the major hurdles.

• Click on "Begin Installation".
• Regardless of the ongoing installation, click on "Root Password". Enter a meaningful, and secure, root password. Repeat it. Click on "Done". (You never even considered to enter a weak password, did you? Well, if you did: Click on "Done" twice. :-)
• The installation is still ongoing. Click on "User Creation". Enter a real name and a login name, enable "Make this user administrator" (The option will actually add the created user to the "wheel" group, which has permissions to use "sudo"). Enter a password and repeat it. Click on "Done" twice. (Oops, your passsword is secure: Then once is sufficient.)
• Keep in mind that this is a "network installation": Anaconda will download each and every single RPM to install (In my case about 1200.), so the process will take time. OTOH, with a fast network (DSL, or something like that) it won't take much longer than installation from a DVD.
• Once the actual installation is finished, you'll be asked for a reboot. Confirm that, and the new system comes up. Almost done. One minor step to perform: Accept the GPL license, and accept another reboot. (No, this isn't Windows, but still....)

If you got this far, then you've got a system running CentOS 7 Prerelease. Congratulations. Unfortunately, one thing is still left. Your system doesn't have a valid Yum configuration. (Convince yourself by running

  sudo yum repolist all

Oops, you need a terminal window to do that. That's no problem if you are running KDE or any other desktop that you are used to. If it's GNOME 3, and you are not, here's what to do: Press, and release, the "Windows" key. (No, this is still not Windows, but anyways. If it helps, call it the "Linux" key.) Press, and release, the following keys, in that order: "t", "e", "r", "m", and Enter. At that point, a GNOME Terminal window should appear. (Or, in theory, any other desktop application containing the word "term". However, you had no chance to install "xterm" do far. :-) Using the command

  sudo yum vi /etc/yum.repos.d/centos7-prerelease.repo

create a new file with the following contents:

  [centos7-prerelease]
  name=CentOS 7 Prerelease
  url=http://buildlogs.centos.org/centos/7/os/x86_64-20140614/
  enabled=1
  priority=1
  gpgcheck=0

And now (I am not avoiding any flame wars today :-) you can do

  sudo yum install emacs emacs-nox gcc make binutils kernel-headers

A final note on the VMware tools: Anaconda did automatically install "open-vm-tools-desktop". So, mouse integration, copy and paste, etc. worked immediately for me. No need for a seprate installation.

Installing Obsolete Java JDK versions on Fedora Linux

As a Java developer, one is frequently forced to use obsolete, or even deprecated, Java versions. So I came to the necessity to install Java 6 on Fedota 19. The problem: In the Fedora 19 repositories, there's only Java 7 and 8. Convince yourself:

$ sudo yum list | grep openjdk
java-1.6.0-openjdk.x86_64              1:1.6.0.0-59.1.10.3.fc16         installed
java-1.6.0-openjdk-devel.x86_64        1:1.6.0.0-59.1.10.3.fc16         installed
java-1.6.0-openjdk-javadoc.x86_64      1:1.6.0.0-59.1.10.3.fc16         installed
java-1.7.0-openjdk.x86_64              1:1.7.0.60-2.4.2.0.fc19          @updates
java-1.7.0-openjdk-demo.x86_64         1:1.7.0.60-2.4.2.0.fc19          @updates
java-1.7.0-openjdk-devel.x86_64        1:1.7.0.60-2.4.2.0.fc19          @updates
java-1.7.0-openjdk-javadoc.noarch      1:1.7.0.60-2.4.2.0.fc19          @updates
java-1.7.0-openjdk-src.x86_64          1:1.7.0.60-2.4.2.0.fc19          @updates
java-1.7.0-openjdk-accessibility.x86_64
java-1.8.0-openjdk.i686                1:1.8.0.0-0.9.b89.fc19           updates 
java-1.8.0-openjdk.x86_64              1:1.8.0.0-0.9.b89.fc19           updates 
java-1.8.0-openjdk-demo.x86_64         1:1.8.0.0-0.9.b89.fc19           updates 
java-1.8.0-openjdk-devel.i686          1:1.8.0.0-0.9.b89.fc19           updates 
java-1.8.0-openjdk-devel.x86_64        1:1.8.0.0-0.9.b89.fc19           updates 
java-1.8.0-openjdk-javadoc.noarch      1:1.8.0.0-0.9.b89.fc19           updates 
java-1.8.0-openjdk-src.x86_64          1:1.8.0.0-0.9.b89.fc19           updates 

The same goes for Fedora 18 and 17, btw. (I'll skip the output here. Note, that processing these commands will take some time, as yum will download the complete repository metadata for the respective version.

$ sudo yum --releasever=17 list | grep openjdk
$ sudo yum --releasever=18 list | grep openjdk

However, Java 6 is available for Fedora 16!

$ export http_proxy=MY_PROXY_URL, for example http://my.proxy.server:8080
$ wget wget http://archives.fedoraproject.org/pub/archive/fedora/linux/releases/16/Fedora/x86_64/os/Packages/java-1.6.0-openjdk-1.6.0.0-59.1.10.3.fc16.x86_64.rpm
$ wget http://archives.fedoraproject.org/pub/archive/fedora/linux/releases/16/Fedora/x86_64/os/Packages/java-1.6.0-openjdk-devel-1.6.0.0-59.1.10.3.fc16.x86_64.rpm
$ wget http://archives.fedoraproject.org/pub/archive/fedora/linux/releases/16/Fedora/x86_64/os/Packages/java-1.6.0-openjdk-javadoc-1.6.0.0-59.1.10.3.fc16.x86_64.rpm

Now, my first (and preferred) attempt to install these would be

$ sudo yum localinstall --obsoletes java-1.6.0-openjdk*

which fails, due to the following error message:

  error: Failed dependencies:
  java-1.6.0-openjdk is obsoleted by (installed) java-1.7.0-openjdk-1:1.7.0.60-2.4.2.0.fc19.x86_64
  java-1.6.0-openjdk-devel is obsoleted by (installed) java-1.7.0-openjdk-1:1.7.0.60-2.4.2.0.fc19.x86_64
  java-1.6.0-openjdk-javadoc is obsoleted by (installed) java-1.7.0-openjdk-1:1.7.0.60-2.4.2.0.fc19.x86_64

(Please contact me, if you have an idea on how to get rid of these!) Fortunately, there's another possibility, which does the job quite neatly:

$ sudo rpm --nodeps -i java-1.6.0-openjdk*

If you're an Eclipse user, the JDK can now be found in /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/

The new kid on the virtualization block

Last week, I happily upgraded my Linux installation to Fedora 11. As usual, this wasn't driven by any requirements, just by the fun to have the latest and greatest. (Do I hear Anjas "MEN!" :-) On the whole, things have improved. For example, my UMTS stick is now working out of the box. Monitor switching at work is now working nicely.

An obvious minus, however, is the integration of VMware. I am using VMware server 1, which is almost unsupported on Fedora in general. In particular, it it unsupported for Fedora 11. As usual, it was no problem to find a matching kernel patch. But, what a surprise, it is no longer sufficient to patch the VMware modules: You need to patch the kernel as well. Ok, I detected the procedure within one hour. But that means, that I will have to compile my own kernel with any kernel upgrade. Given the frequency of kernel updates on Fedora, I'll likely recompile every two weeks or so.

Brings up the question for alternatives. I have tried VMware server 2 in the past, but was definitely disappointed, because it is both a resource hog (for example, more than 400MB on disk!) and the lack of the former vmware-console just adds on. Nevertheless, I tried again. Just to detect that the same problem seems to be present: The kernel modules fail to load with the same error message of a missing symbol.

I never tried VirtualBox before, but this seemed to be a good enough reason to do it now. First impressions have been quite positive, until I tried to start a VM with a windows guest system. Obviously, that's not so easy: To get it work, you have to change some settings, fiddle with the windows registry (of course, before starting Windows ...) and similar niceties. Again, that's not what I'd like to have as a standard procedure. VM's should be easily adoptable from or given to colleagues.

So far, I was sticking to VMware server 1. But today, I detected the announcement of VirtualBox 3 beta. And, hard to believe, it just works, even with Windows guests imported from VMware. I think, VMware lost a user...

Automatically compiling VMWare modules

VMWare does, in general, an excellent job. It runs smoothless on my machine, generally being one of my best work horses. In particular, with VMWare Server coming at no cost.

There's an exception, though: The kernel modules. As usual, the problem doesn't exist on a Windows host (or guest, for that matter), but you've got to know how to deal with it on a Linux host. VMWare depends on a number of kernel modules, for example vmnet.o, which creates the virtual network interfaces. In theory, these modules are delivered as part of the VMWare distribution for a variety of Linux distributions. In practice, I am unaware of any example, where these precompiled modules could been used: I always needed to compile them for myself.

Ok, that's not too much trouble (at least not, if you've been able to obtain the right patch for your system, typically after a lot of Googling), basically all you need to do is to run vmware-config.pl (on the host) or vmware-config-tools.pl. However, one problem is still left: The procedure of recompiling the modules needs to happen after any Kernel upgrade again.

But here's a solution: An init-script, which is invoked before VMWare starts upon every reboot. The script checks, whether there are modules matching the running kernel. If not, vmware-config.pl is invoked with the necessary options for batch mode.

To install it, download the script here. Store it as /etc/init.d/vmware-kernel-modules. On Fedora-Linux, create the necessary links by running /sbin/chkconfig --add vmware-kernel-modules. On other distributions, this must be done manually.

Mobile Internet with Fedora 10 and Simply (T-Mobile)

I think, any experienced Linux user knows that feeling: Even while you generally feel fine with your OS, there are these moments when you ask yourself whether you should switch to Windows. Typically, these moments come whenever you've got some new hardware gadget.

In my case, this has been a so-called web'n'walk Stick from Germany's T-Mobile, which I intend to use for connecting to the Internet on travel. Unfortunately, I am quite frequently on the road, or visiting customers, where I cannot connect my Laptop to the network, so this thing will come in quite handy.

Would I be a Windows user (or perhaps a Mac fanatic), this wouldn't be worth posting: Of course, the device is neatly trimmed for Windows, making almost everything automatic. Basically, you plug it in, enter your PIN, and that's it. Not so with Linux, or (to be fair), at least not with Fedora Linux. I've got it running now (in fact, this post is written with the Ethernet disconnected), but that's after several hours of recherche, postings in mailing lists and in the Fedora Forum (not that these had any results). As usual, you need to understand what's going on, making yourself known to technical concepts, command line utilities and configuration files, which you never intended to know. And that's the reason for writing this: Perhaps I can save some other persons time.

The first thing to understand is this: In order to make life easier for Windows and Mac users, the device is running in one of two quite different operation modes. The first mode is the default mode: The stick acts as a very small USB drive. On Windows, this allows to automatically install software from it. Needless to say, there are no Linux drivers. (The good news: All drivers came as part of Fedora. :-) Also needless to say: This default mode is not what you want. You must deactivate it and switch to the other mode, where you can actually use the stick. (I assume that the installed software does that automatically on Windows.)

There are several tools and utilities for doing this switch: usb_modeswitch (which I choosed, because it comes with Fedora), rezero, ozerocdoff, and perhaps a multitude of others. (My guess is, it would help, if distributions could agree on a common choice here.) These tools typically need some configuration. To obtain this configuration, start looking at the output of

[jwi@mcjwi ~]$ /sbin/lsusb
Bus 001 Device 005: ID 413c:8103 Dell Computer Corp. Wireless 350 Bluetooth
Bus 001 Device 006: ID 0b97:7762 O2 Micro, Inc. Oz776 SmartCard Reader
Bus 001 Device 004: ID 0b97:7761 O2 Micro, Inc. Oz776 1.1 Hub
Bus 001 Device 002: ID 413c:a005 Dell Computer Corp. Internal 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 004: ID 0af0:6971 Option
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

If you don't know, which line belongs to your stick: Just remove it, run the program again, and see what changes. In my case, the interesting part is

  Bus 003 Device 004: ID 0af0:6971 Option

The ID consists of two parts: The so-called vendor ID (0af0) and the product ID (6971).

If you have usb_modeswitch, you might inspect a file called usb_modeswitch.conf (in my case /etc/usb_modeswitch.conf) and search for the above ID's. There's a good chance that you find them there. If not, enter them into Google, together with usb_modeswitch as an additional search term. Again, there's a good chance to find something. If not: Bad luck. I don't know what to do in that case, but I guess consulting the above tools mailing lists, forums, or whatever.

In my case, I've learned from the configuration file and some Internet pages that I've got to enter the command

sudo usb_modeswitch -v 0af0 -p 6971 -P 6971 -m 0x05 -M 55534243785634120100000080000601000000000000000000000000000000

to change the mode. First step done. If everything's fine, the following command should now provide some meaningful output:

  [jwi@mcjwi ~]$ hal-find-by-capability --capability=modem
/org/freedesktop/Hal/devices/usb_device_af0_6971_Serial_Number_if0_serial_unknown_1
/org/freedesktop/Hal/devices/usb_device_af0_6971_Serial_Number_if0_serial_unknown_0

Now enter NetworkManager (aka nm-connection-editor) and switch to "Mobile Broadband". Press "Add" to create a new connection. If you're lucky, you will find a popup like the following:


The second and third entry are default entries. The presence of the first entry shows you that NetworkManager recognized your stick. Needless to say: In my case, it didn't. After consulting the home page of usb_modeswitch I found out, that I need to load some other driver explicitly:

/sbin/modprobe option

In your case, this might be usbserial, rather than option. Sorry, can't help you here.

But if you can choose your "modem": Almost there! (Not yet, of course.) NetworkManager will open a window like the following:



(In the US, or to be precise, with CDMA this might look quite different.) The PIN and the PUK are what you get from your mobile broadband provider. If you're even luckier, the provider will tell you the other data as well, in the written data sheet, or at least on the hotline. Perhaps, you already guessed it: My provider didn't. ("We aren't supporting Linux.")

To find the remaining data, use Google again. In my case, the relevant search terms have been "T-Mobile APN PIN". (Simply is a reseller of T-Mobile) Another choice might be to consult the list of operators on the Gnome site. I've found the following entry there:

        
              147
              T-mobile
              de
              D1
              internet.t-d1.de
              t-d1
              
                      193.254.160.1 
                      193.254.160.130
              
      

Tells me the APN (might be some servers host name?), and the password. (You should be able to ignore the DNS servers, as they are configured automatically.) In my case the user name was missing, but some more googling revealed the user name "Internet".

Believe it or not, but now it's working! (Might be, that you need to click on the NetworkManager's applet, if you didn't choose "Automatic Connect" and activate the connection.)

And now you know, why I clearly prefer a lot of Linux experience in profiles or curriculum vitae, when my employer hires: People who deal with that stuff should be ready for the problems we provide them with...

VMWare and key maps on Fedora 10

I am one of those poor souls who require Windows for some tasks. I wish, this weren't the case, but that's how things are. Fortunately, VMware Server comes to my rescue: A comparatively small VM of about 15GB is sufficient.

However, after my recent upgrade to Fedora 10, I suddenly noticed that some of my keys were no longer working in the VM: This included the arrow keys, but also some keys, which have been reachable via "Alt Gr" only, like '@', or '\'.

A quick search on Google revealed that I am far from being the only one bothered with that problem. In fact, the difficulties are more likely related to a Kernel upgrade. Users of Ubuntu 8.10 with a similar new kernel seem to suffer the same trouble. Fortunately, solutions were always at hand. For example, the VMware support suggests to use

xkeymap.usekeycodeMapIfXFree86 = true

or

xkeymap.usekeycodeMap = true

in ~/.vmware/config. Other sources proposed a list of explicit code settings instead, like

xkeymap.keycode.108 = 0x138 # Alt_R
xkeymap.keycode.106 = 0x135 # KP_Divide
xkeymap.keycode.104 = 0x11c # KP_Enter
xkeymap.keycode.111 = 0x148 # Up
xkeymap.keycode.116 = 0x150 # Down
xkeymap.keycode.113 = 0x14b # Left
xkeymap.keycode.114 = 0x14d # Right
xkeymap.keycode.105 = 0x11d # Control_R
xkeymap.keycode.118 = 0x152 # Insert
xkeymap.keycode.119 = 0x153 # Delete
xkeymap.keycode.110 = 0x147 # Home
xkeymap.keycode.115 = 0x14f # End
xkeymap.keycode.112 = 0x149 # Prior
xkeymap.keycode.117 = 0x151 # Next
xkeymap.keycode.78 = 0x46 # Scroll_Lock
xkeymap.keycode.127 = 0x100 # Pause
xkeymap.keycode.133 = 0x15b # Meta_L
xkeymap.keycode.134 = 0x15c # Meta_R
xkeymap.keycode.135 = 0x15d # Menu

In my case, none of these solutions worked completely. The hex codes were refused by VMware Server and the usekeycodemap stuff was fixing some keys, but not all. It turned out, that I had to convert the hex key codes to decimal in order to get it working. For the convenience of those who share my trouble, I post my settings here:

xkeymap.keycode.108 = 312 # Alt_R
xkeymap.keycode.106 = 309 # KP_Divide
xkeymap.keycode.104 = 284 # KP_Enter
xkeymap.keycode.111 = 328 # Up
xkeymap.keycode.116 = 336 # Down
xkeymap.keycode.113 = 331 # Left
xkeymap.keycode.114 = 333 # Right
xkeymap.keycode.105 = 285 # Control_R
xkeymap.keycode.118 = 338 # Insert
xkeymap.keycode.119 = 339 # Delete
xkeymap.keycode.110 = 327 # Home
xkeymap.keycode.115 = 335 # End
xkeymap.keycode.112 = 329 # Prior
xkeymap.keycode.117 = 337 # Next
xkeymap.keycode.78 =   70 # Scroll_Lock
xkeymap.keycode.127 = 256 # Pause
xkeymap.keycode.133 = 347 # Meta_L
xkeymap.keycode.134 = 348 # Meta_R
xkeymap.keycode.135 = 349 # Menu

Fedora PreUpgrade

You've got to learn every day, that's for sure. Sometimes it's tedious (yes, I admit to being so old as no longer love learning for its own sake), but sometimes it's nice. An example of the latter was today when I read about Fedora PreUpgrade.

A while ago, I wrote about UNetbootin, a very nice utility for starting Linux installation or live cd's like GPartEd from a running system without burning a CD or DVD. I've been using it since then and will do so in the future. However, in the case of Fedora, CentOS or Red Hat Enterprise Linux upgrades, using UNetbootin has its limitation. (Which is, of course, not the fault of UNetbootin, but a limitation of these distributions, in the latter simply referenced as Fedora.)

For upgrade of Fedora, there are basically two options:

1. The officially supported way is using the Anaconda Installer. That means booting from a CD, DVD (or via UNetbootin :-). That's nice, if you have a DVD ready and also have direct access to the system.
2. The officially unsupported way is using Yum. Much better in some aspects: You can do it from within a running system, even remotely. However, if you are reading the Yum Upgrade FAQ, then you cannot fail to notice that there seem to be a lot of traps and possible problems. I have had my share of these in the past, for example when the IDE devices have been renamed from /dev/hdx to /dev/sdx: At that point you could bet your house on Yum upgrades failing.
   For similar reasons, the Yum upgrade should not happen with a UI running. If you are actually using the machine (for example on your own desktop), then that means a lot of more downtime than you want. (Ok, you might use the download-only plugin... I am ranting, but there's a reason for this Blog's title...)

In other words, you either got to do it safe (Anaconda) or nice (Yum). No longer: Use PreUpgrade.

It's a small python utility with a UI. You start it. It connects to the Fedora server and gathers a list of releases, which are available for an upgrade. (This might include alpha and/or beta releases, if you like.) Proxy servers are supported, btw., I did not check, whether it uses http_proxy, yum.conf, or both. You select a release and click on "Apply". After that, it automatically calculates dependencies and loads the required RPM's to your hard drive. So far, you' ve got the advantages and the comfort of Yum.


But that's not all. In the next step, PreUpgrade is loading a kernel image, a ram disk and similar stuff to your hard drive and configures your system for using them at the next reboot: In other words, it does what UNetbootin would, for you.

All this is happening in the background. You can continue your work, no downtime so far. Finally, when PreUpgrade is finished, you may click on Reboot: Anaconda comes up, performing a safe installation without downloading anything or using a slow CDROM drive.

By using PreUpgrade, I have just upgraded from Fedora 9 to Fedora 10. My downtime was about 10 minutes. (Excellent possibility to get some coffee!) Aint this magic?

Linux Installation - Simpler than ever

I had my share of Linux installation in the past, starting with floppy disk based 15 years ago, and used various installation methods, including CD, DVD, bootp based network, local file system, and so on. I am used to things breaking, but of course, I enjoy if everything works well.

This week, I stumbled over a package called UNetbootin. Think of it as a Windows setup.exe for installing Linux. It is actually that simple. You may choose between Fedora 8 (as of this writing, less than one week old), OpenSUSE 10.3, Ubuntu 7.10, Debian Etch, and even a simple partition manager. If you do not have Windows installed, you can choose a different host system: There also are .rpm, and .deb files, as well as a simple shell script.

I am definitely impressed. Most possibly, I will use it for my future installations as well. It's worth spreading the news.