Stuff for testing: Kernel 4.9, docker and nDPI

Help on building IPFire & Feature Requests
Post Reply
Trikolon
Community Developer
Community Developer
Posts: 551
Joined: October 16th, 2008, 6:21 am
Location: Erlangen
Contact:

Stuff for testing: Kernel 4.9, docker and nDPI

Post by Trikolon » March 13th, 2017, 3:49 pm

Dear all,
these are some "private" package for your personal testing. There is absolutely no warrenty that these builds do work at your system.

Here are tar files with a modified 4.9.13 kernel with some additional modules. All packages are for x86_64 only!

Please be so kind and give a feeback whether it is working for you.

Kernel:

Code: Select all

wget http://people.ipfire.org/~trikolon/kernel-4.9.13.tar.bz2
tar xvf kernel-4.9.13.tar.bz2 -C /
grub-mkconfig -o /boot/grub/grub.cfg
I needed a newer FW for my wlan chip with this kernel.

nDPI netfilter - http://www.ntop.org/products/deep-packe ... tion/ndpi/

Code: Select all

wget http://people.ipfire.org/~trikolon/ndpi.tar.bz2
tar xvf ndpi.tar.bz2 -C /
edit /etc/sysconfig/modules and add:

Code: Select all

### ndpi
nf_conntrack
nf_conntrack_netlink
nf_nat_ipv4
nf_nat
nf_reject_ipv4
nf_defrag_ipv4
nf_conntrack_ipv4
nf_conntrack_pptp
nf_conntrack_proto_gre
nfnetlink
xt_ndpi
Check dmesg for ndpi errors.

I am using a costum sh script for loading ndpi iptable rules to classify traffic for QOS:

Code: Select all

#!/bin/bash                                                                                                                                                             

# Debugging 
# echo 2 >/sys/module/xt_ndpi/parameters/log_debug

ethtool -K red0 tso off
ethtool -K red0 gro off
ethtool -K red0 lro off
ethtool -K red0 gso off
ethtool -K red0 rx off
ethtool -K red0 tx off
ethtool -K red0 sg off

# Clear Conntrack list
conntrack -F

# Something in conntrack
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j LOG

######## nDPI Rules #########
## Streaming in Class 205
iptables -t mangle -A QOS-INC -m ndpi --spotify -j MARK --set-mark 205
iptables -t mangle -A QOS-INC -m ndpi --spotify -j RETURN
For me the module is working quite well for 2 days now with ~20 rules for QOS.

Docker:

Code: Select all

wget http://people.ipfire.org/~trikolon/docker-1.13.1-2.ipfire   
tar xvf docker-1.13.1-2.ipfire   
tar xvf files.??
./install.sh


grub-mkconfig -o /boot/grub/grub.cfg
edit /etc/default/grub

Code: Select all

...
GRUB_CMDLINE_LINUX="panic=10 cgroup_enable=memory swapaccount=1" 
...
execute: grub-mkconfig -o /boot/grub/grub.cfg

Code: Select all

ln -s /etc/init.d/docker /etc/rc.d/rc3.d/S65docker
ln -s /etc/init.d/docker /etc/rc.d/rc0.d/K35docker
ln -s /etc/init.d/docker /etc/rc.d/rc6.d/K35docker
iptables for /etc/sysconfig/firewall.local

Code: Select all

        # Docker
        /sbin/iptables -A CUSTOMFORWARD -i docker0 -o red0 -j ACCEPT
        /sbin/iptables -A CUSTOMFORWARD -i red0 -o docker0 -m state --state ESTABLISHED,RELATED -j ACCEPT
        /sbin/iptables -t nat -A POSTROUTING -o red0 -j MASQUERADE
        /sbin/iptables -A CUSTOMFORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
        /sbin/iptables -A CUSTOMFORWARD -i docker0 ! -o docker0 -j ACCEPT
        /sbin/iptables -A CUSTOMFORWARD -i docker0 -o docker0 -j ACCEPT
        /sbin/iptables -A CUSTOMINPUT -i docker0 -j ACCEPT
        /sbin/iptables -A CUSTOMOUTPUT -o docker0 -j ACCEPT
Don't forget to reboot your system ;-)

All packages are build for the 4.9.13 kernel and I guess they will not work with the default ipfie kernel. All patches form original kernel are included.

Update:
Newer Kernel is available:
http://people.ipfire.org/~trikolon/kern ... 24.tar.bz2
Best regards
Ben
Last edited by Trikolon on July 18th, 2017, 2:29 pm, edited 2 times in total.

