Kernel-kit questions

Post by **rockedge** » Wed Oct 14, 2020 10:40 pm

After tracking down why kernel after kernel is compiling using the kernel-kit, but unable to boot cleanly, it seems that the firmware section of the build scripts is skipped and the drivers for mounting the file system are not present.

When I run ./build.sh it does not reach the query of what firmware to use and if built in or fdrv separated.
I am applying RT-Patches successfully and the kernel compiles but when a boot is attempted it fails because of the inability to mount /dev/pup2 and the file system so the system ends up dropping out to console. A uname -a results in the correct kernel string but at that point a reboot command is the option to take.

Why is the ./build.sh script skipping the firmware config queries?

I think I could have had more working real time kernels in the 5.xx series if I had spotted this anomaly earlier.

Post by **rockedge** » Thu Oct 15, 2020 12:57 am

Using the Kernel-kit I have not been able to build a working kernel for some time. I feel like it and some of the errors that seem to indicate something is not right with the firmware inclusion :
Noticed the 2 errors :

Code: Select all

cp: cannot stat 'linux_kernel-5.4.70-bionicpup64/lib/modules/5.4.70/modules.builtin': No such file or directory
cp: cannot stat 'linux_kernel-5.4.70-bionicpup64/lib/modules/5.4.70/modules.order': No such file or directory

Code: Select all

Creating the kernel headers package
Building aufs-utils - userspace modules
aufs-util-5.4.70 is in output
Compiling the kernel
Creating the kernel package
cp: cannot stat 'linux_kernel-5.4.70-bionicpup64/lib/modules/5.4.70/modules.builtin': No such file or directory
cp: cannot stat 'linux_kernel-5.4.70-bionicpup64/lib/modules/5.4.70/modules.order': No such file or directory
linux_kernel-5.4.70-bionicpup64 is ready in output
Cleaning the kernel sources
Installing aufs-utils into kernel package
Creating a kernel sources SFS
Parallel mksquashfs: Using 4 processors
Creating 4.0 filesystem on output/kernel_sources-5.4.70-bionicpup64.sfs, block size 131072.
[===========================================================================================/] 67555/67555 100%

Exportable Squashfs 4.0 filesystem, xz compressed, data block size 131072
	compressed data, compressed metadata, compressed fragments, no xattrs
	duplicates are removed
Filesystem size 147924.99 Kbytes (144.46 Mbytes)
	16.85% of uncompressed filesystem size (877922.92 Kbytes)
Inode table size 496412 bytes (484.78 Kbytes)
	21.25% of uncompressed inode table size (2336379 bytes)
Directory table size 628618 bytes (613.88 Kbytes)
	42.42% of uncompressed directory table size (1481811 bytes)
Number of duplicate files found 1704
Number of inodes 72675
Number of files 67326
Number of fragments 5744
Number of symbolic links  38
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 5311
Number of ids (unique uids + gids) 1
Number of uids 1
	root (0)
Number of gids 1
	root (0)
Pausing here to add extra firmware.
building firmware for fdrv
./firmware_picker.sh: line 111: /tmp/firmware.lst.5.4.70: No such file or directory
rm: cannot remove '/tmp/firmware.lst.5.4.70': No such file or directory
Extracting licences
Parallel mksquashfs: Using 4 processors
Creating 4.0 filesystem on output/fdrv-5.4.70-bionicpup64.sfs, block size 131072.
[=================================================================================================|] 69/69 100%

Exportable Squashfs 4.0 filesystem, xz compressed, data block size 131072
	compressed data, compressed metadata, compressed fragments, no xattrs
	duplicates are removed
Filesystem size 49.62 Kbytes (0.05 Mbytes)
	18.79% of uncompressed filesystem size (264.05 Kbytes)
Inode table size 554 bytes (0.54 Kbytes)
	23.70% of uncompressed inode table size (2338 bytes)
Directory table size 926 bytes (0.90 Kbytes)
	48.81% of uncompressed directory table size (1897 bytes)
