October 12th, 2012

Patching a non-syncing RAID 1

I have yet to figure out why, but today one of my hard drives hit multiple CRC errors and went offline. It is part of a software (mdraid) RAID 1 and I had seen such errors before, so I did the usual procedure: Shutdown and power off for a few minutes, check that all drives come up on boot, boot to a rescue system, stop RAIDs, run a long self-test on the lost drive and then resync the RAID by running mdadm --add using the drive that remained online as source. Sounds okay? Too bad I had errors on the source drive…

When the first RAID partition’s resync neared completion around 95%, it suddenly stopped and marked the target drive as spare again. I wondered what happened and looked at the kernel log which told me that there have been many failed retries to read a particular sector which made the resync impossible to complete. Plus, S.M.A.R.T. now listed one “Current Pending Sector”.

What could I have done to avoid this?

First of all, I should have run check/repair more regularly. If a check is being run, uncorrectable read errors can be noticed and the failed sectors can be re-written from a good disk. However, check/repair can be a rather lengthy task which means it is not very suited to desktop computers that are not running 24/7.

Another option could have been to use --re-add instead of --add, which might have synced only recently modified sectors, thus skipping the bad one I hit on the full resync caused by --add. However, since I had my system in use about one hour before I noticed the emails indicating RAID failure, I doubt this could have helped much. Plus, it would likely have been too late to run that after a resync has already tried and failed as the data on the lost disk was already partially overwritten.

What I did to work around the issue

WARNING!

The following steps can cause irreparable damage to your data. Only continue if you fully understand what you are doing and you either have a working backup or can avoid loosing the data. This post is omitting information you should know if you are going to follow these steps. Please make your own mind about them before running any commands.

THE AUTHOR WILL NOT BE HELD LIABLE FOR ANY DAMAGE CAUSED BY FOLLOWING THE BELOW STEPS. FOLLOWING THIS BLOG POST IS ON YOUR OWN RISK.

NOTE: The failed sector will be called 12345 from now on. The broken sector resides on /dev/sdb and the drive that went offline and has a partial resync but good sector is /dev/sdc.

A quick search turned up some helpful sites ([1], [2]). First, I verified that I had the correct sector address by running hdparm --read-sector 12345 /dev/sdb, which returned an I/O error just as expected. I then checked the sectors immediately before and after the failed one. I was lucky to find a strangely uniform pattern that simply counted up – I’m not sure if that is some feature of either ext4 or mdraid or just random luck. I tried to ask debugfs what’s stored there (could have been free space, as in [2]) but I wasn’t sure if I had the correct ext4 block number, so I didn’t give anything on that information.

Since this is a RAID 1, I thought, maybe I could just selectively copy the sector over from /dev/sdc. What I needed to do was to get the correct sector address for sdc and then run some dd command. Since the partition layouts differ on sdb and sdc, the sector numbers don’t match 1:1 and have to be calculated. I ran parted and set unit s to get sector addresses, then ran print to get the partition tables of both disks. All that has to be done is subtracting the start offset from the failed sector address, then add the other partition’s offset again. Let’s say the address was 23456.

Since I knew what the sector should look like, I could verify it directly with hdparm. Additionally, I checked a few sectors below and above that address and the data matched perfectly.

Next, I had to assemble a dd command to display and then copy the sector. Using dd if=/dev/sdc bs=512 count=1 skip=23456 | hexdump (bs should match the logical sector size) and comparing it to the hdparm output, I could verify that I read the correct sector. I also tried a few sectors above/below again. When I was ready, I finally copied the sector: dd if=/dev/sdGOOD of=/dev/sdBAD bs=512 count=1 skip=23456 seek=12345 oflag=direct (replace sdGOOD and sdBAD by the actual drives – just making this post copy&paste-proof :) ) oflag=direct is required or you will likely get an I/O error.

To be sure that everything went fine, I checked the result with hdparm again. After restarting the RAID, the resync ran fine this time.

January 15th, 2012

Reconstructing directory modification times

