I did of course read it but not carefully enough. As a side note, I think it would be better if the selected kernels were on separate lines or at least seperated by a comma. My brain only saw 3.6.11-r1

Anyway, when I try to

Quote:

emerge -pv =sys-kernel/gentoo-sources-3.8.4:3.8.4

which is what I did to originally get the kernel it throws a

Quote:

emerge: there are no ebuilds to satisfy "=sys-kernel/gentoo-sources-3.8.4:3.8.4".

I really did spend a lot of time configuring the 3.8.4 how do I get the gentoo sources again for it??? I won't be rebooting for a while because I don't want it to fall back to the 3.7-r1 and find everything broken again. Haha.

You can safely install gentoo-sources-3.8.12 keeping the .config you built for the 3.8.4. They are perfectly compatible. So the time you spent configuring the 3.8.4 won't be lost.

My opinion is that it is far better than trying to restore whatever obsolete kernel of the same branch.

BTW, next time you emerge kernel sources, emerge them --noreplace =gentoo-sources-X.Y.Z, this way, you'll prevent depclean to behave as you experienced.

Edit : I had forgotten to answer the question title of the thread : 3.8.4 went to some dustbin ! Because devs (rightly) believe that now that higher releases of the 3.8 are made available in the tree, there are absolutely no reason for anyone to prefer the 3.8.4_________________

Last edited by aCOSwt on Sat May 11, 2013 4:28 pm; edited 1 time in total

If you want to keep a kernel for longer than a month then consider using a stable kernel, 3.8.13 is about to get introduced and stabilized soon if you want to pick the right one. Unstable versions in Portage are meant for people whom want to test them and like to compile / upgrade more often (which translates to a kernel upgrade every month, whereas new versions are released almost every week); 3.8.4 is nearly two months old, we don't need anyone testing these old unstable versions anymore. In fact, we advise anyone on these to upgrade...

Budoka wrote:

Little frustrated but mostly at myself. I inadvertently uninstalled kernel sources for 3.8.4 which after much time and effort, trial and error, I got to work perfectly with my hardware.

You can copy the .config (which didn't get removed; if it did, you can extract it from the kernel) to a newer kernel, then follow the upgrade instructions ([1] or [2]) after which your hardware should still work; don't forget `emerge @module-rebuild`.

The following configuration parallels that of the text based configuration with make config. For every difference between the kernel versions, it asks if you want to activate the driver or feature. An example:

The string (NEW) at the end of the line marks this option as new. Left to the string in square brackets are the possible answers: Yes, no, module or ? to show the help. The recommend answer is capitalized (here Y). The help explains the option or driver.
Unfortunately make oldconfig doesn't show - next to the help - a lot more information for each option, like the context, so that it is sometimes difficult to give the right answer. In this case the best way to go is to remember the option name and revise it afterwards through one of the graphical kernel configuration tools.

I don't know about genkernel, but I would think that you just copy in the old .config, cd to the new kernel and do a "make oldconfig" and when thats done do a genkernel? I've done this several times using "make xconfig" and everything has transfered nicely._________________"We have/need art, so that we don't die of the truth." -- Friedrich Nietzsche

I did of course read it but not carefully enough. As a side note, I think it would be better if the selected kernels were on separate lines or at least seperated by a comma. My brain only saw 3.6.11-r1

You can use update to maintain your install: it does --depclean after a world update (ie when you call it just as update) before revdep-rebuild, and after glsa-check. There's some custom code to stop it removing both your running kernel and the /usr/src/linux-linked kernel, as I ran into the same issue a few years ago, and often don't upgrade kernel for a couple of versions. (I don't have USE=symlink any more, as it should reflect what's running, but keeping both has saved me in the past when I'm in-between changes.)

It also won't let you upgrade kernel-headers to later than your running kernel. (eg: if 3.9 headers are available and you're on 3.8, it'll skip them and warn you to upgrade your kernel first.) If you do try it, I'd recommend the git version as it's kept more up to date, though I will put out a new ebuild version soon. (New features come in disabled by default, and the people I work with use the git master branch, so it's kept bug-fixed, or I hear about it straightaway;)

Good luck with make oldconfig anyhow. I normally just do that, then a make nconfig to review.

With genkernel the method I use to build a new kernel based on the .config of the current kernel is

Code:

zcat /proc/config.gz > /usr/share/genkernel/arch/x86_64/kernel-config

The destination address " /usr/share/genkernel/arch/x86_64/kernel-config" should match the address that genkernel prints when it builds a new kernel. If genkernel has already built the kernel and you want to throwaway its configuration file you have to remove it from the directory /etc/kernels.