Number of duplicate files found 1
Number of inodes 73
Number of files 69
Number of fragments 3
Number of symbolic links  0
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 4
Number of ids (unique uids + gids) 1
Number of uids 1
	root (0)
Number of gids 1
	root (0)
Firmware script complete.
Extracting firmware from the kernel.org git repo has succeeded.
Parallel mksquashfs: Using 4 processors
Creating 4.0 filesystem on output/kernel-modules-5.4.70-bionicpup64.sfs, block size 131072.
[=================================================================================================/] 71/71 100%

Exportable Squashfs 4.0 filesystem, xz compressed, data block size 131072
	compressed data, compressed metadata, compressed fragments, no xattrs
	duplicates are removed
Filesystem size 859.59 Kbytes (0.84 Mbytes)
	17.88% of uncompressed filesystem size (4807.40 Kbytes)
Inode table size 850 bytes (0.83 Kbytes)
	32.76% of uncompressed inode table size (2595 bytes)
Directory table size 842 bytes (0.82 Kbytes)
	52.59% of uncompressed directory table size (1601 bytes)
Number of duplicate files found 2
Number of inodes 72
Number of files 40
Number of fragments 5
Number of symbolic links  4
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 28
Number of ids (unique uids + gids) 1
Number of uids 1
	root (0)
Number of gids 1
	root (0)
Huge compatible kernel packages are ready to package.
Packaging huge-5.4.70-bionicpup64 kernel
vmlinuz-5.4.70-bionicpup64
fdrv-5.4.70-bionicpup64.sfs
kernel-modules-5.4.70-bionicpup64.sfs
huge-5.4.70-bionicpup64.tar.bz2 is in output

/initrd/mnt/dev_save/woof-out_x86_64_x86_64_ubuntu_bionic64/kernel-kit
Compressing the log
------------------
Output files:
- output/huge-5.4.70-bionicpup64.tar.bz2
  (kernel tarball: vmlinuz, modules.sfs - used in the woof process)
  you can use this to replace vmlinuz and zdrv.sfs from the current wce puppy install..

- output/kernel_sources-5.4.70-bionicpup64.sfs
  (you can use this to compile new kernel modules - load or install first..)
------------------
Done!

The kernel is 5.4.70 and the RT patches seem to have been applied successfully.
This will not boot because it can not load the puppy_bionicpup64_8.0.sfs and mount in /dev/loop* or any of the file system.

Post by **rockedge** » Thu Oct 15, 2020 1:08 am

also indicates there is a firmware error during the running of ./firmware_picker.sh

Code: Select all

Pausing here to add extra firmware.
building firmware for fdrv
./firmware_picker.sh: line 111: /tmp/firmware.lst.5.4.70: No such file or directory
rm: cannot remove '/tmp/firmware.lst.5.4.70': No such file or directory
Extracting licences

Post by **rockedge** » Thu Oct 15, 2020 1:14 am

Because the path is wrong!?

Code: Select all

cp: cannot stat 'linux_kernel-5.4.70-bionicpup64/lib/modules/5.4.70/modules.builtin': No such file or directory

but the path should be:linux_kernel-5.4.70-bionicpup64/lib/modules/5.4.70-rt40/modules.builtin

any help on fixing this ?

01101001b · Post by **01101001b** » Thu Oct 15, 2020 4:31 am

rockedge wrote: ↑Thu Oct 15, 2020 1:14 am Because the path is wrong!?
[...]
any help on fixing this ?

Hi @rockedge!
Maybe this can help?

Good luck Ace!

ozsouth · Post by **ozsouth** » Thu Oct 15, 2020 6:37 am

@rockedge - I always choose 'I'll add my own in later", then don't when asked for it & use an fdrv instead.
Would that suffice? Attached is my build script for ubuntu-clone kernels (also builds headers pkg).

buildu.sh.fake.gz: (remove .fake.gz & ensure executable); (36.62 KiB) Downloaded 56 times

peebee · Post by **peebee** » Thu Oct 15, 2020 6:49 am

Kernel-kit was updated in August by 01Micko - now handles firmware differently....

