1. Install Ruby programming language and Rails framework

$ sudo yum install ruby
$ sudo gem install rails  --include-dependencies

2. Install header files and libraries for building extension libraries for Ruby

$sudo yum install ruby-devel

3. Download and install Passenger, an Apache module for deployment Ruby on Rails applications on Apache. When running “passenger-install-apache2-module”, follow the instructions on the screen to solve any problems (the installer is friendly and helpful).

$ sudo gem install passenger
$ passenger-install-apache2-module

4. Create a sample Ruby on Rails application

$ cd ~/public_html
$ rails  demo

5. That’s it, you should now be able to access your Ruby on Rails application on localhost using web browser

The X session would not initialize because of the following error:

X.Org X Server 1.4.0.1
Release Date: 5 September 2007
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.20-1.3002.fc6xen i686
Current Operating System: Linux tank.matrix.local 2.6.23.1-49.fc8 #1 SMP Thu Nov 8 21:41:26 EST 2007 i686
Build Date: 13 November 2007 05:47:17PM
Build ID: xorg-x11-server 1.4.99.1-0.10.fc9
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Module Loader present
Markers: (–) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: “/var/log/Xorg.0.log”, Time: Thu Nov 15 22:31:35 2007
(==) Using config file: “/etc/X11/xorg.conf”
dlopen: /usr/lib/xorg/modules/drivers//nvidia_drv.so: undefined symbol: xf86GetPciVideoInfo
(EE) Failed to load /usr/lib/xorg/modules/drivers//nvidia_drv.so
(EE) Failed to load module “nvidia” (loader failed, 7)
(EE) No drivers available.Fatal server error:
no screens found
giving up.
xinit: Connection refused (errno 111): unable to connect to X server
xinit: No such process (errno 3): Server error

I immediately thought that the update broke something related to Nvidia driver, see the undefined symbol above. So I re-installed the driver:

[ikendra@tank][~] sudo yum remove kmod-nvidia
[ikendra@tank][~] sudo yum install kmod-nvidia

This didn’t help and I started to suspect Fedora from releasing a broken update. However, because I have never seen such a major problem after Fedora update, I decided to log on IRC to discuss this with competent people. On the #fedora-qa channel I chatted with a friendly and helpful tester from Fedora, Will Woods. After a few questions, he found the root cause of the problem: I had the fedora-development repository enabled which means that the packages from current development head repository were downloaded. This was easy to be confirmed by issuing

[ikendra@tank][~] cat /var/log/yum.log | grep “fc9″

So it was entirely my mistake. Will asked me, what made me enable the repository at the first place. Good question! I confused fedora-development with fedora-updates-testing – I was interested in the test updates not realizing that I enabled the Rawhide repository. Although I was entirely aware of the fact that the Rawhide cannot be considered stable, I wasn’t aware of the fact I was actually enabling it and the UI did not warn me:

I tried to save the day by disabling the fedora-development repository and issuing…

[ikendra@tank][~] sudo yum install yum-utils
[ikendra@tank][~] package-cleanup –orphans

…to get the list of all fc9 package installed in order to remove them and re-install the fc8 packages – the list was however too long, I will have to reinstall the system. I was glad that Will acknowledged the fact that the repository name “fedora-development” was confusing. It was a good school for me, too, but I could have imagined to spend the evening in a different way!

To resolve the problem, I unchecked the epiphany and firefox packages and let the Package Updater finish the job. A subsequent check for updates (still using the Package Updater) would bring up the update for the two packages (as expected), the update would break on the same dependency (also as expected).

After closing the Package Updater I opened a Terminal to find out more details about the problem:

[ikendra@tank][~] sudo yum update
Loading “installonlyn” plugin
Setting up Update Process
Resolving Dependencies
–> Running transaction check
—> Package epiphany.i386 0:2.18.3-2.fc7 set to be updated
—> Package firefox-devel.i386 0:2.0.0.5-1.fc7 set to be updated
—> Package firefox.i386 0:2.0.0.5-1.fc7 set to be updated
–> Processing Dependency: gecko-libs = 1.8.1.4 for package: epiphany
–> Finished Dependency Resolution
Error: Unresolveable requirement gecko-libs = 1.8.1.4 for epiphany

Since I didn’t have much clues what is causing this problem (any hint would be much appreciated), my next step to resolve the problem was to use brute force by doing the following:

[ikendra@tank][~] sudo yum remove epiphany
[ikendra@tank][~] sudo yum update
[ikendra@tank][~] sudo yum install epiphany

This way, I now have both firefox and epiphany updated.

Due to a change in the way that the Linux kernel handles storage devices, the device names like /dev/hdX or /dev/sdX may differ from the values used in earlier releases. In Fedora 7, for instance the first partition on my first disk (ATA) is now

/dev/sda1

instead of

/dev/hda1

and for instance the first partition on my second disk (SATA) is now named

/dev/sdb1

instead of

/dev/sda1

I wasn’t aware of this change before upgrading to Fedora 7. And because I had previously modified my /etc/fstab manually using the device names linked to the mount points instead of using labels, Fedora 7 installer now refused to upgrade.

The solution was to boot back to the original installation and to run “e2label” to create a label for each partition on your disk. It is pretty simple:

[ikendra@tank][~] sudo /sbin/e2label /dev/hda6 HOME

After that, modify your /etc/fstab to use the labels instead of device names. Example: modify the fstab line which used to be for instance

/dev/hda6 /home ext3 defaults 1 2

to

LABEL=HOME /home ext3 defaults 1 2

I recommend a single reboot to the original Fedora installation to check if all partitions were mounted as expected. After that, run the installer again, it will work.