Fedora 17 Upgrade

So, to upgrade, rather than downloading a DVD image to a USB or disc and installing/upgrading from there, and instead of using the system updater (yum) to update OS versions like I do regular applications, I use pre-upgrade.  It purportedly offers you the complete experience that downloading an image does without any of the physical media woes.  Yay!



It has a few stages.  First, it downloads all the packages you'll need to your local machine for the upgrade (from Fedora 16 to 17 this time) and then it asks you to restart.  You then restart into a preupgrade mode which is a minimal system that runs an installer that updates your system.  It's great.



My first problem is this:

Key phrases being "An unhandled exception has occurred", "device has not been created", and "non-existent 0MB storage" with some UUID string.  I assure you, doctor, my devices exist and are relatively healthy.



It seems to be documented well by bug 823048.  I will try to fix that and then update you on my next problem. :)



UPDATE:

Bug 825500 ended up helping me resolve my bug.  There was an older root partition that wasn't being used that came first on my hard disk and Preupgrade was finding that instead of my active one.  Once I deleted that volume (using system-tool-lvm) Preupgrade + Anaconda proceeded perfectly smoothly. :)

GXml: bringing Serialisation for GSOC 2012

Hello there.  Here is a quick post because I haven't posted yet, but I am still a bit busy this week.



For GSOC 2012, we're adding XML serialisation of GObjects to GXml!  Whee!  For details, here is the proposal.  I'm happy to be working with my mentor from last year, Alberto Ruiz, again.



Since last summer, the amazing Daniel Espinosa Ortiz added autotools and useful GObject Introspection support.  Hooray!  Sadly, WAF support has languished a little and so have the tests.  My inadequate attempt to push libxml2 vala binding changes upstream also didn't go far, as most of my time went towards my Masters (two semesters to go!).  I'm pleased to be a part of the 2012 Google Summer of Code and grateful for the opportunity to focus time this summer on GXml again (rather than taking another unrelated (albeit exciting) Teaching Assistant position :D). 



So far, I've been

• investigating other serialisation libraries, such as Java's serialisable interface, XStream, JsonGlib, .NET's XML serialisation, and Buzztard's BtPersistence.  I'm grateful to Emmanuele Bassi for answering questions about JsonGlib so far. 


• fixing bitrot: I got waf working again, have the tests working again, and have addressed feedback on the vala libxml2 binding patch I originally submitted (and am making better progress now with it split up as a series of patches, thanks to reviews by the timely Evan Nemerson :D).  Relevant bug numbers filed today include 677375, 677374, 677359, 677355, 677354 if anyone's interested.


• playing with serialisation.  Part of my thesis wants it, so I have a prototype with that, and I have a quick prototype trying to use JsonGlib's approach, but with XML.  This is just for self-educational purpose.

Coming up, an actual design needs to be agreed upon and plans on integrating the new functionality with other people.  Whee! 

Firefox 8: Faster, by delaying tab loading

Short version: Preferences -> General -> "Don't load tabs until selected", now you can have hundreds of tabs "open" without slowing down your computer.

I like to keep many tabs "open" in Firefox.  I use a tree-based tab manager (Tree Style Tab view) that lets me build collapsible trees of tabs, built around a common theme.  Yay.  But having a tab open takes up memory and sometimes CPU (with Javascript in the background).  Bookmarks don't work for me, because they're an extra layer of management and "out of sight-out of mind" applies.  I just bookmark and forget forever, so instead I leave the tabs open until I have time to deal with each one.  Some are open forever, for good reason.



I used to use an extension called BarTab, which would allow me to delay the loading of a tab until I actually clicked it to visit it.  So, when I'd start my browser and it would restore all my tabs from my last sessions, they wouldn't load and thus save me a lot of memory.  Once I clicked on a tab, the page would actually load.  This was wonderful, but BarTab hasn't officially supported a version of Firefox since 3.x, and today we're on 8.  (I've been editing the extension to alter the version it supports, but that's fragile and not a good long term solution.)



Good news though!  Firefox 8 now supports on-demand tab loading!  I would post screenshots, but my interface is in German, so just follow these instructions if you need detail.  Elsewise, just go to Preferences, General, and with "restore tabs from last session" selected as your default home page, check the "Don't load tabs until selected" box.  Yay!