I’m currently migrating large parts of a Windows NTFS partition to Ext4 on my desktop system and accidentally messed the modification times of all directories I moved with Dolphin (KDE) by aborting the operation and restarting it over the already created directories from the first run. I decided to hack a small script to reconstruct the modification times (getting close to the original ones). It works by recursively finding the latest, deepest nested file modification time for a directory (as those have been copied correctly) and using touch to set the same timestamp on the target directory. I would advise to call it with find on the directories it should operate on, for example if it has been saved as ~/fix-copied-dirtimes.sh:

find first/ second/ -type d -not -empty -exec ~/fix-copied-dirtimes.sh \{\} \;

It is by far not optimized (being called this way will perform highly redundant queries on the file system) but it works very fast nevertheless and you usually don’t run it frequently, so that’s okay…

A little word of warning: Verify the correct behaviour on your own! That means: Please manually confirm that all calls performed by this script and method turn up with the correct result. This comes without any warranty and although touch shouldn’t do any more than changing timestamps you never know… ;) So… do your checks please and try it on some unimportant test directories first.


#!/bin/bash
# sets one directory modification time according to its latest file modification time (searched recursively)

DIR=$1
LATESTDATE=`find "$DIR" -type f -printf '%TY%Tm%Td%TH%TM.%TS\n' | sort -n | tail -n1 | cut -c-15`

if [ $LATESTDATE ]
then
        touch -m -t "$LATESTDATE" "$DIR"
fi
September 20th, 2011

Akamai CDN and public DNS resolvers

In the past months I experienced random irresponsiveness of several websites such as Facebook, Netvibes, Microsoft, wetteronline.de (a German weather site), just to name a few. All those sites have one thing in common: they use (complete or partly) Akamai as a CDN. Traceroutes show that I end up in Amsterdam, being blocked behind xe-2-0-0.ams21.ip4.tinet.net or xe-3-0-0.ams21.ip4.tinet.net. Letting my router “redial” to get another IP address does not work, after a few days the problem usually disappears again. In the meantime, I helped by using Opera Turbo as a proxy to access those sites.

Yesterday, the problems started again. Having done some traceroutes and confirmed that there were again unreachable Akamai hosts in Amsterdam, I decided to open a trouble ticket at my ISP. Just before I was about to send it, I tried from another computer on our home network, just to be sure. Strangely, all websites worked well. A traceroute ended in what seems to be a colocation of Akamai at our ISP’s data center in Hamburg. Then I remembered that I had my desktop set up to use OpenDNS. I ran dig +trace on the domains and confirmed that if Akamai is queried directly, it points me to Hamburg, not Amsterdam. After changing the nameservers back to my ISP’s, I could access all sites again.

The basic problem with public DNS services such as OpenDNS or Google (the famous, easy to remember, 8.8.8.8 and 8.8.4.4) not being able to provide the geo-location-based DNS resolution in the way CDNs require it for their load balancing and low latency is nothing new. If you search for opendns akamai you will find a lot of forum posts, blogs and articles about it. Under the title “In a CDN’d world, OpenDNS is the enemy!” Sajal Kayan made a nice comparison matrix of how latency is affected by using OpenDNS and Google to resolve the Akamai CDN. What was new to me was that in my case Akamai or some hop close to it seems to take active counter-measures to avoid the (really so large?) extra traffic that should be directed elsewhere if DNS resolution works as intended and goes even as far as to block one of Germany’s largest ISPs whose customers I would not suspect to use external DNS resolvers in so large numbers that it seriously impacts CDNs. I don’t intend to point fingers to either CDNs or public DNS resolvers on this issue since both sides have their points for working the way they do and there won’t be any practical solution to this situation other than to avoid the problem from a user perspective by using local resolvers.

So, bottom line: If you have trouble reaching popular websites and use OpenDNS or Google DNS, try again with local nameservers and if the public DNS resolver was causing the problem, resort to a local resolver instead.

May 22nd, 2011

Java: Deployment issues

