Experience and observations of F11a/rawhide so far

[Keith G. Robertson-Turner]

Surprisingly stable, for the most part, but with a few nasties:

. RPM broke completely at one point (md5 mismatch errors), necessitating
  manual extraction from an RPM of updated components. Was there a more
  graceful way of handling the changeover?

. Radeon driver and kernel modesetting. This has been coming on in leaps
  and bounds, but it's still not quite there yet. The stock F11a kernel
  had no support, then there was support but it caused visual
  corruption, now it seems to work properly (2.6.29-0.252.rc8.fc11) but
  the radeon driver subsequently causes the system to lock hard when
  running anything OpenGL related (drm?). That final point was the cause
  of the next...

. ext4 data loss. It's been many years since I lost an entire filesystem
  in normal operation, and that was not under Linux, but it happened
  yesterday after the aforementioned lockup. I had to hard reset, but
  the worst I expected was a journal recovery. Not so. In this case, the
  kernel first insisted there was no space left on the device (whereas
  there was actually over a 100GB), then another reboot later it failed
  to grok the filesystem at all, claiming it did not appear to be an
  ext4 filesystem. I can't say whether or not this is related to the now
  well publicised delayed allocation issue, or whether this will be
  resolved in the fixes promised for 2.6.30, but it has definitely put
  me off ext4 ... for now. Maybe I'll come back to it in a few years. I
  would question the prudence of pushing this as a visible anaconda
  option in the final release though, since some are undoubtedly bound
  to accept it as ready for production, and IMHO it isn't.

. Speed issues. I noticed no discernible improvement in disk access
  speed (no benchmarks, just my impression), and the graphics subsystem
  was dog slow, but this was probably just an expected result of the
  current state of radeon. Booting seemed slightly faster, although
  maybe that was a purely psychological effect of being distracted by
  Plymouth? I seem to recall timing a cold boot at 60 seconds to the
  login prompt, which is OK for a 5400RPM EIDE laptop drive, but not
  stunning. IIRC I get that now on the currently installed Fedora 8
  (2.6.26.8-57.fc8). Overall, the system felt decidedly laggy.

. Compatibility issues. The newly pushed Thunderbird 3 reintroduced an
  age-old problem with saving draft copies on an IMAP directory (hangs
  forever). I can't remember what I did to fix it last time, but nothing
  obvious worked this time around. Naturally, my huge collection of
  plugins no longer work (something which seems to happen even with the
  most minor update, and which I find intensely irritating), most
  crucially the Enigmail plugin, which seems to lack any compatible
  update (64 bit system). I did grab one which looked like it was
  supposed to work, but plugin manager complained about the build being
  incompatible (gcc issue?). That's a blocker for me, since I absolutely
  must have GPG support, so I had to revert back to Thunderbird 2.

. Suspend/Hibernate ... broken again. I must admit this really confuses
  me. If it works once, then why shouldn't it always work? Very, very
  annoying.

. Pulseaudio stuttering and proper device control ... It's quite funny
  seeing mplayer suggest that my 2GHz AMD64 system, with Audigy 2 audio,
  "might not be fast enough" to play media. The "tsched=0" setting does
  help somewhat, but this really needs to be addressed. Another issue is
  the lack of equaliser controls (bass/treble) which is provided by the
  DSP on the card. I really want to see more than just "Master" when I
  open volume control. No, seriously, I really, really do. A post
  elsewhere from one of the devs, suggested that equaliser controls
  should "never be part of the software", which I found to be a rather
  arrogant position, since how else is one supposed to control the
  equaliser settings on a pair of headphones connected to a laptop,
  especially when the card actually provides this function in the
  hardware? I spent a few minutes trying to hack support in using
  something called swh and ladspa, but whatever this is supposed to do
  it didn't work here - either that or I just failed to grasp the
  incredibly convoluted and confusing Pulseaudio configuration settings.
  This is something that really needs to be built in. No human  should
  ever need to endure the torture of Pulseaudio's dotfiles. Until PA can
  actually play audio without stuttering, and provide the same degree of
  device control as ALSA (easily), then I'm afraid I won't be using it.

Ending on a positive note ... radeon, when it actually worked, was
highly impressive. I found no discernible difference in 3D speed between
it (under F11a) and the proprietary fglrx (under F8), although I'm sure
a more empirical benchmark would have revealed a difference in numbers.
It gives me real hope that fully accelerated Free Software 3D graphics
drivers are now actually a reality.

As for everything else, well it's still early days yet, but my overall
impression is "OK", nothing more. Plymouth stands out in my mind as a
compelling motive, along with various improvements to libgpod - which
are unavailable to older releases due to a cascade of unresolvable deps,
and I have become rather enamoured with KDE4.2, so I suppose this may be
the release that finally compels me to dump F8. I just hope some of the
above issues are addressed by the time it goes public.

One request I would like to throw out there, as a RFE, is the ability to
specify *keyfiles* instead of a password, when anaconda is setting up an
encrypted filesystem with cryptsetup. My current arrangement requires me
to manually edit the initrd thus:

echo Setting up disk encryption: SecureKeys
cryptsetup luksOpen /dev/sdb1 SecureKeys
mkdir /SecureKeys
mount -t ext3 /dev/mapper/SecureKeys /SecureKeys
echo Setting up disk encryption: takeMScrypt
cryptsetup luksOpen /dev/sda2 takeMScrypt
   --key-file=/SecureKeys/takeMScrypt.key
echo Closing encryption keys volume: SecureKeys
umount /SecureKeys
cryptsetup luksClose SecureKeys

sda is a USB keychain, with a built in MicroSDHC card reader.
sda1 is "/boot", unencrypted.
sda2 is "/" on an LVM volume encrypted with the kefile on sdb1.

sdb is a MicroSDHC card, with the key store on sdb1, which is itself
password encrypted.

So when this boots, I'm asked for a password once, which unlocks the key
store, and uses keyfiles in that key store to unlock the other
filesystems, then closes and unmounts the keystore, so the MicroSDHC
card can be physically removed (and possibly hidden).

How easy would it be to build something like this into anaconda?

Thanks for listening.

-- 
Regards,
Keith G. Robertson-Turner