stable

kernel-5.11.11-300.fc34, kernel-headers-5.11.11-300.fc34, & 1 more

FEDORA-2021-41fb54ae9f created by jforbes 4 years ago for Fedora 34

The 5.11.11 stable kernel update contains a number of important fixes across the tree.

Reboot Required
After installing this update it is required that you reboot your system to ensure the changes supplied by this update are applied properly.

How to install

Updates may require up to 24 hours to propagate to mirrors. If the following command doesn't work, please retry later:

sudo dnf upgrade --refresh --advisory=FEDORA-2021-41fb54ae9f

This update has been submitted for testing by jforbes.

4 years ago

This update's test gating status has been changed to 'ignored'.

4 years ago

This update's test gating status has been changed to 'waiting'.

4 years ago

This update's test gating status has been changed to 'ignored'.

4 years ago
User Icon bretth commented & provided feedback 4 years ago
karma

Default & performance tests pass (KVM)

Test Case kernel regression
User Icon itrymybest80 commented & provided feedback 4 years ago
karma

Default & performance regression tests PASS, libhugetlbfs & paxtest was skipped. Tested on x86_64, PRIME Z270-A, i5-7600K, 16GB DDR4, AMD RX 580 8GB (MESA 21.0.1-3) & 970 EVO M.2.

Test Case kernel regression

This update has been pushed to testing.

4 years ago

This update can be pushed to stable now if the maintainer wishes

4 years ago
User Icon geraldosimiao commented & provided feedback 4 years ago
karma

Works fine on Acer Aspire V3-571 v: V2.11 CPU: Quad Core Intel Core i7-3632QM GPU: Intel 3rd Gen Core processor Graphics Controller KDE Plasma. No regressions found

Test Case kernel regression
User Icon atim provided feedback 4 years ago
karma
Test Case kernel regression
User Icon smithp commented & provided feedback 4 years ago
karma

+1

User Icon pwalter commented & provided feedback 4 years ago
karma

Works in VirtualBox

This update has been submitted for stable by jforbes.

4 years ago

jforbes edited this update.

4 years ago
User Icon storm commented & provided feedback 4 years ago
karma

