Currently I am testing updating from Slackware 10.2 to 11.0.

A significant issue is that I have no sound. I have scoured the web looking for clues and all to no avail.

Although I updated the core Slackware to 11.0, I have not updated to KDE 3.5.4. I am using the stock 2.4.33.3 kernel, ALSA 1.0.11_2.4.33.3, but with KDE 3.4.3. That is, I have updated Slackware to 11.0 with the exception of KDE and aRts.

Through trial and error I discovered that after I started KDE, and then from the command line (as root) restarted ALSA, I then had full sound. Without restarting ALSA I have no sound, even from the command line. Yet there never are any error messages. Everything seems to work as though I merely had unplugged the speakers. The KMix volume control is set for 50%. Understand that everything works fine in my production partitions running 10.2 and KDE 3.4.3.

Before manually restarting ALSA I could not run aplay, madplay, and ogg123 from the command line. After manually restarting ALSA from within KDE I could. There are no error messags when I run noatun, kaboodle, or xine. I have installed the libvorbis, libtheora, and xine packages.

If I do not restart ALSA from within KDE, and then exit KDE, aplay, madplay, and ogg123 still do not work from the command line. I have to manually restart ALSA and then all is fine.

Another noticeable difference is that any time I try to modify the KDE sound system from within the Control Center, KDE locks up hard and I have to perform a Ctrl-Alt-Backspace to regain control. This never happens in 10.2.

I read some snippets that there were problems with the libasound libraries back in the spring of 2006 and this was just before the last update of ALSA in the Slackware current tree. Could this be the problem? Do I need to find a more current version of ALSA? This is not a typical permissions issue because all of this happens as root. There are no error messages when I start ALSA. Running ps ax | grep artsd while in X/KDE reveals the same result from either my testing partitions or my good partitions (two instances of artsd). I have reinstalled all artsd and ALSA packages. After running alsaconf and depmod -a my /etc/modules.conf remains unchanged except for the ALSA version number. Running lsmod | grep snd seems to reveal nothing mysterious, nor does ls -R /proc/asound. Yet, something halts ALSA after I start KDE.

Everything seems fine after I manually restart ALSA, but something is killing ALSA when KDE (3.4.3) starts. I notice no other issues with the underlying Slackware 11.0 or KDE 3.4.3.

So what is halting/killing ALSA after I start KDE? How do I troubleshoot?

If you do not start KDE at all upon boot-up, do aplay, madplay, and ogg123 work?

Any particular reason for not upgrading KDE and arts to the Slackware 11 versions?

