# Annoyance: Kernel Config File Mysteriously Dissapears

## jsnorman

On occasion, after running an emerge/update, I find that my kernel config file in /usr/src/linux disappears.  I am not sure when this is happening, or why.  I usually only notice it when, on running an emerge, I get errors stating that the kernel config cannot be found.  Of course I backup my kernel configs, so I can easily restore and restart, but it is very annoying especially when I leave a long system rebuild to the weekend and come back to find a failure like that.

A few notes on this strange problem:

1) I have verified that the symlink /usr/sys/linux still points to my current kernel version (even though newer kernel versions may have been released and installed).  I verified this manually (ls -l) as well as using eselect.

2) This has happened several times over the past 6 months.  But I cannot discern a pattern so I don't know what causes it.  It does not always happen, and usually my .config file is left alone.

3) I never delete .config for any reason.  I do backup the file to /boot/config-gento-x.y.z but I always use cp.

4) I have checked file corruption, which is unlikely anyway as I am using lsraid 5 volumes over 4 drives.

If this is an emerge "feature" that somehow gets triggered occasionally, I would like to turn it off!

Thanks for any insights.

----------

## nick_already_taken

Not that I can explain to you why your kernel .config gets lost. Normally I would say you had run "make mrproper" or something similar.

But I have another solution for you:

Follow

http://cateee.net/lkddb/web-lkddb/IKCONFIG_PROC.html

and set the mentioned option, when you build a new kernel.

It makes it possible for you to access the .config file in a future running kernel through /proc/config.gz, which means that you can

access the kernel .config independently from its location on your filesystem directly under /proc/ inside

of your running kernel. The positive effect of this setting is, that it can't get lost  :Smile: 

----------

## DONAHUE

do you ever run emerge --depclean?

----------

## platojones

 *Quote:*   

> If this is an emerge "feature" that somehow gets triggered occasionally, I would like to turn it off! 
> 
> Thanks for any insights.

 

 *Quote:*   

>  do you ever run emerge --depclean?

 

Beat me to it...that's my bet too.  

Unmerging the kernel sources leaves them intact, but it removes any configuration files.  That's the only mechanism that would explain this from a Gentoo perspective.

----------

## jsnorman

 *DONAHUE wrote:*   

> do you ever run emerge --depclean?

 

Ahhhh yes.  Just starting running depclean and eclean about 6 months ago when I ran out of space on my /usr/portage mounts 'cause I was too lazy to expand the partition.

Never occurred to me that depclean would actually modify my files though - seems like undesirable behavior (I mean, if it REMOVED the old sources I get it.  But to only delete my .config file??? seems flaky).

Is there a way to turn this behavior off (only with respect to the kernel source, which I generally like to keep until I manually delete  them)?

----------

## wthrowe

emerge --depclean shouldn't remove the .config file, because it was modified after the package was installed.  I still have all my old .config files around.  Have you done anything weird with your portage FEATURES?

----------

## wthrowe

Actually, looking closer, portage FEATURES should be irrelevant, because I see that the .config file isn't listed in the gentoo-sources CONTENTS file.  But depclean still shouldn't be touching it.  Is your kernel source directory still there, or was that deleted too?

----------

## jsnorman

 *wthrowe wrote:*   

> Actually, looking closer, portage FEATURES should be irrelevant, because I see that the .config file isn't listed in the gentoo-sources CONTENTS file.  But depclean still shouldn't be touching it.  Is your kernel source directory still there, or was that deleted too?

 

Yeah, that is what I thought too.  I mean, I would expect the opposite behavior from what seems to be occurring - all files in the CONTENTS file might well get deleted, but MY files (or at least the derived .config file I created) should not be harmed at least in my sense of what depclean should do (assuming that is the culprit).

As far as FEATURES, I just use ccache and parallel-fetch - nothing very esoteric there I don't think.

Kernel source tree appears intact ..If I copy my archived .config from /boot, I can recompile the kernel so I think that is a pretty good indication that most of the kernel tree is intact.  Also, eselect still has my current kernel source tree listed as the active kernel (I would expect that, if depclean actually were to unmerge and delete the kernel source tree or any part of it, that eselect would have been updated as well or maybe that is too much to hope for!)

.config is definitely blown away though as I said not sure what caused it ... from timing perspective it seems like it might have been the depclean (I also run eclean to reduce my /usr/portage drive space, revdep-rebuild and lafilefixer too of course but I cannot imagine any of those clobbering my .config).  I will experiment tomorrow morning (system at work now) and see if I can repeat the deletion effect with just depclean.

----------

## DONAHUE

Emerge a kernel of the same type but a newer version than the one in service, run emerge --depclean without protecting the kernel in service, try to recompile the kernel in service. What ought to be and what is are not always the same  :Smile: .

----------

