Kernel 5.8 RC (Release Canidate) series

[zika]

Well, the same information is also in /var/log/kern.log, available to anyone. One problem I observe with linux is no concern for backwards compatibility. These type of changes create a cascading ton of work as documentation becomes obsolete.

True for kern.log but that does not make it right... About documentation: better not to start, I'll get banned for complaining. Never mind, that made me, for decades, learn to learn much quickly...

[Doug S]

re: dmesg now needs root permissions:

True for kern.log but that does not make it right...

see this. And, actually the access rights for /var/log/kern.log are restricted.

doug@s18:~/temp-k-git/linux$ grep CONFIG_SECURITY_DMESG_RESTRICT .con*
.config:CONFIG_SECURITY_DMESG_RESTRICT=y
...
.config-5.8.0-050800rc1-lowlatency:# CONFIG_SECURITY_DMESG_RESTRICT is not set
.config-5.8.0-050800rc4-lowlatency:CONFIG_SECURITY_DMESG_RESTRICT=y
.config-5.8.0-050800rc5-lowlatency:CONFIG_SECURITY_DMESG_RESTRICT=y
.config-5.8-rc1-doug:# CONFIG_SECURITY_DMESG_RESTRICT is not set
...

and:

doug@s18:~/temp-k-git/linux$ ls -l /var/log/kern.log
-rw-r----- 1 syslog adm 1217129 Jul 15 15:20 /var/log/kern.log

[zika]

I did not have any relationship with that change...
It's OK with me.

[Doug S]

Kernel 5.8-rc6 is available. There are a lot of kernel configuration file changes between -rc5 and -rc6.

[zebra2]

Thanks for pointing out this problem. I agree with the Link provided posted by Matthew Ruffell, that these various logs should be admin protected. Actually I don't see how linux has survived this long with this vulnerability. If an intruder can mine my network data he is no longer blocked by closed ports. It may be a long shot, but possible. Also a good reason to make sure that gufw is active.

PS
This discussion is a diversion from the OP (Kernel 5.8 RC (Release Canidate) series) but without regard for that is a great discussion point.

[Cavsfan]

Kernel 5.8-rc6 is available. There are a lot of kernel configuration file changes between -rc5 and -rc6.

It installed without any errors or problems.

cavsfan@groovy:~$ inxi -SMCG
System:    Host: groovy Kernel: 5.8.0-050800rc6-lowlatency x86_64 bits: 64 Desktop: Xfce 4.14.2 
           Distro: Ubuntu 20.10 (Groovy Gorilla) 
Machine:   Type: Desktop System: ASUS product: All Series v: N/A serial: <superuser/root required> 
           Mobo: ASUSTeK model: Z87-K v: Rev X.0x serial: <superuser/root required> UEFI: American Megatrends v: 1103 
           date: 01/02/2014 
CPU:       Topology: Quad Core model: Intel Core i7-4770K bits: 64 type: MT MCP L2 cache: 8192 KiB 
           Speed: 3498 MHz min/max: 800/3900 MHz Core speeds (MHz): 1: 3499 2: 3498 3: 3499 4: 3500 5: 3501 6: 3502 7: 3502 
           8: 3499 
Graphics:  Device-1: NVIDIA GM200 [GeForce GTX 980 Ti] driver: nvidia v: 450.57 
           Display: x11 server: X.Org 1.20.8 driver: nvidia resolution: 3840x2160~60Hz 
           OpenGL: renderer: GeForce GTX 980 Ti/PCIe/SSE2 v: 4.6.0 NVIDIA 450.57

[Cavsfan]

Kernel 5.8-rc7 is available.

[corradoventu]

In the page https://kernel.ubuntu.com/~kernel-pp...line/v5.8-rc7/
I see:
Test amd64/self-tests failed (rc=2, on=amd64, time=0:01:05, log=amd64/self-tests/log)
... self-tests failed... what does it mean? is the kernel unreliable?
however I installed it and seems working fine.

[Doug S]

In the page https://kernel.ubuntu.com/~kernel-pp...line/v5.8-rc7/
I see:
Test amd64/self-tests failed (rc=2, on=amd64, time=0:01:05, log=amd64/self-tests/log)
... self-tests failed... what does it mean? is the kernel unreliable?
however I installed it and seems working fine.

The Ubuntu mainline build process appears to also build a lot of, if not all of, the tools and tests and such. It appears to fail while attempting to link "tools/testing/selftests/bpf/tools/build/bpftool/disasm.o".

This has nothing to do with the kernel itself, and it compiled fine.

However notice it is bpfilter related, and my bpfilter error issues started with -rc5

Without any proof, I think too much new code was added too deep into this -rc series. In my opinion, a violation of their own rules, but Linus himself did it, so who am I to comment. See the release notes for -rc5, in particular:

In addition to the outright fixes, there's a few cleanups that are
just prep for 5.9. They all look good and simple too.

Ya, no.

[Doug S]

Kernel 5.8-rc5 is available,...
I am getting some error:

Jul 13 07:01:08 s18 kernel: [    9.429363] bpfilter: Loaded bpfilter_umh pid 826
Jul 13 07:01:08 s18 kernel: [    9.432623] bpfilter: write fail -22
Jul 13 07:01:08 s18 kernel: [    9.432676] bpfilter: write fail -22
Jul 13 07:01:08 s18 kernel: [    9.458993] bpfilter: Loaded bpfilter_umh pid 836
Jul 13 07:01:08 s18 kernel: [    9.459132] bpfilter: write fail -22
Jul 13 07:01:08 s18 kernel: [    9.459185] bpfilter: write fail -22

It seems the default for iptables/nftables was changed. Couldn't run my VM's either. Do:

# update-alternatives --set iptables /usr/sbin/iptables-nft
# update-alternatives --set ip6tables /usr/sbin/ip6tables-nft
# update-alternatives --set arptables /usr/sbin/arptables-nft
# update-alternatives --set ebtables /usr/sbin/ebtables-nft

and re-boot fixed.

References: https://askubuntu.com/questions/1262...will-not-start and https://wiki.debian.org/iptables