Veti
Posts: 320
Joined: November 22nd, 2009, 9:26 am

Re: Stuff for testing: Kernel 4.9, docker and nDPI

Post by Veti » March 14th, 2017, 7:03 am

docker support. that is very tempting.

if only we could get this included in the next ipfire kernel.

Trikolon
Community Developer
Community Developer
Posts: 551
Joined: October 16th, 2008, 6:21 am
Location: Erlangen
Contact:

Re: Stuff for testing: Kernel 4.9, docker and nDPI

Post by Trikolon » March 14th, 2017, 7:54 am

It depends on the used filesystem. Basically it is possible to build docker with the default kernel, but it is suggested to use a "fast" filesystem like squashfs or overlayfs. ZFS and BRTFS is also supported, but I did not test it. With newer Kernels overalyfs is supported and that is why I am using it.
So far the performance with docker on ipfire is very good. I am using it to have a pmacctd container to monitor the internet traffic per lan ip, a munin node container to have some more system data at one point (munin server) and to build the nDPI-netfilter module.

Best regards
Ben

User avatar
Deepcuts
Posts: 279
Joined: March 1st, 2016, 3:18 pm
Location: Romania

Re: Stuff for testing: Kernel 4.9, docker and nDPI

Post by Deepcuts » March 31st, 2017, 5:51 pm

I used only the kernel to see if it fixes my Squid using 100% CPU.
And it did.

Another upside to this: it seems my nvme SSD is a lot faster now also!

[root@ipfire ~]# hdparm -tT /dev/nvme0n1
/dev/nvme0n1:
Timing cached reads: 16088 MB in 1.99 seconds = 8065.55 MB/sec
Timing buffered disk reads: 3952 MB in 3.00 seconds = 1317.22 MB/sec

Before I could only get ~ 800 MB/sec without --direct

Thank you very much !
Image
Image

2Big2Fail
Posts: 4
Joined: April 22nd, 2017, 7:28 pm
Location: Hessen, Germany

Re: Stuff for testing: Kernel 4.9, docker and nDPI

Post by 2Big2Fail » April 22nd, 2017, 8:19 pm

Thanks Trikolon for the v. 4 LTS Kernel!

I tried it on my new APU3A4 https://www.pcengines.ch/apu3a4.htm box with a fresh IPFire 3.19 CU109.
Was doing all the tests via serial console.

During boot up it shows two read errors which seem to fit into the random number generator:

Code: Select all

...
Setting hostname to ipfire...                                          [  OK  ]
Setting up firewall                                                    [  OK  ]
Triggering network devices...                                          [  OK  ]
Starting Random Number Generator Daemon...
read error

read error
                                                                       [  OK  ]
INIT: Entering runlevel: 3
Mounting vnstat ramdisk...                                             [  OK  ]
Starting kernel log daemon...                                          [  OK  ]

...
IPFire v2.19 - www.ipfire.org
===============================
ipfire running on Linux 4.9.13-ipfire x86_64
....

[root@ipfire ~]# dmesg
[   30.548579] igb 0000:02:00.0 red0: igb: red0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX
[   35.548655] igb 0000:01:00.0 green0: igb: green0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
....
[   60.230027] random: crng init done
....

[root@ipfire ~]# /etc/init.d/rngd status
/usr/sbin/rngd is not running.
[root@ipfire ~]# /etc/init.d/rngd start
Starting Random Number Generator Daemon...
read error

read error
                                                                       [  OK  ]
Additionally, there is no IPv6 message. Was it build with no IPv6 Support?

On the "old" default kernel 3.14.79-ipfire x86_64 it has mor info messages:

Code: Select all

[root@ipfire ~]# dmesg
[   22.562221] IPv6: ADDRCONF(NETDEV_UP): green0: link is not ready
[   23.982678] IPv6: ADDRCONF(NETDEV_UP): blue0: link is not ready
[   24.782284] IPv6: ADDRCONF(NETDEV_UP): orange0: link is not ready
[   25.729041] IPv6: ADDRCONF(NETDEV_UP): red0: link is not ready
[   27.176828] igb 0000:01:00.0 green0: igb: green0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[   27.177019] IPv6: ADDRCONF(NETDEV_CHANGE): green0: link becomes ready
[   27.363430] igb 0000:02:00.0 red0: igb: red0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: None
[   27.363602] IPv6: ADDRCONF(NETDEV_CHANGE): red0: link becomes ready
...

[root@ipfire ~]# /etc/init.d/rngd start
No Hardware Random Number Generator found...                           [ WARN ]