build.conf needs:

## This kit now gets firmware from kernel.org
## The default is to produce a firmware package that is based on the running
## kernel package and sent to main build or you can send it to the fdrv
## or you can opt to have no firmware
## fware=b >> builtin (zdrv)
## fware=f >> fdrv
## fware=n >> no firmware - no download of large firmware repo
## RECOMMENDATION: choose f!
fware=f

01micko · Post by **01micko** » Thu Oct 15, 2020 7:39 am

Nah there is something else wrong methinks... preceding @peebee 's mentioned change .. looking into it.

There is a wrong variable somewhere that didn't used to be wrong to do with the custom_suffix (which in the OP case would be -rt40)

EDIT: 10 minutes later:

Nope, that is not it. I suspect now that the RT patches may be the cause. Do they alter the kernel version? A link to those patches would be good.

Post by **rockedge** » Thu Oct 15, 2020 12:21 pm

@01micko

Looks like you are on to something here.....The kernel version name is changed by the patch! for example 5.4.70 will become 5.4.70-rt40

Links to RT-Patches :
https://rt.wiki.kernel.org/index.php/Main_Page
https://rt.wiki.kernel.org/index.php/CO ... _Patch_Set

Main link : https://mirrors.edge.kernel.org/pub/lin ... ojects/rt/

the kernel-kit used to handle this occurrence up to the point I compiled 5.4.5-rt3

Post by **rockedge** » Thu Oct 15, 2020 1:19 pm

definitely this is a problem:

Code: Select all

cp: cannot stat 'linux_kernel-5.4.70-bionicpup64/lib/modules/5.4.70/modules.builtin': No such file or directory
cp: cannot stat 'linux_kernel-5.4.70-bionicpup64/lib/modules/5.4.70/modules.order': No such file or directory

where the RT patches are (both the monolithic and separated versions) are changing the "5.4.70" to "5.4.70-rt37"
so any symlinks or copying prodeures fail...hence no drivers to mount the puppy SFS file system into RAM and the system eventually drops down to the console where a "reboot" or Ctrl-Alt-Del will initiate a system restart

Post by **rockedge** » Thu Oct 15, 2020 1:52 pm

tried a really vanilla kernel build using the kernel kit with 5.4.70....... no go..... refuses to load the puppy file system into RAM

Code: Select all

#--
#             Configuration options
#             =====================
# 
#  **NOTE**: check the original file every once in a while
#            settings might be added or removed...
#
# see http://www.kernel.org/ for the latest kernel info..
#--

################################################################
## add a Kernel .config file in one of the configs_* directories
## It must follow this syntax:
##           version  info
## DOTconfig-3.14.73-i686-4g
################################################################

## speed up the process by specifing a DOTconfig file:
#DOTconfig_file=DOTconfig
#DOTconfig_file=configs_x86/DOTconfig-3.16.85-i686-4g

## use this version string with the current ./DOTconfig
## (in case it doesn't have usable version info inside)
kernel_ver=5.4.70

## i386 specific stuff: force pae/nopae - i486/i686
## note: the script will run 'make oldconfig' to ensure
##       the new settings take effect..
#x86_disable_pae=yes
#x86_enable_pae=yes

## this is the kernel suffix hack, you can leave it empty ie: uname -r
## if you don't leave empty the leading "dash" is required
## DO NOT change it between minor versions (i.e 3.14.1 and 3.14.2); otherwise,
## third-party drivers will break and users won't be able to upgrade: kernel-kit
## patches the kernel to ensure drivers built for the major version (say, 3.14)
## continue to work with any future minor version (3.14.1, 3.14.2, etc') and
## don't have to be rebuilt, but the suffix must not change for this to work
## (this is particularly good if you wish to stick with a longterm kernel branch
## without any maintenance and without frustrating users that need extra drivers)
## example:
#custom_suffix=-4G
custom_suffix=

## this is the name of the pet package suffix, and source sfs
## name it whatever you like, usually put in a signifier for your distro
## eg: "s" is for slacko
## if you leave empty the script will determine a proper package suffix
package_name_suffix=

