Quick howto: 32bit Firefox 2 within 64bit openSUSE 11.1

openSUSE 11.1

I am currently in the process of creating myself my very own openSUSE distribution using the excellent SUSE Studio.

As I've written previously, I am still using the old Firefox 2, which allows me to integrate with the KDE's excellent kprinter, something that was killed in the Firefox 3 branch.
Trying the distribution with VirtualBox I stumbled upon a problem with the Firefox 2 which I have actually seen previously. This 32bit Firefox 2 is unable to connect to any website when run from 64bit openSUSE 11.1 (probably in other versions as well).

The solution, however, is an easy one. The openSUSE is remarkably different from for example Ubuntu, as they actually include the 32bit environment out of the box in 64bit systems. This means that some 32bit versions of the various libraries are automatically installed. However, the distribution maintainers in openSUSE have, for some unknown reason, left out one of the necessary 32bit libraries: nss-mdns-32bit. Install this and the 32bit Firefox 2 works!

Gnome with Compiz and disabling Focus Prevention

Linux Mint 7 "Gloria"

One thing I've always hated about new Gnome after switching from openSuse and KDE is the focus prevention. I'm doing Flex development with Eclipse and whenever I run my application, a Firefox window is opened with the Flex compiled Flash file inside. The Compiz focus prevention, however, makes sure that the Firefox window is opened in the background. Also any and all Flash error dialogs (from the debug Flash player) appear only as the flashing taskbar button. It is ridiculous that I need to click on them to bring them forward.

Notoriously, neither Gnome nor Compiz ever mention the Focus Prevention in their setups. KDE 3.5 allowed the focus prevention settings in great detail to be modified via the KDE control center. Now, however, I've dug a bit deeper and I've found a rather simple solution to the problem.

It seems that all the hidden features are still present in Gnome and accessible via an app called gconf-editor. Just search for "prevention" in there (be sure to check the "Search also in key names" checkbox) and you should find a few matches.

Go to the key /apps/compiz/general/screen0/options/focus_prevention_level and change that value to zero to turn off the focus prevention. It's that simple!

How to make MPlayer from SVN work with Compiz?

Linux Mint 7 "Gloria"

One of the bigger problems when enabling Compiz for all these fancy UI tricks is the sad fact that video display will become, depending on which video output method your video player uses, either flashy, very slow or just totally unusable.

The root cause for this comes from the video output method. Those video output devices that render the graphics directly to the graphics card usually create a lot of flickering, since they effectively overwrite the rendered 3D graphics which in turn then overwrite the video window. The other video output methods think they render into a window become slow, since compiz will then have to copy the window contents to a 3D texture to be rendered by the video card.

With the Ubuntu 9.04 or (in my case) Linux Mint 7 "Gloria" x64 Edition the graphics driver installation is almost too trivial. At my workplace, with the ATI's Radeon X1650 card, the DRI R300 driver was installed automatically and effects were enabled out of the box with Gloria. At home I have ATI's Radeon HD3870 in which case I only had to confirm the installation of ATI's own Linux Catalyst drivers. The 3D effects along with full Compiz Fusion was already installed and ready to be swithced on.

But now became the real problem, how to make sure that watching video would still be possible with Compiz being active? I had heard a long time ago, at the dawn of Compiz, that there was one video player, which was patched to work with Compiz... I searched for it and was glad to find out that the player in question was MPlayer which is what I've always used in the past.

Since the patch is meant to modify source code, I had compile a patched version of MPlayer.

The compilation, however, blew up with some errors. The first error came from a module called IVTV... whatever that was I did not know. I simply disabled it with --disable-ivtv switch for ./configure script. The web told that there was a patch also to fix this, but I didn't care about that. The next error came from the x264 module which is a far worse thing, as this is one of the cornerstones of free MPEG-4 video. The web tells that this incompatibility of MPlayer 1.0rc2 and x264 is based on the fact that the aformentioned MPlayer source is outdated and does not support the much evolved current x264 version anymore. The only solution would be to compile the newest version of MPlayer, which currently is only available via an anonymous Subversion repository.