Fedora 16: Nice new features

Deliciously in Deutsch

Tablet support

One of my favourite new features in Fedora 16 and GNOME 3.2 is improved tablet support, complete with some programmability, under the System Settings menu.  There are more features to support, but at least the basic ones don't require text file editing anymore. :)



On-screen keyboard

There is even a nice on-screen keyboard under the accessibility menu, which is great if you have touch on your tablet PC.  :)  It even hides neatly in the notification tray.



Online accounts and privacy concerns

Something I'm wary of is the new Online Accounts manager, found in the user menu (top right).  Basically, you can log in once with GNOME to a web service provider like Google and it will share access to applications that request it.  A bit simpler than giving your login credentials to a dozen different programmes.  A bit safer in that respect.



But then there doesn't seem to be a facility to control which applications have access to that. I'd like to log in through GNOME, and then give permission to Evolution to just access my E-mail and Calendar, and give permission to Empathy to just access my contacts.  Perhaps this is restricted, and I have to find out before I use it, because I don't want just any application to go accessing my private data.

Fedora 16: "Oh no!" failure at log in (solution within)

I've just upgraded to Fedora 16, and it was an almost perfect upgrade except for one ugly problem.


Unlike my upgrade to Fedora 16 Beta, this upgrade of packages went well.  I used the preupgrade tool to download all the packages and let them update after a reboot: almost no input required.  However, when I went to log in to my system, I saw a useless error message:

"Oh no!  Something has gone wrong."

It then asks me to log out.  I quickly realised that nothing really seemed wrong.  I clicked on the full-screen error message and pressed alt-F4 to close it and continue working.  I didn't want to deal with this every time, so I figured out the source (method documented below):



The culprit is installed colour profiles from Fedora 15 causing a key component to crash invisibly in the background due to security policy issues.  Ugh.



Solution

On a terminal,

restorecon -r ~/.local/share/icc 

An idea situation would be to have random ICC colour profiles not cause this.



Problem Solving Method

• test a fresh account: does it have the problem?  No, so it must be my user's configuration.


• back up my configuration and then try resetting various parts to default until I can find the source of the problem.   


• With .config and .gnome2 reset, the problem persisted, so it must be something else


• Try resetting all configuration directories (/home/user/.somecfgdirname)




• alright, that worked, so it is in one of the . directories.




• I have 189 of them, so bisect my original configuration to narrow down its location




• Alright, a-m reset resolves the problem, so it's in there




• A quick scan and I see .local which seems relevant, as lots of applications store information in there.




• Testing my original configuration without my .local resolves the problem. 


• I don't want to get rid of everything in my .local




• Try removing .local/lib: problem still there


• Try removing .local/share: problem fixed


• Alright, which application is storing problematic files in .local/share?




• bisect again, it's in a-m


• bisect again, it's in h-m


• take a look, and icc, the colour profile configuration seems like a possible candidate




• Reset icc and bingo!  

Then feel stupid because I actually read about this very problem in Fedora 16's common bugs page (it's a wiki that has things added with work arounds until they are resolved).   However, I didn't think it was my problem because there it says that GNOME Shell fails, and I unfortunately knew that my GNOME Shell was still running, but just giving me an error message inexplicably. 



From the Fedora Project's common bugs page:

Starting GNOME Shell fails after upgrade from Fedora 15 with color profile installed

link to this item - Bugzilla: #741549


If you used the gnome-color-manager
tool to install a color profile for any of your hardware in Fedora 15,
then after upgrading to Fedora 16, you may not be able to log in to
GNOME Shell with SELinux enabled. Login will fail with the "Oh no!
Something has gone wrong" error screen that GNOME pops up if a component
is crashing repeatedly.



The issue is caused by gnome-settings-daemon
crashing when it encounters a color profile with an incorrect SELinux
context: the correct context for color profiles changed between Fedora
15 and Fedora 16, but the upgrade process does not re-label existing
profiles.




To resolve the issue, boot to a different desktop or to a console and run the command restorecon -r ~/.local/share/icc. After doing this, GNOME login should work correctly.

Problem solving