##-----------------------------------------------------------------------

## remove kernel sublevel, or not : set yes or no
remove_sublevel=no

## aufs version (git branch) - see README -> AUFS GIT BRANCHES
## the script automatically detects the aufs version, but when it does not
## you must specify it here:
aufsv=5.4.3

## JOBS ###
## if you have a multicore processor you can set this var
## don't set if you have a single core! >> cooked machine 
## DO NOT set it to 0 (zero) >> cooked machine
JOBS=-j4

### squashfs compression ###
## unset this for the default of your mksquashfs binary
#COMP="-comp gzip"
COMP="-comp xz"
#COMP="-comp xz -b 512K"

## strip kernel modules?
## warning: this might cause issues
STRIP_KMODULES=no

## Firmware tarballs repository
#FW_URL=http://ftp.nluug.nl/ftp/pub/os/Linux/distr/puppylinux/firmware

## Firmware tarball or SFS (fdrv)
## specify pkg url to automate the process
#FW_PKG_URL="http://ftp.nluug.nl/ftp/pub/os/Linux/distr/puppylinux/firmware/firmware-140621-big.tar.bz2"

## Kernel download mirrors
kernel_mirrors='https://www.kernel.org/pub/linux/kernel
ftp://ftp.ntu.edu.tw/linux/kernel
ftp://ftp.heanet.ie/pub/kernel.org/pub/linux/kernel
ftp://ftp.yandex.ru/pub/linux/kernel/
https://mirror.aarnet.edu.au/pub/ftp.kernel.org/linux/kernel
ftp://ftp.jaist.ac.jp/pub/Linux/kernel.org/linux/kernel
ftp://www.mirrorservice.org/pub/linux/kernel
ftp://ftp.be.debian.org/pub/linux/kernel'

## This kit now gets firmware from kernel.org
## The default is to produce a firmware package that is based on the running
## kernel package and sent to main build or you can send it to the fdrv 
## or you can opt to have no firmware
## fware=b >> builtin (zdrv)
## fware=f >> fdrv
## fware=n >> no firmware - no download of large firmware repo
## RECOMMENDATION: choose f!
fware=b

## -- AUTO --
## Enforce automation of the process. Also triggered by: ./build.sh auto
## Every error is fatal, so you must specify all the needed stuff in build.conf first..
#AUTO=yes

The kernel-kit has not produced a working kernel for the last 40 attempts at least. Lucky I have a machine that can compile a kernel in 20 minutes or less to test all this out.....

666philb · Post by **666philb** » Thu Oct 15, 2020 2:21 pm

hi @rockedge

your kernel version says 5.4.70
and your aufs says aufsv=5.4.3

that might be the issue

Post by **rockedge** » Thu Oct 15, 2020 3:40 pm

no, the aufs-5.4.3 is correct. The trick is to get as close as possible to the aufs version. There is no 5.4.70 aufs5, but using one closest is the way to go. really important is that the RT patches are the right version..that must be exact.

What is happening is the paths are incorrect when after applying the rt patches, but why the vanilla build is also failing and showing errors is another story it seems. Like I've said I haven't been able to generate a single working kernel with the kernel-kit in many many new attempts. I was able to do a set of Rt kernels using the kernel-kit very successfully last year and now not one will boot.

01micko · Post by **01micko** » Fri Oct 16, 2020 2:03 am

I have made an alteration to `build.sh` setting the custom_suffix variable after the Makefile is patched in a standard build if the RT patchset (not the mono patch) is detected in /patches. Am trying a build of 5.4.70-rt40 right now and if successful will share the code.

Later ... looks the goods and no errors.

: rt40.png (34.25 KiB) Viewed 1876 times

Will boot it and see,,,

SUCCESS!!!

: rt40-term.png (22.5 KiB) Viewed 1876 times

I'll tidy up the code and post my build.conf and build.sh

Ok, here is diff of the current build.sh in woof-ce

Code: Select all

--- build.sh	2020-07-14 21:39:06.639827036 +1000
+++ ../../../kk-5.4.71-rt40/build.sh	2020-10-16 11:33:20.081639240 +1000
@@ -561,6 +561,10 @@ fi
 ## custom suffix
 if [ -n "${custom_suffix}" ] ; then
 	sed -i "s/^EXTRAVERSION =.*/EXTRAVERSION = ${custom_suffix}/" Makefile
+elif [ -e "$MWD/patches/0285-Add-localversion-for-RT-release.patch" ]; then # rt kernel patch set
+	tgt_patch=`ls "$MWD/patches/"|grep '0[0-9][0-9][0-9]\-'|tail -n1`
+	custom_suffix=`grep '+\-rt[0-9][0-9]' $MWD/patches/$tgt_patch`
+	custom_suffix=${custom_suffix/+/}
 elif [ "$kernel_is_plus_version" = "yes" ]; then
 	CONFIG_LOCALVERSION="`grep -F 'CONFIG_LOCALVERSION=' ../DOTconfig`"
 	if [ "$CONFIG_LOCALVERSION" != "" ]; then

I'll attach a tarball of my full build.sh and build.conf and my build logs. (removed)

NOTES
- DO NOT set custom_suffix in build.conf. The rt patches take care of it
- it is useful to set package_name_suffix
- you can choose auto or manual
- firmware builds fine

garnet · Post by **garnet** » Fri Oct 16, 2020 4:07 am

But you're not enabling the RT features, no? When RT features are enabled, you will see "PREEMPT_RT" when you run uname -a ...

01micko · Post by **01micko** » Fri Oct 16, 2020 10:38 am

garnet wrote: ↑Fri Oct 16, 2020 4:07 am But you're not enabling the RT features, no? When RT features are enabled, you will see "PREEMPT_RT" when you run uname -a ...

yes, oversight in the config.. and when CONFIG_PREEMPT_RT=y in 5.4.70 compilation fails

It is either a kernel bug or an AUFS bug (the latter for sure) because when preempt is set an extra include header file is sourced and aufs fails to compile. Note that junjiro (AUFS maintainer) has been out of action for several months due to some personal issues. This may get fixed if/when he is back on deck.

However, with some minor mods to my build.sh script (making it more portable across RT patch-set versions) I did successfully build k4.19.148-rt65 with the correct kernel configuration.

Code: Select all

# uname -r
4.19.148-rt64
# uname -v
#1 SMP PREEMPT RT Fri Oct 16 20:08:29 AEST 2020
# uname -a
Linux ryzen21236 4.19.148-rt64 #1 SMP PREEMPT RT Fri Oct 16 20:08:29 AEST 2020 x86_64 AMD Ryzen 5 1600 Six-Core Processor AuthenticAMD GNU/Linux

I'll attach updated file for build.sh and my config.

Post by **rockedge** » Fri Oct 16, 2020 3:20 pm

Thanks @01micko

I am testing out the script with 5.4.70. All the RT patches are applying successfully but I seem to get this error more often than not:

Code: Select all

Applying ../patches/0296-rwsem-Provide-down_read_non_owner-and-up_read_non_ow.patch
Applying ../patches/0297-Linux-5.4.70-rt40-REBASE.patch
Cleaning the kernel sources
grep: .config: No such file or directory

Not sure what this is causing if anything. what condition would a .config exist? The script will continue but so far no luck compiling a full RT 5.4.70 now it is error and out during the compile

I will attempt to build 5.4.70 without the full rt selected

Post by **rockedge** » Fri Oct 16, 2020 5:34 pm

Using the new version of build.sh I was able to compile on a Fossapup64 the kernel 4.19.148-rt64 successfully.
The kernel boots and the system seems to be running well and as expected.

: Screenshot.png (8.27 KiB) Viewed 1821 times

Noticed though with the {custom_suffix=} not defined, the script did not pick up the -rt64 designation and add it to the output name

/output/huge-4.19.148-focal.tar.bz2

01micko · Post by **01micko** » Sat Oct 17, 2020 11:30 pm

