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.