Being new to developing Java web applications using a lot of dependencies, I encountered a few issues when deploying an update onto our Geronimo app server. Since some were hard to find solutions for, I decided to write them down in this blog post. I didn’t have any of these issues while running the application for development by mvn jetty:run (even on the same machine as Geronimo).

  1. Doubled dependencies
    We use Quartz Scheduler in our application while Geronimo itself also uses Quartz (however, in an older version). That resulted in a module conflict indicated by an IncompatibleClassChangeError since both libraries can not be loaded at the same time within the same classloader. The solution to this was rather simple: all that was necessary is adding <inverse-classloading /> to the deployment plan (which may better be placed in a separate directory so you can easily switch between multiple deployment targets). If our application was using Quartz 1.6 (the version Geronimo is using) I might have simply added a dependency to my deployment plan and could have shared the classes.
  2. Missing XML implementation
    Our application also writes PDFs using the Apache XSL-FO processor. For a reason I still don’t understand, there appeared to be only stubs available but no implementations although it worked happily with apparently the same configuration on the same machine when run from mvn jetty:run instead of Geronimo. The message I got was something like “org.apache.xerces.jaxp.SAXParserFactoryImpl not found”. After a lot of search and failed tries I figured out that I simply had to add xerces/xercesImpl as a dependency. Another option may have been to dig deeper into property handling and figure out how to properly solve the problem by specifying an existing implementation as suggested on an older StackOverflow question. (however I’m unsure if that really was the problem as it appeared that the classes were missing but the class name was correct and it worked fine from command line so the classes – to my understanding – should have been available through the default class loader)
  3. LinkageError
    The last problem I had to deal with took me much longer to figure out. Take a look at this part of a stack trace:

    
    Caused by: java.lang.LinkageError: loader constraint violation: when resolving method "javax.imageio.metadata.IIOMetadata.getAsTree(Ljava/lang/String;)Lorg/w3c/dom/Node;" the class loader (instance of org/apache/geronimo/kernel/config/MultiParentClassLoader) of the current class, org/apache/xmlgraphics/image/loader/impl/imageio/ImageIOUtil, and the class loader (instance of <bootloader>) for resolved class, javax/imageio/metadata/IIOMetadata, have different Class objects for the type org/w3c/dom/Node used in the signature
    	at org.apache.xmlgraphics.image.loader.impl.imageio.ImageIOUtil.extractResolution(ImageIOUtil.java:54)
    	at org.apache.xmlgraphics.image.loader.impl.imageio.PreloaderImageIO.preloadImage(PreloaderImageIO.java:101)
    	at org.apache.xmlgraphics.image.loader.ImageManager.preloadImage(ImageManager.java:175)
    	at org.apache.xmlgraphics.image.loader.cache.ImageCache.needImageInfo(ImageCache.java:128)
    	at org.apache.xmlgraphics.image.loader.ImageManager.getImageInfo(ImageManager.java:122)
    	at org.apache.fop.fo.flow.ExternalGraphic.bind(ExternalGraphic.java:81)
    	at org.apache.fop.fo.FObj.processNode(FObj.java:123)
    	at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:282)
    	at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:171)
    	at org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1020)
    	at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
    	at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
    	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
    	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
    	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
    	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
    	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
    	at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
    	at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:432)
    

    Let’s take a step back from that clutter of information, take a deep breath and examine the top-most sentence a bit closer:

    • we have some sort of class loader conflict
    • the method getAsTree in class javax.imageio.metadata.IIOMetadata refers to org.w3c.dom.Node
    • the class loader we are coming from is “MultiParentClassLoader”, provided by Geronimo
    • we come from org.apache.xmlgraphics.image.loader.impl.imageio.ImageIOUtil
    • the class loader being used by the method we try to call is called “bootloader”
    • the access to “bootloader” originates from javax.imageio.metadata.IIOMetadata
    • both class loaders link to incompatible and thus conflicting signatures of org.w3c.dom.Node, so we cannot continue

    Let’s interpret these facts: org.apache.xmlgraphics..ImageIOUtil calls a method from javax.imageio.metadata.IIOMetadata. We have at least two class loaders that have different understandings of what org.w3c.dom.Node should look like and both classes we access are using a different one of these signatures. Apparently the javax packages are provided by the JDK and are being used by xmlgraphics, so our dependency of xmlgraphics appears to be incompatible with the JDK we are running. We are confident that both the JDK and xmlgraphics are up-to-date, so what next?

    I searched for over an hour and couldn’t find anything relevant except some voodoo stuff. At first I tried to hide classes by adding a filter in the deployment plan; then I tried to enforce one specific version by adding a direct dependency to org.w3c.dom. It was a bug report saying something like “strange, org.w3c.dom hasn’t been touched for years” plus another report saying “use xml-apis-1.3.04″ that got me on the right track: Today’s Java versions seem to ship with at least some org.w3c.dom classes. However, Maven pulled xml-apis as a dependency nevertheless which includes its own versions of org.w3c packages but doesn’t seem to be a problem unless deployed to the app server. Maybe that’s a side-effect of the inverse classloading we enabled to get Quartz running. The solution was to simply exclude that dependency in the pom file. If you are using NetBeans you can simply right-click xml-apis and select “Exclude Dependency” which will automatically add

    
                <exclusions>
                    <exclusion>
                        <artifactId>xml-apis</artifactId>
                        <groupId>xml-apis</groupId>
                    </exclusion>
                </exclusions>
    

    to all relevant dependency definitions (in my case xerces/xercesImpl and org.apache.xmlgraphics/fop).