And here is the catch -- how to enable the fast Compiz video, yet keep x264 support also? The Compiz video patch is for the old MPlayer source, while the newer source supports the new x264?

I decided that the fortune favors the bold and tried to see if the patch could in any way be adopted to the new MPlayer source. The file in question is libvo/vo_xv.c. Of course there were numerous differences between the old and new versions of this file and this level of C code is well beyond my understanding (I generally dislike C).

Then I decided that it's worth a try to include the patched old vo_xv.c file with the rest of the new source code taken from Subversion. I expected it to blow up at ./configure script right away - it did not. I expected it to at least bail out with errors at compilation - it did not. It surely will crash once run - it does not. It works!

Since the following sources do a superb job at explaining at detail what packages you need to install, how to patch the file and how to compile the MPlayer, I will not copy their explanations, but merely add some remarks:

• A post in Ubuntu forums describing the original 1.0rc2 patching and compilation. Note that the patch file is no longer available from the link in that post (see below).


• A post in SmSpillaz with similar contents, but with a working link to the patch file. You can of course always use your friend Google to find alternate links to this file.


• An MPlayer download page with details how to download the new MPlayer from Subversion.

All you need to do really, is follow the first post up to the point of patching the original libvo/vo_xv.c file, back up the patched file, download the SVN version of MPlayer, copy the patched old file into libvo directory of the new source code overwriting the SVN version and follow the rest of the configuration, compilation and installation instructions from the first post but now within the new source code directory.

There's only one more glitch which needs to be rooted out. The fullscreen mode of MPlayer uses different screen mode which does not work anymore (reliably anyway). The solution is to turn off the special fullscreen mode by setting the property fstype=none. The only downside is that the Gnome panels remain visible that way.

I hate scripts and script languages!

Ubuntu 9.04

One of the big strengths of Linux is its open nature and the capabilities to customize everything to your personal needs and taste. Most of the times it requires a bit of learning, but other times it is a blessing to be able to create the needed tool yourself knowing that probably you are alone with your weird requirement anyway :-)

One way to make tasks less taxing and more convenient for yourself in Linux is to create scripts which do the tedious jobs for you. It is well known that in stark contrast to the Windows world, where the user interface of an app you see is the whole app, in Linux many apps you are using in the graphical desktop are actually only shells and the real work is done by other, command line apps. One of the better examples of this kind of shell is K3B, the KDE's CD and DVD burning application, which uses command line utilities such as cdrdao, wodim, growisofs, etc. to do all the dirty work.

This also means that you can use these same command line utilities to do that work directly without even launching the GUI or you can also create your own GUI if you prefer it that way. One big helper in creating scripts with better usability has been the kdialog command, giving a nice graphical touch.

During my time with Linux I have created a lot of scripts for various things I do. Since these scripts have been part of my activities for a number of years already, many having seen several revisions becoming more and more robust, I had no choice but to bring them all over to Ubuntu now that I'm using it. And this brings me to the point of this post - I hate scripts and script languages!

Though there are other bad traits with the scripts such as the lack of strong typing of variables, the most I hate scripts for their loose bindings. At its simplest a script -- as opposed to a compiled language program -- is a list of commands to be run in sequence.

But what happens if one of the commands is not installed and hence unavailable? Or if the command is of the wrong version and does not have the behavior you are using in your script? Or if the command itself depends on your environment and simply works differently? What if the command expects a file or directory to be at one place but in your OS they have been moved or installed in a different location? And since the UNIX doctrine specifies text to be the default data transmission medium, the commands become dependent on your current charset - is your $LANG set to UTF-8 or simply ISO-8859-1 or perhaps even ASCII instead?

