Setting resolution of external monitors on Linux

Connecting my Fedora laptop to an external monitor by default limits the resolution of the external monitor. I know the monitor can do 1920×1080 vs 1024×768. I got tired of looking up the xrandr commands so I wrote up a little script.

Usage: ./addmode x-resolution y-resolution or ./addmode 1920 1080

If there are multiple monitors it will list them out giving you the option to select the correct one.

WARNING: If only one is available it will use that one without prompting. Also the script defaults to 1366×768 unless you pass in an x,y resolution.

#!/bin/sh

xres=$1
yres=$2
fullmodeline=$(cvt 1366 768 | grep Modeline | awk '{$1=""; print $0}')
modeline=$(echo $fullmodeline | awk '{print $1}')
monitors=$(xrandr | grep " connected " | awk '{print $1}')
matches=$(echo $monitors | gawk '{print NF}')

case "$matches" in
    0)
       echo "No matches found"
       show=""
       ;;
    1)
       show=$monitors
       ;;
    *)
       echo
       echo "Multiple matches found..."
       i=1
       for option in $monitors
       do
          echo "$i: $option"
          i=`expr $i + 1`
       done
       echo "q: Quit"
       echo
       read -p "? " ans
       if [ "q" == "$ans" ]; then
          show=""
       else
          show=$(echo $monitors | gawk '{print $'$ans'}')
       fi
       ;;
esac

if [ "" != "$show" ]; then
   #xrandr --newmode $fullmodeline
   xrandr --addmode $show $modeline
fi

You can download the script from https://gist.github.com/jmrodri/cad187f6cb5d5ed832a3

Fedora 13 to Centos 7

A couple of weeks ago, I finally updated my home server from Fedora 13 to CentOS 7. Fedora had the media support but I can’t keep the machine updated fast enough. This time I decided to go with another Red Hat derivative so I chose CentOS. The goal is to have an OS that has a longer release cycle. Most of the services I’m running haven’t changed in a while (considering Fedora 13 was ancient).

This was NOT an in place “upgrade”. Going to CentOS was a fresh install. I backed up all 70G of the root partition to an external drive then told CentOS to reformat the existing partitions. My biggest worry was the 2TB RAID 5 array. During the installation I told the installer to mount the array on /vol but DO NOT FORMAT. I checked it three times to make sure I didn’t lose anything. I did NOT backup the RAID array so this was the most dangerous part of the install I did.

Once installed the task of restoring the data back to the server, users, configuration, install needed software to support the services I had running on the machine, etc. Because Fedora 13 was so old, I couldn’t just rsync /etc.

First thing I had to do was change the UID and GUID of all the backup files since the default UID changed from 500 to 1000. I created the users, then I had to change the access to the backed up files and to the RAID array.

# owner
chown -R --from=500 1000 $1
chown -R --from=501 1001 $1
chown -R --from=502 1002 $1
chown -R --from=504 1004 $1
chown -R --from=505 1005 $1
chown -R --from=506 1006 $1
chown -R --from=507 1007 $1

# groups
chown -R --from=:500 :1000 $1
chown -R --from=:501 :1001 $1
chown -R --from=:502 :1002 $1
chown -R --from=:504 :1004 $1
chown -R --from=:505 :1005 $1
chown -R --from=:506 :1006 $1
chown -R --from=:507 :1007 $1

chown -R --from=481:466 992:989 $1

The firewall switched from iptables to FirewallD. So instead of restoring my /etc/sysconfig/iptables file I decided to figure out how to use FirewallD. I wrote a script for each of the iptables ports:

#...
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-port=PORT#/tcp
#...
firewall-cmd --reload

Most of the services were easy to get back running: http, vnc, and plexmediaserver. Some of the others were a bit tricky to get back up and running.

Streambaby had an error with the newer version of ffmpeg. It would fail with:

Exception in thread "main" java.lang.NoClassDefFoundError: net/sf/ffmpeg_java/v53/AVFormatLibrary …

Thankfully, this post had the suggested solution of simply adding the following to the streambaby.ini

com.unwiredappeal.tivo.vm.ffjava.FFmpegJavaVideoModule=false
ffmpegexe.transcode.sameqargs=-ab 192k

