[SOLVED] Civil Infrastructure Platform Kernel slackbuild

kjhambrick · 04-07-2023, 08:25 AM

Quote:

Originally Posted by Didier Spaier

The compression method (if any) ...<<<snip>>>

Thanks for clearing that up Didier Spaier !

-- kjh

kjhambrick · 04-07-2023, 08:43 AM

Quote:

Originally Posted by bigbadaboum

Hello kjhambrick and saxa

I started the migration from the linux-4.4.302 kernel to linux-cip-4.4.302-cip 73 only last month.

if I replace the linux-4.4.302 file.tar.xz by the linux-cip-4.4.302-cip74 file.tar.gz in the SlackBuilds, the job creates a kernel-generic-4.4.302-x86_64-1 package.txz and nothing more.

I did get a kernel-modules-4.4.302_cip74_st39-x86_64-1.txz Package. ( note the underscores, instead of the 'CIP-native' dashes ).

BUT, the kernel-modules Package has no kernel modules in it:

Code:

[root@bupbox pkg]# tar -tvf kernel-modules-4.4.302_cip74_st39-x86_64-1.txz

drwxr-xr-x root/root         0 2023-04-04 17:23 ./
drwxr-xr-x root/root         0 2023-04-04 17:23 lib/
drwxr-xr-x root/root         0 2023-04-04 17:23 lib/modules/
drwxr-xr-x root/root         0 2023-04-04 17:23 install/
-rw-r--r-- root/root      1034 2023-04-04 17:23 install/slack-desc
-rw-r--r-- root/root       164 2023-04-04 17:23 install/doinst.sh

I see the modules in /tmp/moddir/lib/modules/4.4.302-cip74-st39/ but I believe it is because of the -cip74 and -st39 localversion tags and the rules for SlackBuild Packages.

Code:

[root@bupbox pkg]# ls -la /tmp/moddir/lib/modules/4.4.302-cip74-st39/

total 3868
drwxr-xr-x  3 root root   4096 Apr  4 17:23 .
drwxr-xr-x 13 root root   4096 Apr  5 18:32 ..
lrwxrwxrwx  1 root root     32 Apr  3 18:47 build -> /usr/src/linux-cip-4.4.302-cip74
drwxr-xr-x 13 root root   4096 Apr  4 17:23 kernel                          # the expected .ko files are here
-rw-r--r--  1 root root 999046 Apr  4 17:23 modules.alias
-rw-r--r--  1 root root 982428 Apr  4 17:23 modules.alias.bin
-rw-r--r--  1 root root   8334 Apr  4 17:23 modules.builtin
-rw-r--r--  1 root root  11448 Apr  4 17:23 modules.builtin.bin
-rw-r--r--  1 root root 391826 Apr  4 17:23 modules.dep
-rw-r--r--  1 root root 552175 Apr  4 17:23 modules.dep.bin
-rw-r--r--  1 root root    394 Apr  4 17:23 modules.devname
-rw-r--r--  1 root root 140541 Apr  4 17:23 modules.order
-rw-r--r--  1 root root    186 Apr  4 17:23 modules.softdep
-rw-r--r--  1 root root 372747 Apr  4 17:23 modules.symbols
-rw-r--r--  1 root root 466541 Apr  4 17:23 modules.symbols.bin
lrwxrwxrwx  1 root root     32 Apr  4 17:23 source -> /usr/src/linux-cip-4.4.302-cip74

I gave up -- there is too much 'Deby' Specific Code in the CIP Source since the January Release so I turned to 4.14.y instead

-- kjh

bigbadaboum · 04-07-2023, 01:33 PM

Hello kjhambrick

Quote:

root@bupbox linux-cip-4.4.302-cip74]# for i in localversion*; do echo "# cut-here ( $i )"; cat $i; echo "# cut-there"; done

# cut-here ( localversion-cip )
-cip74
# cut-there

# cut-here ( localversion-st )
-st39
# cut-there

thank you this solved the slackbuild problem.

Quote:

I gave up -- there is too much 'Deby' Specific Code in the CIP Source since the January Release so I turned to 4.14.y instead

I have the same judgment as you

sadly my hardware does not support 4.14 I will stay on 4.4.302 (I have no problem with it, it was just to have an up-to-date kernel).
When I saw the CIP entrusted debian with the maintenance of the kernel I had a bad feeling, so we will try it with a lot of goodwill, thank you all.

