# Life after Pappy's Kernel Seeds.

## TheLexx

It seams the old adage "You don't appreciate what you have until it's gone", is true when it comes to Pappy's Kernel Seeds. I suppose that I am one of the last people to have used this service to feel the sting of it's loss, because I am one of those people who use the  longterm stable kernels

I am currently running all my computers on the 3.4 Longterm stable series kernels. I stared using the 3.4 series shortly after the Greg Kroah-Hartman Team declared that they would maintain it. They did a great job and the team did a smooth hand-off to Li Zefan, who continues to patch in with bug-fixes in a timely manner. The current EOL projection is in about 10 months, so I've been shopping for a replacement, I've pretty much settled on the 3.14 Longterm stable series that is being maintained by the Greg Kroah-Hartman Team due to the fact that I feel that I can trust them to keep the updates coming.

When I first created a ".config" file for my 3.4 kernel, I used Pappy's Kernel Seeds, then I used "make localmodconfig" to cut-down on the unnecessary module creation. As I upgraded within the 3.4 series, I just use the command "make oldconfig" each upgrade. This command just verifies that the ".configure" file is still good. Most/all the time "make oldconfig" left the ".config" file unchanged other than the kernel number.

Now without Pappy's Kernel Seeds, I'm trying to figure out the best way to configure my "new" 3.14 kernel. One way I can update my configuration, is to use oldconfig to move from 3.4 to 3.14. However with this plan, oldconfig ask me tons of questions regarding new ".config" options. If the option is concerning a new driver for a hardware unit, I can just answer no and then later compile modules if I decide I need the driver. My quandary is that some of the new options are for new kernel features. For these new kernel features, I do not know what the best settings are.

An alternate way that I could deal with the upgrade is to use Gentoo's sys-kernel/genkernel. I would rather copy/rename the kernel and adjust grub myself, but I suppose that genkernel might be helpful to setup ".config". I have not messed with genkernel in a very long time, because I just used Pappie's seeds. I'm wondering how hard it will be to find a version of genkernel that will work with the 3.14 line of Linux kernels.

Any thoughts on the best way to upgrade to the 3.14 line?

----------

## Tony0945

When you run "make oldconfig" just keep hitting RETURN to take the default choice. A few items don't have a default and you have to figure out which to choose.

If you run genkernel, definitely choose to start with your existing kernel and not a default kernel.  Copy your present .config to say "pappys_config". If you lost it and hopefully configured  CONFIG_IKCONFIG=y then just "zcat /proc/config.gz >pappys_config"  and "genkernel --config=pappys_config --oldconfig --menuconfig all" The --oldconfig might be a default. When the menuconfig appears, pay particular attention to the new Gentoo options which is the top menu item. You might want to review your /etc/genkernel.conf to make sure you have the right bootloader and other options.  The bootloader options are "grub" which is for grub legacy and "grub2" which is for grub2. If you use something else don't do an automatic install because it will create a grub menu if one doesn't exist.  This is for stable genkernel. I have no experience with the new modular genkernel.

----------

## The Doctor

 *Tony0945 wrote:*   

> When you run "make oldconfig" just keep hitting RETURN to take the default choice. A few items don't have a default and you have to figure out which to choose.

 Then you are just using make oldnoconfig the hard way then.  :Wink: 

Actually, I'm still using a .conf from pappy's seeds. I use the make oldconfig and take the time to accept or reject the proposed changes. Less cruft sneaks in that way, but I'd certainly be happy to see his seeds make a come back.

I'd stay well clear from Genkernel. It works because it takes the shotgun approach and turns everything on. Make oldconfig with google in a browser seems to work very nicely.

----------

## Tony0945

 *The Doctor wrote:*   

> I'd stay well clear from Genkernel. It works because it takes the shotgun approach and turns everything on. Make oldconfig with google in a browser seems to work very nicely.

 

ONLY if you accept a default config instead of specifying. Of course, it does make a (useless) initramfs even if you have specified no initramfs in the kernel config.