Other Streambaby & multimedia resources:

https://code.google.com/p/streambaby/wiki/StreamBabyIni
http://info.vortexbox.org/tiki-index.php?page=InstallStreamBaby
http://wiki.centos.org/TipsAndTricks/MultimediaOnCentOS7

Next up was to revive the NFS shares.

The server also acts as a TimeMachine drive to backup our MacBook Pro. The old server used netatalk 2.x so the configuration files changed here too.

  • config files moved from /etc/atalk to /etc/netatalk
  • afpd.conf became afp.conf
  • afp conf is completely different

I basically followed the following sources:
http://netatalk.sourceforge.net/wiki/index.php/Netatalk_3.1.7_SRPM_for_Fedora_and_CentOS
http://netatalk.sourceforge.net/3.1/htmldocs/configuration.html#idp139639181431264

The last service was to setup VirtualBox to run headless for my Windows 7 guest. See VirtualBox installation it wasn’t that difficult.

That’s was pretty much the only things I hit during the “upgrade”. It took a couple days to get everything up and running. I did it one service at a time.

One lesson I learned? Don’t wait so long to update your servers :)

Snow removal

Lot’s of folks complain that the south doesn’t know how to deal with snow. We don’t know how to drive in it. We don’t know how to work in it. We don’t have snow trucks, well not many and most are in the mountains. But we do know how to get rid of the snow, we let the Sun take care of it :)

This morning at 9 am both the front and backyard had plenty of snow covering it.

IMG_20150225_091149

IMG_20150225_091127

By 12:30pm, it was pretty much all gone.

IMG_20150225_123250

IMG_20150225_123227

I think we’re ready for the snow now :) Bring it!

14471503-1424897959-400x300

Deal with git am failures

Today I needed to take my model git branch which was based off of the develop branch a week ago, and rebase it off of the master. First I did the obvious, git rebase master in my model branch, that yielded tons of conflicts. The conflicts were a result of commits in the develop branch being squashed when they got merged to master to keep the history clean. Instead of fixing tons of conflicts, I simply chose to take my 3 commits and create patches from them:

git format-patch -3 HEAD

I created a new branch off of master and applied my patches using git am.

git checkout master
git checkout -b model_updates
git am ~/0001-add-rhev-params-remove-serialized-hash.patch 
git am ~/0002-start-v21-of-deployments.patch
git am ~/0003-rename-columns-and-include-missing-columns.patch

Patch 0001 and ultimately 0003 applied without problems. Patch 0002 on the other hand gave me fits, I expected it, but I refused to recode the change. git am ... just fails when it hits a conflict. Using the trusty Google, I found this blog: Deal with git am failures. I followed the instructions from that blog post:

git am --abort #abort the previously failed 0002 patch run
git apply ~/0002-start-v21-of-deployments.patch --reject # yield .rej files I could inspect
git add server/app/controllers/fusor/api/v2/deployments_controller.rb # ensure changes are fine
git add server/app/controllers/fusor/api/v21/ # new files from patch
git am --resolved # tells git we're good to go, proceed.

Done! Way easier than dealing with the conflicts from the rebase. Easier than trying to recode the patch as well.

Re-run a modified ActiveRecord Migration

Rails has this cool feature called ActiveRecord Migration. It’s an easy way to create and update your database. But if you get it wrong it is super annoying. This is where migrations and me loathe each other.

I had a migration which had the wrong column names. Now I could easily create another migration to change the names, but I’m still developing and I don’t want yet another migration. First thing I did was modified the migration before rolling things back. That is definitely going to fail. SO I reverted my changes.

class AddRhevParams < ActiveRecord::Migration
  def change
    remove_column :fusor_deployments, :rhev_params
    add_column :fusor_deployments, :rhev_hypervisor_host_id, :integer
    add_column :fusor_deployments, :rhev_engine_host_id, :integer
    add_column :fusor_deployments, :rhev_hypervisor, :string
    add_column :fusor_deployments, :rhev_engine, :string
    add_column :fusor_deployments, :rhev_database, :string
    add_column :fusor_deployments, :rhev_cluster, :string
    add_column :fusor_deployments, :rhev_storage, :string
    add_column :fusor_deployments, :rhev_cpu, :string
    add_column :fusor_deployments, :rhev_share, :string
  end
