SUSE Linux 9.2: Let the Branding Begin!
Gotchas and Tsotchkes

Bill von Hagen
Thursday, December 16, 2004 02:58:41 PM
Aside from the upgrade and wireless-tools issues I mentioned earlier,
I only had a few minor problems. One of these was with getting sound
to work on my system. 2.6-based systems use ALSA (Advanced Linux Sound
Architecture) rather than OSS (Open Sound System), which was the
standard for 2.4-based (and earlier) Linux systems. ALSA frequently
starts up muted, which is easily corrected by running its alsaconf
application. However, this alone didn't do it for me.
I could play CDs
fine, but XMMS and other audio players remained mute, though they
thought that they were playing since their timers were running. I
eventually had to run the alsamixer application and enable various DXS
playback items before my system would play any of the audio files that
I've lovingly ripped from my CD collection. For me, keeping a stack of
CDs beside the computer is silly nowadays, especially because I have a
fairly wide range of tastes. And if you're from the RIAA and are
reading this, you're free to stop by and visit my attic to see boxes
of dusty CDs. Don't get your hopes up.
Another issue which was irritating for me is that SUSE turns off the
ability for remote X Windows clients to connect to your desktop by
default. Though "ssh -X" provides a more secure version of this
capability for office use, I'm used to opening up X on my home network
for convenience' sake. Even the generic "xhost +" command doesn't
help, and I flushed the firewall just in case, but nothing. It had to
google for quite a while before I found the magic info-byte to find
out how to do what I viewed as a classically simple X Window system
task. In order to enable remote X clients to display on recent SUSE
releases, you have to crawl through various YaST menus once your
system is up and running.
After entering the Control Center's YaST2
Modules pane (see Figure 5), select System, and select /etc/sysconfig Editor. After authenticating (unless you're already root), expand the Desktop
selector, and expand the Display manager selector. You must then set
both DISPLAYMANAGER_REMOTE_ACCESS and
DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN to "yes." The next time you
start the display manager, things will work normally.
Looking through /var/log/messages, I noticed some bizarre messages from
the driver for the Marvell Ethernet chip on my 64-bit system. These
are of the form:
Dec 12 16:19:53 64bit kernel: eth0: -- ERROR --
Dec 12 16:19:53 64bit kernel: Class: internal Software error
Dec 12 16:19:53 64bit kernel: Nr: 0x19e
Dec 12 16:19:53 64bit kernel: Msg: Vpd: Cannot read VPD keys
To be honest, I don't know what these mean, and the only information
that I could find on the web about problems such as these were that
they might indicate a BIOS issue. 100 Mb Ethernet seems to work fine,
and I don't have a GigE network at home. Well, not yet.
As far as cool things that were new to me are concerned, one of the
handiest was SUSE 9.2's use of /media as a location where removable
media are automounted was both pleasant and handy. I'm used to
tweaking /etc/fstab to allow user mounts or configuring automounting,
both of which can be a PITA in different circumstances. With SUSE 9.2,
I noticed that I can immediately access any removable media that I've
inserted under the appropriate directory in /media, one of
/media/floppy, /media/cdrom, or /media/dvdrecorder. As far as I'm
concerned, that's just "the right thing."
Next: Conclusion »