Your way is certainly very good, tight, too the point, and traditional. But the O.P> did ask about genkernel. I sually recommend the default genkernel only to newbies that have never built a kernel and are doing their first install. It helps them to get their system up so that they can refine it later, rather than quiiting in frustration. And it can be frustrating. I was quite frustrated my first time, but only the knowledge (and professional pride) that I had rolled my own complete embedded systems, with and without bare bones RTOS kept me going.

Lately I've been intrigued with the idea of starting with a genkernel default config then running "make localmodconfig" afterward. I only became aware of this make option last week and have used it to remove cruft from my kernels. Didn't make them much smaller, but why try to load modules that are going to fail? I like a non-bloated optimal system. It's a thing of beauty. So many of today's soi-disant "Software Engineers" are in it for money and power, not pride of craftsmanship. That's why I like hanging out here. There are about half a dozen like-minded people (including yourself). Besides, now that I'm retired what would I do? Watch old sitcom reruns on TV? Go shopping with my wife? (Horrors! I'd rather watch the fiftieth re-run of M*A*S*H)

Editted for typoLast edited by Tony0945 on Thu Sep 17, 2015 1:22 pm; edited 2 times in total

----------

## krinn

 *TheLexx wrote:*   

> It seams the old adage "You don't appreciate what you have until it's gone", is true when it comes to Pappy's Kernel Seeds. I suppose that I am one of the last people to have used this service to feel the sting of it's loss, because I am one of those people who use the  longterm stable kernels

 

I'm not him so i couldn't speak for him ; but i would certainly be disappointed that you use its kernel seeds and never learned from it ; i don't think he has made it for anyone to not have to do their own work and learning.

I think he made it as a sharing knowledge, if you didn't learn anything from it, sad, as it would mean at least his all good work has produce no result on you.

Sure the seeds are big lost for new comers but for his "old" users, it's a shame if they didn't learn themselves from him howto build their own seed.

From what i remember, seeds were like 0.1% of his www, and 99.99% of its content was explaining why he use this option or not, what option is for, what option is good for what usage... so 99.9% of knowledge.

----------

## steveL

I thought funtoo had taken the project on?

----------

## NeddySeagoon

steveL

Kernel Seeds

The old site is still up, as is my mirror.

----------

## TheLexx

 *krinn wrote:*   

> I'm not him so i couldn't speak for him ; but i would certainly be disappointed that you use its kernel seeds and never learned from it ; i don't think he has made it for anyone to not have to do their own work and learning.  I think he made it as a sharing knowledge, if you didn't learn anything from it, sad, as it would mean at least his all good work has produce no result on you.

 

I really take issues with your statement that, I have learned nothing from the use of Pappy's Kernel Seeds.  When I upgraded to the 3.4 series, I looked over what was written to choose the best seed. What happened was, I found a kernel that worked well and found no need to improve it.  I added new hardware, and moved up the 3.4 tree with oldconfig, thus using the provided bug fixes.  During the last few years, I used my studying to understand user space on a Linux system. I have also become obsessed with what is required for a minimal system.

I have been compiling Linux kernels since the late 90's and I would say that unless a person spends considerable time on JUST THE KERNEL, the settings have become more abstract and confusing for the "journeyman kernel compiler". My first distro was Redhat 5.2, at that time, the user would start with a "canned kernel". However, it was expected you would complete the instillation process by compiling a kernel specifically for your computer. I complied kernels 2.0.x, 2.2.x and 2.4.x. In those days, there were far fewer kernel specific options (not those options relating to hardware drivers). At that time, it was practical to read the text in "menuconfig" for all kernel specific options. The questions were relatively simple, such as do you allow for a asymmetric multi-core processor. Do you want to allow for kernel preemption, etc.  When I upgraded past 2.6.0, I noticed that there were many more options, and the options themselves are quite a bit more abstract. Before finding kernel seeds, I would compile a 2.6 kernel I would read the description and find myself saying, "What the hell does that mean" then just choosing the default.

Today, I was about to create a text fie using the results of make oldconfig to farther my study the new (3.4 -> 3.14) options.  I might be able to find Pappy's opinion on the subset of those new options added before the Kernel seeds went dormet.  There are most likely new options added to 3.14 that were not present even in the last kernel that Pappy put in his archives.

PS. There only so many hours in the day, and to be honest I really need to spend more on projects that have real world benifits. Otherwise, I will just my days working at a retail job that barely pays above minimum wage.

----------

## saellaven

Note that, every release or two, one or two of the default config options in make oldconfig is set in a way that disagrees with the recommended setting for that option. You should always take the time to at least major sure the defaults are sane before accepting them.

----------

## Tony0945

 *saellaven wrote:*   

> Note that, every release or two, one or two of the default config options in make oldconfig is set in a way that disagrees with the recommended setting for that option. You should always take the time to at least major sure the defaults are sane before accepting them.

 

SLOB, SLUB, or SLAB. I have no idea what to pick, so I took the default (SLUB IIRC). The default disagreeing with the recommendation might be a mistake but maybe (the way I would do it) the default is the existing but the new way is recommended.  There really is not enough information about these releases except for those intimately involved.

Edit: Besides, 90% of the choices are drivers for hardware I never heard of.

----------

## steveL

@TheLexx: you should really try: make nconfig instead of: make menuconfig

(after oldconfig when upgrading.)

Cheers, Neddy; doesn't look like anything's happened with it.

From the old site, Pappy got up to 3.10.20 and 3.12.1.

Maybe it'd be a good idea to do a 3.18.x or w/e the LTS version is round there; 3.10 was stable for ages before that.

Then move on to a later one.

----------

## ct85711

stevel:  What is so special about nconfig over menuconfig?  I'm just wondering, as I've never used that one so I don't know why that one is being recommended.  From a quick search indicates nconfig is also using ncurses like menuconfig.

----------

## steveL

Try It And See ;)