end

First I tried rake db:rollback STEP=1 hoping that it would put the DB in the state prior to my latest migration. For whatever reason it failed with an IrreversableMigration error.

$ rake db:rollback STEP=1
The Apipie cache is turned off. Enable it and run apipie:cache rake task to speed up API calls.
Workaround for RbVmomi may not work as ComputeResource is already loaded: ComputeResource
[deprecated] I18n.enforce_available_locales will default to true in the future. If you really want to skip validation of your locale you can set I18n.enforce_available_locales = fal
se to avoid this message.
==  AddRhevParams: reverting ==================================================
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled:

ActiveRecord::IrreversibleMigration/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration/command_recorder.rb:42:in `block in inverse'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration/command_recorder.rb:40:in `map'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration/command_recorder.rb:40:in `inverse'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:401:in `block (3 levels) in migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:358:in `revert'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:400:in `block (2 levels) in migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:399:in `block in migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/connection_adapters/abstract/connection_pool.rb:129:in `with_connection'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:389:in `migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:528:in `migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:720:in `block (2 levels) in migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:775:in `call'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:775:in `block in ddl_transaction'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/connection_adapters/abstract/database_statements.rb:192:in `transaction'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/transactions.rb:208:in `transaction'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:775:in `ddl_transaction'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:719:in `block in migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:700:in `each'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:700:in `migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:574:in `down'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:656:in `move'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:562:in `rollback'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/railties/databases.rake:276:in `block (2 levels) in '
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/bin/ruby_executable_hooks:15:in `eval'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/bin/ruby_executable_hooks:15:in `'
caused by: (ActiveRecord::IrreversibleMigration) ActiveRecord::IrreversibleMigration
    ... skipped 46 lines
ActiveRecord::IrreversibleMigration: ActiveRecord::IrreversibleMigration
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration/command_recorder.rb:42:in `block in inverse'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration/command_recorder.rb:40:in `map'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration/command_recorder.rb:40:in `inverse'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:401:in `block (3 levels) in migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:358:in `revert'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:400:in `block (2 levels) in migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:399:in `block in migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/connection_adapters/abstract/connection_pool.rb:129:in `with_connection'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:389:in `migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:528:in `migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:720:in `block (2 levels) in migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:775:in `call'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:775:in `block in ddl_transaction'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/connection_adapters/abstract/database_statements.rb:192:in `transaction'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/transactions.rb:208:in `transaction'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:775:in `ddl_transaction'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:719:in `block in migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:700:in `each'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:700:in `migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:574:in `down'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:656:in `move'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:562:in `rollback'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/railties/databases.rake:276:in `block (2 levels) in '
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/bin/ruby_executable_hooks:15:in `eval'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/bin/ruby_executable_hooks:15:in `'
Tasks: TOP => db:rollback
(See full trace by running task with --trace)

Then I tried rake db:migrate:down --trace VERSION= and that failed with the same error.