Even on this box, there is a sligthly improvement of storage speed as reported for NVMe:

Code: Select all

[root@ipfire ~]# hdparm -tT /dev/sda
/dev/sda: (16 GB mSATA SSD)
 Timing cached reads:   1214 MB in  2.00 seconds = 607.65 MB/sec
 Timing buffered disk reads: 1038 MB in  3.00 seconds = 345.71 MB/sec

[root@ipfire ~]# hdparm -tT /dev/mmcblk0
/dev/mmcblk0: (4GB SD Card, IPFire install test)
 Timing cached reads:   1102 MB in  2.00 seconds = 550.72 MB/sec
 Timing buffered disk reads:  34 MB in  3.17 seconds =  10.73 MB/sec
 
Compared to the old kernel:

Code: Select all

[root@ipfire ~]# hdparm -tT /dev/sda
/dev/sda: (16 GB mSATA SSD)
 Timing cached reads:   1170 MB in  2.00 seconds = 584.96 MB/sec
 Timing buffered disk reads: 908 MB in  3.00 seconds = 302.40 MB/sec

[root@ipfire ~]# hdparm -tT /dev/mmcblk0
/dev/mmcblk0: (4GB SD Card, IPFire install test)
 Timing cached reads:   1038 MB in  2.00 seconds = 518.57 MB/sec
 Timing buffered disk reads:  34 MB in  3.18 seconds =  10.68 MB/sec
 
Both kernels perform the same in terms of AES software performance:

Code: Select all

[root@ipfire ~]# openssl speed -elapsed -evp aes-256-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-256-cbc for 3s on 16 size blocks: 19473981 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 64 size blocks: 6268625 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 256 size blocks: 1806796 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 1024 size blocks: 469489 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 8192 size blocks: 59242 aes-256-cbc's in 3.00s
OpenSSL 1.0.2k  26 Jan 2017
built on: reproducible build, date unspecified
options:bn(64,64) md2(int) rc4(8x,int) des(idx,cisc,16,int) aes(partial) blowfish(idx)
compiler: gcc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DSSL_FORBID_ENULL -m64 -DL_ENDIAN -O2 -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fPIC -fstack-protector-strong --param=ssp-buffer-size=4 -m64 -mtune=generic -DPURIFY -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256-cbc     103861.23k   133730.67k   154179.93k   160252.25k   161770.15k
How to check if geode-aes is enabled? This will improve aes speed a lot and will speed up APU and ALIX boards powered by AMD Geode embeded systems. Is this feature missing in the current release?
APU should have as well the HWRND, and the only thing I found was this http://wiki.ipfire.org/en/hardware/pcengines/apu2b4 for apu2b4. Should this SoC have a HWRNG? If not, the service could be removed from startup.

I found an article which shows the performance improvement for ALIX: https://www.twam.info/hardware/alix/usi ... on-alix3d3

I will open a feature request for this as well and switch from 3.14 to a LTS kernel like 3.16 or more recent 4.9. Maybe it is possible to fix the support for random number generator and hopefully also the error message.

CPU info:

Code: Select all

[root@ipfire ~]# cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 22
model           : 48
model name      : [b]AMD GX-412TC SOC[/b]
stepping        : 1
microcode       : 0x7030105
cpu MHz         : 600.000
cache size      : 2048 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf eagerfpu pni pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 movbe popcnt [b]aes[/b] xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt topoext perfctr_nb perfctr_l2 arat cpb xsaveopt hw_pstate npt lbrv svm_lock nrip_save tsc_scale flushbyasid decodeassists pausefilter pfthreshold vmmcall bmi1
bogomips        : 1997.38
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb [12] [13]
CPU temp is about 54 °C within idle.



UPDATE:

After running this kernel for about 4 hours testing a bit, I got the following console message and the box web gui is unresponsive and needs to be rebooted:

Code: Select all

NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [ip:14883]
NMI watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [collectd:2730]
NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [ip:14883]
NMI watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [collectd:2730]
NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [ip:14883]
NMI watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [collectd:2730]
NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [ip:14883]
NMI watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [collectd:2730]
NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [ip:14883]
NMI watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [collectd:2730]
NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [ip:14883]
NMI watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [collectd:2730]
NMI watchdog: BUG: soft lockup - CPU#2 stuck for 23s! [ip:14883]
NMI watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [collectd:2730]
NMI watchdog: BUG: soft lockup - CPU#2 stuck for 23s! [ip:14883]
NMI watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [collectd:2730]
NMI watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [collectd:2730]
NMI watchdog: BUG: soft lockup - CPU#2 stuck for 23s! [ip:14883]
NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [vnstat:14991]
NMI watchdog: BUG: soft lockup - CPU#3 stuck for 23s! [collectd:2730]
NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [ip:14883]