----------

## pappy_mcfae

To be honest, I am a bit sad that it the seeds have more or less died. I still have them, and I do update, but only on my schedule. For instance, this machine has an updated 4.1.6 kernel, and other than the machine running it being slower than molasses in January, it still runs pretty well.

When updating, it's fairly easy. Using make oldconfig, you simply answer "n" to new drivers. If there are other options that don't seem to be driver based, hitting the "?" will give you the smallest amount of help. Generally speaking, unless they're making a previously silent default option a choice, hitting "n" will usually get you to a decently operational kernel.

And yes, part of the idea of the seeds was to teach people a little bit about what goes on inside their computers. It is my hope that someone, or many someones learned a bit more about their computer from working with a seed and the information required to successfully get a kernel up and running with as little cruft as possible in the .config.

Cheers,

Pappy

----------

## NeddySeagoon

pappy_mcfae,

kernel-seeds.org is still a valuable resouce even without a current seed.

The methods it describes still work and I still refer users who ask how rather that what to it.

I still have various incarnations of my kernel-seeds mirror too.

----------

## pappy_mcfae

I can't begin to tell you how much I appreciate that. I have been thinking about getting back into doing the seeds, but on a much more limited scale. The way I did it previously was extremely time consuming, especially on nights where the devs of every kernel version I worked with decided to do a three or four version dump all at once. 

If I do it again, it will be more along the lines of one master seed for each family. That means, if you want to configure a 4.1.8 kernel, I'd make just a 4.1.0-vanilla-sources version, and all updates within families would be done by means of make oldconfig. Do you want 4.1.6-gentoo-sources? Do the same thing. 

That would, of course, make it a bit more educational, if only for the minor adjustments made inside a particular family. Doing a discreet seed for each version is just far too taxing for one dude with three computers. 

Cheers,

Pappy

----------

## steveL

It would rock if you came back, Pappy.

wrt doing master for series, and letting people do the oldconfig, that sounds fine to me; but bear in mind that you have helpers here, and we can always do the oldconfig thing, and try to emulate your style, which you could then review and post/move to the other section.

IOW you're not alone, and should feel free to make use of willing helpers.

After all you've helped all of us. Let us return the compliment.

----------

## Tony0945

 *steveL wrote:*   

> It would rock if you came back, Pappy.
> 
> wrt doing master for series, and letting people do the oldconfig, that sounds fine to me; but bear in mind that you have helpers here, and we can always do the oldconfig thing, and try to emulate your style, which you could then review and post/move to the other section.
> 
> IOW you're not alone, and should feel free to make use of willing helpers.
> ...

 