Can you perhaps free a partition where you can perform a fresh install of Slackware 11.0 so you can test whether the problem exists there? To me it sounds like KDE is seriously confused by the new ALSA libraries from the 11.0 (and/or possibly other library conflicts as well since you're using a KDE from around Slackware 10.2 .... but 3.4.3 was never part of Slackware afaik).

It is never a good idea to mix programs and libraries from two Slackware versions like this. Most people reporting problems with Slackware 11.0 in the forum are suffering from bad upgrade paths.

Eric

Yes.

Caution and personal preferences. I never have been a person who updates or installs new software "blindly." I ran one test at updating KDE to 3.5.4 and there are certain usability issues that I don't like in the newer version of KDE, mostly with Kate. However, I had more problems with sound after updating to KDE 3.5.4 and aRts 1.5.4. And there were other usability issues with KDE 3.5.4. Sufficiently so that I am considering not updating KDE. More on that, perhaps, later.

Yes, I have thought of that. I could wipe the testing partitions and perform an installation from scratch. But then I have to burn CDs and my CD player on that box is flaky.

I have a copy of the Slackware current tree on my /home partition. Is there a way to perform a fresh installation within the same box without networking? I have not performed a full or fresh installation of Slackware in a long time---only updated. If there is a way to perform a fresh installation within the same box using the current tree, then I can try this.

This would be my conclusion. But why do I have no issues when manually restarting ALSA from within KDE? Makes no sense to me.

No, 3.4.3 never was "officially" updated in the Slackware tree. I do not know why not. But I never had any problems with 3.4.3 downloaded from the KDE FTP site (somebody always uploads Slackware packages there immediately after releases).

Generally I agree, but KDE should be independent of kernels, modules, etc. That this sound issue is the only problem I experience seems to affirm that.

FWIW, after restarting ALSA from within KDE, noatun, kaboodle, and xine work fine.

This thread: http://www.linuxquestions.org/questi....php?p=2453156 has a nice tip on using lilo to fire off an installation if the slackware tree is located somewhere on your disk and you can't use a CD to boot.

Eric

Okay Eric, thanks. I use GRUB, but was able to quickly adapt the idea and I now can boot into setup. Kind of cool.

Now, how do I modify the setup scripts such that I do not have to manually type all the partition information (again, and again, and again, and again . . . ). After all, these are testing partitions and I expect to repeat this act several times until I solve various issues.

Where are the setup scripts? I cannot find them in the file tree. I maintain backups and could restore if I botched my typing during the installation, but I'd rather not risk the chance. Instead I'd rather temporarily hard-code the setup script to my testing partitions. I want to skip formatting the partitions too. That part of the installation script is not exactly user-friendly because there is no way to back up or repair typos.

Are the setup scripts embedded in the ram disk image? If so, then hopefully I can find a workaround to modify the scripts to hard-code partition locations, skip formatting, etc.

For this test I'll perform a full installation in order to hopefully solve the problem in this thread.

The setup scripts are indeed embedded within the ramdisk image. After you gunzip the compressed image and loop-mount it somewhere, you will find the used scripts in ./usr/lib/setup.
Since you want to automate things a bit, you could try "sfdisk" to create the partitions for you.
Read the man page for sfdisk and especially the "-d" parameter which is the way to dump the partition information for the disk once you've partitioned it to your liking. YOu can then use the output as input to sfdisk in your modified initrd image.
Also, if you want to automate the selection and installation of packages (if you prefer a non-full install) create a set of tagfiles and use them to install the Slackware packages you need.

Eric

Why that sneaky little stinker . . .

Okay, got that far. My eyes and head now hurt! I can write shell scripts, and generally follow the intent of complicated scripts, but trying to edit these scripts would be several days of sweat equity before I felt confident of anything.

Partitions are set in stone, and will remain so until the day arrives when I decide otherwise. That is, all I would want to do is edit the installation scripts such that the partition info is preset rather than me manually typing. To me this section of the installation scripts has always been a weak link in the process. There is no way to gracefully back step and correct typos and trust me, I've been there done that. Very frustrating to have to restart because of typos. The more sensible approach is to provide some kind of pick list to match partitions to file system points. I seem to recall the old Lycoris ncurses installation scripts doing something like that. Perhaps PV might take a look at those old scripts. I probably still have the CD if he is interested. Anything at this point of the script that eliminates manual typing would be more friendly and less mistake-prone.

Similarly with selecting the device partition when installing from a local directory rather than CD. Eliminate the typing.

In my case, because I am maintaining separate partitions for testing, I would want the installation scripts to know which partitions to use and not bother me with asking. I do not want to risk typos and muck up my good partitions.

Additionally, because all of my partitions are set in stone, I do not want any partitions to be formatted. Or, I would only want my testing partitions "quick formatted." And that is another weak point in the installation scripts. The default selection when the script asks whether or not to format is to format. For somebody like me who maintains production partitions, and separate partitions for /boot, /home, /usr/local, etc, using the installation scripts is nerve-racking. I'd rather skip that step or at least reverse the default order so that not formatting is the default choice. I'd rather have an installation fail because of a lack of partition space rather than mistakenly format a good partition. I haven't yet done that and I'm knocking on every piece of wood I can find.

BTW, I hope later today to post an update to my original query. Still no success at obtaining sound. Quite frustrating. I've tried a few other things and right now as I type I am performing a full updating with the --install-new switch. I have not maintained a full installation in a long time so if this works I'll at least then know that the sound problem was a missing package or two. But if this effort fails to produce sound then I'll try the clean installation and I am hoping to avoid that---time is a scarce resource and the last thing I want to know is that I will have to perform a clean full installation to update to 11.0 and KDE 3.5.4---on two boxes.

I solved the problem with no sound after updating to Slackware 11 and KDE 3.5.4.

If you are interested in the entire story, look here:

Updating to Slackware 11---Part 2

I hope this helps somebody.