IPFire v2.19 - www.ipfire.org
===============================
ipfire running on Linux 4.9.13-ipfire x86_64
ipfire login: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [vnstat:14991]
NMI watchdog: BUG: soft lockup - CPU#3 stuck for 23s! [collectd:2730]
NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [ip:14883]
NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [vnstat:14991]

IPFire v2.19 - www.ipfire.org
===============================
ipfire running on Linux 4.9.13-ipfire x86_64
ipfire login: NMI watchdog: BUG: soft lockup - CPU#3 stuck for 23s! [collectd:2730]
NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [ip:14883]
NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [vnstat:14991]
NMI watchdog: BUG: soft lockup - CPU#3 stuck for 23s! [collectd:2730]
NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [ip:14883]
NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [vnstat:14991]
NMI watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [collectd:2730]
NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [ip:14883]
I will let the box run and take a look if this happens again.
What exactly does "cgroup_enable=memory swapaccount=1"? I didnt set it, because i wont use docker on that box.

If you need more details or some log input, just let me know.

UPDATE2:

The error seems to happens always between 3-4 hr by idle usage.
Looks like an kernel bug. Last post saved it by setting usb to 2.0. (The board offers 2x 3.0):
https://ubuntuforums.org/showthread.php ... 211&page=3
For me, this error sounds like power management.

Maybe you can take a look into a diff of the kernel config files from /boot/?

Both kernels do support AMD RNG as module, but how to load it?
CONFIG_HW_RANDOM_AMD=m

Kernel 4.9 has theese options more set and 3.14 not:
CONFIG_X86_AMD_PLATFORM_DEVICE=y
CONFIG_PERF_EVENTS_AMD_POWER=m

Trikolon
Community Developer
Community Developer
Posts: 551
Joined: October 16th, 2008, 6:21 am
Location: Erlangen
Contact:

Re: Stuff for testing: Kernel 4.9, docker and nDPI

Post by Trikolon » April 24th, 2017, 9:57 am

Hello 2Big2Fail,
thank you for the detailed imput of how the kernel performs. I am sorry that I have to say that I cannot give you a lot of help here, because for me this kernel is working very good (on a intel system) I do not have a APU system for tests and I simply do not have the time to do testings except of my HW.

You can find the Kernel config under /boot/ on your device.

I do not know how to fix the RNDG Problem. Have you tried to google the problem? I have a newer kernel compiled, but not tested, yet.

The soft lock up is strange. Can you please try to disable the watchdog? (E.g. by blacklisting the kernel driver).

"cgroup_enable=memory swapaccount=1" is only needed for a docker host. Details please see the docker doc.

Load a kernel module: modprobe CONFIG_HW_RANDOM_AMD

Best regards
Ben

Update:
For bloody testing: http://people.ipfire.org/~trikolon/kern ... 24.tar.bz2

User avatar
Arne.F
Core Developer
Core Developer
Posts: 7474
Joined: May 7th, 2006, 8:57 am
Location: BS <-> NDH
Contact:

Re: Stuff for testing: Kernel 4.9, docker and nDPI

Post by Arne.F » April 25th, 2017, 7:06 am

How to check if geode-aes is enabled? This will improve aes speed a lot and will speed up APU and ALIX boards powered by AMD Geode embeded systems. Is this feature missing in the current release?
This feature was disabled because it breaks strongwan vpn's entirely. (seems to corrupt the keys in the hardware)
Btw the APU is no geode system and not has this hardware.

The cpu stuck problem on the APU2/3 is a hangup of the intel nic driver. I have patched this in my tree with 4.9.18
http://git.ipfire.org/?p=people/arne_f/ ... 56a9ef3706
So it should work with 4.9.24

The Random Generator of the APU2/3 is not supported by the kernel.
In old kernels that believe the hw is supported you get only "00 00 00 00 ... " so i have disabled the entire module in 3.14. Now it detects the incorrect hardware revision and doesn't use it.

The rngd userspace error is showed on all systems because the new kernel always create /dev/hwrng also if there is no hardware present. This need a change on the rngd initskript.
I will open a feature request for this as well and switch from 3.14 to a LTS kernel like 3.16 or more recent 4.9
I work on this since but also 4.9 doesn't support the APU2 Random Number Generator. For intel the kernel looks good but there is a lot of work to do for arm.
http://git.ipfire.org/?p=people/arne_f/ ... kernel-4.9
Arne