Aha!

: rt40-5.4.70.png (14.67 KiB) Viewed 1761 times

I managed to conjure up a patch.

Be warned: I cannot take any responsibility for stability of the patch!

With that said it seems to be running ok on my ryzen box.

Here is the code:

Code: Select all

This patch enables compilation of 5.4.70-rt40 as it failed to compile.
if CONFIG_PREEMPT_RT=y then this block is skipped
See aufs4.19.63+ i_op.c for the reason it compiles.
by 01micko, released under GPLv2 NO WARRANTY whatsoever!!!
--- a/fs/aufs/i_op.c	2020-10-18 08:05:34.210960876 +1000
+++ b/fs/aufs/i_op.c	2020-10-18 08:09:49.863984667 +1000
@@ -633,7 +633,9 @@ out:
 
 static void au_pin_hdir_set_owner(struct au_pin *p, struct task_struct *task)
 {
+#if !defined(CONFIG_PREEMPT_RT)
 	atomic_long_set(&p->hdir->hi_inode->i_rwsem.owner, (long)task);
+#endif
 }
 
 void au_pin_hdir_acquire_nest(struct au_pin *p)

Attached is a tarball with updated build.sh, my build.conf, the DOTconfig I used (in the configs_x86_64/ dir) and the patch - in patches/09999-aufs-i_op_c-rwsem-rt.patch.

NOTES
Easy way: expand the tarball at the root of your kernel kit tree, expand the rt-patches set for 5.4.70 to patches/ and run build.sh then wait anything from 10 minutes to several hours depending on your download speed and cpu speed. Typically it takes about 20 minutes on the ryzen 6 core, 40 in an i5, well over an hour on core 2 duo.

Advanced way

open tarball and cherry pick what you want. build.sh and the patch is required for 5.4.70 to build
get the rt patches and insert in patches/
use my build.conf as a template, except turn off AUTO= at the bottom (just comment it out), either enter a kernel version and comment my DOTconfig_file= or use my DOTconfig or replace it in the configs dir with a config of the same name or if using your own substitute the name you used in the DOTconfig_file variable. Syntax must be the same. Don't set aufsv= ; this will one day be deleted. Don't enter anything for custom_suffix or package_name_suffix. If RT patches are there build.sh will take care of that now (previous version did not)
you can use any config that is designed for 5.4 kernel series. Mine is a good starting point.
run ./build.sh
Make sure AUFS patches have applied then RT patches then my patch and configure the kernel when prompted. Use whatever option but 1. and 2. are almost foolproof. 3. requires QT4 (iirc - been a while since I used it) and 4 will just use your config (or mine if you left things as they are but changed AUTO=). Be sure to find the entry CONFIG_PREEMPT_RT and turn it on (CONFIG_PREEMPT_RT=y). There are 'help' buttons in the ncurses, gtk and qt gui configuration tools for each option. Turn on or off whatever else you like.
Once configured, just save the configuration (there is a button) and follow the prompts. Soon you should have a shiny 5.4.70-rt40 kernel

Have fun!

(BTW, I got thru this post and it's still runnung

)

Post by **rockedge** » Sun Oct 18, 2020 5:35 pm

@01micko

Success!!
I took the patch you supplied and added it to the rt patches in /kernel-kit/patches, replaced build.sh and I used the .config for base settings from kernel 5.4.3 which I then modified for 5.4.70-rt40 to build a full real time kernel. Running now on a Bionic64-CE (the "-CE" designation indicates a Woof-CE built OS) and Fossapup64-9.0.5. I am going to try it out on a FirstRib Void Linux based OS without the Void kernel and replace that with this Puppy Linux kernel. In the beginning of the WeeDog development using the first series of FirstRib scripts I built several OS's without the Void Linux kernel and just copied in the Puppy Linux kernel components and then ran the scripts to make the system able to boot.

The compile was finished in 19 minutes. The build system is a Fossapup64-9.0.5 running with kernel 5.4.3
So far the systems using the 5.4.70-rt40 kernel are running well and as expected.

