I'm trying to build the 4.6.4 kernel and create packages to install it alongside the default 4.4.x of Slackware 14.2. I haven't been able to find any Slackbuilds for building the kernel, so I'm doing it manually for now, and will write my own once I figure it out.
I've been using this post for reference:
http://www.linuxquestions.org/questi...3/#post4893452
So far I've used the 4.6.x config file in 14.2 testing to build the kernel (huge rather than generic for now) as well as the modules, but I have some questions on how to create the packages properly.

The kernel itself is easy enough. Copy the bzimage, system.map, and config to the "boot" directory in the package location and create the package.

For the modules, after building I ran make modules_install with the INSTALL_MOD_PATH set to another package directory. However, it creates both the modules AND the firmware directories. I'm guessing I'll want to package these separately so that I can install them independently, much like the regular kernel packages. The modules seems to make sense, as installing it will put it in its own directory. However, firmware looks like it would replace the current firmware directory, meaning the 4.6.x firmware would be used by whichever kernel I was using. Is this desirable? If so, would I install the firmware package I create using installpkg or upgradepkg?

As for the packages to create, in addition to huge, modules, and firmware, I'm assuming I'll want to create packages for generic and source. Is there anything I'm missing? (Also, since the modules were built using the huge config, would I need to rebuild them with generic, since that's what they'll be used with?)

Any advice on creating kernel packages would be appreciated, as this is my first time trying to do my own.

I think you'll be interested in this. This is Pat's SlackBuilds for generating packages for the kernel.

1 members found this post helpful.

And here are mine, though a little non-standard.

I usually use something like:
./build_kernel -s /usr/src/linux -c config-file -C '-custom'

I recommend always using a LOCALVERSION string (the -C argument will override whatever is specified in the config file).

The buildpkg script is an optional dependency that will allow you to build as non-root users, though the build_kernel script will try and use su if it's not present. I use buildpkg in most my build scripts in place of makepkg. It requires a rule in sudoers to work however.

Anyway, you might find them interesting, or over-engineered, or possibly both

I've been using it successfully for a few years now, but as always... No warranty, use at your own risk... blah blah...


p.s. don't forget to remove the .txt extension, and read the usage comments in both scripts if you're going to risk using them

2 members found this post helpful.

I used to use original SlackBuilds from Pat to install an updated kernel manually. Only thing i had to be carefull is that the kernel SlackBuild overwrite the vmlinuz symlinked to bzImage file (huge or generic) on /boot so i had to add some different name to the package or redo the symlink manually, i can't remember what i did.

What i did was in the .config, before make, i set an append to the kernel name. This way i could build a different kernel from same version without overwriting files from the existing kernel and modules.

Also if you run https://slackbuilds.org/mirror/slack...are.SlackBuild it will download the actual date data from git repository.

1 members found this post helpful.

To add to my previous message, I will say that I don't bother with creating packages for kernels (pretty much the only software I do this for... everything else is installed using Slackware packages, whether I create them myself or use someone else's SlackBuild). Due to their simplicity in regards to install locations, I am perfectly content to just install them manually and remove them manually if needed. You only need to clear out the source, the modules, and your stuff in /boot/. But then I also don't normally remove kernels either. They are one of the few pieces of software that doesn't care if multiple versions are installed since they are independently referenced by version.

1 members found this post helpful.

Here are (even less standard) scripts we use to build linux-libre kernel

2 members found this post helpful.

Awesome information! I almost went your route, bassmadrigal, since it seemed simple enough. But just in case my memory fails me, I may just make the packages anyway, since it's easier to keep track of everything.
Also, what about the firmware directory? I was told by another source I could just overwrite it with the new firmware, as it should be compatible across versions. But wouldn't that cause issues with the package tracking?

Syl, firmware locations are consulted in this order:

/lib/firmware/updates/$(uname -r)
/lib/firmware/updates
/lib/firmware/$(uname -r)
/lib/firmware

If you don't want to mangle the installed package, you can remove it and install new firmware into the default location /lib/firmware. Or you can install new firmware into one of the other dirs above, and it should, in theory, take over.

P.S.: kernel firmware is not the only package installing into /lib/firmware. Some binary blobs are also found in /n/ group.

P.P.S.: Actually, locations above are valid for udev. I don't know whether they are valid for eudev. Indeed, it looks like eudev 3.x does not load any firmware (is that right?), but instead the kernel now loads it with CONFIG_FW_LOADER=y

Also, since CONFIG_FW_LOADER_USER_HELPER=y in the stock config, the loading is then passed to the userspace, but there is no agent to load it there now, at least according to this post:

https://forums.gentoo.org/viewtopic-...626eae1e38f812

I wish someone with greater kernel-foo would clarify how the firmware is loaded in 14.2.

1 members found this post helpful.

What do you mean? removepkg won't remove a file that is contained in another installed package.

I decided to go with the slackbuilds for now, as they'll fulfill my needs, although I have saved the other scripts for potential use, as they're very handy.
One more question. How would I build and create a package for the kernel headers?

The Traditional advice on this has always been that the kernel headers are closely related to glibc and you shouldn't update the headers unless you're also going to rebuild and reinstall glibc. The downside of this approach is any new kernel APIs won't be exposed. The upside is nothing breaks.

Having said that, I don't think headers are any more complex than:
PKGTMP=/tmp/somewhere
make INSTALL_HDR_PATH=$PKGTMP/usr headers_install

...adding a slack-desc file and packaging it up in the usual manner. But if I'm wrong, someone please correct me.

1 members found this post helpful.

Ah I figured it out. The kernel itself loads the userspace firmware (drivers/base/firmware_class.c) in the same fashion as above.

I'll side with GazL: it may be more helpful to think of kernel-headers as "glibc headers" and leave them the way they are.

http://docs.slackware.com/howtos:sla...eaders_package

1 members found this post helpful.

When updating the kernel I only update the packages kernel-generic (I usually run the generic kernel) and kernel-modules.

After extracting the kernel source to /usr/src I make a new symlink for /usr/src/linux that points to the extracted source. Then I copy the current kernel config to /usr/src/linux/.config

Then I rund make menuconfig, load the kernel configuration from .config. Now I start make the desirde changes and append a local version (-xxx). When I am done with my changes I save, exit and run:
After the compilation is done, I modify the official SlackBuild (kernel-generic.SlackBuild and kernel-modules.SlackBuild) to use my local version (-xxx). I create the packages and use installpkg (not upgradepkg) to install the new packages.

I do not update the kernel-headers because the headers expose the kernel's API for use by Glibc and one would have to rebuild and reinstall Glibc for that.

Untill today I never had to update the kernel-firmware. If I had to I would use the official SlackBuild and use upgradepkg to upgrade the kernel-firmware package. As I understand, the kernel-firmware is independent and I would not have to recompile anything else.

I hope that helps.

Well, I've got everything up and running to my satisfaction. Thanks to everyone for the advice!