Now, in case of a compiled program (unless it too uses external commands which is very unlikely), it should run just fine under different conditions (my experience here comes from years of Pascal and Delphi programming).
But in case of a script, you are most probably busted! Unless of course you test for every possible thing that can go wrong, but in such case you have probably spent 80% of time to write 80% of code that does not do what you wanted to do with your script in the first place. And the main power of the script is meant to be the speed and simplicity of doing what you want to do!

After my move from openSUSE to Ubuntu, I have stumbled upon this script nuisance several times already. The list of either direct or indirect problems encountered so far:

1. The regular expression [a-z] does not cover all of the alphabet if $LANG is set to et_EE.UTF-8 (as I've written before).


2. The KDE4 version of kdialog does not work with keyboard anymore (as I've also written before).


3. Ubuntu includes version 6.10 of the GNU's cut utility (used to cut chars away from a line of text) which does not work in UTF-8 space - special characters are counted as two. The solution is to get at least version of 6.11, which already supports UTF-8.


4. The KDE4 version of kfmclient (K File Manager) has a reduced set of commands. While previous KDE3.5 version could be used in scripts as the main file manipulation tool (coping, moving, renaming, etc.) the current version can only be used to open Konqueror browser windows. The new tool for file manipulation is kioclient and there's no backward compatibility - you have to change your scripts if you wish to port them to KDE4!

The fortunate thing is that KDE4 is installed directly into /usr, while KDE3 was always installed into /opt/kde3. So you can always install the KDE3.5 environment and point your $PATH first to /opt/kde3 to pick up the KDE3 version first. If for any reason you need to run KDE4 version, just use the full path, for example /usr/bin/konqueror.

Thats it for today.

A better way to stop ComboBox from resizing itself automatically...

Adobe Flex 3

This is an update to my earlier post about mx:ComboBox which, if set to a percentage width, will by default always take the width of the widest line it contains, widening possibly its container and/or changing the container to be scrollable.

The solution I suggested earlier was not enough for example in case the ComboBox was on a panel which was not visible when it was created. Now I am using a different solution.

Basically you extend the ComboBox and override the protected measure() method to cancel out the setting of minimum width set by the original code which is the cause the ComboBox will force its width upon its container.

The following code has some more changes, like resizing the dropdown list to the width of the longest line it will display and also refusing even programmatic focusing when either disabled or hidden.

Did you know, that if the focus already is on the standard ComboBox, then disabling or even hiding it does not block the keyboard input? For example, the [Down] and [Up] keys still change the items within the invisible ComboBox with all the corresponding events triggering, and [CTRL-Down] will still open the dropdown list even though the ComboBox itself is hidden and disabled?

public class ComboBoxEx extends ComboBox
{
   private var initDone:Boolean;
   public var preferredDropdownWidth:Number;

   public function ComboBoxEx()
   {
      super();
      this.preferredDropdownWidth = NaN;
      this.initDone = false;

      this.addEventListener("dropdownWidthChanged",
         function(event:Event):void { if (!initDone) preferredDropdownWidth = event.target.dropdownWidth; });

      this.addEventListener(FlexEvent.INITIALIZE,
         function(event:Event):void { initDone = true; });

   }

   /** A property indicating if the combobox should resize itself to the width of its contents */
   [Inspectable(category="General", enumeration="true,false", defaultValue="false")]
   public var resizeWidthToContent:Boolean = false;

   /**
    * A property indicating if the dropdown of the combobox should resize its width to the width of the longest
    * label within the combobox'es data, though never below the width of the combobox itself.
    * NOTE! that if you leave this property to its default value of true then the property dropdownWidth
    * will not be respected if it happens to be smaller than the width of the longest label in the combobox.
    */
   [Inspectable(category="General, enumeration="true,false", defaultValue="false")]
   public var resizeDropdownWidthToContent:Boolean = true;

   /**
    *  @private
    */
   override protected function keyDownHandler(event:KeyboardEvent):void
   {
      // Handle keyboard only if we are enabled and visible!
      if (super.enabled && super.visible)
      super.keyDownHandler(event);
   }

   /**
    *  @private
    */
   override public function setFocus():void
   {
      // Take focus only if we are enabled and visible!
      if (super.enabled && super.visible)
      super.setFocus();
   }

   /**
    * The super method determines the measuredWidth and measuredHeight
    * properties of the control.
    * This version will reset the measuredWidth property to the value of
    * UIComponent.DEFAULT_MEASURED_WIDTH unless the resizeWidthToContent
    * property is set.
    * @see mx.core.ComboBase#measure()
    */
   override protected function measure():void
   {
      super.measure();
      if (!this.resizeWidthToContent) measuredMinWidth = DEFAULT_MEASURED_MIN_WIDTH;
   }

   override protected function updateDisplayList(unscaledWidth:Number, unscaledHeight:Number):void
   {
      super.updateDisplayList(unscaledWidth, unscaledHeight);
      if (this.resizeDropdownWidthToContent && isNaN(this.preferredDropdownWidth))
      {
         var width:Number = getContentMaxWidth().width + getStyle("arrowButtonWidth");
         this.dropdownWidth = Math.max(this.width, width);
      }
   }

   public function getContentMaxWidth():Object
   {
      return calculatePreferredSizeFromData(this.collection.length);
   }

}

I also opened a bug about it.

Do not use your own language in Ubuntu!

Ubuntu 9.04

For crying out loud, I just spent a whole evening trying to figure out why the Gnome's Sensor Applet, which docks to the panel, does not work correctly and shows an error "Error compiling URL regex" instead of CPU core temperatures ?!?

The reason was simple - the function libsensors_plugin_init() within libsensors-plugin.c used regex which included [a-z0-9] in it and since in the alphabet of the Estonian language the letter "z" comes right after letter "s", any letters following them ("tuvxyz") will be excluded with the [a-z] regex. This included the "T" in "Core 0 Temp", so there you have it - "Error compiling URL regex" !

Aw gawd, I thought we are over this stupidity, but apparently not. Nobody probably knows the extent of this [a-z] bug and all the languages which are affected by it...

So the bottom line is:
Do not use your own language as the UI language if you want a working system!!!

My experiences trying out Ubuntu vs. openSUSE

Ubuntu 9.04 & openSUSE 11.1

I am and for a very long time already have been a die-hard SUSE user. However, most Linux people in my workplace are using Ubuntu.

Now that the Ubuntu 9.04, Jaunty Jackalope was released and my friend updated his laptop with it, I was excited to also try it out as it looked really good. The Gnome that comes with openSUSE somehow did not look that good...

Over the time I've almost always used KDE. I feel quite the same as Linus has once said - Gnome has taken the wrong turn in over simplifying its user interface. Over simplifying to the extent of removing also most of the necessary power-user stuff.

Unfortunately, nowadays the KDE 4 has also taken this bad route of over-simplifying the UI and probably for that cause, the KDE 4 team has re-written from the scratch many of the major KDE tools, such as Kate and KWrite, KDialog, Gwenview, Konsole, Amarok and many others. The new versions of the KDE 4 apps look, feel and are as useful as the namesakes of them at the time the KDE 2 started - raw and lacking many important features that I have grown accustomed to, plus introducing horde of bugs which should not be there at this point - an example would be KDialog, the new version of which does not return the correct response if you used only keyboard for selecting the button - with mouse it works, but not with keyboard. The old KDE 3.5 version, of course, works like a charm no matter how you use it.

One thing I found unbelievable in 64bit Ubuntu is the total lack of 32bit binary execution support out of the box. No 32bit ELF binary will run - bash, for example, says that the file you are trying to execute is not even there!
According to AMD64FirefoxAndPlugins page, in order to get the 32bit support you have to install several additional packages by hand and in order to run any 32bit binary you (apparently) need to modify some environment variables as well (better make a script). Additionally, for 32bit Firefox to be able to resolve names, you need some more installations to do.

Why on earth did the Ubuntu distro managers not create a normal dual architecture environment like openSUSE has - general 32bit support is given out of the box without any library path fiddling and only in case of more specific applications you need to select also the 32bit versions of any libraries they need.

Out of the box, there is one area where Ubuntu fares better than openSUSE - printers. I have two USB printers attached - an Epson Stylus Photo R220 and HP LaserJet 1020. Ubuntu noticed both of them, installing the Epson printer automatically with zero questions and for HP LaserJet only asking permission to install proprietary plugin direct from HP. Both work normally and to my biggest surprise, you can configure a ton of things for both printers including the CD printing capabilities of my Epson printer.

Right from the start I decided that I can not and will not use only Gnome tools and apps - I need at least Krusader, Gwenview, K3B, Konsole and KWrite. And I need the KDE 3.5 version of these apps - the ones that work as I've gotten used to. Again, out of the box there is no way to get KDE 3.5 apps. Fortunately there is the Pearson Computing KDE3.5 Repository for Ubuntu Intrepid and Above, which has a repository enabling the installation of KDE 3.5.10 environment and applications.

Another area where Ubuntu surprised me positively was the fact that KDE trash location was the same as the Gnome trash location. Deleting a file into trash from Krusader made it appear in Gnome's Trashcan... freedesktop.org has done a great job in unifying these two rivals making life easier for users of both.

So far so good, the system seems stable, printers work, audio works, my 32bit work environment (Java 6, Eclipse 3.4, Flex Builder, Firefox with Flash) is also working... so I guess I'll continue this experiment for a while longer.

How to make KPrinter work with Firefox 3?

openSUSE 11.1

In the recent past there have been several new software updates and upgrades which have almost infuriated me and forced me to revert to using old versions. The top two of these new things are:

1. Firefox 3 which cannot be persuaded to use kprinter anymore the way Firefox 2 was persuaded.


2. KDE 4 and its applications which totally and absolutely ignore the KDE 3 configuration with no apparent way to migrate the configuration either. Fortunately openSUSE still carries KDE 3.5 which I'm using currently.

The first of these items, however, is solved now, and here are the steps I took to make kprinter work with Firefox 3 (inspired by a post from this thread):

1. The first step is to edit the file /etc/gtk-2.0/gtkrc and add the following line to the end:
   

   gtk-print-backends = "lpr,file"

   
   This will make the lpr target appear in the Firefox 3 print dialog.


2. The second step is to switch the lpr command for kprinter command by executing:
   

   cd ~/bin
   ln -s `which kprinter` lpr
   



3. And the third and final step is to get rid of the Firefox 3 print dialog by opening the URL about:config and creating there the following new Boolean option:
   

   print.always_print_silent = true

And that's it - Firefox 3 now prints directly to kprinter.

NB! The only quirk I've found is that you cannot cancel the kprinter dialog - or it will hang Firefox 3 for some reason.

EDIT: After some testing, however, this way of printing seems to be very buggy - most pictures do not print at all and those that do end up on the printed page are heavily compressed with visible compression artifacts, the text is uneven and looks ugly.
It seems that the LPR printing uses the lowest possible resolution with no known way to fix this higher.

I've switched back to Firefox 2.0.0.20 for now until the Firefox 3 will play nice within KDE!

How to stop ComboBox from resizing itself automatically...

Adobe Flex 3

One of the many grievances I have with the otherwise wonderful Adobe Flex is the way the ComboBox component with percentage width resizes itself to accommodate the data which is loaded into it. There seems to be no switch to disable this behavior and yet retain the scalability of the ComboBox control itself.

The problem manifests itself best when you have, for example, two adjacent ComboBox widgets both set to be 50% width and you assign to the first a list of rows with short names and to the other a list of rows with long names - both widgets will resize themselves to a different width to accommodate their respective contents.

After searching for and failing to find a solution to this, I decided to try and write a workaround myself. I needed to fixate the width of the comboboxes right after they were first displayed and before they got their data. There was no need for the combobox to be resized later. In order to do this, I extended the original ComboBox and added the following code to it:

First I added a property via which you can turn on or off the new functionality:

/**
 * Property indicating if the initially measured width of the combobox will be
 * fixed as soon as the combobox has been layed out.
 * Only applies to combobox'es which have their width specified as a percentage.
 */
[Inspectable(category="General", enumeration="true,false", defaultValue="false")]
public var fixPercentWidthAfterInitialMeasurement:Boolean = false;

Second, to the constructor of the combobox, I added an event listener:

public function AComboBox()
{
   super();
   this.addEventListener(FlexEvent.UPDATE_COMPLETE, handleUpdateComplete);
}

Finally, I added the event handler method:

/**
 * This eventhandler is called right before the widget is drawn on screen - it's size has already been calculated,
 * but it has not yet received its contents, therefore now it is good time to convert its percentage width into
 * an explicit width, so that future data loaded into the combobox would not resize the compobox causing scrolling.
 */
private function handleUpdateComplete(event:FlexEvent):void
{
   if (this.fixPercentWidthAfterInitialMeasurement &&
      (!isNaN(this.percentWidth))) this.explicitWidth = this.width;
}

The idea here is to capture the event which is dispatched after the ComboBox size has been determined, right before the combobox is drawn on screen. Each ComboBox can have its width specified either explicitly in pixels or as a percentage of the containers width. When the width of the ComboBox is set as a percentage, I now assign its actual pixel width to the explicitWidth property. This will fixate the width and also stop the ComboBox from automatically resizing itself.

That solved the situation for me - the ComboBox retained its size after the initial layout.

A RAID success - with a Linux of course!

This is a continuation of my struggle to create a viable RAID-5 array for my sensitive data, started in this post and continued in this post
This saga continues in here.

The first tries at setting up Linux RAID system were failures for yet unknown reason. As suggested somewhere I created 20GiB partitions on each disk for /root filesystem to be RAID-1 (mirror) array and into the rest of the space I created partitions for /home filesystem in RAID-5. I tried this with both openSuSE 11.0 and the newest openSuSE 11.1, but in both cases the system was unable to boot, complaining about missing root filesystem. Sometimes the system would boot if I gave it the obvious root=/dev/md0 as the kernel parameter, other times even that did not help.

After some more experimenting I finally gave up trying to make the system totally redundant and resolved the situation by putting 10GiB on each of the four disks aside for /root, /swap, /usr and /tmp, accordingly, and using the rest of the space on disks as a RAID-5 /home partition. This worked as a charm of course.

I did extensive testing on the redundancy of the drive and found it to be rock solid. When one of the drive was disconnected, the MD reported an active RAID-5 system having with 3 out of 4 drives working... and that's it. Coping, moving and changing the content did not even seem to be any slower than before.

After some testing I re-attached the fourth drive and booted the system up again. This time the boot messages reported that the fourth drive of the array was rejected as not being fresh. Checking the mdadm command for any clues how to make the array complete again showed that the correct command was
mdadm --manage /dev/md0 --add /dev/sdd2
after that, the rebuilding of the fourth drive commenced in the background (it took a few hours) and the system was again working at peak efficiency.

Later I have been thinking what did I do wrong in the first two attempts and there are some things I can think of, but these must be verified first:

1. I used partition type Linux-RAID when creating partitions to be set up as RAID-1 later for the /root file system. Maybe I should have used the normal Linux partition type instead?
   
2. After creating the first 20GiB partition, I used the rest of the drive for the second partition on each drive. Since the drives were not identical, I probably should have created the second partition by specifying the size by hand, keeping it some gigs smaller than the rest of the space to insure the equality on all drives?
   

Anyway, now I am sure that I can restore all of my data, if one of the drives fails and as a bonus, I am also sure that I can insert a replacement drive and continue working without any need to reinstall the system.
I call that a success story!

More RAID rant

This post is an update to my previous post about my RAID-5 experience. Also see the continuation of this saga.

I found some disturbing problems with the nForce semi-software RAID-5 fault tolerance - without the fourth drive, the array seemed to work normally, but any modifications to the drive contents seemed to corrupt data on the drive. For example, in order to back up the data, after I had copied a few folders of data, I started to verify the copied data and delete it as I moved on. I always do it this way - first copy the data over, then run byte-per-byte verify (or MD5 hash verify) to see if the copy process worked and only after successful verify I will delete the data at the source.

Now, however, after I had verified and deleted the first folder of data from the RAID-5 array, the next folder showed an error in couple of files. Since they were picture files I was able to visually check the difference and the result was puzzling - the copied data seemed to be OK, but the source data on RAID-5 was corrupted. I tried a reboot, but the source file contents were still corrupted. I dismissed this as random happening and deleted the source (after all the errors were in the source data). Now the next folder showed even more corruptions and again the corrupted data was at the source.

A RAID-5 array with N drives saves actual data on N-1 of the drives and calculates a parity information to the remaining one drive. The data is saved in rotating stripes, so that the parity information of each next stripe is always on a different disk.
In case of reading data, if any one of the drives have failed, then N-1 times out of N, the the failed part of the data for each stripe is constructed by using the parity.

For example, when a stripe has parity on the drive 4, but drive 2 has failed, then the contents of drive 1 and 3 as well as the drive 4 with parity info is read and the contents of the failed drive 2 is constructed from the three other drives. Only in case the drive 2 held the parity data, is the reconstruction not needed.

The writing, however, is much more difficult. Assuming the above scenario, if the data is updated in the drive 1 region, then in addition to updating data on drive 1, the contents of drives 3 and 4 are read, the contents of drive 2 is temporarily reconstructed and new parity data is generated, which is updated on drive 4. If the data is updated in the failed drive 2 region, then similarly the data from drives 1, 3 and 4 are read, the original data of drive 2 is reconstructed, updated in memory and new parity is created and updated on drive 4.

Since the corruption was only few dozen bytes at a time and with no detectable pattern of changed bits I dismissed any further drive failure and assumed that one of the SATA cables could be faulty. I bought full set of new cables and tried again, recreated new RAID-5 array, copied a few dozen gigabytes of data on it. Made a copy of the data and then another copy of the same data. While the second copy was in progress, I disconnected one of the drives. At first, everything seemed to work normally. The array was in degraded mode and the copy was finished normally. Then I started to verify the copies of the data. At first things looked good, but then one of the bigger files had a few kilobytes of data totally differing in the middle of the file.

At this point I decided to power off the system, re-attach the drive I removed earlier and try the rebuilding. However, the nForce RAID BIOS reported error for the fourth drive and did not integrate it to the array. Booting Windows was also broken. After several attempts, somehow, I was able to boot and log into Windows at which point most things I tried to run either crashed, reported access violations or did not run at all.

For me, all this means that I will never trust the chipset semi-software RAID anymore. It could well be, that it is my motherboard that is at fault here, or the BIOS version... But still, having the RAID array is all about the ability to save important data on it without the need to worry if it will still be available after something happens to one of the drives. When the RAID array starts to corrupt data while in degraded mode then there really is no point in having a redundant RAID array.

If anyone has had a success using a chipset provided BIOS RAID array where a drive has failed in the middle of using it, please let me know the type and model of your motherboard.

Next I will try the software RAID offered by Linux. I'll try to do the same kind of trick - power down one of the disks while in use and see if and how much data I'll lose.