March 29th, 2011

wine caching Temporary Internet Files indefinitely

Taking a look at where my disk space went, I was quite surprised to find 11GiB in a directory at ~/.wine/drive_c/windows/profiles/username/Local Settings/Temporary Internet Files/Content.IE5/

It appears that this is an already reported issue with wine, as downloads made through calls to wininet.dll are supposed to be deleted by Windows sooner or later. As wine caches its downloads the same way but without ever removing old files, everything ever downloaded through wine’s wininet.dll currently gets cached indefinitely. To work around that problem, it’s currently necessary to clear that folder once in a while (or to automate that on reboots or similar). Simply deleting that directory should work just fine as it is supposed to be created automatically if needed.

It’s probably best to also search for other temp directories inside ~/.wine from time to time. Apart from cached downloads I could free another 6GiB of unnecessarily wasted space at the usual locations. It’s easy to forget about “C:” when running wine… :)

August 3rd, 2010

LauncherPro expired

When I decided to try a custom ROM for my HTC Hero about one and a half months ago (official ROMs are still stuck at Android 1.5…) I chose to set LauncherPro as my default launcher which came preinstalled with the ROM. A few minutes ago I started to get a popup notice telling me “This version of LauncherPro has expired.” Nice to know (why does it expire anyway?!), but unfortunately it effectively locked me out from my phone: I was unable to switch back anywhere I could have done something useful (like opening a browser or the app drawer or switching back to a different launcher). To unlock the phone again, I was forced to install the recent version from their homepage. Luckily, I had USB debugging already turned on (else I would have been lucky if I could have got into the settings to activate it) and was at home where I have the Android SDK installed. After downloading the latest version, all I had to do was plugging the phone into a USB port and run: (-r is important or installation fails with “INSTALL_FAILED_ALREADY_EXISTS”)

adb install -r LauncherPro-0.7.1.0.apk

After a few seconds the install completed and after disconnecting the phone from USB I got the app chooser where I could re-select LauncherPro. A few moments later it finished reloading all widgets and the phone worked as always.

While I really like LauncherPro and would consider buying it, this incident scared me: I may have been able to get to the Market using the “back” button to download an update (had it open sometime yesterday) but imagine not being able to get there from the phone itself while being nowhere near a computer or with USB debugging turned off – I usually disable it and only had it turned on because I forgot that last week. There’s at least one guy at their forums who has USB debugging disabled. The developer apologizes in that thread but having had that unexpected sudden (remote?) deactivation, I wonder what else LauncherPro may do.

May 24th, 2010

Getting fed up with HTC’s non-existent maintenance…

I bought a HTC Hero last year in September and was quite happy with it. HTC’s custom Sense UI looked far better than the default Android UI. It also shipped with better applications, less Google bundling and pioneered some basic multitouch support (only in the browser and the photo app) and integration with Flickr, Facebook and Twitter.

Sense’s initial release was very sluggish (see older reviews on YouTube) but has just become fixed when I ordered my phone. After that, there was one more update in November without information on what has been fixed with it. Since it required yet another wipe and was still Android 1.5 (Codename Cupcake) and everything worked fine for me so far, I decided not to install it.

It’s the end of May now, 6 months since that last update, 8 months since the UI fix and when I got my phone. Android 1.6 (Donut) was released the day after I bought my phone, providing new features such as VPN connections, text-to-speech support, a new market application and multiple screen resolutions. I would call the last feature the most important one since newer devices required it and soon applications started requiring that API, resulting in older Android versions not being able to run them (they are simply hidden from the market). In preparation of the Droid release in November Android 2.0 (Eclair) was released just one month later, along with support for newer hardware (camera flash, OpenGL 2.0 ES) it also added more Bluetooth profiles (up to that point Android phones could only interact with headsets) and a better Bluetooth API as well as Google Voice Search among others. If I remember correctly, this was mainly used by the Droid and no other phone at that time. It was Android 2.1 (also Eclair) that shipped these new features to phones from other manufacturers since January but not without adding some more features such as live wallpapers. HTC said they would skip 1.6 and go directly to 2.0/2.1 for the Hero. Android 2.1’s release date was timed with the release of Nexus One which was manufactured by HTC. Last week, Android 2.2 (Froyo = Frozen yogurt) was released, bringing (among others) WiFi and USB tethering without the need of rooting your device.

Sprint released a 2.1 update for their customized Hero last week, one week after another customized revision called “Droid Eris” got the update. Hero owners using the plain GSM phones (in contrast to CDMA by US operators) are still waiting in vain for a release. There were multiple release dates, both rumored and official, each cancelled a few days before or simply missed. According to phandroid.com HTC now has yet another release date for us: A first preliminary update should roll out someday in June and the final 2.1 update should follow “a couple of weeks later” which could easily mean July or August regarding their previously announced dates. HTC also said, that 2.2 would come to all phones released in 2010 – that excludes the Hero for now…

Actually, Google released Android 1.6, 2.0 and 2.1 much too fast for any manufacturer to keep up with in time, that’s true. Also, HTC’s custom UI called Sense has to be ported to each Android revision they release an update for. But HTC already released a phone running Sense on 1.6. So assuming, they stopped support for Sense@1.5 at latest in November, they now had 6 months to tinker at ports to newer Android versions and prepare an update for the Hero. And they did: Not only did Droid Eris and Sprint Hero get an update in the past weeks, they also released a lot of phones previously, developing even more. All have similar hardware and starting from the Hero all of their Android phones have Sense UI.

So why didn’t HTC release any 2.1 update for the Hero yet? Considering that at least the Sprint Hero could have had its update so “soon” only because the network operator Sprint may have built its own release, I’ve got the notion that HTC is building throw-away phones: If one gets outdated, just dispose it and buy a new one; maintenance will only run for a few months and then suddenly stops. This may have worked for conventional phones in the past but since smartphones run on a common operating system that is often maintained by another company, that’s the completely wrong path to keep the Android platform healthy and customers as well as developers satisfied. By healthy I mean that a device should usually support all public API levels until the hardware becomes insufficient which shouldn’t be that much of a problem with smartphones which are nothing but PDAs with a cellular radio chip. However, since Android is open source and modifications to the Linux kernel have to be published under GPL, Android phones should be open to custom upgrades and so is the HTC Hero.

Unfortunately I’m legally unable to link or name any of the custom ROMs I’ve found but if you do a standard Google search you will most likely find them quite easily. They either run the plain Android system or incorporate (pirated) copies of Sense UI from leaked or previously released images. Since I’m not the only one who is sick of HTC’s poor excuses, there seems to exist a variety of ROMs specifically targeting the Hero. Reading into what’s necessary to get an update, I’ve found out that HTC is actually making it difficult to flash an inofficial ROM onto the phone. This involves unlocking a special diagnosis mode and signed files; things I would not have expected at all from a badly maintained open source based phone! Although I didn’t try it myself, it seems like even versions containing ripped Sense binaries run surprisingly fine (with some minor bugs and inconveniences) on the Hero, so the question remains: Why does HTC delay updates if a community of a few unrelated developers is able to build almost completely working releases?

To make things worse, it seems like at least a few released 2.1 images introduced a jail lock that appears to not have been broken completely yet. So you are strongly advised to check the news on this topic before installing any official HTC updates from now on or you may not be able to ever go further than Android 2.1.