$ rake db:migrate:down --trace VERSION=20150216190947
** Invoke db:migrate:down (first_time)
** Invoke environment (first_time)
** Execute environment
The Apipie cache is turned off. Enable it and run apipie:cache rake task to speed up API calls.
Workaround for RbVmomi may not work as ComputeResource is already loaded: ComputeResource
[deprecated] I18n.enforce_available_locales will default to true in the future. If you really want to skip validation of your locale you can set I18n.enforce_available_locales = fal
se to avoid this message.
** Invoke db:load_config (first_time)
** Execute db:load_config
** Execute db:migrate:down
==  AddRhevParams: reverting ==================================================
rake aborted!
ActiveRecord::IrreversibleMigration: ActiveRecord::IrreversibleMigration
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration/command_recorder.rb:42:in `block in inverse'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration/command_recorder.rb:40:in `map'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration/command_recorder.rb:40:in `inverse'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:401:in `block (3 levels) in migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:358:in `revert'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:400:in `block (2 levels) in migrate'
/home/vagrant/.rvm/rubies/ruby-1.9.3-p448/lib/ruby/1.9.1/benchmark.rb:280:in `measure'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:399:in `block in migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/connection_adapters/abstract/connection_pool.rb:129:in `with_connection'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:389:in `migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:528:in `migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:679:in `run'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:578:in `run'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/railties/databases.rake:238:in `block (3 levels) in '
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/gems/rake-10.4.2/lib/rake/task.rb:240:in `call'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/gems/rake-10.4.2/lib/rake/task.rb:240:in `block in execute'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/gems/rake-10.4.2/lib/rake/task.rb:235:in `each'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/gems/rake-10.4.2/lib/rake/task.rb:235:in `execute'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/gems/rake-10.4.2/lib/rake/task.rb:179:in `block in invoke_with_call_chain'
/home/vagrant/.rvm/rubies/ruby-1.9.3-p448/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/gems/rake-10.4.2/lib/rake/task.rb:172:in `invoke_with_call_chain'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/gems/rake-10.4.2/lib/rake/task.rb:165:in `invoke'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/gems/rake-10.4.2/lib/rake/application.rb:150:in `invoke_task'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/gems/rake-10.4.2/lib/rake/application.rb:106:in `block (2 levels) in top_level'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/gems/rake-10.4.2/lib/rake/application.rb:106:in `each'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/gems/rake-10.4.2/lib/rake/application.rb:106:in `block in top_level'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/gems/rake-10.4.2/lib/rake/application.rb:115:in `run_with_threads'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/gems/rake-10.4.2/lib/rake/application.rb:100:in `top_level'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/gems/rake-10.4.2/lib/rake/application.rb:78:in `block in run'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/gems/rake-10.4.2/lib/rake/application.rb:176:in `standard_exception_handling'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/gems/rake-10.4.2/lib/rake/application.rb:75:in `run'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/gems/rake-10.4.2/bin/rake:33:in `'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/bin/rake:19:in `load'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/bin/rake:19:in `'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/bin/ruby_executable_hooks:15:in `eval'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/bin/ruby_executable_hooks:15:in `'
Tasks: TOP => db:migrate:down

Doing some googling, I found you can run rails console and run the migrations by hand, see Executing Migration Commands From Rails Console.

I then ran these commands in my rails console:

ActiveRecord::Migration.remove_column :fusor_deployments, :rhev_hypervisor_host_id
ActiveRecord::Migration.remove_column :fusor_deployments, :rhev_engine_host_id
ActiveRecord::Migration.remove_column :fusor_deployments, :rhev_hypervisor
ActiveRecord::Migration.remove_column :fusor_deployments, :rhev_engine
ActiveRecord::Migration.remove_column :fusor_deployments, :rhev_database
ActiveRecord::Migration.remove_column :fusor_deployments, :rhev_cluster
ActiveRecord::Migration.remove_column :fusor_deployments, :rhev_storage
ActiveRecord::Migration.remove_column :fusor_deployments, :rhev_cpu
ActiveRecord::Migration.remove_column :fusor_deployments, :rhev_share
ActiveRecord::Migration.add_column :fusor_deployments, :rhev_params, :text

Then I went into the database and deleted the reference to my migration from the schema_migrations.

=# delete from schema_migrations where version = '20150216190947';

That cleaned up the migration and I was able to rerun using rake db:migrate

class AddRhevParams < ActiveRecord::Migration
  def change
    remove_column :fusor_deployments, :rhev_params
    add_column :fusor_deployments, :rhev_hypervisor_host_id, :integer
    add_column :fusor_deployments, :rhev_engine_host_id, :integer
    add_column :fusor_deployments, :rhev_hypervisor_hostname, :string
    add_column :fusor_deployments, :rhev_engine_hostname, :string
    add_column :fusor_deployments, :rhev_database_name, :string
    add_column :fusor_deployments, :rhev_cluster_name, :string
    add_column :fusor_deployments, :rhev_storage_name, :string
    add_column :fusor_deployments, :rhev_storage_type, :string
    add_column :fusor_deployments, :rhev_storage_address, :string
    add_column :fusor_deployments, :rhev_cpu_type, :string
    add_column :fusor_deployments, :rhev_share_path, :string
  end
end

So if you have trouble rolling things back automatically, you can try using rails console and mucking with the schema_migrations database table.