JayByrd · 04-08-2023, 03:06 PM

I know this thread has been marked solved, but if anyone is interested, I've attached a kernel SlackBuild script. This is basically the same routine that I devised for compiling a custom kernel to keep the ancient nvidia-legacy304 kernel module working on Slackware 15.0. I've stripped out all the nvidia stuff, and it can now be used on its own.

Use the $KTYPE variable to specify what kind of kernel you want. Options are:

Code:

KTYPE=generic
KTYPE=huge
KTYPE=both
KTYPE=all
KTYPE=custom

The script will look in /boot for an appropriate (matching KTYPE) config file. You can override this and search in another directory by setting $CONFIG_PATH variable. Also, the script assumes your KERNEL tree is located at Slackeware's standard location: /usr/src/linux-${KERNEL}. This too can be overridden by setting $SRCPATH variable on the command line.

Setting the variable(s) $MODULES and/or $HEADERS on the command line will instruct the script to build those packages, as well. Alternatively, you can use the KTYPE=all option.

Some examples:

Code:

KERNEL=4.4.302 KTYPE=huge MODULES=y ./jay_kernel.SlackBuild

will build two packages: kernel-huge and kernel-modules.

Code:

KERNEL=4.4.302 KTYPE=both ./jay_kernel.SlackBuild

will build kernel-huge and kernel-generic (but no kernel-modules.)

Code:

KERNEL=4.4.302 KTYPE=all ./jay_kernel.SlackBuild

will build four packages: kernel-huge, kernel-generic, kernel-modules, and kernel-headers.

There are several more configurable options available on the command-line, including the ability to build a Slackware-style install-able kernel-source package by setting the $SRCPACK variable. My apologies for not completing a proper README file...

I've used this script for compiling CIP kernels and it seems to work out of the box:

Code:

jay@fax:~$ ls /var/log/packages | grep kernel
kernel-generic-4.4.302_cip72-i586-1_jay
kernel-modules-4.4.302_cip72-i586-1_jay

jay@fax:~$ uname -r
4.4.302-cip72-st28

kjhambrick · 04-08-2023, 04:47 PM

Quote:

Originally Posted by JayByrd

I know this thread has been marked solved, but if anyone is interested, I've attached a kernel SlackBuild script. This is basically the same routine that I devised for compiling a custom kernel to keep the ancient nvidia-legacy304 kernel module working on Slackware 15.0. I've stripped out all the nvidia stuff, and it can now be used on its own.

Use the $KTYPE variable to specify what kind of kernel you want. Options are:

Code:

KTYPE=generic
KTYPE=huge
KTYPE=both
KTYPE=all
KTYPE=custom

The script will look in /boot for an appropriate (matching KTYPE) config file. You can override this and search in another directory by setting $CONFIG_PATH variable. Also, the script assumes your KERNEL tree is located at Slackeware's standard location: /usr/src/${KERNEL}. This too can be overridden by setting $SRCPATH variable on the command line.

Setting the variable(s) $MODULES and/or $HEADERS on the command line will instruct the script to build those packages, as well. Alternatively, you can use the KTYPE=all option.

Some examples:

Code:

KERNEL=4.4.302 KTYPE=huge MODULES=y ./jay_kernel.SlackBuild

will build two packages: kernel-huge and kernel-modules.

Code:

KERNEL=4.4.302 KTYPE=both ./jay_kernel.SlackBuild

will build kernel-huge and kernel-generic (but no kernel-modules.)

Code:

KERNEL=4.4.302 KTYPE=all ./jay_kernel.SlackBuild

will build four packages: kernel-huge, kernel-generic, kernel-modules, and kernel-headers.

There are several more configurable options available on the command-line, including the ability to build a Slackware-style install-able kernel-source package by setting the $SRCPACK variable. My apologies for not completing a proper README file...

I've used this script for compiling CIP kernels and it seems to work out of the box:

Code:

jay@fax:~$ ls /var/log/packages | grep kernel
kernel-generic-4.4.302_cip72-i586-1_jay
kernel-modules-4.4.302_cip72-i586-1_jay

jay@fax:~$ uname -r
4.4.302-cip72-st28

Wow, Jabird !

Very nice.

I would say that the Request was more [ABANDONED] than [SOLVED]

