Mailinglist Archive: opensuse (2700 mails)

< Previous Next >
Re: [SLE] Disappointed in 9.3
  • From: Darryl Gregorash <raven@xxxxxxxxxxxxx>
  • Date: Fri, 01 Jul 2005 16:55:46 -0600
  • Message-id: <42C5C9F2.40400@xxxxxxxxxxxxx>


Andreas Jaeger wrote:

What problems do you have?

This pertains to a ftp install. I didn't even get as far as running anything, or trying to compile anything.

The MD5sums for the ispell American and British dictionaries seem to be wrong. kdebase3 also failed the MD5sum check, but that was picked up later during an online update. I suppose the ftp transfer of the kdebase rpm might have failed at first, but the two ispell dictionaries have failed the checksum consistently every time, and on several different mirrors.

I pre-formatted my second drive in SuSE 9.0, XFS on all partitions. I did so because I wanted to try XFS, with varying journal sizes (see a comment below for the reasoning behind this), and the install doesn't allow that as far as I could tell. As I customarily do when installing a new version, I switch the two drives so /dev/hda is always the boot drive.

This turned out to be a disaster. After the install was complete, I tried copying my data over from the 9.0 to the 9.3 installation, using recursive cp. The system locked up cold after a short while. This was actually my second warning bell, because a previous wget, under 9.0, targetted to that same partition also locked the system cold, after an equally short time. BTW, this brings up another point. Previously I had tried an ftp install of 9.2, several in fact, and every time I could not even get past downloading more than a couple of rpm's, so I guess by this time I have had 3 bells go off.

Next an ordinary user starting up the graphical desktop (default runlevel is 3, desktop is KDE) could not do so: either xinit crashed, or something in KDE, most likely kwin, crashed, almost immediately. The result was a system that had the user still logged in, with all of his processes in uninterruptible sleep (status D in top). That user could no longer log in (the new console immediately went into uninterruptible sleep), but the administrator still could log in and everything seemed recoverable -- until I tried to reboot, that is. That locked the system up cold, presumably when the ordinary user's processes were being sent a KILL signal. The end result was a forced system reset (the nice friendly button on the front of the computer case, that is), and a totally corrupted /home partition. It could not be mounted, and xfs_repair just locked up. The /usr partition also wound up with a lot of errors on it, but at least it would mount. The /opt partition I didn't even bother to check.

At that point, I umounted /home, and fired up badblocks because this partition had previously shown hard errors in the drive media, destructive mode (no point in trying to salvage what cannot even be read) -- the partition is fine, and continues to check OK with both destructive and non-destructive tests.

Conclusion: either XFS in 9.0 is f***ed, or it is in 9.3 -- or there are incompatibilities between the two versions used in each of these SuSE releases. If that isn't it, then I have to say that XFS itself is rather susceptible to nonrecoverable errors in the event of a forced reboot -- but that goes against all that I have read on the Internet. Here are some typical formatting combinations I used, which may have some bearing on the matter (but I rather doubt it)

root partition (520 MB) - blocksize 512b, journal size 2500 blocks (this runs roughly in agreement with some information I found on tweaking an XFS system to get better speed out of it). This partition suffered the least corruption of all, yet it includes both /var and /tmp.

/home partition (4.9GB) - I think I just let mkfs.xfs use the defaults here, so 4KB blocksize and a journal size of 2560 blocks.

/usr (4.9GB) - also default values.

/data partition (target of the copy and wget that locked up, 61,6GB) - 4K blocks and a 32MB journal (8K blocks)

I'm about to try another install of 9.3 in the next few days -- maybe I'll wait until mid-week when I can get some more CDRs, and fetch the 5 install iso files -- but I doubt I will be using XFS, unless it can be demonstrated conclusively to me that this won't all just happen again.

Oh, and yes, my 9.0 kernel is the most recent available with YOU.


< Previous Next >