kernel-kit misbehaves in kernels versions without sublevel version

[peabee]

kernel-kit gets confused with kernels numbered like 4.9

Sometimes it uses 4.9 sometimes 4.9.0

e.g. the huge kernel is called huge-4.9-lxpup.tar.bz2 but within it the naming is /lib/modules/4.9.0-lxpup-32-pae in the zdrv

but in the kernel_sources-4.9-lxpup.sfs it is /lib/modules/4.9-lxpup-32-pae

[wdlkmpx]

i think it's because of 'remove_sublevel=yes'

kernel_srcsfs_version=4.9 if [ "$remove_sublevel" = "yes" ] ; then kernel_srcsfs_version=4.9.0

[peabee]

Too soon closed.....

A rebuild of 4.9 with the above mod shows that the kernel sfs and the sources sfs still name /lib/modules inconsistently:

/kernel-kit/dist/packages/linux_kernel-4.9-lxpup/lib/modules/4.9.0-lxpup-32-pae kernel-kit/kernel_sources-4.9-lxpup/lib/modules/4.9-lxpup-32-pae

[peabee]

Problem continues with kernel 4.10 - see: https://github.com/puppylinux-woof-CE/woof-CE/commit/1a938d324b56a34834c62a395865789e6388e040

[mavrothal]

reopen as needed

[peabee]

I don't believe this has been fixed - so should remain open....

[mavrothal]

Aufs changes is a bit behind the forefront kernel version. Did you try recently? Did not see any complains in the stretch/ascii forum thread. In general I would monitor Aufs mailing list for fully supported kernels and possible problems.

[peabee]

Nothing to do with aufs.... 4.10 build had the problem Just made 4.10.2 and as the kernel has moved on there is now no problem.... Will resurface when 4.11 is released and then 4.12, 4.13 etc

[mavrothal]

Ok, I was confused looking at the quoted commit above (1a938d3) So basically the build fails when there is no sublevel number. Correct?

[peabee]

Correct. Not a total fail - just that the the /lib/modules naming is different in the kernel sfs vs. the kernel sources sfs. See original issue report above.

[mavrothal]

Is this happening regardless of the remove_sublevel value (in woof-CE/kernel-kit/build.conf)? I'm not sure why @dimkr and @01micko were messing up with sublevel (aufs compatibility?) Hopefully they'll show up before we are forced to start digging.

[dimkr]

@mavrothal, by resetting the sublevel you're able to load third-party modules built for x.1 when you update the kernel to x.2. This way, third-party drivers can be uploaded to the PET repo while minor versions of a puplet also update the kernel to the next stable release, without breaking anything. There's no reason not to do this update, as it only fixes bugs without adding features.

[peabee]

the remove_sublevel value is set to no in my builds - I have never tried setting to yes no is the default I believe

[wdlkmpx]

To fix this we have to take into account the kernel sources tarball/directory filename.

At least the extracted sources must match the actual kernel version: 4.9 -> 4.9.0. This requires a proper hack. Will push something later for peebee to test, although I have some other changes i made 2 weeks ago that like i'd to push first, it was split into 6 commits but

[peabee]

4.11 Still a problem - sources .sfs has misnamed /lib/modules folder