Support the project on the IPFire whishlist!

Image

Image

Image
PS: I will not answer support questions via email and ignore IPFire related messages on my non IPFire.org mail addresses.

Veti
Posts: 320
Joined: November 22nd, 2009, 9:26 am

Re: Stuff for testing: Kernel 4.9, docker and nDPI

Post by Veti » April 25th, 2017, 9:01 am

000000 könnte random sein :)
http://dilbert.com/strip/2001-10-25

2Big2Fail
Posts: 4
Joined: April 22nd, 2017, 7:28 pm
Location: Hessen, Germany

Re: Stuff for testing: Kernel 4.9, docker and nDPI

Post by 2Big2Fail » April 27th, 2017, 11:34 pm

Dear All,

Thanks for the fast response and good input! I will test the new kernel from Trikolon and post my results.

@Arne:
Is there a plan to put those kernel work you did into the pakfire system?
Or integrate it as "beta testing" for users using the GUI? Guess this will bring "good" feedback regarding hardware support of IPFire.

2Big2Fail
Posts: 4
Joined: April 22nd, 2017, 7:28 pm
Location: Hessen, Germany

Re: Stuff for testing: Kernel 4.9, docker and nDPI

Post by 2Big2Fail » April 29th, 2017, 8:08 am

Dear all,

So far, the new kernel 4.9.24 fixed the problem. I just switched the kernel, no need to do something else.

Code: Select all

[root@ipfire ~]# uname -a
Linux ipfire 4.9.24-ipfire #1 SMP Mon Apr 24 13:11:20 GMT 2017 x86_64 GNU/Linux
[root@ipfire ~]# sensors
ath10k_hwmon-pci-0400
Adapter: PCI adapter
temp1:         +3.0°C

k10temp-pci-00c3
Adapter: PCI adapter
temp1:        +53.2°C  (high = +70.0°C)
                       (crit = +105.0°C, hyst = +104.0°C)

fam15h_power-pci-00c4
Adapter: PCI adapter
power1:        6.60 W  (interval =   0.01 s, crit =   6.00 W)

[root@ipfire ~]# uptime
 10:01:10 up 1 day,  8:37,  1 user,  load average: 0.01, 0.02, 0.00
I will upgrade to CU110 this weekend and report if there is any problem.
Thanks for the kernel work!

User avatar
Deepcuts
Posts: 279
Joined: March 1st, 2016, 3:18 pm
Location: Romania

Re: Stuff for testing: Kernel 4.9, docker and nDPI

Post by Deepcuts » June 12th, 2017, 5:06 pm

Updated to 4.9.24 and loving it so far.
No error or crashes.
Performance is way better than stock.
Thank you again Trikolon
Image
Image

zcworld
Posts: 15
Joined: May 4th, 2015, 10:31 am

Re: Stuff for testing: Kernel 4.9, docker and nDPI

Post by zcworld » October 19th, 2017, 9:00 am

@Trikolon
im not trying to hi-jack your post
just liking to know how did you get the kernel to compile/ how to pack it up to replace the default one on IPfire
+ can you make modules ( like VPN Tap for softether VPN ? )
i can compile it . but when it comes down to the kernel side , its fails

User avatar
Arne.F
Core Developer
Core Developer
Posts: 7474
Joined: May 7th, 2006, 8:57 am
Location: BS <-> NDH
Contact:

Re: Stuff for testing: Kernel 4.9, docker and nDPI

Post by Arne.F » October 19th, 2017, 9:15 am

To build the kernel you need to build the whole IPFire system. I had a 4.9 branch in my git repo.
https://git.ipfire.org/?p=people/arne_f ... kernel-4.9

After this has build you can copy the kernel (/boot/) and the modules (/lib/modules/) if they are present update-bootloader will rebuild the grub menu.
Arne

Support the project on the IPFire whishlist!

Image

Image

Image
PS: I will not answer support questions via email and ignore IPFire related messages on my non IPFire.org mail addresses.

Trikolon
Community Developer
Community Developer
Posts: 551
Joined: October 16th, 2008, 6:21 am
Location: Erlangen
Contact:

Re: Stuff for testing: Kernel 4.9, docker and nDPI

Post by Trikolon » October 19th, 2017, 9:26 am

Thanks Arne!
That's exactly what I did ;-) All Kernels are on the system, there is no replacing.

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests