On Sun, 2005-10-30 at 12:09 -0500, taharka wrote: > Tim wrote: > > >On Sat, 2005-10-29 at 12:36 -0400, taharka wrote: > > > > > > > >>Every time I upgrade to the latest kernel, /etc/modprobe.conf gets > >>hammered & I have to replace it with a backup copy :-( > >> > >> > > > >Doesn't happen to me. Maybe you should provide some more details and > >someone can resolve that issue for you. > > > > > > > Well, thanks for the offer but I doubt it :-( The first reported > incident, is the posting below; > > https://www.redhat.com/archives/fedora-list/2005-May/msg04057.html > > kernel-2.6.11-1.27_FC3 destroyed my sound configuration. > > * From: "Erik P. Olsen" <erik epo dk> > * To: Fedora Mailing List <fedora-list redhat com> > * Subject: kernel-2.6.11-1.27_FC3 destroyed my sound configuration. > * Date: Fri, 27 May 2005 23:52:07 +0200 > > I upgraded my kernel to the subject version on May 24. In that very > moment all sound stopped on my system (only the hiss from the fans are > still there). I can see that modprobe.conf was also changed at that > time. I have restored the previous modprobe.conf but that only allowed > alsamixer to work, still no sound so apparently more damage was done. > > I assume I have to reinstall/reconfigure alsa, but why did it happen and > how can I prevent this from happening next time I upgrade the kernel? > > -- > Regards, > Erik P. Olsen > > Note, that there was no response to this guy's post :-( Now, the very > same thing happened to me. I was fortunate enough to have a backup of > /etc/modprobe.conf on a SCO Open Server box attached to my LAN. > Overwriting the hammered modprobe.conf with the backup copy worked for > me. It's a good thing I had that backup because, I had pushed out that > kernel update to ten clients with identical systems & their > modprobe.conf file was hammered likewise :-( > > taharka > > Lexington, Kentucky U.S.A. > Well, with the plethora of messages in the archive, if that is the only one you find where modprobe.conf was corrupted then it does not seem very prevalent an issue. Personally I have never had that issue on any system I manage. I understand your concern and am glad you had the backup, but what is unique about your systems that made it happen to you when very few others are reporting this problem? Is someone interrupting the update before it completes the configuration step? Is there something else that interferes? such as maybe the update running and backups starting at the same time, etc.? Kernel updates seem to take a long time to finish the update. At times I have felt they were hung and have been tempted to kill the power since the system was inaccessible at the time, ( although I never have :-) ) .... but after waiting a long enough time they have always finished for me.