100% in agreement! And that's a commitment.

----------

## steveL

Yay! Cheers, Tony :-)

See, Pappy? ;)

Any more for any more? Don't be shy, and feel free to join in at whatever point.

It's going to be a great learning-experience, for anyone who does help out with the project.

Speaking of which, any chance of a 3.18.x to base off, Pappy?

----------

## Nicias

This would be much appreciated! I've been using makeoldconfig from your last seed as well.  One seed for each major version would be great!

----------

## NeddySeagoon

pappy_mcfae,

I'll still be around to help your users and donate a mirror.

One update per  

```
VERSION = 4

PATCHLEVEL = 1

SUBLEVEL = 3
```

SUBLEVEL would be more than adequate as options are normally only added at PATCHLEVEL changes.

Users not using the correct SUBLEVEL seed would neeh make oldconfig but it would run with no questions most times.

My mirror has moved from France to Germany and its now a KVM rather than a hardware host. 

I got a lot more bang for my Euro by moving providers.  I still rent the real hardware the KVM runs on.

----------

## TheLexx

Over the past week, I've been thinking about what might be a replacement for Pappies Kernel Seeds.  There was/is a Funtoo project that tried to replace it, but it does not seem that the project has gotten off the ground. I may try to send this post to that project.  I have an idea for an alternative to the seeds project that might provide much the same benefit as the Pappy's Kernel Seeds project did, and at the same time, require less work to maintain.

The problem that I wish to address in not the lack kernel documentation, but the feeling that combing through all the available documentation is like drinking from a fire hose.  I believe that something is needed to help cut through the mountains of information on kernel options. There is simply not enough time for the "casual" person who may be interested in compiling a kernel to read through everything. 

I've come up with an idea for a project I call "The Hitch Hikers Guide to Kernel Configuration", to help remedy the situation.  My idea is to create a small number of kernel config files, paired with a tuning file. The tuning file would be a text file that informs the user of kernel options that he/she should consider for altering prior to compiling the kernel. The tuning files would be designed to help users tune the kernel to work in a particulate situation. The information would be prioritized to put the information with the greatest effect first.

Under my vision of the Hitchhikers guide to kernel configuration the goal is to only produce a small number of configuration files for each supported kernel line (kernel 3.18.X where X could any number grater than 18 would be an example of a kernel line) he HHG would produce far fewer configuration files per kernel line than the Pappy's Seeds project did.  Using HHG the user may be expected to use "make oldconfig" to prepare the seed for use, unlike Pappy's Seeds.

Part of this different philosophy would result in x86-32 and x86-64 using the same seed. The tuning file that described how to transition between 32bit and 64 bit mode. If there were people willing to take on other architectures there could be seed/tuning file pairs for Arm and IA64, etc.

The overall philosophy of the tuning file is that the information is prioritized with the most important info at the first of the file. The tuning file would then be divided into the "Critical Section" and the "Performance" Section. Because most x86 users now-a-days use 64-bit machines the x86 seed would be tuned to for 64-bit use. For users using 32-bit architectures changing this setting is critical to producing a kernel that will run on there system. Therefor information on switching to a x86-32 will appear in the critical section of the tuning. The "Critical" section and the The Critical section would contain only those config file options that will prevent a kernel from booting altogether.

----------

## ulenrich

@TheLexx, here you'll exactly find the templates of what you desire:

http://ftp.heanet.ie/pub/aptosid/debian/pool/main/l/linux-aptosid/linux-aptosid_4.2-7.debian.tar.xz

----------

## steveL

 *TheLexx wrote:*   

> Over the past week, I've been thinking about what might be a replacement for Pappies Kernel Seeds.  There was/is a Funtoo project that tried to replace it, but it does not seem that the project has gotten off the ground. I may try to send this post to that project.  I have an idea for an alternative to the seeds project that might provide much the same benefit as the Pappy's Kernel Seeds project did, and at the same time, require less work to maintain.

 

Huh? YTF don't you just help out with Pappy's Kernel Seeds?

It's a wiki, people.

There's several of us here discussing restarting it, so it's quite weird to watch you talk past us, as if none of us had spoken.

----------