I know it it pre-release beta etc, it my "job" to workaround any bugs, but It cannot boot, it stuck in plymoth waiting 2 jobs, endlessly trying to mount swap and root. Pressing CTRL+ALT+DEL it stuck waiting rngd job. Pressing CTRL_ALT+DEL second time it actually reboot. Previous kernel (5.11.10-300.fc34.x86_64) work flawlessly. Obviously, nothing in logs after reboot to old kernel (tried journalctl -b-1, -b-2 etc), as it looks like cannot mount any writable partitions. Beside, it is first such scary big issue with Fedora since that dreadful partition eater ~ 5 years ago. And more, no idea how to force gnome-software to skip that update, so i just hope next kernel u[pdate will be more lucky and until that i must double boot every time.

I found in discussion of 33 version of that kernel there was similar looking issue with arm, may be it related.

User Icon jforbes commented & provided feedback 4 years ago

@storm Do not regen your initramfs for 5.11.10. This is not a kernel issue, I was debugging this with someone in #fedora-devel and they regenerated all of their initramfs, leaving no kernel bootable. I would guess the issue is in either the systemd update in updates-testing right now, or the dracut update that dropped a couple of days ago.

User Icon storm commented & provided feedback 4 years ago

@jforbes Thanks for quick answer,i thought it somewhat initramfs related, as my second box is F33 and it updated and work as intended and nothing other errors was in console except that 2 endless mount jobs. I will wait for the next updates.

User Icon throwaway commented & provided feedback 4 years ago
karma

I'm not sure if it's related but I briefly ran into an issues with "zram: Cannot change disksize for initialized device" or rngd being stuck at some point on a Raspberry Pi 4, which was bootstrapped via UEFI/iPXE with the PXE kernel and initrd, installed in text mode with btrfs ("use entire disk") and upgraded with dnf update -y. The zram issue caused a bunch of services to fail during startup and prevented me from logging in on the console.

Unfortunately I'm not sure what caused either of these issues this since I did a whole bunch of Fedora Server installs in a short run, most of which failed for various reasons (mostly PEKBAC):

  • UEFI/iPXE booted a 5.11.10 kernel with inst.repo set to a local mirror which likely lagged behind 1-2 days with respect to packages
  • UEFI/iPXE booted a 5.11.11 kernel with inst.repo set to the same, local mirror
  • ran dnf update -y after the install
  • dabbled with an option to disable "Limit RAM to 3GB" in UEFI for Raspberry Pi 4 (its enabled by default in EDK2 UEFI)
  • booted the system via u-boot and GRUB2 without knowing exactly which of my three disks (all attached to the same Raspberry Pi, each having a throwaway install of F34) it booted from

Anyways, in the end I succeeded with an install which was UEFI/iPXE booted with the PXE vmlinuz (5.11.11) and initrd.img from https://dl.fedoraproject.org/pub/fedora/linux/development/34/Server/aarch64/ (with inst.repo set to the same mirror).

I've run dnf update -y and dracut --regenerate-all --force (dracut 053) with no issues on a Raspberry Pi 4. Currently I'm running dracut 053-1.fc34, kernel 5.11.11-300.fc34 and systemd 248-1.fc34.

FWIW: F34 Beta shipped with Dracut 0.51 (see https://github.com/dracutdevs/dracut/releases) and a 5.11.10 kernel. The initrd.img built by this version of Dracut lacked most MDIO drivers, needed by Raspberry Pi among others, due to a driver location change in kernel 5.10. As noted in https://bugzilla.redhat.com/show_bug.cgi?id=1943983, this was fixed in https://github.com/dracutdevs/dracut/commit/3c8ca29 (shipped in Dracut 0.52 and 0.53). Dracut 0.53 went stable in F34 about a day ago.

User Icon storm commented & provided feedback 4 years ago
karma

I suspect i hit https://github.com/dracutdevs/dracut/commit/7fcc4955884355c3943d6c41e459b4b983a818f4, so it was dracut shenanigans.

This update has been pushed to stable.

4 years ago
User Icon antiv commented & provided feedback 4 years ago

After update kernel to 5.11.11-300 boot stuck at start job is running for /dev/mapper/fedora_localhost--live-swap and start job is running for /dev/mapper/fedora_localhost--live-root

5.11.10-300 works fine.

  • OS: Fedora release 34 (Thirty Four) x86_64
  • Host: 80NV Lenovo ideapad Y700-15ISK
  • Resolution: 1920x1080
  • DE: GNOME 40.0
  • CPU: Intel i7-6700HQ (8) @ 3.500GHz
  • GPU: Intel HD Graphics 530
  • GPU: NVIDIA GeForce GTX 960M
  • Memory: 15200MiB / 31933MiB
User Icon kalvinist commented & provided feedback 4 years ago

I'm experiencing the same issue as antiv; backing out to 5.11.10-300 is also a viable workaround for me. The only salient detail for my device is that I'm using full-disk encryption.

$ sudo lsblk
[sudo] password for kalvin:
NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
zram0                                         252:0    0     8G  0 disk  [SWAP]
nvme0n1                                       259:0    0 931.5G  0 disk
├─nvme0n1p1                                   259:1    0   600M  0 part  /boot/efi
├─nvme0n1p2                                   259:2    0     1G  0 part  /boot
└─nvme0n1p3                                   259:3    0 929.9G  0 part
  └─luks-c154495b-f916-49bb-8226-8236686cb807 253:0    0 929.9G  0 crypt
    ├─fedora_localhost--live-root             253:1    0    70G  0 lvm   /
    ├─fedora_localhost--live-swap             253:2    0  10.8G  0 lvm   [SWAP]
    └─fedora_localhost--live-home             253:3    0 849.1G  0 lvm   /home
User Icon okay_awright commented & provided feedback 4 years ago
karma

same symptom as @antiv and @kalvinist; as already mentioned above, reverting to a previous kernel bypassed the problem.

[551199861@cthugha ~]$ sudo lsblk
[sudo] Mot de passe de 551199861 : 
NAME                            MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda                               8:0    0 931,5G  0 disk 
└─sda1                            8:1    0 931,5G  0 part /home
sdb                               8:16   0 111,8G  0 disk 
├─sdb1                            8:17   0   200M  0 part /boot/efi
├─sdb2                            8:18   0 111,1G  0 part 
│ ├─fedora_localhost--live-root 253:0    0  91,1G  0 lvm  /
│ └─fedora_localhost--live-swap 253:1    0    20G  0 lvm  [SWAP]
└─sdb3                            8:19   0   513M  0 part /boot
zram0                           252:0    0     8G  0 disk [SWAP]
User Icon throwaway commented & provided feedback 4 years ago

@antiv, @kalvinist, @okay_awright What does the following commands output?

lsinitrd /boot/initramfs-5.11.10-300.*.img |egrep '^(Image|Version|Arguments)'
lsinitrd /boot/initramfs-5.11.11-300.*.img |egrep '^(Image|Version|Arguments)'
User Icon okay_awright commented & provided feedback 4 years ago

@throwaway here are the results (I didn't install 5.11.10):

[551199861@cthugha ~]$ sudo lsinitrd /boot/initramfs-5.11.11-300.*.img |egrep '^(Image|Version|Arguments)'
Image: /boot/initramfs-5.11.11-300.fc34.x86_64.img: 34M
Version: dracut-053-1.fc34
Arguments:  -f
[551199861@cthugha ~]$ sudo lsinitrd /boot/initramfs-5.11.9-300.*.img |egrep '^(Image|Version|Arguments)'
Image: /boot/initramfs-5.11.9-300.fc34.x86_64.img: 34M
Version: dracut-051-1.fc34.1
Arguments: -f
User Icon throwaway commented & provided feedback 4 years ago

@okay_awright: thanks!

There are reports of Dracut 0.53 possibly breaking the initramfs in bugzilla:

User Icon kalvinist commented & provided feedback 4 years ago

Similar results to @okay_awright:

$ sudo lsinitrd /boot/initramfs-5.11.10-300.*.img |egrep '^(Image|Version|Arguments)'
Image: /boot/initramfs-5.11.10-300.fc34.x86_64.img: 42M
Version: dracut-051-1.fc34.1
Arguments: -f
[j39m@flaglock6 ~/Downloads/tmp]
$ sudo lsinitrd /boot/initramfs-5.11.11-300.*.img |egrep '^(Image|Version|Arguments)'
Image: /boot/initramfs-5.11.11-300.fc34.x86_64.img: 42M
Version: dracut-053-1.fc34
Arguments:  -f

@throwaway, thanks for the bug reports.

User Icon antiv commented & provided feedback 4 years ago

Similar results:

~ sudo lsinitrd /boot/initramfs-5.11.10-300.*.img |egrep '^(Image|Version|Arguments)'
Image: /boot/initramfs-5.11.10-300.fc34.x86_64.img: 34M
Version: dracut-051-1.fc34.1
Arguments: -f
~ sudo lsinitrd /boot/initramfs-5.11.11-300.*.img |egrep '^(Image|Version|Arguments)'
Image: /boot/initramfs-5.11.11-300.fc34.x86_64.img: 35M
Version: dracut-053-1.fc34
Arguments:  -f

Please log in to add feedback.

Metadata
Type
security
Severity
medium
Karma
7
Signed
Content Type
RPM
Test Gating
Autopush Settings
Unstable by Karma
-3
Stable by Karma
disabled
Stable by Time
disabled
Dates
submitted
4 years ago
in testing
4 years ago
in stable
4 years ago
modified
4 years ago
Builds
3
kernel-5.11.11-300.fc34
kernel-headers-5.11.11-300.fc34
kernel-tools-5.11.11-300.fc34
BZ#1945345 CVE-2021-29646 kernel: improper input validation in tipc_nl_retrieve_key function in net/tipc/node.c
0
0
BZ#1945346 CVE-2021-29646 kernel: improper input validation in tipc_nl_retrieve_key function in net/tipc/node.c [fedora-all]
0
0
BZ#1945361 CVE-2021-29647 kernel: information disclosure due to uninitialized data structure in qrtr_recvmsg function in net/qrtr/qrtr.c
0
0
BZ#1945362 CVE-2021-29647 kernel: information disclosure due to uninitialized data structure in qrtr_recvmsg function in net/qrtr/qrtr.c [fedora-all]
0
0
BZ#1945373 CVE-2021-29648 kernel: DoS due to BPF subsystem does not properly consider that resolved_ids and resolved_sizes are intentionally uninitialized in the vmlinux BPF
0
0
BZ#1945374 CVE-2021-29648 kernel: DoS due to BPF subsystem does not properly consider that resolved_ids and resolved_sizes are intentionally uninitialized in the vmlinux BPF [fedora-all]
0
0
BZ#1945379 CVE-2021-29649 kernel: memory leak in user mode driver due to lack of cleanup steps in kernel/usermode_driver.c and kernel/bpf/preload/bpf_preload_kern.c
0
0
BZ#1945384 CVE-2021-29649 kernel: memory leak in user mode driver due to lack of cleanup steps in kernel/usermode_driver.c and kernel/bpf/preload/bpf_preload_kern.c [fedora-all]
0
0
BZ#1945388 CVE-2021-29650 kernel: lack a full memory barrier upon the assignment of a new table value in net/netfilter/x_tables.c and include/linux/netfilter/x_tables.h may lead to DoS
0
0
BZ#1945389 CVE-2021-29650 kernel: lack a full memory barrier upon the assignment of a new table value in net/netfilter/x_tables.c and include/linux/netfilter/x_tables.h may lead to DoS [fedora-all]
0
0
kernel-5.11.11-300.fc34
kernel-headers-5.11.11-300.fc34
kernel-tools-5.11.11-300.fc34

Automated Test Results

Test Cases
0 4 Test Case kernel regression

Copyright © 2007-2025 Red Hat, Inc. and others.

Running bodhi-server 25.5.1 on bodhi-web-2-cmh9v.

bodhi is Free Software. Please file issues if you have any problems. Read the documentation.

• Composes • Legal • Privacy policy •