Why does this happen? What are they thinking? I start to regret having bought my Hero with the wrong expectation to have a modifiable phone that doesn’t outdate for a few years due to an evolving open source operating system. All I can do now is to warn other people from buying HTC’s phones without prior investigation of possible issues. While other Android phones may also be several months late lagging behind Google’s SDK releases, that may be excusable up to some point (especially since Google sprinted ahead with their releases since 1.6). The day the Hero finally receives its 2.1 update, other phones will already get their updates to 2.2 and I doubt HTC will continue to update the Hero further. Since a jail lock may be introduced to the normal Hero by the preliminary update in June I would strongly advise considering either getting a custom ROM instead or live with 1.5 and wait for more information (is HTC serious about 2.1 and will the Hero get 2.2?). Once you installed that update you may not be able to go further without buying a new phone although the hardware would be capable of it. All I know for sure is that I won’t buy another HTC phone in near future.

As of May 17, Android currently has an almost equally distributed version fragmentation across 1.5, 1.6 and 2.1. In the advent of 2.2 and the final updates to 2.1 I would expect that we are one or two months from finally calling 1.5 (the third API level) “legacy”. This means that the number of devices running 1.5 will drop significantly low and therefore less and less applications will run on 1.5 due to API updates more current applications may prefer to use (with Android 2.2 we have reached API level 8). The 34,1% share of Android 1.5 may in fact contain a large percentage of Heros since almost every other phone has had updates and the Hero sold pretty well. Developers have or will have to choose whether they want to maintain a legacy “Hero revision” of their software or not. Thus by holding back OS updates, HTC is not only upsetting its customers but is annoying developers as well, so its highly unlikely they will support a 10% or less share of 1.5 users. Running out on updates in less than one year isn’t what Android was meant to be nor what I would expect from a 400€ device.

April 22nd, 2010

Opera 10.52 Alpha

Wie schon im März und Juni 2009 konnte ich es wiedermal nicht lassen, Opera 10.52 Build 6321 auf PeaceKeeper laufen zu lassen. Die Bedingungen seit dem letzten Test haben sich nicht wirklich geändert, inzwischen läuft KDE 4.3, sonst blieb alles beim Alten (Gentoo Linux, Core2Duo 3,0 GHz, 4GB RAM). Das Ergebnis kann sich sehen lassen; zum Vergleich reihe ich es mal in meine bisherigen Ergebnisse ein:

581 Punkte Opera 9.64
1853 Punkte Opera 10 Beta 1 (Compositing aktiv)
2047 Punkte Opera 10 Beta 1 (Compositing abgeschaltet)
5883 Punkte Opera 10.52 Build 6321 (Alpha; kein Unterschied beim Compositing)

Opera 10 Final und 10.10 hatte ich auch vor längerem getestet, allerdings gab es vermutlich keinen allzu hohen Unterschied, da ich mir das Ergebnis nirgendwo abgespeichert habe. Laut Peacekeeper ist momentan übrigens der höchste Benchmark-Wert mit 14274 Punkte ein Opera 10.52 unter Windows auf einem i7-920.

Von der hervorragenden Performance mal abgesehen (macht sich nicht nur in den Benchmarks bemerkbar), hat Opera 10.52 unter Linux leider noch seine Macken. Zunächst verschwanden meine Schrifteinstellungen. Danach durfte ich feststellen, dass die Schrift irgendwie “anders” aussieht, auf einigen Webseiten (wie z.B. Heise) absolut schlecht. Das Problem ist offiziell bekannt und daher hatte ich auch so lange gezögert, die Alpha auszuprobieren, allerdings hab ich nach dem Anblick der Roadmap entschieden, dass ich doch keine Lust mehr habe, noch länger zu warten – die Beta rückt laut Roadmap näher (Mitte April, also eigentlich schon fast eher gestern als heute) aber das Release soll erst Ende Mai erfolgen. Der Hintergrund ist, dass Opera nach seiner Beschwerde über Microsoft tatsache den sog. Ballot Screen zugestanden bekam, der dann direkt nach seiner Einführung im März einen heftigen Download-Zuwachs für Opera zur Folge hatte. Opera wollte darum die Windows-Version so schnell wie möglich fertig bekommen und hat scheinbar alle verfügbaren Resourcen darauf gebündelt, weshalb der sonst recht synchrone Release-Plan vorübergehend auf die Reihenfolge Windows-Mac-Linux überging und nun erst langsam wieder angeglichen wird.