garnet · Post by **garnet** » Tue Oct 20, 2020 2:20 pm

01micko wrote: ↑Sat Oct 17, 2020 11:30 pm I managed to conjure up a patch.

Wonderful

You're the best! ^_^

nocsak · Post by **nocsak** » Fri Apr 01, 2022 10:40 pm

Greetings to all!

I have really basic English grammar and vocabulary so excuse me if I write something strange!

I have tested the official Woof-ce kernel-kit from github, which was linked on the official Puppy website (Woof-ce). Then succesfully compiled some longterm kernel from the 4.19 kernel family. This is the first time here when I write something to this forum and I hope I can give some useful feedback.

I started this year with compiling kernel 3.2.32-huge in three versions: 32 bit retro (no-PAE), 64 bit only, and 64 bit with ia32 binary emulation support enabled.
All these and all the later longterm kernels can be found on our SF repository.

It was a bit hard to compile this really old kernel with kernel-kit but with some extra trick, I did. One of these extra trick was to change in build.sh the git clone command by modifying it to:

Code: Select all

env GIT_SSL_NO_VERIFY=true git clone

around the aufs sources. In some other cases I recognized the wget's --no-check-certificate parameter which helped me around the SSL mismatches to bypass.

After exploring the issue I guessed it caused by old ca-certs installed on the Puppy where under I started to compile. The puppy where was compiled under are indicated by the suffix in kernel filenames. (tahr puppy for 3.2.32, and tahr64 puppy for 3.2.32 64 bit and the corresponding devx-es.) The 4.19 longterm variants were compiled under official BionicPup64 8.0 with it's devx, and NosPup32 (nospup-1-1_K4.6.3_Pae_Hun-T2.iso) which is a 32bit Bionic 19.03 variant so it needed the 19.03's 32 bit bionic devx.

Experiences with the 4.19 kernel compiling were much more friendly. But there I again needed to change git clone command to that one I mentioned above. Other major problems weren't recognized.

Some extra notices:

As I know RT kernels needs RT glibc as well. In some time when I tested rockedge's RT kernels in the past, many times freezes. After this, our forum member ticoo1, he drew my attention to it and gave me a working RT glibc to that kernel, and it did not freezed out anymore.

I hope in the future I can give more accurate and helpful feedbacks to you!

Finally I would like to say thank you to mrfricks and pencilandpaper who were shown some extra instructions and working DOTconfigs in the past.

Grey · Post by **Grey** » Sat Apr 02, 2022 3:44 am

nocsak wrote: ↑Fri Apr 01, 2022 10:40 pm
It was a bit hard to compile this really old kernel with kernel-kit but with some extra trick, I did. One of these extra trick was to change in build.sh the git clone command by modifying it to:
Code: Select all
env GIT_SSL_NO_VERIFY=true git clone 
around the aufs sources. In some other cases I recognized the wget's --no-check-certificate parameter which helped me around the SSL mismatches to bypass.
After exploring the issue I guessed it caused by old ca-certs installed on the Puppy where under I started to compile.

Hello nocsak. That's right, sometimes we have to dance the csárdás, that is, sometimes we have to make changes to build.sh viewtopic.php?t=5440

Puppy Linux Discussion Forum

Kernel-kit questions

Kernel-kit questions

Re: Kernel-kit questions

Re: Kernel-kit questions

Re: Kernel-kit questions

Re: Kernel-kit questions

Re: Kernel-kit questions

Re: Kernel-kit questions

Re: Kernel-kit questions

Re: Kernel-kit questions

Re: Kernel-kit questions

Re: Kernel-kit questions

Re: Kernel-kit questions

Re: Kernel-kit questions

Re: Kernel-kit questions

Re: Kernel-kit questions

Re: Kernel-kit questions

Re: Kernel-kit questions

Re: Kernel-kit questions

Re: Kernel-kit questions

Re: Kernel-kit questions

Re: Kernel-kit questions

Re: Kernel-kit questions

Re: Kernel-kit questions