Nur damit ihr es schonmal gehört habt und auch wenn es bestimmte Docker-Setups eher trifft:
Ich halte es für möglich, dass es auch in unseren Setups zuschlägt und ihr dann ohne langes Basteln auf den vorherigen Kernel zurückstellt:
Und wieder ein Argument, entspannt auf 16.04 LTS auszuharren … (Aber wirklich: danke für die Info!)
Diese Entspannung nehme ich Dir leider gleich: der letzte Screenshot (der Konzentrator) war ein 16.04LTS, auf dem auch ein 4.15.0-60 (im Rahmen von dinges-HWE) per distupgrade installiert worden war.
von @plaste gab es dankenswerterweise ein .yml mit folgendem Inhalt:
---
- hosts: supernodes
become: true
- name: lock kernel version
shell:
if dpkg -l | grep linux-image-4.15.0-58-generic; then
echo linux-image-4.15.0-58-generic hold | sudo dpkg --set-selections;
echo linux-image-generic hold | sudo dpkg --set-selections;
echo linux-generic-hwe hold | sudo dpkg --set-selections;
sudo update-grub
sudo touch /forcefsck
sudo reboot
fi
- name: Remove kernel "4.15.0-60" package
apt:
name: "*4.15.0-60*"
state: absent
Reproduzieren:
[Impact]
Some fragmentation+NAT workloads will cause kernel BUG/Ooops.
[Test case]
sudo iptables -t nat -I POSTROUTING -j MASQUERADE
sudo hping3 192.168.122.1 -s 1000 -p 2000 -d 60000
[Regression potential]
This could make fragmented packets stop flowing. So, make sure fragmented pings still work.
ping 192.168.122.1 -s 60000 still works, even with the above nat rule.
fixed via 4.15.0-62