January 24th, 2010

KDE 4.3 upgrade and Cashew

I reinstalled KDE for an upgrade from 4.2 to 4.3 (doesn’t seem to work without uninstalling on Gentoo; no idea why) and ran into some problems afterwards.

reinstalling KDE

I was still using the unstable KDE 4.2 until this weekend. For some strange reason, the slotted 4.2 ebuilds were completely removed from portage, thus preventing any re-merges which I had to do since I wanted to also upgrade from GCC 4.1.2 to 4.3.4, so I had to uninstall KDE before, upgrade GCC, recompile everything, then finally merge KDE again. To remove KDE more or less completely I was told to do emerge -pCv $(qlist -ICv kde | grep 4.2) (minus the pv of course). I had some other ebuilds left for manual checking but this command caught the vast majority. Unmerging and remerging kde-meta (after the GCC upgrade) went really smooth. To have a WM in the meantime I emerged xfce4-meta and gnome-terminal before I unmerged KDE.

Akonadi migration with bogus entry

Recently I had issues with some corrupted config in Akonadi that could not be solved from within KDE 4.2. On every start I would now get the migration dialog retrying to migrate a bridge called Y2252jgYO7 – whatever that was, I couldn’t find it. Running locate on that ID revealed old lock files back from KDE 3.5. Having searched for a moment I figured out that I could simply find and remove the files:

find ~/.kde* -iname \*Y2252jgYO7\* -exec rm \{\} \;

Next, everything referencing that ID has to be removed from ~/.kde4/share/config/kres-migratorrc – redo whatever runs the migration assistant for you and the problem should be solved.

frenzy Nepomuk – again…

I don’t seem to be the only one where the desktop search never works. With KDE 4.2 I disabled Strigi and Nepomuk because it took 100% CPU even when idling. If it wasn’t idling it was accessing the harddisk way too fast and so it always slowed down my system. That wasn’t without sideeffects however: I was unable to use the runner (Alt+F2) without crashes. I figured out that enabling Nepomuk, disabling Strigi and removing all repository data worked in KDE 4.2. Guess what? The problem reappeared after the upgrade to KDE 4.3. I don’t know if I solved it “properly” (I don’t need desktop search ATM so I can afford disabling it). From Stéphane Laurière at Mandriva’s bug tracker:

  1. make a backup of your Nepomuk database by backuping the folder ~/.kde4/share/apps/nepomuk/repository/
  2. reconfigure Strigi from the Nepomuk System Settings so that it indexes less
    folders
    Note: I unchecked everything plus added * to the exclude patterns, just to be sure.
  3. stop Nepomuk by running the following command:
    qdbus org.kde.NepomukServer /nepomukserver org.kde.NepomukServer.quit
  4. remove the repository folder ~/.kde4/share/apps/nepomuk/repository/
  5. restart Nepomuk: nepomukserver

After restart I got several crashes (what else) but Nepomuk stops retrying after a short time… (you should watch out for large numbers of crash logs though)

the Cashew

If you ever wondered what the name for that moon-and-star-like icon is which you get when unlocking your panels in KDE4, it seems to be called “the Cashew”. I know there was one icon on the desktop when I started using KDE 4.2 but it somehow disappeared very soon on its own and I didn’t miss it. It seems like that has been some bug since I now had it again:

cashew on the right side KDE Cashew

That nasty icon was sitting right on my otherwise clean desktop wallpaper. I could move it around my screen borders but it could not be removed. I thought something was broken until I finally searched for it and figured out that it’s some kind of branding not be meant to be removed. Great… Now, how do you get rid of it?!

As pointed out on the Gentoo forums (thread “KDE 4.3.0 Annoyances“) and also on a blog post, there exists a plasmoid that you can simply drop onto your desktop to remove/hide that useless cashew: I HATE the Cashew

