Well depending on HOW it was obtained. The short answer is that the kernel primarily installs to only TWO locations. /lib/modules/`uname -r`/ and /boot/ So check for the #.##.## of your kernel version in those locations. Also note a few symlinks /boot/config / boot/system /boot/kernel that might link to the #.##.## of your kernel. Not to worry those are handled at your re-install. But there might be an initrd image in there that could linger and not update if you do anything manual-ish that could be a trouble maker. As in could be formed from another version you're not actually using, but the boot loader tries to use it anyway. That one is the primary difference between a custom kernel and a distro kernel in a lot of cases. So the basic procedure might be... $ sudo dpkg --purge --force-all kernel-*version* (might also be some header, image, modules, or other things for that image depending on how the distro packages it. Purge them all. Make sure only for the version in question. And keep your OLD kernels / ALTERNATE kernels around because you'll have to boot to them to re-install. And/or just to do this step.) $ sudo rm -rf /lib/modules/linux-*version* (tab completion is your friend) $ sudo rm -rf /boot/*version* (make sure you're not grabbing anything important. As long as your alternates don't share the same version number, you should be safe-ish) Perhaps a good ideal to do a full backup before these steps, just in case. $ sudo apt-get install kernel-*version* (plus any related packages) It's not unheard of for a distro to botch a particular kernel for a particular purpose. Depending on your distro and version there of. Most times they will be updated or replaced with the latest and greatest at the next update. At least a couple times a year, so 30 days to six months and your issue might automagically disappear. Otherwise try those steps above. Perhaps an "ls *version*" beforehand to ensure that you're not grabbing anything not intended to be grabbed. You can also "mv" the stuff versus "rm" if you want a recovery option, but a bit more tedious and no real need to hang on to it for all intents with alternate options. Potentially dangerous commands there so be weary of fat fingers. And backup first if you don't trust yourself. And backup if you DO trust yourself. Not to clutter the issue, but sometimes /boot/ is on a different partition / device and unmounted after boot. In that instance you might need to do some trickery to have it be there to uninstall from. Basically don't assume anything, verify verify verify. With certain permission schemes(acl/selinux) it's entirely possible that the process is not that simple. But it could be. - James On 2/15/11, Marcin Szyniszewski <mszynisz@xxxxxxxxx> wrote: > Hello, > > I checked if alsa and stuff is working on other kernels - it seems it is > working brilliantly! Mic and sound works fine! > So the problem would be with the latest kernel. I removed it while being on > previous one and installed it again, but the problem is still present. > Then I tried to do all the stuff that was suggested here again, nothing > worked. So it looks like it's the fault of kernel but reinstalling it > somehow doesn't work! Do you have some suggestions? Maybe it's not kernel > after all? Or maybe there's some different way to remove the kernel > completely and reinstall it? > > My impression that that at some earlier stage audio *was* working, so the > > current lack of working is due to something like an attempt to do something > > like 'upgrade' the kernel. If so, my recommendation is to *always* do a > > backup of your system before doing anything that might furtle things up. > > >> I use 'clonezilla' for this every now and then to try to protect myself > > from my own idiocy. Put the backup on a removable USB HD. But there are > > various other ways you may prefer. > > > Yeah, thats a good idea. Fortunately there are previous kernels available! > > Best, > *mszynisz* > ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Alsa-user mailing list Alsa-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-user