I like hunting and solving problems.   I like narrowing down causes, and combining bisection with intuition and existing knowledge to understand the source of such things.



Sadly, many users don't have the same knowledge.  They might not know where to start.  My Fedora 16 Beta installation problem, where it trashed my system partition, was potentially catastrophic but ultimately not a big deal because I could handle myself.  This ICC colour profile permissions problem is relatively simple, but thanks to an oblique error message, what could a "normal" user do?  It's stuff like this that prevents me from recommending an otherwise wonderful system to my friends.  I fear the problem is systemic.

Error: Protected multilib versions

As noted in a previous post, I had to restore the root portion of my system after a failed attempt to upgrade to F16 Beta.  I'm now reinstalling some software I use, and was trying to install gtk3-devel so I can continue working on GXml this weekend.

I encountered this error message:

"Error: Protected multilib versions: libXi-1.4.3-2.fc15.i686 != libXi-1.4.3-3.fc15.x86_64"





One of the first Google search results is on Fedora Forum, titled "[SOLVED] Issues installing wine (FC15) - FedoraForum.org".  Sadly, the solutions that worked for others didn't apply to me.  Instead, my problem results because, for some reason, after installing from the live USB key, the two software repositories that Fedora was looking for software in were "fedora" and "updates-testing" rather than "fedora" and "updates".  I switched it to the latter two, but now I have some packages installed from "updates-testing" that are too new. 





I realised this when I re-read the message and realised that they were different version numbers, and that the latest one wasn't in "updates".  So, I downgraded it with





# yum downgrade libXi





Yay!

Catastrophic failures while upgrading to beta releases

GNOME 3.2 was released last month, for which I attended a release party and met cool people.  I've wanted to upgrade to it from GNOME 3.0 for a little while, but I use Fedora and Fedora's next release including GNOME 3.2 comes out on November 8th.  Obviously, I'm not that patient.



One way I could start using GNOME 3.2 would be to build it locally using jhbuild.  That might be fun, but I'd like to ensure that the surrounding distribution played well with it, so my intent had been to upgrade to a Fedora 16 Beta.  A beta release: what could go wrong?  I mean, it's not an alpha!  For the record, I usually wait until one of the release candidates comes out before prematurely upgrading to a new Fedora.  On the weekend, I used preupgrade with a Fedora 15 installation on a tablet to successfully upgrade to Fedora 16 Beta.  (Yay for an on-screen keyboard, though I have to file bugs for when using it eventually prevents mouse clicks somehow?)  So, I thought upgrading on my main laptop should go just as smoothly!

Basically says there was a catastrophic failure and installation can't continue

So yah, one of the core packages, util-linux, failed to upgrade, and the installer could not roll back, and my hybrid Fedora installation could not boot afterwards, stuck in its half-upgraded, inconsistent state.  OH NO.



How I've avoided disaster

1. backed up: All my personal data is backed up regularly, even in another city.  Two back-ups, different locations, and backed up before trying the upgrade.  Phew.


2. separate system and data partitions: My personal data is on a separate partition.  On a 500GB HD, I had half for the system (of which only 12GB were actually used) and half for my personal data (of which about 100GB is in use).  This would let me re-install my system without reformatting everything and losing my personal data. 


3. recovery live USB key: I have a nifty Live USB key with Fedora 15 on it that my laptop can boot from, so I can still access my files and use my computer.


4. creating redundant system partitions:
   
   
   
   • I don't actually want to get rid of my old system set-up: if possible, I want to figure out what went wrong, and I want to have access to the list of packages I previously had installed so I can let them reinstall overnight, so I can use resize2fs and lvreduce to first resize the system's file system down to something petite (25GB), resize the partition (logical volume in my case) down to the size of the file system it holds, and then create a new system partition with the left over space (actually, I just used another 25GB for that).
   
   
   • Now I have one large partition with personal data (which is safe), and
     two smaller partitions for system installations: I can actually install
     two systems and switch between them if I like (dual-boot between two
     Fedora Linux installations? :D).  I'll keep this layout for a while, so
     if things go wrong in future upgrades, I'll always have a safe
     installation to boot from without needing a Live USB key.
   
   
   
   

If you have any advice or tips of your own for recovering from system upgrades gone awry, please share :D