I HATE the Cashew

If you should ever want that apparently useless cashew icon back, simply remove “I HATE the Cashew” by clicking the minus icon on the “Add Widgets” dialog.

There used to be an ebuild for it but since I couldn’t find it I simply wrote one on my own (well, half-way copy&pasting from other ones and the ebuild documentation, but it works). In case you need it too, here it is: (kde-misc/ihatethecashew-0.4)


# Copyright 1999-2009 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2

MY_PN=iHateTheCashew

DESCRIPTION="I HATE the Cashew - KDE4 corner icon removal plasmoid"
HOMEPAGE="http://www.kde-look.org/content/show.php?content=91009"
#SRC_URI="http://www.kde-look.org/CONTENT/content-files/91009-${MY_PN}-${PV}.tbz"
SRC_URI="http://www.kde-look.org/CONTENT/content-files/91009-${MY_PN}-4.4.tbz"

LICENSE="GPL-2"
SLOT="0"
KEYWORDS="~amd64 ~x86"
IUSE=""

S=${WORKDIR}

src_unpack() {
        unpack ${A}
}

src_compile() {
        cd iHateTheCashew
        mkdir build
        cd build
        cmake -DCMAKE_INSTALL_PREFIX=/usr .. || die "CMake failed!"
        emake || die "Make failed!"
}

src_install() {
        cd iHateTheCashew/build
        emake DESTDIR="${D}" install || die "Install failed"
}
January 15th, 2010

Installieren könnte so einfach sein…

Eigentlich wollte ich nur Windows 7 installieren. Und es könnte so einfach sein. Aber nein, Windows 7 macht es umständlich:

Erster und zweiter Versuch:
Installation bootet, ich seh das blaue Wallpaper, dann passiert nichts mehr. Rechner lässt sich auch nicht ausschalten, nur hart resetten; für mich ein Anzeichen dafür, daß richtig was im Argen liegt. Ich ziehe alle USB-Geräte ab, schalte das Netzteil ab, versuche es erneut: Selbes Problem.

Dritter Versuch:
Beim blauen Wallpaper hab ich dann parallel zur Installation angefangen nach möglichen Fehlern zu googlen. Ich finde einen Thread, der auf Probleme mit GRUB hinweist; man müsse nur ca. 3 Minuten warten. Just in diesem Moment springt endlich ein Fenster auf. Ich klicke mich sehr langsam überall durch; weitere minutenlange Hänger gibt es nach dem ersten Auswahlbildschirm und dem Partitionieren. Endlich erscheint das “Windows wird installiert…”-Fenster. Windows kopier… nein, es ist sofort fertig und dieser Punkt abgehakt. Jetzt werden wohl die Dateien “expandiert”? … oder vielleicht auch nicht… Minuten später erscheint dort endlich: 0%. Das bleibt wieder ein paar Minuten stehen, dann kopiert der Rechner tatsache mal was. Reboot. Ich gehe ins BIOS und stell erstmal die Reihenfolge zurück. Ich lande in GRUB, boote Windows. Die Installation wird angeblich fortgesetzt. Nach einer Weile erscheint dann: “Windows kann nicht für die Ausführung auf der Hardware dieses Computers konfiguriert werden.”

Neustart. Meldung, daß die Installation abgebrochen wurde und ich es nochmal versuchen soll. Keine Chance, sie einfach wiederzubeleben.

Vierter Versuch:
Ich lasse den Computer komplett unangetastet ab dem Kopier-Fenster. Diesmal klappts. Vergangene Zeit beim endlich mal stattfindenden Login: 1:20. Furchtbar.

Lektionen:

  • auch Windows 7 ist zumindest in der Installation immernoch furchbar und gibt keinerlei Informationen von sich, wenn Probleme auftreten
  • nicht in die Installation eingreifen, auch wenn man der festen Meinung ist, daß es gar keine Möglichkeit geben kann, daß man mit der Installation in Konflikt kommen könnte
  • auch wenn etwas in der VM in 15 Minuten installiert, zieht es sich auf einem echten System über Stunden hin
  • Linux installiert sich leichter

Ein Glück brauch ich Windows nur für EVE Online und Blurays.