Backlight class isn't present

[gerald_clark]

If you compile a new kernel, you need to compile all the modules you need.
Some packages depend on extensions that are named after the kernel version.
You will need to create all these packages too.

[Scampada]

And if I patch a TC kernel with an incremental patch, e.g. 3.16.6-7 then all those modules won't work too?..

[gerald_clark]

Each kernel version has its own modules directory.
You can compile additional modules for an existing kernel, but when you compile a kernel with a different name, you also need all new modules.

[Scampada]

Strange... I'm trying to rebuild a patched kernel. And something's wrong...

I have linux-3.16.6-patched.txz, fbcondecor-3.16.patch (and a linux-3.16.6-7.patch).
I extract kernel source then do patch -p1 < ../fbcondecor-3.16.patch then make.

All these files I also have used last time I had been rebuilding the core. A few months ago. They mustn't have changed. Last time I'd patched and typed make and there was no errors. Today I see "HUNK FAILED" and after trying 'make' it wastes my time for about half of a hour building and gets stuck with "recipe failed", obviously because of failed patch.

Strange... what could've happened

[Rich]

Hi Scampada

Today I see "HUNK FAILED" ...

This gives a couple of possibilities for the cause of that type of error:
http://stackoverflow.com/questions/14282617/hunk-1-failed-at-1-whats-that-mean

[Scampada]

I have seen that Q&A article, thanks. But this doesn't still make obvious why that would happen. The files I used were not being changed from last time I built the core...

PS Yeah. That what could have changed... is subdirectory level.

Then: patch -p1 < ../fbcondecor-3.16.patch
Now: patch -p1 < ../../fbcondecor-3.16.patch

I mean... Don't I need to set -p2 instead of -p1 in the last case?..

[Scampada]

I mean... Don't I need to set -p2 instead of -p1 in the last case?..

I wasn't sure about this. -p2 option didn't work, so I just copied patches from ../../ to ../ and all is going well now.
Yet another gap in my experience. Or, maybe, yet another experience in my gap.

[Scampada]

Including modules in the initrd is no different to an extension, as long as they're properly integrated - depmod files updated.

I'm afraid you have a kernel bug in the i915 driver. Since other distros work, it's propably fixed in later kernels. Search for your model in the commit logs, etc.

You were right about a bug; I have rebuilt the core with a 3.16.7 patch and now backlight is working fine. There is small problems though, but they are not critical. The first is, new 3.16.7 modules folder for some reason weighs about 60 Mbs, while old 3.16.6 modules folder weighs about 7 Mbs. This ends up in very heavy core.gz, its weight is about 50 Mbs.

The second is, I don't even want to mention this, my fbcondecor splash vanishes when backlight module is loaded during boot... I will resolve this myself. Btw is there some early-stage splash for Tiny Core? Newer than fbcondecor which is a bit outdated.

[gerald_clark]

The old modules folder only contains modules needed to boot and install on most systems.
The rest of the modules are in the various packages loaded by extensions that depend on them or by users that know they need them
for their hardware.

[Scampada]

All right. So I could just compare both folders file list and drop all files from the new folder that aren't present in the previous?

[curaga]

Well, you also want the graphics and backlight modules, and maybe some others, so keeping the same set wouldn't be enough.

[Scampada]

Sure, but default set contains backlight module.
Look, I have now 3.16.7 kernel and those extensions that have $(uname -r) in their names do not load at boot. The kernel looks for module-3.16.7.tcz and even when I try to load them manually they decline to load their dependencies for the same reason.

Is it correct if I just rename all extensions from e.g. alsa-modules-3.16.6-tinycore.tcz to alsa-modules-3.16.7-tinycore.tcz?Maybe it's a crude way.
I've tried to build the kernel with a bogus version string. There was said that version string is set inside of top level Makefile. There was base version=3, subversion=16 and something_else=7. I've changed 7 to 6 and started building. Nevertheless, modules were compiled as 3.16.7 and after I havebooted into new kernel uname-r showed out that I'm after all in 3.16.7.

So, what is the most accurate and elegant way to break make the system load all these modules that contain uname output in their names? Without a new rebuilding, please...

For now, I did something like this...

ln -s /etc/sysconfig/tcedir/optional/*3.16.6* /etc/sysconfig/tcedir/optional/*3.16.7*

and just in case

sudo ln -s /lib/modules/3.16.6-tinycore /lib/modules/3.16.7-tinycore

It seems for me that extensions' loading takes quite longer than before... it THINKS when loading

Hm... what if I do

alias uname -r='echo 3.16.6' ?
well... kinda joke

[Misalf]

As gerald_clark said

Each kernel version has its own modules directory.
You can compile additional modules for an existing kernel, but when you compile a kernel with a different name, you also need all new modules.

I'd say "the most accurate and elegant way" would be to create extensions using correct directory structure, containing the modules that were built when you compiled the kernel.

Alternatively, you could add modules to your initrd. This would use more RAM, though, depending on how much you'd add.

[Scampada]

As gerald_clark said

Each kernel version has its own modules directory.
You can compile additional modules for an existing kernel, but when you compile a kernel with a different name, you also need all new modules.

I'd say "the most accurate and elegant way" would be to create extensions using correct directory structure, containing the modules that were built when you compiled the kernel.

Alternatively, you could add modules to your initrd. This would use more RAM, though, depending on how much you'd add.

1. Well,,, the most accurate way to do this quick.
But if I have to... I will. I would. I have to look how to unpack them first, then change their contents, then pack again, for I need not recompile them all I guess. Tcz-tools provides a packaging script, but tcz unpacking is too obvious to have an entire script for it, I believe. It's just a squashfs image, so... *mumbles*

2. I can. But I also will have to edit all tcz.dep's to remove module packages. Otherwise extensions will check for dependencies, right? And won't find them.

[curaga]

wget 'http://git.tinycorelinux.net/index.cgi?url=sorter/plain/sorter.sh'

That is the script we use to create the module extensions.