The threads are long and convoluted, but the punch line is that bigbadaboum and I were finally able to build the Kernel Packages using Pat's SlackBuilds.

But then the Kernels did not boot for either one of us due to the custom mods to the 4.4.302 kernel source for the CIP Reference Machine

One Q: do the resulting HUGE and/or GENERIC kernels actually boot on your Slackware 14.2 OS ?

Thanks for the SlackBuild !

-- kjh

JayByrd · 04-08-2023, 05:06 PM

Quote:

Originally Posted by kjhambrick

Wow, Jabird !

Very nice.

I would say that the Request was more [ABANDONED] than [SOLVED]

The threads are long and convoluted, but the punch line is that bigbadaboum and I were finally able to build the Kernel Packages using Pat's SlackBuilds.

In fact, "my" SlackBuild amounts to not much more than a wrapper for Pat's. All the heavy lifting in kernel_build.functions was pretty much lifted wholesale from the official Slackware kernel SlackBuilds.

Quote:

Originally Posted by kjhambrick

But then the Kernels did not boot for either one of us due to the custom mods to the 4.4.302 kernel source for the CIP Reference Machine

One Q: do the resulting HUGE and/or GENERIC kernels actually boot on your Slackware 14.2 OS ?

Thanks for the SlackBuild !

-- kjh

Yes, I successfully compiled and am currently running 4.4.302-cip72-st28 on my last remaining i586, Slackware 14.2. This machine is my router/gateway, so it runs 24/7, and I've encountered no hiccups so far. (On this antique box, it did take over 50 hours to compile the modules, though!)

bigbadaboum · 04-08-2023, 10:58 PM

ok I'm telling you the whole truth,
While working on the CIP-74, I noticed some strange things on my machine, kernel.org provides a tar.gz I wanted to convert it to tar.xz, I tried three times I got errors three times.

the Kernel-CIP-73 gives this with dmesg:
[ 0.015785] Spectre V2 : Mitigation: Retpolines
normally it is:
[ 0.015791] Spectre V2 : Mitigation: Full generic retpoline

there are modifications to the management of the microsoft RNDIS driver but this creates small things not very clean (nothing serious instead of having android device we have a double entry, android device and the SerialNumber)

Nothing particular to report on the compilation times:

linus torvalds kernel 4.4.202 (gimp-2.8.22)
real 2m34,755s
user 4m8,815s
sys 0m24,490s

linux-cip-4.4.302-cip73 (gimp-2.8.22)
real 2m35,552s
user 4m8,747s
sys 0m25,235s

But after the problems encountered with linux-cip-4.4.302-cip74 there confidence is no longer there.
I even did a system restore like a good paranoid that I am

The definition of insanity is doing the same thing over and over and expecting different results.
Albert Einstein.

Didier Spaier · 04-09-2023, 02:28 AM

Quote:

Originally Posted by bigbadaboum

The definition of insanity is doing the same thing over and over and expecting different results.
Albert Einstein.

This reminds me an old sysadmin's joke: "The thing about Windows is when you do the same thing several times you get different results every time". I attach a document originally written by Jean-Denis CARRETERO and reproduced with his authorization, in both French (original) and English (Google translated) languages. Remove the .txt extension to read it in a web browser.

PS I just found that it is also on line.

PPS For some reason LQ didn't let me upload the French version. Dunno why but this is the on online so nothing lost.

bigbadaboum · 04-09-2023, 05:38 AM

Hello Didier Spaier,
I knew the time when we were bowing down to a friend who had just bought the latest matrox millennium, when a simple ubuntu signed kernel boosted the UNIGINE Benchmarks performance by 30%.

Hello kjhambrick,

Quote:

I would say that the Request was more [ABANDONED] than [SOLVED]

You have already seen these herds of wildebeest in Africa during transhumance, the leaders of the herd spending 90% of the time leading the herd rather than thinking, dragging them into rivers that are too deep and infested with crocodiles, well our wildebeest is Patrick Volkerding, but he stays behind, observes and then crosses at the right time when the water level is low and we can see the crocodiles, he used 100% of his intelligence to find a solution rather than wanting to prevent the herd from to die because time is not unlimited, you have to make choices.
I have seen it done with sys ini, ldap and recently with chrocus.
So JayByrd I write the post with the SOLVED status but I can put the ABANDONED status it doesn't give me a problem. so I'm doing it for the kernel-CIP.
but I know that you wrote her to tease me